You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2008/10/03 03:19:12 UTC
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote:
> Jukka Zitting wrote:
> > This is a slight majority (of binding votes) for accepting the
> > proposed change, but given the clear lack of consensus and the
> > concerns voiced about that, I unfortunately need to conclude that this
> > issue should be tabled until better consensus is reached.
> Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL].
> A decision, however frustrating, has been reached.
Actually, Jukka's approach is correct. Greg Stein has discussed this sort of situation on multiple occasions with the same conclusion and guidance as Jukka.
> > Does the ASF "endorse" these releases, and what does that endorsement mean?
> yes...
You are talking about a legal licensing matter, whereas discussion during the setup and formation of the Incubator was quite clear that Incubator releases are NOT to carry the ASF's imprimatur and unfettered brand. Hence the restrictions and disclaimer requirements.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi All,
FWIW in my experience, the release process is a key driver for a podling
community to get it's collective act together.
On Qpid, we've done 3 major releases now. Until we worked towards the first,
one couldn't guarantee that the code would compile from trunk every day. Our
project really took shape during this process, and it was a good way to
start getting a handle on the Apache Way.
Having a focus, in the shape of a release, is a really useful way to move a
community towards a clear goal. Even better, it forces the podling to agree
targets (JIRAs etc) and work together to achieve them in a bounded way.
The other major plus is that iirc it took about 6 weeks of to+fro on our
first release to get a viable RC out (with all the necessary bits etc). The
process gets easier each time (at least the Apache bits do). On incubator
projects get oversight etc while all this happens and so they get better at
doing it, fairly early on.
In my view, without releases there wouldn't be any podling projects (as
Aidan suggested earlier).
Trust me, there are plenty of incentives to graduate :-)
Hth,
Marnie
On Tue, Oct 7, 2008 at 5:18 PM, Henning Schmiedehausen <
henning@schmiedehausen.org> wrote:
>
> On Mon, 2008-10-06 at 13:45 -0500, William A. Rowe, Jr. wrote:
> > How about a brand new idea?
> >
> > Lay down a Milestone-style chart of what it takes to operate as an ASF
> > project. Demonstrate community of meritocracy, add committers or ppmc
> > members based on contributions, complete IP review, and then... and only
> > then... they hit the release milestone. One or two releases later, they
> > are ejected from the Incubator - either to the target PMC or as a TLP.
>
> While I like that idea, it is hard for a podling that comes from a
> corporate environment (where the initial committer base is basically a
> development team) to build a developer community without a release.
>
> Giving a podling a defined exit strategy (e.g. "Three incubator
> releases") is nice, but it will be subverted by projects doing "rc,
> alpha and beta" releases ("Oh no, that is not our second release, this
> is 2.0-alpha-1" Which is followed by 2.0-alpha-2 up to 2.0-alpha-8, then
> -beta-1 and so on).
>
> Then again, some podlings could use a kick in their collective ass to do
> at least one release (Hello Shindig).
>
> Ciao
> Henning
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Allow incubator releases? [was: way too wordy]
Posted by Henning Schmiedehausen <he...@schmiedehausen.org>.
On Mon, 2008-10-06 at 13:45 -0500, William A. Rowe, Jr. wrote:
> How about a brand new idea?
>
> Lay down a Milestone-style chart of what it takes to operate as an ASF
> project. Demonstrate community of meritocracy, add committers or ppmc
> members based on contributions, complete IP review, and then... and only
> then... they hit the release milestone. One or two releases later, they
> are ejected from the Incubator - either to the target PMC or as a TLP.
While I like that idea, it is hard for a podling that comes from a
corporate environment (where the initial committer base is basically a
development team) to build a developer community without a release.
Giving a podling a defined exit strategy (e.g. "Three incubator
releases") is nice, but it will be subverted by projects doing "rc,
alpha and beta" releases ("Oh no, that is not our second release, this
is 2.0-alpha-1" Which is followed by 2.0-alpha-2 up to 2.0-alpha-8, then
-beta-1 and so on).
Then again, some podlings could use a kick in their collective ass to do
at least one release (Hello Shindig).
Ciao
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Tue, Oct 7, 2008 at 2:45 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>
>> How about a brand new idea?
>>
>> Lay down a Milestone-style chart of what it takes to operate as an ASF
>> project. Demonstrate community of meritocracy, add committers or ppmc
>> members based on contributions, complete IP review, and then... and only
>> then... they hit the release milestone. One or two releases later, they
>> are ejected from the Incubator - either to the target PMC or as a TLP.
>>
>> So releases would reflect the project is probably ready to graduate, the
>> only difference would be that the incubator PMC wants to see this done
>> right before calling the podling baked.
>
> Works for me, although you say nothing about whether that release is
> an ASF release or not. IMHO, it is an Incubator PMC release, just like
> any other PMC operated umbrella project. ;-)
Right - I pointed out earlier that it's a binary condition at the ASF, either
released or not released. I'm not even picky if they would rather release an
alpha or beta (not a bad idea if they followed your org.apache.incubator.foo
naming convention) or wanted to call it a GA/Gold release. That wasn't my
point, it was simply that ratifying their release would be the "last checkmark"
on the steps to graduation.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Oct 7, 2008 at 2:45 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> How about a brand new idea?
>
> Lay down a Milestone-style chart of what it takes to operate as an ASF
> project. Demonstrate community of meritocracy, add committers or ppmc
> members based on contributions, complete IP review, and then... and only
> then... they hit the release milestone. One or two releases later, they
> are ejected from the Incubator - either to the target PMC or as a TLP.
>
> So releases would reflect the project is probably ready to graduate, the
> only difference would be that the incubator PMC wants to see this done
> right before calling the podling baked.
Works for me, although you say nothing about whether that release is
an ASF release or not. IMHO, it is an Incubator PMC release, just like
any other PMC operated umbrella project. ;-)
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>
>> Drop any pretense that the incubator has a say
>> over the already-done code releases, and we can seriously start the real
>> discussion, which would have been "motivating projects to graduate" if we
>> hadn't wasted several hundred posts on a silly topic.
>
> Uhhh... I might misunderstand your English here (mine ain't that refined);
> Are you suggesting that the Incubator PMC has no say over code
> releases of podlings?
Pretty much, that's it. The code is voted released by the Incubator PMC
under the Apache License. The ASF places exactly those AL limits on the
code (very few) and enforces those limits, alone.
To have a successful release vote, we have lots of extra rules, such as
how the Podling vote happens, the IPMC vote ratifies it, rat and other
methods validate that the copyrights, licenses and such line up, that
there is a DISCLAIMER in the package, etc. If preconditions don't happen
they won't have the successful release vote they wanted.
The Incubator PMC has a strong say over what appears on incubator.a.o/*
pages, what is added to or revoked from www.a.o/dist/incubator/*, and so
forth and so on. But that's the extent. Postconditions that aren't in
the license don't exist. You can't say "Commercial use is disallowed",
and so forth.
> My stance is still; Releases from the Incubator are ASF releases of
> code, no different than another PMC. IMHO, the disclaimers are not
> helping anyone, not the podling, not the IPMC, not the downstream
> projects, not the public, not the repository management, not the tool
> chain...
> So, I still think; WTFing Point?
Well we could drop the DISCLAIMER requirement, that's another thread
entirely :)
> Now, we can deal with such situation in two possible ways;
>
> * Accept that projects eventually dies, and that everyone downstream
> needs to deal with that, and that downstream users are capable of
> basic SWOT analysis and let podlings release as much as they want. I
> would like (as a Maven user) the <groupId> in Maven artifacts to be
> org.apache.incubator.<podling> until the graduation occurs.
>
> * Not accept podlings to release code. Possibly having the "final
> act" of the podling to do a release, which effectuates the graduation.
>
> I am Ok with either of these, since I think that downstream users
> ain't stupid and more capable than I think we give them credit for.
How about a brand new idea?
Lay down a Milestone-style chart of what it takes to operate as an ASF
project. Demonstrate community of meritocracy, add committers or ppmc
members based on contributions, complete IP review, and then... and only
then... they hit the release milestone. One or two releases later, they
are ejected from the Incubator - either to the target PMC or as a TLP.
So releases would reflect the project is probably ready to graduate, the
only difference would be that the incubator PMC wants to see this done
right before calling the podling baked.
WDYT?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases? [was: way too wordy]
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Oct 6, 2008 at 8:22 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> * Not accept podlings to release code. Possibly having the "final
> act" of the podling to do a release, which effectuates the graduation.
>
> I am Ok with either of these, since I think that downstream users
> ain't stupid and more capable than I think we give them credit for.
>
Not being able to release code from the incubator will have one or more of
three effects:
1) podlings will find building a community massively more difficult.
2) podlings will push releases through non-ASF routes, bypassing the IPMC
entirely. Some projects are already doing this due to not being able to push
to central.
3) potential podlings will ignore the incubator and the ASF entirely.
The first will prolong a podlings stay in the incubator due to diversity
issues. The second will stop podlings getting experience with things like
LICENSE, NOTICE etc, which are surprisingly difficult to get right. The
third is just undesireable.
As for making the incubator a less comfortable place for podlings, waiting
weeks to get a new committer approved and almost a month for a release to be
approved are pretty uncomfortable experiences for a project.
They are also things which actively hinder a project graduating. The focus
seems to be on finding bigger, stickier sticks.
Perhaps a more effective approach would be, as suggested elsewhere, to
require a podling to report on it's progress towards graduation in the board
reports. If unsatisfactory progress is being made, then the mentors should
get involved.
If that isn't sufficent, perhaps podlings should not use the Apache brand in
supporting materials? Changing code layout, distribution channels etc is a
substantial amount of work, but having to refer to it as Frobnicator instead
of Apache Frobnicator gives some incentive to podlings without imposing an
additional burden on them.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
"Nine-tenths of wisdom consists in being wise in time." - Theodore Roosevelt
Re: Allow incubator releases? [was: way too wordy]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Oct 6, 2008 at 10:21 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Drop any pretense that the incubator has a say
> over the already-done code releases, and we can seriously start the real
> discussion, which would have been "motivating projects to graduate" if we
> hadn't wasted several hundred posts on a silly topic.
Uhhh... I might misunderstand your English here (mine ain't that refined);
Are you suggesting that the Incubator PMC has no say over code
releases of podlings?
My stance is still; Releases from the Incubator are ASF releases of
code, no different than another PMC. IMHO, the disclaimers are not
helping anyone, not the podling, not the IPMC, not the downstream
projects, not the public, not the repository management, not the tool
chain...
So, I still think; WTFing Point?
Now, we can deal with such situation in two possible ways;
* Accept that projects eventually dies, and that everyone downstream
needs to deal with that, and that downstream users are capable of
basic SWOT analysis and let podlings release as much as they want. I
would like (as a Maven user) the <groupId> in Maven artifacts to be
org.apache.incubator.<podling> until the graduation occurs.
* Not accept podlings to release code. Possibly having the "final
act" of the podling to do a release, which effectuates the graduation.
I am Ok with either of these, since I think that downstream users
ain't stupid and more capable than I think we give them credit for.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Allow incubator releases?
Posted by J Aaron Farr <fa...@apache.org>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Niclas Hedhman wrote:
>> I will support the "initial intent" of no releases out of Incubator.
>
> Which would work, except for the fact that the incubator decided it's a good
> idea to have podlings demonstrate how releases work in a meritocracy. Sure
> they've grokked vetoes over code, but the majority-vote release schema is
> nearly at odds with that. It's good that they demonstrate the entire cycle
> of envisioning ... creating ... collecting ... releasing code as a community.
+1
> So this is a better schema. Drop any pretense that the incubator has a say
> over the already-done code releases, and we can seriously start the real
> discussion, which would have been "motivating projects to graduate" if we
> hadn't wasted several hundred posts on a silly topic.
This is simple, people. This is what mentors are for. When the PMC
submits the board report, someone should mark the ones that need
motivating and task the mentors with doing so. If the mentors can't
(which is fine, we're all volunteers here), then delegate to someone
who can.
As for motivation, escaping the neverending threads on this mailing
list should be encouragement enough.
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Allow incubator releases? [was: way too wordy]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Sat, Oct 4, 2008 at 12:45 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>> Color me confused again, but during setup and formation of the Incubator,
>> a podling had to graduate before doing a release. It was rather well
>> established before this rule was modified, but it seems that this change
>> resulted in a number of different interpretations, some of which aren't
>> compatible with the ASF license.
>
> I will support the "initial intent" of no releases out of Incubator.
Which would work, except for the fact that the incubator decided it's a good
idea to have podlings demonstrate how releases work in a meritocracy. Sure
they've grokked vetoes over code, but the majority-vote release schema is
nearly at odds with that. It's good that they demonstrate the entire cycle
of envisioning ... creating ... collecting ... releasing code as a community.
So this is a better schema. Drop any pretense that the incubator has a say
over the already-done code releases, and we can seriously start the real
discussion, which would have been "motivating projects to graduate" if we
hadn't wasted several hundred posts on a silly topic.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Oct 4, 2008 at 12:45 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Color me confused again, but during setup and formation of the Incubator,
> a podling had to graduate before doing a release. It was rather well
> established before this rule was modified, but it seems that this change
> resulted in a number of different interpretations, some of which aren't
> compatible with the ASF license.
I will support the "initial intent" of no releases out of Incubator.
This not only puts an end to this discussion, incl Maven's stance that
policy enforcement is not their responsibility, but also accelerates
the need to graduate for podlings and hopefully make incubation
periods shorter. I would also move for requirement that Mentors remain
PMC members of the graduated project and overseas the initial
releases.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels
like the central Maven repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Noel J. Bergman wrote:
> William A. Rowe, Jr. wrote:
>
>> Jukka Zitting wrote:
>
>>> Does the ASF "endorse" these releases, and what does that endorsement mean?
>
>> yes...
>
> You are talking about a legal licensing matter, whereas discussion during the setup and formation of the Incubator was quite clear that Incubator releases are NOT to carry the ASF's imprimatur and unfettered brand. Hence the restrictions and disclaimer requirements.
Color me confused again, but during setup and formation of the Incubator,
a podling had to graduate before doing a release. It was rather well
established before this rule was modified, but it seems that this change
resulted in a number of different interpretations, some of which aren't
compatible with the ASF license.
Nobody is disputing the need for DISCLAIMER at the same visibility as the
LICENSE and NOTICE files. But Maven doesn't demand click through license
acceptance, so click through disclaimers make little sense, either.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org