You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Bozhong Lin <bl...@iona.com> on 2006/09/27 12:30:58 UTC
what are required for contributing to release management
Hi,
As I previously posted email on cxf-dev, I am very keen in contributing
to CeltiXfire release management and other project management related
stuff. From the Apache release process document [1], I am not sure what
qualification/requirements it takes to get the release management job done:
1. Does it require SVN commit right? I don't have CXF commit right yet
(working toward it :-), would this be a problem?
2. Does it require some one to be on PPMC?
3. Signing release. According to my knowledge, ASF needs to meet
in-person whoever will be signing release. I am willing to make the trip
meet ASF person in US.
I hope I can contribute to CeltiXfire release management without commit
access and without being on PPMC. If for some reason that I am not
qualified to contribute fully, then I will try to contribute as much as
possible.
Regards,
Bo
[1] http://www.apache.org/dev/#releases
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/28/06, robert burrell donkin <ro...@gmail.com> wrote:
> On 9/28/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> > Garrett Rooney wrote:
>
> <snip>
>
> > > PPMCs are formed for an incubating project, and exactly how
> > > that works tends to differ a bit between projects. Some mentors start
> > > off with just the mentors on the PPMC, and then invite project members
> > > as time goes on (or that's the impression I've gotten). Others just
> > > start with the whole group of committers plus the mentors on the PPMC
> > > (that's what we did with Abdera).
> > >
> > Well that explains my utter confusion. Thanks for the clarification. So
> > this is up to the mentors to decide then?
>
> i think so (hopefully someone will jump in with a correction if i have
> this wrong)
>
> it would probably be a good idea to record any election as a VOTE of
> the mentors on the private list
Makes sense to me.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/28/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> Garrett Rooney wrote:
<snip>
> > PPMCs are formed for an incubating project, and exactly how
> > that works tends to differ a bit between projects. Some mentors start
> > off with just the mentors on the PPMC, and then invite project members
> > as time goes on (or that's the impression I've gotten). Others just
> > start with the whole group of committers plus the mentors on the PPMC
> > (that's what we did with Abdera).
> >
> Well that explains my utter confusion. Thanks for the clarification. So
> this is up to the mentors to decide then?
i think so (hopefully someone will jump in with a correction if i have
this wrong)
it would probably be a good idea to record any election as a VOTE of
the mentors on the private list
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release
management]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Garrett Rooney wrote:
> On 9/28/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> robert burrell donkin wrote:
>> > thinking about whether there's a need to wait to release until the
>> > PPMC is fully formed and representation of the podling committers.
>> >
>> > PPMCs are typically filled up relatively late in the process - towards
>> > graduation. (whether this is a good idea, i'm not sure.) if there are
>> > just mentors on the PPMC then i see no benefit in waiting until the
>> > PPMC is composed of a representation cross-section of committers
>> > before creating a release.
>> >
>> > - robert
>> Hiya,
>>
>> Pardon my ignorance here, but can you elaborate or point me to docs on
>> how exactly the PMCs are formed? I know that the mentors from a project
>> are on it, but as for the rest of the committers I have heard
>> conflicting things. I have heard that you need to be voted on and I have
>> also heard that the all of initial committers ends up on the PPMC.
>> Obviously it can't be both and I can't find any real docs on it
>> (http://incubator.apache.org/guides/ppmc.html is silent) either.
>
> Well, PMCs are formed by the board when a project moves to top level
> status.
Sorry for the confusion - I meant to say PPMC, not PMC in my message.
> PPMCs are formed for an incubating project, and exactly how
> that works tends to differ a bit between projects. Some mentors start
> off with just the mentors on the PPMC, and then invite project members
> as time goes on (or that's the impression I've gotten). Others just
> start with the whole group of committers plus the mentors on the PPMC
> (that's what we did with Abdera).
>
Well that explains my utter confusion. Thanks for the clarification. So
this is up to the mentors to decide then?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: PPMCs [was Re: what are required for contributing to release management]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dan Diephouse wrote:
> I assume you're referring to this sentence:
> "Initially, it is composed of the Podling's mentors and initial
committers."
> I have also found some threads which indicate that all committers should
> be added [1][2]. I want to know here - who is wrong? The documentation?
Neither. Both. I'm probably the one who is quoted in that documentation.
And the idea of the PPMC and Incubator oversight has evolved. Taken at face
value, the sentence says that the PPMC is bootstrapped from the PMC members
acting as Mentors and the initial people involved in the project. At the
time, it probably made sense, since we had few problems with the initial
commit lists. Then things started to change, with accusations both of
piling on and exclusionary behavior.
At the moment, there is a proposal being mooted to remove the list of
initial committers from the proposal (there would be a list of interested
participants), and have the whole thing bootstrapped by the Mentors after
the PMC has voted to accept.
> "The PPMC is directly responsible for the oversight of the podling and
> it also decides who to add as a PPMC member."
That is correct.
> I am pretty philosophically against making every committer PPMC members.
Personally, I agree, but there are benefits to biasing the process towards
making people PPMC members in short course. I'd have a lower bar on that
than on a PMC member, since only PMC members have binding votes, anyway.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 1, 2006, at 11:36 AM, Dan Diephouse wrote:
>
> I assume you're referring to this sentence:
>
> "Initially, it is composed of the Podling's mentors and initial
> committers."
>
> I have also found some threads which indicate that all committers
> should be added [1][2].<opinion>
> I am pretty philosophically against making every committer PPMC
> members.
Who is advocating that?? certainly not I. I'm just stating that
the initial list of committers are likely those most active
in the community of that code and are good candidates for
initial PPMC membership. In fact, I would guess that they
are better judges than Mentors.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/1/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> For example, if I were to work on a project for many months at Google Code
> and then propose it to come here, why shouldn't I continue to have a say in
> what the project does? Why do I need to justify myself all over again? Why
> aren't my past contributions enough to merit a seat on the PPMC? What gives
> the mentors the power to 'reset' the community and block me from
> participating until I jump through their vague and ill-defined hoops?
Personally, I think the bar on commit to incoming projects should be
simple, if you've made a contribution (code, docs, whatever) that's
significant enough that it would justify commit access here, you
should get it. For projects that are coming from the open source
world, that just means "If you've got commit on it before it's at the
ASF, you still do when it moves to the ASF", if it's corporate then
obviously some due diligence needs to be done, but I think that's
probably important in order to prevent the problem of providing a
backdoor that avoids the whole meritocracy thing.
Specifically though, I'd like to be clear that I don't think you
should have to be an active participant in the project at the time it
moves to the ASF in order to get commit/PPMC membership. As long as
you're paying attention enough to sign the paperwork, the fact that
you at one point qualified for this sort of access should be enough
IMO. I know personally, when I have earned commit access to a project
I expect that to still be there in the future, even if I fall off the
planet for a while and don't have time to work on it. If the project
had moved to the ASF in the meantime and all of a sudden I had to
fight my way back to the same level of access I had in the past, I'd
be pissed.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Daniel Kulp <da...@kulp.com>.
Let me see if I can summarize some of the issues as I see them...
Currently, new podlings come from one of three sources:
1) Closed source code (usually from and external company) that is useful and
thus would like to be made open source. (tuscany, yoko, etc...)
2) One (or more) open source communities wanting to move their project to
Apache. (CXF, Wicket, etc...)
3) Completely ground up, no code yet exists, ideas to be complete built in
apache.
All three have a different set of initial concerns that I think we all need to
think about. I don't know enough about the 3rd case so I cannot comment on
it. Does that even happen? Or is it mostly some code exists somewhere?
For case (2) - there are public communities that exist with commiters,
effective PMC's, etc... We should definitely leverage those and move those
lists along with the code whenever possible. However, the thing that I've
seen recently is during the proposals a LOT more people are added onto the
initial commiter list than have earned commit access in the other community.
To me, that is the the problem. If they didn't earn it there, why should we
give it to them "for free"? Thus, for (2), I would suggest just commiters
from the external project(s) and no others for the initial bootstrap list.
I'd like to see something mentioned about "inactive commiters" from the other
projects, but the PPMC could deal with that in incubation or upon graduation.
One thought would be to ask each of the commiters on those projects if they
want to be commiters on the new one at apache. If yes, then add them. If
they say no, no harm done. Some people may actually prefer not to be
apache commiters. Taking the CXF proposal for example (I was involved with
this one so I'm just as guilty as anyone here): of the 34 proposed initial
commiters, I think 8-10 of them had not been commiters at either Celtix or
XFire. Another 5 or 6 or so would be in the "inactive" category.
For case (1), there doesn't exist a community already except for within a
single company. If we just go with "those who have worked on the code" as
initial commiters, they'd all be from one company. (not that I'm saying
that's bad for a start in the incubator. I'm actually 100% OK with that.
To me, that's a good thing.) However, going the other way of throwing on 20+
commiters that have yet to even see the code is probably not good. Again,
to me, that's giving out karma like it's candy. Anyone who asks during the
proposal phase gets it without any other criteria. Unfortunately, lately,
it seems like there are more of the later case of throwing on people that
express any interest. Personally, IMO, I'd like the initial commit list to
be ONLY those who have seen the code, and in the incubator, they can
completely build their community. I COULD see adding other "industry
experts" (example: if the project is implementing a spec, having some of the
spec reps on the project might be OK to help direct it), but even then, I
don't see the downside of having them earn it.
Anyway, I'm not sure of the "right" approach for dealing with (1). I would
say that in all three cases, the incubator PMC needs to do a better job of
reviewing the commiter lists before the vote.
Basically, I'd like to know:
1) Why are projects being submitted with 20-40 initial commiters? Most of
the successful projects in apache don't have that many. The barrier to
getting accepted at apache is supposed to be very low. To me, 3-5 commiters
should be more than adequate. One the PPMC is setup, they can quickly and
easily "grow" their community. That's not a problem. It's easier, and
certainly produces less arguments, to grow a community than to remove people
that don't belong.
2) What's the downside of having people in the incubator projects actually
earn the commit rights instead of giving it freely? If normal apache
projects grow their community through contributions, why shouldn't a podling
try and act like a normal apache project? The "recent trend" of giving
everyone commit access immediately, to me, has more downsides. It doesn't
follow the apache meritorious processes and it can also cause the community
to fracture if corrective action is taken. I really don't like the "PPMC
can correct it in incubation" idea. From this whole thread, you can see
that the major effect this has is to splinter the community, causes heated
discussions, pisses people off, etc.... If a project/podling can start
off on the right foot, there would be a much better experience.
Of course, I'm not an incubator PMC member so my opinion definitely doesn't
bind to a vote and I don't have the years of experience and expertise, this
is just based on my (limited) experience so far.
Enjoy!
Dan
On Monday October 02 2006 8:42 am, Jim Jagielski wrote:
> On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote:
> > On 10/1/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> >> would however encourage only voting people in after they an
> >> appropriate
> >> level of committment and involvement with the project.
> >
> > This creates a dividing line by omitting past contributions from the
> > discussion which I feel is inappropriate.
> >
> > For example, if I were to work on a project for many months at
> > Google Code
> > and then propose it to come here, why shouldn't I continue to have
> > a say in
> > what the project does? Why do I need to justify myself all over
> > again? Why
> > aren't my past contributions enough to merit a seat on the PPMC?
> > What gives
> > the mentors the power to 'reset' the community and block me from
> > participating until I jump through their vague and ill-defined
> > hoops? --
> > justin
>
> ++1. If the problem is "piling on" in the committer list
> for the proposal *then that should be addressed at the
> proposal timeframe and before the podling is accepted*!
>
> As mentioned in a different Email, I'm +1 on adding
> in, in the proposal: Mentors | Initial PPMC | Initial
> Committers if people want it explicit, but no matter
> what, this should be handled before podlings are
> accepted, not after.
>
> I think that issue is that some Mentors have different
> feelings from what is documented... Recall, after all,
> that people from the outside ONLY have access to
> what is documented, not our internal discussions...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
Daniel Kulp
dan@kulp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote:
> On 10/1/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>>
>> would however encourage only voting people in after they an
>> appropriate
>> level of committment and involvement with the project.
>
>
> This creates a dividing line by omitting past contributions from the
> discussion which I feel is inappropriate.
>
> For example, if I were to work on a project for many months at
> Google Code
> and then propose it to come here, why shouldn't I continue to have
> a say in
> what the project does? Why do I need to justify myself all over
> again? Why
> aren't my past contributions enough to merit a seat on the PPMC?
> What gives
> the mentors the power to 'reset' the community and block me from
> participating until I jump through their vague and ill-defined
> hoops? --
> justin
++1. If the problem is "piling on" in the committer list
for the proposal *then that should be addressed at the
proposal timeframe and before the podling is accepted*!
As mentioned in a different Email, I'm +1 on adding
in, in the proposal: Mentors | Initial PPMC | Initial
Committers if people want it explicit, but no matter
what, this should be handled before podlings are
accepted, not after.
I think that issue is that some Mentors have different
feelings from what is documented... Recall, after all,
that people from the outside ONLY have access to
what is documented, not our internal discussions...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/1/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> would however encourage only voting people in after they an appropriate
> level of committment and involvement with the project.
This creates a dividing line by omitting past contributions from the
discussion which I feel is inappropriate.
For example, if I were to work on a project for many months at Google Code
and then propose it to come here, why shouldn't I continue to have a say in
what the project does? Why do I need to justify myself all over again? Why
aren't my past contributions enough to merit a seat on the PPMC? What gives
the mentors the power to 'reset' the community and block me from
participating until I jump through their vague and ill-defined hoops? --
justin
Re: PPMCs [was Re: what are required for contributing to release
management]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Dan Diephouse wrote:
> Noel J. Bergman wrote:
>
>> Justin Erenkrantz wrote:
>>
>>
>>> Noel J. Bergman <no...@devtech.com> wrote:
>>>
>>>
>>>>>> I am pretty philosophically against making every committer PPMC
>>>>>>
>>>>>>
>>>>>>> members.
>>>>>>>
>>>>>>
>>>>> I don't agree at all. If they contribute code, they merit a say in
>>>>>
>>>>
>> the
>>
>>
>>>>> direction of the project.
>>>>>
>>>>
>>>> Are you reading Dan's statement as independent or dependent upon time?
>>>>
>>>
>> I
>>
>>
>>>> read it as an objection to mandated concurrency. Over time, your view
>>>> should be the dominant one, as each Committer becomes a (P)PMC member.
>>>>
>>>
>>> as for the one line that you retained: I view Dan's perspective as
>>> being independent of time - that is, committers should never equal
>>> the PMC - I view that as extremely unhealthy.
>>>
>>
>>
>> If I had read it as you do, I would agree with you. I read it as
>> suggestive
>> of a process over time, and that at any snapshot in time, the body of
>> Committers might not be entirely present in the PPMC.
>>
>>
> I did in fact mean it as dependent on time. And specifically I meant
> at the beginning of incubation. I don't think every committer should
> be on the PPMC from the outset. Every committer may be on the PPMC at
> graduation, and this is encouraged, but only after they are explicitly
> voted on by the existing PPMC members. Now the PPMC may just chose to
> vote on specific individuals or everyone at once, its up to them. I
> would however encourage only voting people in after they an
> appropriate level of committment and involvement with the project.
>
One reason I feel this way is that I think protect's Apache's interests.
Lets say that hypothetically, more people are put on a proposal than
should be. If the PPMC members are elected after showing their
committment to the long term health of the project, as opposed to all
committers being added at the outset of the project, I believe this
gives a better chance for correction. If I end up on the CXF (P)PMC I
have every intention of starting a vote which removes any committers who
have not contributed anything during incubation or significantly in the
past. I hope I don't have to do that, but it doesn't seem fair that
they would graduate as part of the project and have as much say as those
who have shown their committment. If someone wants to get involved
later, they can always contribute and get voted back in. I think this
gives people a slightly lower barrier to get involved, which seems
befitting to incubation and starting of a project, but also provides
corrective measures in case there are problems.
Cheers,
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release
management]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Noel J. Bergman wrote:
>Justin Erenkrantz wrote:
>
>
>>Noel J. Bergman <no...@devtech.com> wrote:
>>
>>
>>>>>I am pretty philosophically against making every committer PPMC
>>>>>
>>>>>
>>>>>>members.
>>>>>>
>>>>>>
>>>>I don't agree at all. If they contribute code, they merit a say in
>>>>
>>>>
>the
>
>
>>>>direction of the project.
>>>>
>>>>
>>>Are you reading Dan's statement as independent or dependent upon time?
>>>
>>>
>I
>
>
>>>read it as an objection to mandated concurrency. Over time, your view
>>>should be the dominant one, as each Committer becomes a (P)PMC member.
>>>
>>>
>>as for the one line that you retained: I view Dan's perspective as
>>being independent of time - that is, committers should never equal
>>the PMC - I view that as extremely unhealthy.
>>
>>
>
>If I had read it as you do, I would agree with you. I read it as suggestive
>of a process over time, and that at any snapshot in time, the body of
>Committers might not be entirely present in the PPMC.
>
>
I did in fact mean it as dependent on time. And specifically I meant at
the beginning of incubation. I don't think every committer should be on
the PPMC from the outset. Every committer may be on the PPMC at
graduation, and this is encouraged, but only after they are explicitly
voted on by the existing PPMC members. Now the PPMC may just chose to
vote on specific individuals or everyone at once, its up to them. I
would however encourage only voting people in after they an appropriate
level of committment and involvement with the project.
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: PPMCs [was Re: what are required for contributing to release management]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> Noel J. Bergman <no...@devtech.com> wrote:
> > > > I am pretty philosophically against making every committer PPMC
> > > > > members.
> > > I don't agree at all. If they contribute code, they merit a say in
the
> > > direction of the project.
> > Are you reading Dan's statement as independent or dependent upon time?
I
> > read it as an objection to mandated concurrency. Over time, your view
> > should be the dominant one, as each Committer becomes a (P)PMC member.
> as for the one line that you retained: I view Dan's perspective as
> being independent of time - that is, committers should never equal
> the PMC - I view that as extremely unhealthy.
If I had read it as you do, I would agree with you. I read it as suggestive
of a process over time, and that at any snapshot in time, the body of
Committers might not be entirely present in the PPMC.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/1/06, Noel J. Bergman <no...@devtech.com> wrote:
>
> > > I am pretty philosophically against making every committer PPMC
> members.
>
> > I don't agree at all. If they contribute code, they merit a say in the
> > direction of the project. To do otherwise is to exclude them from the
> > community. Remember that only folks on the PPMC have a vote: a
> committer
> > does not have any say or vote in the project at all.
>
> Are you reading Dan's statement as independent or dependent upon time? I
> read it as an objection to mandated concurrency. Over time, your view
> should be the dominant one, as each Committer becomes a (P)PMC member.
My comment was in reply to the entirety of Dan's comment (which you
snipped).
But, as for the one line that you retained: I view Dan's perspective as
being independent of time - that is, committers should never equal the PMC -
I view that as extremely unhealthy. Placing qualities besides what they
contribute as qualifications to PMC status is to miss the point - if you
contribute to the project, you get a vote. -- justin
RE: PPMCs [was Re: what are required for contributing to release management]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> Dan Diephouse wrote:
> > I am pretty philosophically against making every committer PPMC members.
> I don't agree at all. If they contribute code, they merit a say in the
> direction of the project. To do otherwise is to exclude them from the
> community. Remember that only folks on the PPMC have a vote: a committer
> does not have any say or vote in the project at all.
Are you reading Dan's statement as independent or dependent upon time? I
read it as an objection to mandated concurrency. Over time, your view
should be the dominant one, as each Committer becomes a (P)PMC member.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/1/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> I am pretty philosophically against making every committer PPMC members.
> Apache is meritocracy based and IMO it makes much more sense to start
> with the mentors on the PPMC and have committers voted on based on their
> leadership. There may be many people on the incubation proposal or who
> have committed code to a project in the past, but an additional level of
> leadership is needed [3]. Not everyone may have the necessary leadership
> skills, and to presuppose they do because they have contributed good
> code, is IMO, a mistake.
I don't agree at all. If they contribute code, they merit a say in the
direction of the project. To do otherwise is to exclude them from the
community. Remember that only folks on the PPMC have a vote: a committer
does not have any say or vote in the project at all.
The critical aim of the PPMC is to create a self-managing project. By
excluding everyone from that process except for mentors, you will not be
teaching the new people how the project should be managed.
In the early days of the podlngs, the mentors should have proportionally
more say in how things proceed; but in order to graduate to TLP status, the
PPMC must be able to demonstrate the ability to manage itself - and probably
the contributions from the mentors should be excluded from that
determination - i.e. is the PPMC without the mentor able to govern itself.
-- justin
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Steve Vinoski <vi...@iona.com>.
+1 to Dan's opinion.
--steve
On Oct 1, 2006, at 11:36 AM, Dan Diephouse wrote:
> Hi Jim,
>
> Jim Jagielski wrote:
>
>>
>> On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote:
>>
>>>
>>> On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote:
>>>
>>>>
>>>> Well, PMCs are formed by the board when a project moves to top
>>>> level
>>>> status. PPMCs are formed for an incubating project, and exactly
>>>> how
>>>> that works tends to differ a bit between projects. Some
>>>> mentors start
>>>> off with just the mentors on the PPMC, and then invite project
>>>> members
>>>> as time goes on (or that's the impression I've gotten). Others
>>>> just
>>>> start with the whole group of committers plus the mentors on the
>>>> PPMC
>>>> (that's what we did with Abdera).
>>>>
>>>
>>> I think starting with the mentors is the wisest choice as at
>>> that point any committers can be brought aboard if deemed fit.
>>> So that can support both models as all committers can be brought
>>> aboard if it fits, or over time if more suitable. I was also
>>> confused about this as I heard one thing from Noel and one thing
>>> from Jim, but the mentors deciding seems sensible as projects
>>> can be dealt with on a case by case basis. I don't believe
>>> committers should automatically be made (P)PMC members as to me
>>> it's a different level of understanding and commitment.
>>>
>>
>> http://incubator.apache.org/guides/ppmc.html
>
> I assume you're referring to this sentence:
>
> "Initially, it is composed of the Podling's mentors and initial
> committers."
>
> I have also found some threads which indicate that all committers
> should be added [1][2]. I want to know here - who is wrong? The
> documentation? Or the previous incubated projects who didn't add
> all the initial committers? There is also the following sentence
> which adds some doubt that the above is the official policy:
>
> "The PPMC is directly responsible for the oversight of the podling
> and it also decides who to add as a PPMC member."
>
> While this could be referrering to post PPMC formation, it isn't
> clear. I will happily make a patch for the documentation to make
> things more clear if there is consensus.
>
> <opinion>
> I am pretty philosophically against making every committer PPMC
> members. Apache is meritocracy based and IMO it makes much more
> sense to start with the mentors on the PPMC and have committers
> voted on based on their leadership. There may be many people on the
> incubation proposal or who have committed code to a project in the
> past, but an additional level of leadership is needed [3]. Not
> everyone may have the necessary leadership skills, and to
> presuppose they do because they have contributed good code, is IMO,
> a mistake.
> </opinion>
>
> Cheerz,
> - Dan
>
> 1. http://mail-archives.apache.org/mod_mbox/incubator-general/
> 200312.mbox/%3C3FD9F8C4.5090404@apache.org%3E
> 2. http://mail-archives.apache.org/mod_mbox/incubator-general/
> 200603.mbox/%3c44162B45.2090701@rowe-clan.net%3e
> 3. See Project Management Committee section here http://
> www.apache.org/foundation/how-it-works.html#structure
>
> --
> Dan Diephouse
> (616) 971-2053
> Envoi Solutions LLC
> http://netzooid.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release
management]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Jim,
Jim Jagielski wrote:
>
> On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote:
>
>>
>> On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote:
>>
>>>
>>> Well, PMCs are formed by the board when a project moves to top level
>>> status. PPMCs are formed for an incubating project, and exactly how
>>> that works tends to differ a bit between projects. Some mentors start
>>> off with just the mentors on the PPMC, and then invite project members
>>> as time goes on (or that's the impression I've gotten). Others just
>>> start with the whole group of committers plus the mentors on the PPMC
>>> (that's what we did with Abdera).
>>>
>>
>> I think starting with the mentors is the wisest choice as at that
>> point any committers can be brought aboard if deemed fit. So that
>> can support both models as all committers can be brought aboard if
>> it fits, or over time if more suitable. I was also confused about
>> this as I heard one thing from Noel and one thing from Jim, but the
>> mentors deciding seems sensible as projects can be dealt with on a
>> case by case basis. I don't believe committers should automatically
>> be made (P)PMC members as to me it's a different level of
>> understanding and commitment.
>>
>
> http://incubator.apache.org/guides/ppmc.html
I assume you're referring to this sentence:
"Initially, it is composed of the Podling's mentors and initial committers."
I have also found some threads which indicate that all committers should
be added [1][2]. I want to know here - who is wrong? The documentation?
Or the previous incubated projects who didn't add all the initial
committers? There is also the following sentence which adds some doubt
that the above is the official policy:
"The PPMC is directly responsible for the oversight of the podling and
it also decides who to add as a PPMC member."
While this could be referrering to post PPMC formation, it isn't clear.
I will happily make a patch for the documentation to make things more
clear if there is consensus.
<opinion>
I am pretty philosophically against making every committer PPMC members.
Apache is meritocracy based and IMO it makes much more sense to start
with the mentors on the PPMC and have committers voted on based on their
leadership. There may be many people on the incubation proposal or who
have committed code to a project in the past, but an additional level of
leadership is needed [3]. Not everyone may have the necessary leadership
skills, and to presuppose they do because they have contributed good
code, is IMO, a mistake.
</opinion>
Cheerz,
- Dan
1.
http://mail-archives.apache.org/mod_mbox/incubator-general/200312.mbox/%3C3FD9F8C4.5090404@apache.org%3E
2.
http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/%3c44162B45.2090701@rowe-clan.net%3e
3. See Project Management Committee section here
http://www.apache.org/foundation/how-it-works.html#structure
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote:
>
> On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote:
>
>>
>> Well, PMCs are formed by the board when a project moves to top level
>> status. PPMCs are formed for an incubating project, and exactly how
>> that works tends to differ a bit between projects. Some mentors
>> start
>> off with just the mentors on the PPMC, and then invite project
>> members
>> as time goes on (or that's the impression I've gotten). Others just
>> start with the whole group of committers plus the mentors on the PPMC
>> (that's what we did with Abdera).
>>
>
> I think starting with the mentors is the wisest choice as at that
> point any committers can be brought aboard if deemed fit. So that
> can support both models as all committers can be brought aboard if
> it fits, or over time if more suitable. I was also confused about
> this as I heard one thing from Noel and one thing from Jim, but the
> mentors deciding seems sensible as projects can be dealt with on a
> case by case basis. I don't believe committers should automatically
> be made (P)PMC members as to me it's a different level of
> understanding and commitment.
>
http://incubator.apache.org/guides/ppmc.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: PPMCs [was Re: what are required for contributing to release management]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason van Zyl wrote:
> I think starting with the mentors is the wisest choice as at that
> point any committers can be brought aboard if deemed fit.
My view of that should be quite clear by now. :-)
> I was also confused about this as I heard one thing from Noel and
> one thing from Jim
Can you elaborate so that we can clarify and make sure that we have a
consensus?
> the mentors deciding seems sensible as projects can be dealt with on a
> case by case basis.
Agreed. The Mentors are PMC members. And the rest of the PMC can be as
involved as any PMC member wants to be involved.
> I don't believe committers should automatically be made (P)PMC members
> as to me it's a different level of understanding and commitment.
Yes, although there are benefits to making people PPMC members as soon as
you feel that they can be trusted with confidentiality. After all, they do
NOT gain binding votes in the PPMC, since those are exclusively held by PMC
members.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote:
>
> Well, PMCs are formed by the board when a project moves to top level
> status. PPMCs are formed for an incubating project, and exactly how
> that works tends to differ a bit between projects. Some mentors start
> off with just the mentors on the PPMC, and then invite project members
> as time goes on (or that's the impression I've gotten). Others just
> start with the whole group of committers plus the mentors on the PPMC
> (that's what we did with Abdera).
>
I think starting with the mentors is the wisest choice as at that
point any committers can be brought aboard if deemed fit. So that can
support both models as all committers can be brought aboard if it
fits, or over time if more suitable. I was also confused about this
as I heard one thing from Noel and one thing from Jim, but the
mentors deciding seems sensible as projects can be dealt with on a
case by case basis. I don't believe committers should automatically
be made (P)PMC members as to me it's a different level of
understanding and commitment.
> -garrett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PPMCs [was Re: what are required for contributing to release management]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/28/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> robert burrell donkin wrote:
> > thinking about whether there's a need to wait to release until the
> > PPMC is fully formed and representation of the podling committers.
> >
> > PPMCs are typically filled up relatively late in the process - towards
> > graduation. (whether this is a good idea, i'm not sure.) if there are
> > just mentors on the PPMC then i see no benefit in waiting until the
> > PPMC is composed of a representation cross-section of committers
> > before creating a release.
> >
> > - robert
> Hiya,
>
> Pardon my ignorance here, but can you elaborate or point me to docs on
> how exactly the PMCs are formed? I know that the mentors from a project
> are on it, but as for the rest of the committers I have heard
> conflicting things. I have heard that you need to be voted on and I have
> also heard that the all of initial committers ends up on the PPMC.
> Obviously it can't be both and I can't find any real docs on it
> (http://incubator.apache.org/guides/ppmc.html is silent) either.
Well, PMCs are formed by the board when a project moves to top level
status. PPMCs are formed for an incubating project, and exactly how
that works tends to differ a bit between projects. Some mentors start
off with just the mentors on the PPMC, and then invite project members
as time goes on (or that's the impression I've gotten). Others just
start with the whole group of committers plus the mentors on the PPMC
(that's what we did with Abdera).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
PPMCs [was Re: what are required for contributing to release management]
Posted by Dan Diephouse <da...@envoisolutions.com>.
robert burrell donkin wrote:
> thinking about whether there's a need to wait to release until the
> PPMC is fully formed and representation of the podling committers.
>
> PPMCs are typically filled up relatively late in the process - towards
> graduation. (whether this is a good idea, i'm not sure.) if there are
> just mentors on the PPMC then i see no benefit in waiting until the
> PPMC is composed of a representation cross-section of committers
> before creating a release.
>
> - robert
Hiya,
Pardon my ignorance here, but can you elaborate or point me to docs on
how exactly the PMCs are formed? I know that the mentors from a project
are on it, but as for the rest of the committers I have heard
conflicting things. I have heard that you need to be voted on and I have
also heard that the all of initial committers ends up on the PPMC.
Obviously it can't be both and I can't find any real docs on it
(http://incubator.apache.org/guides/ppmc.html is silent) either.
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by Bozhong Lin <bl...@iona.com>.
Thanks to all for clarifications. I am clear about what I can help now.
Cheers,
Bo
robert burrell donkin wrote:
> On 9/27/06, Leo Simons <ma...@leosimons.com> wrote:
>> On Sep 27, 2006, at 3:10 PM, robert burrell donkin wrote:
>> <snips throughout/>
>> > it is very rare for a non-committer to act as release manager.
>>
>> Yeah, I can't really remember ever seeing that.
>
> i was involved with something reasonable similar a year or two ago.
> fortunately, the developer was good enough to be elected committer
> before they'd finished the (extensive) preparatory work required.
>
> <snip>
>
>> > however, a PPMC is a
>> > little different. the PPMC takes a while to bootstrap and it may make
>> > little sense to wait until it has.
>>
>> I suspect it *does* make sense to bootstrap a PPMC before that PPMC
>> votes on a release. If you're not bootstrapped you shouldn't be doing
>> anything else. Can't quite understand what you're thinking of here.
>
> thinking about whether there's a need to wait to release until the
> PPMC is fully formed and representation of the podling committers.
>
> PPMCs are typically filled up relatively late in the process - towards
> graduation. (whether this is a good idea, i'm not sure.) if there are
> just mentors on the PPMC then i see no benefit in waiting until the
> PPMC is composed of a representation cross-section of committers
> before creating a release.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/27/06, Leo Simons <ma...@leosimons.com> wrote:
> On Sep 27, 2006, at 3:10 PM, robert burrell donkin wrote:
> <snips throughout/>
> > it is very rare for a non-committer to act as release manager.
>
> Yeah, I can't really remember ever seeing that.
i was involved with something reasonable similar a year or two ago.
fortunately, the developer was good enough to be elected committer
before they'd finished the (extensive) preparatory work required.
<snip>
> > however, a PPMC is a
> > little different. the PPMC takes a while to bootstrap and it may make
> > little sense to wait until it has.
>
> I suspect it *does* make sense to bootstrap a PPMC before that PPMC
> votes on a release. If you're not bootstrapped you shouldn't be doing
> anything else. Can't quite understand what you're thinking of here.
thinking about whether there's a need to wait to release until the
PPMC is fully formed and representation of the podling committers.
PPMCs are typically filled up relatively late in the process - towards
graduation. (whether this is a good idea, i'm not sure.) if there are
just mentors on the PPMC then i see no benefit in waiting until the
PPMC is composed of a representation cross-section of committers
before creating a release.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by Leo Simons <ma...@leosimons.com>.
On Sep 27, 2006, at 3:10 PM, robert burrell donkin wrote:
<snips throughout/>
> it is very rare for a non-committer to act as release manager.
Yeah, I can't really remember ever seeing that. Of course, it happens
quite often that downstream repackagers aren't committers.
> if the CXF community really want you to manage the release, it would
> be possible to make it work.
I would think so.
>> > I hope I can contribute to CeltiXfire release management without
>> commit
>> > access and without being on PPMC. If for some reason that I am not
>> > qualified to contribute fully, then I will try to contribute as
>> much as
>> > possible.
>>
>> In my view, this is up to the PPMC for Celtixfire.
>
> +1
Yup. Its definitely possible to make useful contributions towards a
release without being on a (P)PMC or having karma.
> IMHO a PMC would need to consider why a person they trust to create a
> release is not trusted to make binding decisions.
+1
> however, a PPMC is a
> little different. the PPMC takes a while to bootstrap and it may make
> little sense to wait until it has.
I suspect it *does* make sense to bootstrap a PPMC before that PPMC
votes on a release. If you're not bootstrapped you shouldn't be doing
anything else. Can't quite understand what you're thinking of here.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by robert burrell donkin <ro...@gmail.com>.
On 9/27/06, Upayavira <uv...@odoko.co.uk> wrote:
> Bozhong Lin wrote:
> > Hi,
> >
> > As I previously posted email on cxf-dev, I am very keen in contributing
> > to CeltiXfire release management and other project management related
> > stuff. From the Apache release process document [1], I am not sure what
> > qualification/requirements it takes to get the release management job done:
we tend to talk about knowledge and karma rather than qualifications
and requirements. knowledge is much more important that karma. karma
can be granted by a project. knowledge takes energy to aquire.
release management at apache is an informal role. details are left to
the project to organise themselves. at it's most minimal, it's just
the name infrastructure folks give to the apache user who uploaded and
signed the release. so, the minimum requirement for this is project
karma.
creating a good apache release requires knowledge, energy and
organisation. most projects find that the release process works better
if they elect a release manager who knows (or is willing to learn) how
to create apache releases to organise and push the release forward.
there is no requirement that this role is filled by someone with the
karma required to execute the upload (the technical release manager)
though in the vast majority of cases it will be.
> > 1. Does it require SVN commit right? #
to perform the actual cut and upload, yes
to perform the social and organisational management side of a release
required to prepare a release not necessarily but typically. it is a
matter for the project but it is very rare for a non-committer to act
as release manager.
> > I don't have CXF commit right yet
> > (working toward it :-), would this be a problem?
depends on the attitiude of the project.
the preparation can be done through submitting patches for the
existing committers to apply. management is done on the mailing list.
if the CXF community really want you to manage the release, it would
be possible to make it work.
> > 2. Does it require some one to be on PPMC?
not necessarily but typically. it is easier to cut a release when on the PMC.
IMHO anyone who cuts a good release deserves to be on the PMC
> > 3. Signing release. According to my knowledge, ASF needs to meet
> > in-person whoever will be signing release. I am willing to make the trip
> > meet ASF person in US.
the only requirement is that a signature is created by the committer
who makes the upload. a good connection to the web of trust is
important and offers stronger security but is only strongly
encouraged.
> > I hope I can contribute to CeltiXfire release management without commit
> > access and without being on PPMC. If for some reason that I am not
> > qualified to contribute fully, then I will try to contribute as much as
> > possible.
>
> In my view, this is up to the PPMC for Celtixfire.
+1
> Basically, doing a release is the central responsibility of the PPMC,
> and they cannot delegate the decision to someone outside of itself. Nor
> can they delegate the work of signing the release (that to my mind
> wouldn't make sense, as the PPMC is vouching for its integrity).
IMHO a PMC would need to consider why a person they trust to create a
release is not trusted to make binding decisions. however, a PPMC is a
little different. the PPMC takes a while to bootstrap and it may make
little sense to wait until it has.
> However, if those on the PPMC wanted some help with the actual process
> of preparing the release - testing, building, etc, that is up to those
> PPMC members, and maybe there is some way you can help there.
the preparatory work can definitely be done by anyone: just find out
what needs doing and start patching.
the social management could also be done by anyone with access to the
mailing lists who knows how to cut apache releases provided that the
development community are happy for someone who is not a committer to
take the lead.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by Upayavira <uv...@odoko.co.uk>.
Bozhong Lin wrote:
> Hi,
>
> As I previously posted email on cxf-dev, I am very keen in contributing
> to CeltiXfire release management and other project management related
> stuff. From the Apache release process document [1], I am not sure what
> qualification/requirements it takes to get the release management job done:
> 1. Does it require SVN commit right? I don't have CXF commit right yet
> (working toward it :-), would this be a problem?
> 2. Does it require some one to be on PPMC?
> 3. Signing release. According to my knowledge, ASF needs to meet
> in-person whoever will be signing release. I am willing to make the trip
> meet ASF person in US.
>
> I hope I can contribute to CeltiXfire release management without commit
> access and without being on PPMC. If for some reason that I am not
> qualified to contribute fully, then I will try to contribute as much as
> possible.
In my view, this is up to the PPMC for Celtixfire.
Basically, doing a release is the central responsibility of the PPMC,
and they cannot delegate the decision to someone outside of itself. Nor
can they delegate the work of signing the release (that to my mind
wouldn't make sense, as the PPMC is vouching for its integrity).
However, if those on the PPMC wanted some help with the actual process
of preparing the release - testing, building, etc, that is up to those
PPMC members, and maybe there is some way you can help there.
Does that make sense?
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by Bozhong Lin <bl...@iona.com>.
Thanks for clarification. I will definitely take a look into Maven
release plugin.
Cheers,
Bo
Jason van Zyl wrote:
>
> On 27 Sep 06, at 12:30 PM 27 Sep 06, Bozhong Lin wrote:
>
>> Hi,
>>
>> As I previously posted email on cxf-dev, I am very keen in
>> contributing to CeltiXfire release management and other project
>> management related stuff. From the Apache release process document
>> [1], I am not sure what qualification/requirements it takes to get the
>> release management job done:
>> 1. Does it require SVN commit right? I don't have CXF commit right yet
>> (working toward it :-), would this be a problem?
>
> Yes, you need commit privs as you create a new tag and modify trunk.
>
>> 2. Does it require some one to be on PPMC?
>
> Yes, generally.
>
>> 3. Signing release. According to my knowledge, ASF needs to meet
>> in-person whoever will be signing release. I am willing to make the
>> trip meet ASF person in US.
>
> It's not mandatory that your key be signed by another ASF person but
> it's recommended. Anyone in the web of trust will do so you probably
> don't need to travel all the way to the US.
>
>>
>> I hope I can contribute to CeltiXfire release management without
>> commit access and without being on PPMC. If for some reason that I am
>> not qualified to contribute fully, then I will try to contribute as
>> much as possible.
>>
>
> Typically with Maven the release is handled almost entirely by the Maven
> release plugin. It prepares the release by inspecting your POM and makes
> sure you have no SNAPSHOT dependencies, makes sure you're not using any
> SNAPSHOT plugins, and makes sure none of your POM ancestry contains any
> SNAPSHOTs. It then creates a tag for you in SVN. Then you perform the
> release, and this can be done on the same machine or a separate machine,
> or Continuum can do it. Find a machine in a public space that you will
> use for all your releases. Using the Maven zones is probably a good
> idea. Build the release on a machine everyone can get access to. I've
> run into small glitches building releases on my machine. Anyway the
> perform operation will check out the tag, build, test, and deploys to a
> Maven repository with the release metadata information.
>
> The release plugin will take care of most of the crap work. I am working
> on adding signing to the release plugin, and adding staging of the
> releases where the candidate is staged and if deemed working and intact
> is then transfered to the official release repository.
>
> If you want to help with the release then the best thing you can do is
> evaluate the release plugin and fix anything that isn't working.
>
>> Regards,
>> Bo
>> [1] http://www.apache.org/dev/#releases
>>
>
Re: what are required for contributing to release management
Posted by Jason van Zyl <ja...@maven.org>.
On 27 Sep 06, at 12:30 PM 27 Sep 06, Bozhong Lin wrote:
> Hi,
>
> As I previously posted email on cxf-dev, I am very keen in
> contributing to CeltiXfire release management and other project
> management related stuff. From the Apache release process document
> [1], I am not sure what qualification/requirements it takes to get
> the release management job done:
> 1. Does it require SVN commit right? I don't have CXF commit right
> yet (working toward it :-), would this be a problem?
Yes, you need commit privs as you create a new tag and modify trunk.
> 2. Does it require some one to be on PPMC?
Yes, generally.
> 3. Signing release. According to my knowledge, ASF needs to meet in-
> person whoever will be signing release. I am willing to make the
> trip meet ASF person in US.
It's not mandatory that your key be signed by another ASF person but
it's recommended. Anyone in the web of trust will do so you probably
don't need to travel all the way to the US.
>
> I hope I can contribute to CeltiXfire release management without
> commit access and without being on PPMC. If for some reason that I
> am not qualified to contribute fully, then I will try to contribute
> as much as possible.
>
Typically with Maven the release is handled almost entirely by the
Maven release plugin. It prepares the release by inspecting your POM
and makes sure you have no SNAPSHOT dependencies, makes sure you're
not using any SNAPSHOT plugins, and makes sure none of your POM
ancestry contains any SNAPSHOTs. It then creates a tag for you in
SVN. Then you perform the release, and this can be done on the same
machine or a separate machine, or Continuum can do it. Find a machine
in a public space that you will use for all your releases. Using the
Maven zones is probably a good idea. Build the release on a machine
everyone can get access to. I've run into small glitches building
releases on my machine. Anyway the perform operation will check out
the tag, build, test, and deploys to a Maven repository with the
release metadata information.
The release plugin will take care of most of the crap work. I am
working on adding signing to the release plugin, and adding staging
of the releases where the candidate is staged and if deemed working
and intact is then transfered to the official release repository.
If you want to help with the release then the best thing you can do
is evaluate the release plugin and fix anything that isn't working.
> Regards,
> Bo
> [1] http://www.apache.org/dev/#releases
>
Re: what are required for contributing to release management
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 27, 2006, at 6:30 AM, Bozhong Lin wrote:
> Hi,
>
> As I previously posted email on cxf-dev, I am very keen in
> contributing to CeltiXfire release management and other project
> management related stuff. From the Apache release process document
> [1], I am not sure what qualification/requirements it takes to get
> the release management job done:
> 1. Does it require SVN commit right? I don't have CXF commit right
> yet (working toward it :-), would this be a problem?
> 2. Does it require some one to be on PPMC?
> 3. Signing release. According to my knowledge, ASF needs to meet in-
> person whoever will be signing release. I am willing to make the
> trip meet ASF person in US.
>
> I hope I can contribute to CeltiXfire release management without
> commit access and without being on PPMC. If for some reason that I
> am not qualified to contribute fully, then I will try to contribute
> as much as possible.
In the ASF, the PMC (and the PPMC) is the entity responsible for
releasing s/w. In fact, it is one of prime responsibilities of
the (P)PMC, since it's the release of s/w and its distribution
which the ASF, as a legal entity, is worried about.
As such, only the (P)PMC can release it, and therefore a person
in the (P)PMC is required. Now you can certainly help the
release manager (RM), but *they* are responsible for the
release, and they need to do the work.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: what are required for contributing to release management
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 27, 2006, at 6:30 AM, Bozhong Lin wrote:
> Hi,
>
> As I previously posted email on cxf-dev, I am very keen in
> contributing to CeltiXfire release management and other project
> management related stuff. From the Apache release process document
> [1], I am not sure what qualification/requirements it takes to get
> the release management job done:
> 1. Does it require SVN commit right? I don't have CXF commit right
> yet (working toward it :-), would this be a problem?
> 2. Does it require some one to be on PPMC?
> 3. Signing release. According to my knowledge, ASF needs to meet in-
> person whoever will be signing release. I am willing to make the
> trip meet ASF person in US.
>
> I hope I can contribute to CeltiXfire release management without
> commit access and without being on PPMC. If for some reason that I
> am not qualified to contribute fully, then I will try to contribute
> as much as possible.
In the ASF, the PMC (and the PPMC) is the entity responsible for
releasing s/w. In fact, it is one of prime responsibilities of
the (P)PMC, since it's the release of s/w and its distribution
which the ASF, as a legal entity, is worried about.
As such, only the (P)PMC can release it, and therefore a person
in the (P)PMC is required. Now you can certainly help the
release manager (RM), but *they* are responsible for the
release, and they need to do the work.