Re: Jakarta [was: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]]
On Saturday 29 September 2007 00:03, Roland Weber wrote: > Staying at Jakarta will buy some time, but won't last forever. > > If you have ideas on what to do with these small but active > projects, please come over to [EMAIL PROTECTED] and share your > thoughts. Can't Jakarta just be revitalized as a home for small, but mature and stable projects?? We must allow for stable, near perfect codebases, to "just exist" without further development, i.e. no dedicated community. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta [was: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]]
Niall Pemberton wrote: > Theres more of an issue IMO with projects that don't come thru the > incubator, since they don't have to meet the Incubator's stringent > graduation requirement. As an example - Tapestry was pushed out to a > TLP from Jakarta,[...] Jakarta is disintegrating. All big projects have gone TLP, there are two or three more that might just make it. The rest is too inactive, because of maturity or disinterest, to stand on their own. There have been discussions every few months on how to revive inactive projects, and sending them back into the incubator was one of the options. Not that it matters much, I don't remember any that picked up enough interest. Now the projects that are still active but have only a small developer community - too small for Incubator standards for sure - are caught between a rock and a hard place. There are users out there, and the code has seen many official releases. Going into the Incubator and making unofficial "incubating" releases from there is not a preferred option. Going TLP with just enough PMCs to collect three binding votes during holiday season creates TLPs with a very high dependency on very few people. Projects which are an issue. Staying at Jakarta will buy some time, but won't last forever. If you have ideas on what to do with these small but active projects, please come over to [EMAIL PROTECTED] and share your thoughts. The two examples I have in mind are HttpComponents and JMeter, but there may be others: http://jakarta.apache.org/httpcomponents/index.html http://jakarta.apache.org/jmeter/index.html cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On Sep 28, 2007, at 4:16 AM, Bertrand Delacretaz wrote:
On 9/27/07, ant elder <[EMAIL PROTECTED]> wrote:
...So I'm wondering if as podling releases are not endorsed by the
ASF and if
the "incubating" and the disclaimer text is everywhere as required
then
could we be a little more lenient? Maybe just note any issues so
they can be
fixed in the next release?...
Do you mean technical issues ("code does not work") or legal stuff
("notice is missing for library XYZ")?
IMHO the incubator PMC doesn't care much about technical issues in
podling releases, at least for early releases.
What we care about is that podlings get the "legal stuff" right, and
letting releases out without this being ok is not an option, due to
potential legal risks.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On Friday 28 September 2007 17:12, Guillaume Nodet wrote: > On 9/28/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > What we care about is that podlings get the "legal stuff" right, and > > letting releases out without this being ok is not an option, due to > > potential legal risks. > > I thought projects in incubator were not endorsed by the ASF, hence > the ASF could not be responsible for the legal stuff in podling > releases... Did I miss something here ? Yes, you missed the fact that Incubator is part of ASF, and the Incubator are doing the releases on behalf of the podling. AFAIUI, we are responsible of the legal aspects of the releases (i.e. upstream sources), but we have no practical responsibilities towards the downstream users. If the Incubator was not part of ASF, then that would be a different story... And I think the original intent was to come into that effect, but the legal reality is different. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On 9/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > On 9/28/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > > What we care about is that podlings get the "legal stuff" right, and > > letting releases out without this being ok is not an option, due to > > potential legal risks. > > I thought projects in incubator were not endorsed by the ASF, hence > the ASF could not be responsible for the legal stuff in podling > releases... Did I miss something here ? This is exactly the question i'm trying to clarify. The policy at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases says: - No release made by a Podling will be endorsed by the ASF - (releases) SHALL NOT occur until all source has been legally transferred to the ASF. - the release archive MUST contain the word "incubating" in the filename - the release archive MUST contain an Incubation disclaimer and that seems to imply there is no constraint that every podling release MUST met all the legal requirements expected of a non-incubating ASF release. ...ant
Re: How strict should podling release reviews be?
On 9/28/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > On Friday 28 September 2007 16:16, Bertrand Delacretaz wrote: > > IMHO the incubator PMC doesn't care much about technical issues in > > podling releases, at least for early releases. > > This is an important observation. The reviewers has no opportunity to > figure > out if the release at all work. That is up to the Podling, and AFAIA > concerned, the technical quality can be non-existent. > IMHO, the mentors are responsible together with the PPMC to bring the > technical quality to a level expected from ASF projects. But I feel it is > at > that group's discretion. > AFAIR, technical quality hasn't been a problem in the past for > graduations. Yes, and there is some quality expectations for real (non-incubating) Apache releases so Incubator release reviews help podlings learn about those, past review discussions have brought up various non-legal aspects, for example consistent artifact naming, distributions not unzipping to the current folder etc. ...ant
Re: How strict should podling release reviews be?
On Friday 28 September 2007 16:16, Bertrand Delacretaz wrote: > IMHO the incubator PMC doesn't care much about technical issues in > podling releases, at least for early releases. This is an important observation. The reviewers has no opportunity to figure out if the release at all work. That is up to the Podling, and AFAIA concerned, the technical quality can be non-existent. IMHO, the mentors are responsible together with the PPMC to bring the technical quality to a level expected from ASF projects. But I feel it is at that group's discretion. AFAIR, technical quality hasn't been a problem in the past for graduations. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On 9/28/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > What we care about is that podlings get the "legal stuff" right, and > letting releases out without this being ok is not an option, due to > potential legal risks. I thought projects in incubator were not endorsed by the ASF, hence the ASF could not be responsible for the legal stuff in podling releases... Did I miss something here ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On Friday 28 September 2007 15:40, ant elder wrote: > Anyway, so i'm thinking more of a benevolent educator than traffic warden > style reviewer role. *My* worry is that quality will drop if there is no expectations. So we could turn this around and say; What are the expectations from the I PMC reviewers? I happen to think that a smaller, new project should be given a much more lenient treatment, than the larger projects in their 5th release cycle. Should such distinction be ratified in policy? I don't think that is necessary. Personal judgement is IMHO enough on a case-by-case basis. Podlings are capable of making the review process smoother. Run RAT, publish the result, publish the "???" and protests of RAT, plus make a small list with explaination of why things are the way they are, just indicating that you are on top of the issue, and I think most of us would gladly pass thru less than perfect releases, since that shows you know what you are doing which is more important than doing it correctly. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On 9/27/07, ant elder <[EMAIL PROTECTED]> wrote:
> ...So I'm wondering if as podling releases are not endorsed by the ASF and if
> the "incubating" and the disclaimer text is everywhere as required then
> could we be a little more lenient? Maybe just note any issues so they can be
> fixed in the next release?...
Do you mean technical issues ("code does not work") or legal stuff
("notice is missing for library XYZ")?
IMHO the incubator PMC doesn't care much about technical issues in
podling releases, at least for early releases.
What we care about is that podlings get the "legal stuff" right, and
letting releases out without this being ok is not an option, due to
potential legal risks.
-Bertrand
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How strict should podling release reviews be?
On 9/28/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > On Friday 28 September 2007 05:12, Yoav Shapira wrote: > > > Personally, that's my take on it, and what I've done historically. > > I agree with Yoav, but would like to add that I personally have different > standards for different podlings, i.e. > > - The sooner one can expect graduation -> higher bar. > - Projects with many existing ASFers in it -> higher bar. > - Projects with high visibility outside Incubator, such as >some ws.apache.org sponsored ones -> higher bar. > > One problem we are facing is that we are unable to track the "delta" of > issues > from one release to the next. If we could, then things would be so much > easier. > And don't forget, many projects are aiming for one perfect release to > graduate... > > I think the end result of "rather strict than lenient" improves ASF legal > quality over time, as these concerns will "rub off" on less than perfect > reviews in other projects through the participation of individuals. > > > Cheers > Niclas It sounds reasonable to make part of the graduation criteria being able to demonstrate some competence in making releases, and thats already on the graduation checklist in the Incubator policy and graduation guide. I know there's no simple way to keep track of all the issues over all the releases but that could be part of the review required when deciding how to vote on a graduation proposal - trawling through the mailing list to see how their releases went. So couldn't the decision on whether or not to respin a release still be left up to the the podling anyway? If they're thinking about graduation and its important to them to be able to demonstrate a perfect release let them choose to respin themselves. I'm less keen on having different standards for different projects. One of the difficulties for incubating projects is finding out about all the release requirements. One way i've found to do that is by looking at what other releases do but when the same issues aren't flagged for some releases it can be quite confusing what the actual requirements are. Making most issues non-blocking could actually improve reviews as in some cases it could be easier to mention an issue it if its not going to force a respin. Anyway, so i'm thinking more of a benevolent educator than traffic warden style reviewer role. ...ant
