incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: [discussion] Harmony podling to ask for vote for graduation
Date Wed, 18 Oct 2006 13:22:58 GMT
On Tuesday October 17 2006 10:33 pm, Geir Magnusson Jr wrote:
> Roy T. Fielding wrote:
> > The early rule did not work, specifically for projects that intended
> > to graduate as a TLP.  There was insufficient experience left in one
> > group post-graduation to properly create an Apache release, so we
> > were criticized for having approved their graduation.
> >
> > How do we know that a group has learned the Apache way of doing
> > things if they have never voted on a release?  The single most
> > important action of a TLP should be learned by the committers before
> > they become a TLP.
>
> Are you looking for us to show that we can vote and deal with
> contention?  We've had that.
>
> I think we've had 20+ votes on various issues on the dev list, which
> mainly were formal records, because we try to always reach consensus.
> We've had to vote in lots of donations, and have had disagreements
> about contributions that were all peacefully resolved with full
> consensus in the end.
>
> >> This is a major project (at 1.3M lines of code and counting) with a
> >> clearly defined deliverable (compatible java SE 5), and we're not
> >> ready yet to release something.
> >
> > But are you ready to produce something that can be voted on?
> > Even if it is only a milestone package for developer use only?
>
> I'd prefer not to produce a new kind of artifact just for this purpose,
> but if this really is required, we can certainly hold a vote tomorrow
> about a new snapshot if that demonstrates something more than our
> history has demonstrated.
>
> Will that be sufficient?
>
> > It doesn't need to result in a released product -- it just needs
> > to make everyone in the project agree and understand how future
> > releases will be made.  Sometimes, shit can lay hidden until an
> > important decision needs to be made, such as who will RM and what
> > should be included.  It is better to let the shit hit the fan now
> > than to assume it will all work out later on.
>
> Ok.  Will you be satisfied with a vote on posting a snapshot?


The issue, as I see it, is that if you think the release process is 
just "vote and release,"  the podling has a problem and is not ready to 
graduate.   From what I've gathered talking to people, that was the 
problem that the graduating podlings exposed and the incubator is now 
trying to "correct" by asking the podling to demonstrate the process.     
What I think the IPMC wants to see is whether the podling knows and can 
perform the complete release process.

Here are the steps as I see them (I'm not an IPMC person or even an ASF 
member, one of them should definitely look at this and add/comment on it.   
This is all gathered from talking to people/mentors, watching projects do 
releases, reading vote threads on this list, etc....):

1) Select a Release Manager (RM) - the release manager should be a PPMC 
member.   They should (not required, but nice) also have a public key 
that has been signed by a "significant" number of other apache folks to 
establish a level of trust that the person is the person.    I assume you 
would volunteer for this in this case.

2) When concensus is reached that a release is ready, the RM prepares for 
the release - this includes adding the KEYS file to SVN, tracks what 
still has to get in,  checks JIRA to see if there are other known "legal" 
issues or other showstoppers that would prevent a release,  tagging it in 
SVN, etc....   The RM should also review "current decisions" of the 
Apache board/legal to see if anything has changed since the last release 
that requires action.   New notices, new license headers, etc....    
Note:  that was a concensus, not a vote.  That comes in step 4.

3) The RM does the build, signs the artifacts, uploads them to a public 
area (apache home directory for example) for the community to see.   By 
signing the artifacts, the RM is certifying that those are the artifacts 
that will be evaluated.

4) NOW the RM calls the vote in the project community - you are voting on 
the uploaded artifacts.   Those artifacts are what are being released.   
The community should download the artifacts, validate the signatures, 
make sure they work, etc...

5) Podlings: If the vote passes, then call the vote on this list.   The 
vote email should point at both the artifacts as well as the SVN tag so 
the IPMC can check to make things are all OK.

6) If all votes pass, THEN "release" the artifacts copying them to the 
final release location.    I THINK (IPMC please clarify) the RM has some 
discretion on this.   On one project I worked on, the vote did "pass" 
(got the required +1 votes), but the release manager decided to withdraw 
the vote as there were "too many" +0 votes that reflected a lack of 
understanding that he felt needed to be clarified before a full release 
was done.     In your case, since you wouldn't actually be releasing, 
your just demonstrating the process, you would do the same.   

Anyway, the incubator PMC is concerned about podlings not understanding 
the whole process.  (I think, I'm not an IPMC member so I really cannot 
speak for them.)  Certain projects (even TLP projects, I'm not naming 
names here) have not been doing it correctly which is a concern.   The 
incubators job is to make sure the podlings know the processes before 
graduation.   It would be nice if the other Apache TLP's did it correctly 
to act as good examples, but the incubator doesn't really have control 
over the other projects. 

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message