0.2.0 release comments

[Joe Schaefer <jo...@yahoo.com>]

First off congratulations on a successful release!  I know
it's been a long time coming, and people worked hard to make
it reality.  Way to go.

The main thing to do at this point: let people know what you've done.
Fix the dowload page on the website so it points at the mirrored
release (and only the release), make an announcement email and send it to

  thrift-user@incubator.apache.org
  announce@incubator.apache.org
  announce@apache.org (why not?- be sure to use your apache address
                       in the From hdr)


Probably should include the incubator disclaimer in the message.

Some things to do for future releases: Todd should try to document
everything he has done and add that info to trunk/RELEASE so other
RM's know the process (and may be able to improve upon it).  People
who vote on a release should provide details on what went into their
vote, as a means of educating one another on the meaning of one's vote.
And decisions like whether to release from a branch or from trunk
should be made on the dev@ list.  It is important to keep in mind that
the dev@ list is where all project decisions (other than personnel
issues) need to be made.  If it didn't happen here, it didn't happen.

Best of luck in the future.  Once the download page is addressed I'll
be able to back off on the push to release, and ask that you continue
to educate your community that subversion is for development,
not end-user distribution (someone should tell the python maintainer
that you've got a release now, and to use that instead of svn, and maybe
mention to them that the version is 0.2.0 not 1.0).

Know that I've gotten to know some of you a bit, I would like to suggest
that sometime in early-mid January you start a discussion about your
graduation plans: if you wish to complete incubation, do you go TLP
or graduate into a subproject of Lucene or Hadoop?  I will continue reading
this list to see what you eventually decide to do, and answer any other
questions you may have about Apache policy (apparently I'm part of a
small minority of people on the IPMC that actually knows the rationale
behind things, so don't hesitate to ask here if there's something you
don't understand).


      

Re: 0.2.0 release comments

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Joe Schaefer <jo...@yahoo.com>
> To: thrift-dev@incubator.apache.org
> Sent: Sat, December 12, 2009 3:11:10 PM
> Subject: 0.2.0 release comments
> 
> First off congratulations on a successful release!  I know
> it's been a long time coming, and people worked hard to make
> it reality.  Way to go.
> 
> The main thing to do at this point: let people know what you've done.
> Fix the dowload page on the website so it points at the mirrored
> release (and only the release), make an announcement email and send it to

While Todd did not remove the stuff on the download page that points
at development-related artifacts, we agreed that adding some contextual
information steering users away from those items was sufficient to be
in alignment with ASF policy.

Since I can't seem to find any documentation where the rationale behind
release policy is explained, let me take a stab at explaining why it exists
and what it is intended to do.

When the Apache Group decided to incorporate, they wanted to create an
organization that reflected their own values on a consensus-based meritocracy,
and also to ensure that the legal risks associated with participation in
collaborative open source development could be managed.  The release policy
is an offshoot of those objectives, and is a major difference between projects
hosted at the ASF versus google code or sorceforge.  If a project follows the
policy, the organization will absorb the legal liability associated with the
wide-scale distribution of material that may infringe on copyrights or patents.
Places like google code or sourceforge OTOH will simply assert common-carrier
status and leave the project developers to defend themselves.

The reason to follow the policy is for your own protection.  The foundation
will offer you no defense for material that isn't distributed as part of a release.
That is why it is good to downplay the distribution of developer resources,
you want to ensure that people who receive those resources do so to help further
the project's aims towards a release, not as a means of receiving the latest
and greatest version of the code.

Now I can understand that legal issues aren't the world's greatest motivator
for someone in their early 20s with not a lot of personal assets to lose in a
suit, but by the time you have a house, a car, and a family of your own the
legal umbrella of the ASF will mean more to you, particularly if you decide
to get more involved in the ASF than as just another committer on a project.

Thrift is not the only project that has failed to stay compliant with Apache
release policy.   Ofbiz is another one- to see what they have done look at
their download link off http://ofbiz.apache.org/ .  The sad part about ofbiz
is that they cut a proper release as part of their graduation requirements,
but once they graduated they chose another non-compliant method of end-user
distribution.  Eventually someone from infrastructure will contact them too,
and ask that they return to compliance with the release policy.  We will probably
get some flak back from them in the early-going, that it's not infra's place
to tell them how to do release management.  If they're smart, they will eventually
wise up and realize that we are doing them a favor, because the ASF won't defend
what they're currently doing.