Re: How to shorten the duration of incubation (Was: Insanity...)
On Wed, Nov 11, 2009 at 6:08 AM, Niclas Hedhman wrote: > On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting > wrote: >> I personally think that the exit criteria are good as they are (in >> hindsight, Abdera is a good example of a project that graduated with >> barely enough diversity of active committers), so if we do want to >> make the Incubator "work faster" my suggestion would be to start by >> raising our entry criteria. One way to do that would be to start >> requiring the three mentors to show higher levels of personal >> commitment than what we currently ask for. > > And would Subversion qualify ?? Just kidding... > > We could do both #1 and #2 ... and then there might be a bunch of > 'stale' ones that we retire. And with a smaller number of incubating > projects, there should be more time for mentors on each one, > addressing your #3. my experience tells me that it's hard to guess which projects are going to struggle. so tightening the entry criteria may prevent community led projects being admitted without an improvement in incubator throughput. i'm not sure that loosening the entry criteria is a good idea either: they give corporations incentives to play our game our way. if graduation came to be seen as less difficult then there would be less incentive for corporations to invest in community building in the incubator. IMHO the main issue is that now the process works fine for large closed source donations (which covers the majority of podlings), the IPMC has stopped developing the process IMHO the next logical step is to break down graduation into a track with several modular votes based on the criteria the IPMC has developed for graduation. this should give a more finely grained idea of where a podling is and would allow immediate approval of steps for some podlings. for example, AIUI subversion already uses open development so that could be approved right away (whereas this is usually the most difficult criterion for podlings which a start as close source projects). releases are a good example. the auditing that is done when the first release is presented could be done as three steps of the track (license audit, source audit and artifact audit). only once all steps were complete would a podling to allowed to submit a release for official IPMC approval. using a track would allow a more linear progression. at the moment, there's a lot of work setting up the podling and getting things moving. getting release approval and passing community is difficult so most podlings drift along for quite a while once the initial effort is over. breaking down these big, difficult tasks into a number of smaller ones may make them more approachable. - robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education
Hi, On Tue, Nov 10, 2009 at 11:53 PM, Davanum Srinivas wrote: > Jukka, > Not so sure... because that dist may contain code that we may not allow. Personally I'd be happy with a plan from the Subversion team that shows how they're going to address any issues that may be raised in the review. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to shorten the duration of incubation (Was: Insanity...)
On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting wrote: > On Tue, Nov 10, 2009 at 5:55 PM, Greg Stein wrote: >> My point above was the Board, at least in the past(*), has *not* been >> happy about the average duration. > > The way I see it, there are three main things we could do to shorten > the average duration of incubation: Agree with your points... > 1) Relax the exit criteria: Especially the diversity requirement is a > major barrier for many projects. There have been various calls to > relax the diversity requirements, but so far I see no consensus on > that. Diversity requirement is actually a derived requirement of "community sustainability" to avoid a sponsoring entity to pull the plug of paid developers. Another is number of active developers, ensuring that community survives if the "main guy" get tired or is hit by bus. So, in reality, it boils down to ASF "unwillingness" to deal with project failures. But, ALL projects will fail, sooner or later. We could also embrace this, and change the exit criteria to something like "Do we think that this community will thrive for N years ahead?" and apply that even though there are only 2 guys on it. And with Attic getting better at folding up projects, we shouldn't worry too much over failing communities. > 2) Tighten the entry criteria: Many of the podlings that end up > failing or taking a long time here are new projects that start from > scratch or from previously closed codebases with weak or no existing > project communities. We could significantly improve the average > duration of incubation if we only accepted mature open source > projects. This is tricky. There are quite a handful of "Let's implement JSR-1234, and I have this initial codebase..." kind of requests that generally turn out well. I worry less about "new projects" than over "mature closed ones" from companies lacking OSS experience. > 3) Increase the amount of mentoring: The lack of mentor time and > better (not necessarily more) supporting documentation gives > unnecessary administrational and procedural headaches (failed release > votes, etc.) to many podlings. > Without more volunteers there's not much we can do about 3, which > leaves the entry and exit criteria as the variables we can control. Agree... > I personally think that the exit criteria are good as they are (in > hindsight, Abdera is a good example of a project that graduated with > barely enough diversity of active committers), so if we do want to > make the Incubator "work faster" my suggestion would be to start by > raising our entry criteria. One way to do that would be to start > requiring the three mentors to show higher levels of personal > commitment than what we currently ask for. And would Subversion qualify ?? Just kidding... We could do both #1 and #2 ... and then there might be a bunch of 'stale' ones that we retire. And with a smaller number of incubating projects, there should be more time for mentors on each one, addressing your #3. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0 (RC-5)
What happen to this release? The links in this post are no longer valid, and the Download page http://incubator.apache.org/wink/downloads.html shows no sign of a 1.0-incubating release... Cheers Niclas On Thu, Nov 5, 2009 at 11:53 PM, Nicholas Gallardo wrote: > The Wink community has voted on and approved the release > of Wink 1.0 (RC-5). We would now like to request the > approval of the Incubator PMC for this release. > > Details of the Wink community vote can be found here: > http://n2.nabble.com/VOTE-Release-Wink-1-0-RC-5-td3936613.html#a3936613 > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachewink-011/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachewink-011/org/apache/wink/apache-wink/1.0-incubating/ > > This release is tagged at: > https://svn.apache.org/repos/asf/incubator/wink/tags/wink-1.0-incubating/ > (revision 832289) > > The vote will be open here for at least 72 hours. > > > Regards, > > -Nick > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 12:29 AM, Jochen Wiedmann wrote: > On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: > >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. > > That would a completely new philosophy for an Apache project, which always > aimed > very heavily on distributions. Not new at all. I know that one of the oldest Java projects here, Cocoon, once only released buildable(!) source code. What is happening in some Java projects, via Maven's release plugin, is disturbing since the "source release" only exist in the subversion repository. The -source.jar is packaged in a non-buildable format optimized for IDE source integration and not to be reproducable. Some ASF projects (I think including some of Maven's own artifacts and subprojects) are now in total opposite of "old school source releases" and effectively only releases "binaries" containing re-packaged sources and one has to go to source repository to find the 'real' source code for that release. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Tue, Nov 10, 2009 at 22:41, Ralph Goers wrote: > On Nov 10, 2009, at 7:17 PM, Greg Stein wrote: > >> On Tue, Nov 10, 2009 at 21:09, Ralph Goers >> wrote: >>> >>> On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: >>> There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. >>> >>> I am fine with doing everything as if this was a TLP with the two >>> exceptions that 1) the main page should say it is still in incubation 2) it >>> is still under the umbrella of the IPMC until graduation. >> >> "the main page" ... are you referring to http://subversion.tigris.org/ >> ? Regardless, yeah.. that thing should be updated to reflect the >> project's new status. If a different page, then please let me know, >> and I'll make it happen. > > No. http://subversion.apache.org. I saw the comment about keeping the main > page at subversion.tigris.org but i see no reason it shouldn't move to apache > during incubation. The tigris page can stay up as long as they want but > should eventually redirect to Apache. Ah. Definitely. We (the podling) haven't really talked much about the web pages. I'll throw that out. (btw, if anyone wants to monitor svn pre-mailing-list-move, then subscribe to d...@subversion.tigris.org; our equiv of private@ has been silent, and should be staying that way until we move to apache.org) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Nov 10, 2009, at 7:17 PM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 21:09, Ralph Goers wrote: >> >> On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: >> >>> There are two other issues to discuss for the Subversion podling: >>> >>> * moving the mailing lists directly to @subversion.apache.org >>> * placing the source code at /subversion/ rather than /incubator/subversion/ >>> >>> We are hoping to minimize overall disruption to the community with a >>> move to incubator space, then a move to apache space. >>> >> >> I am fine with doing everything as if this was a TLP with the two exceptions >> that 1) the main page should say it is still in incubation 2) it is still >> under the umbrella of the IPMC until graduation. > > "the main page" ... are you referring to http://subversion.tigris.org/ > ? Regardless, yeah.. that thing should be updated to reflect the > project's new status. If a different page, then please let me know, > and I'll make it happen. No. http://subversion.apache.org. I saw the comment about keeping the main page at subversion.tigris.org but i see no reason it shouldn't move to apache during incubation. The tigris page can stay up as long as they want but should eventually redirect to Apache. > > Regarding oversight: absolutely. No matter where the assets may > reside, the IPMC is responsible for them. > > And regarding my previous aside: I do think that, in the future, we > (the IPMC) may want to go ahead and place projects in their intended > location to start with, to avoid that graduation-move. Something for a > separate discussion. > > Cheers, > -g > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Tue, Nov 10, 2009 at 22:17, Greg Stein wrote: > On Tue, Nov 10, 2009 at 21:09, Ralph Goers wrote: >... >> I am fine with doing everything as if this was a TLP with the two exceptions >> that 1) the main page should say it is still in incubation 2) it is still >> under the umbrella of the IPMC until graduation. > > "the main page" ... are you referring to http://subversion.tigris.org/ > ? Regardless, yeah.. that thing should be updated to reflect the > project's new status. If a different page, then please let me know, > and I'll make it happen. I've updated subversion.tigris.org (subject to hourly sync). Cheers, -g (a bare version can be seen in source control: http://svn.collab.net/repos/svn/trunk/www/index.html) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Tue, Nov 10, 2009 at 21:09, Ralph Goers wrote: > > On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: > >> There are two other issues to discuss for the Subversion podling: >> >> * moving the mailing lists directly to @subversion.apache.org >> * placing the source code at /subversion/ rather than /incubator/subversion/ >> >> We are hoping to minimize overall disruption to the community with a >> move to incubator space, then a move to apache space. >> > > I am fine with doing everything as if this was a TLP with the two exceptions > that 1) the main page should say it is still in incubation 2) it is still > under the umbrella of the IPMC until graduation. "the main page" ... are you referring to http://subversion.tigris.org/ ? Regardless, yeah.. that thing should be updated to reflect the project's new status. If a different page, then please let me know, and I'll make it happen. Regarding oversight: absolutely. No matter where the assets may reside, the IPMC is responsible for them. And regarding my previous aside: I do think that, in the future, we (the IPMC) may want to go ahead and place projects in their intended location to start with, to avoid that graduation-move. Something for a separate discussion. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Nov 10, 2009, at 11:27 AM, Greg Stein wrote: > There are two other issues to discuss for the Subversion podling: > > * moving the mailing lists directly to @subversion.apache.org > * placing the source code at /subversion/ rather than /incubator/subversion/ > > We are hoping to minimize overall disruption to the community with a > move to incubator space, then a move to apache space. > I am fine with doing everything as if this was a TLP with the two exceptions that 1) the main page should say it is still in incubation 2) it is still under the umbrella of the IPMC until graduation. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
- Original Message > From: Greg Stein > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 2:54:28 PM > Subject: Re: Insanity. Apache Incubator should be about education (was: > [PROPOSAL][VOTE] Subversion) > > On Tue, Nov 10, 2009 at 17:35, Joe Schaefer wrote: > >... > >> Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The > >> input that I received was that that was insufficient -- a branded > >> release was necessary. > > > > I haven't seen that discussion, but unless you actually poll > > gene...@incubator > > for an opinion, running the idea by a few of the more vocal participants > > It was right here on gene...@incubator. Part of the "[PROPOSAL][VOTE] > Subversion" thread. Oops sorry. I tend to ignore the off-topic crap here ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 17:35, Joe Schaefer wrote: >... >> Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The >> input that I received was that that was insufficient -- a branded >> release was necessary. > > I haven't seen that discussion, but unless you actually poll gene...@incubator > for an opinion, running the idea by a few of the more vocal participants It was right here on gene...@incubator. Part of the "[PROPOSAL][VOTE] Subversion" thread. >... > What I'm looking to see personally is the execution of votes and signature > exchange happening on an apache list. That way the IPMC members can ensure > discussion is appropriate on both the private and public mailing lists > and the process is sound. I don't give a rat's ass how it is branded, and > assuming the code grant from the Subversion corporation is comprehensive > expect to vote +1 for graduation without an apache-branded release happening > prior to graduation. People will be more than willing to do a license > review on a non-apache branded release. Thanks, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
- Original Message > From: Greg Stein > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 1:58:28 PM > Subject: Re: Insanity. Apache Incubator should be about education (was: > [PROPOSAL][VOTE] Subversion) > > On Tue, Nov 10, 2009 at 16:39, Joe Schaefer wrote: > > - Original Message > > > >> From: Jukka Zitting > >> To: general@incubator.apache.org > >> Sent: Tue, November 10, 2009 1:25:40 PM > >> Subject: Re: Insanity. Apache Incubator should be about education (was: > [PROPOSAL][VOTE] Subversion) > >> > >> Hi, > >> > >> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: > >> > Unfortunately, some documentation needs to be brought in sync. > >> > > >> > See: http://incubator.apache.org/guides/graduation.html#checklist > >> > >> I'm nitpicking, but even there we only ask the podlings to > >> "demonstrate ability to create Apache releases". > >> > >> > Per Joe, I think it makes sense to run podlings through a release to > >> > teach them the ropes, rather than lump that onto Infrastructure. But I > >> > also believe we should provide waivers when appropriate. > >> > >> Fair enough. > >> > >> As an alternative, how about submitting > >> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for > >> IPMC review? That should require no extra work from and no special > >> waivers for Subversion. > > > > I think Greg and company intend to cut another subversion release in > > the next 2-3 weeks. If we can get some part of that carried out on > > apache mailing lists, I think it would alleviate a lot of the initial > > concerns. > > Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The > input that I received was that that was insufficient -- a branded > release was necessary. I haven't seen that discussion, but unless you actually poll gene...@incubator for an opinion, running the idea by a few of the more vocal participants or "key" people here won't get you an accurate gauge of anything. I have found most people at Apache to be moderate in their views and willing to compromise when given a good reason to. That's part of our success as an organization. What I'm looking to see personally is the execution of votes and signature exchange happening on an apache list. That way the IPMC members can ensure discussion is appropriate on both the private and public mailing lists and the process is sound. I don't give a rat's ass how it is branded, and assuming the code grant from the Subversion corporation is comprehensive expect to vote +1 for graduation without an apache-branded release happening prior to graduation. People will be more than willing to do a license review on a non-apache branded release. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 8:29 AM, Jochen Wiedmann wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Apache's distributions are source distributions as a requirement. Binary distributions are just a convenience for users. If subversion doesn't see any benefit for the project or for users to release binaries, it is not a requirement. Especially as third parties are providing binaries. Just the licensing/trademark issue of what the third parties call their releases. Which question is best left to our licensing/trademark team. Craig Jochen To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Insanity. Apache Incubator should be about education
contrib/ has been removed from the packaging scripts, and won't ship with 1.7. In other news, the box that builds the nightly tarballs is back online, albeit with a new disk, so it'll take me a day or two to get it back up. When it does, I'll point people there, and you can see what a typical tarball would look like (with the caveat that a nightly is untested, not a true release, and could cause a black hole that swallows the Earth). -Hyrum On Nov 10, 2009, at 4:04 PM, Greg Stein wrote: > Dims: Exactly. > > The svn devs have been talking off/on what to do about contrib/ for > nearly a year. Various options: simply toss it and wait for people to > cry and do something to fix it; somehow get it all relicensed (one of > the contributors already said "no"); etc etc. > > Current consensus seems to be that we'll simply not package the > contrib/ section into our 1.7 release. > > Cheers, > -g > > On Tue, Nov 10, 2009 at 16:53, Davanum Srinivas wrote: >> Jukka, >> Not so sure... because that dist may contain code that we may not allow. >> >> Greg, >> Is there any code in there that is not Apache compatible? i see some in the >> contrib section... >> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean >> >> thanks, >> dims >> >> On 11/10/2009 04:25 PM, Jukka Zitting wrote: >>> >>> Hi, >>> >>> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: Unfortunately, some documentation needs to be brought in sync. See: http://incubator.apache.org/guides/graduation.html#checklist >>> >>> I'm nitpicking, but even there we only ask the podlings to >>> "demonstrate ability to create Apache releases". >>> Per Joe, I think it makes sense to run podlings through a release to teach them the ropes, rather than lump that onto Infrastructure. But I also believe we should provide waivers when appropriate. >>> >>> Fair enough. >>> >>> As an alternative, how about submitting >>> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for >>> IPMC review? That should require no extra work from and no special >>> waivers for Subversion. >>> >>> BR, >>> >>> Jukka Zitting >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education
Dims: Exactly. The svn devs have been talking off/on what to do about contrib/ for nearly a year. Various options: simply toss it and wait for people to cry and do something to fix it; somehow get it all relicensed (one of the contributors already said "no"); etc etc. Current consensus seems to be that we'll simply not package the contrib/ section into our 1.7 release. Cheers, -g On Tue, Nov 10, 2009 at 16:53, Davanum Srinivas wrote: > Jukka, > Not so sure... because that dist may contain code that we may not allow. > > Greg, > Is there any code in there that is not Apache compatible? i see some in the > contrib section... > http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean > > thanks, > dims > > On 11/10/2009 04:25 PM, Jukka Zitting wrote: >> >> Hi, >> >> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: >>> >>> Unfortunately, some documentation needs to be brought in sync. >>> >>> See: http://incubator.apache.org/guides/graduation.html#checklist >> >> I'm nitpicking, but even there we only ask the podlings to >> "demonstrate ability to create Apache releases". >> >>> Per Joe, I think it makes sense to run podlings through a release to >>> teach them the ropes, rather than lump that onto Infrastructure. But I >>> also believe we should provide waivers when appropriate. >> >> Fair enough. >> >> As an alternative, how about submitting >> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for >> IPMC review? That should require no extra work from and no special >> waivers for Subversion. >> >> BR, >> >> Jukka Zitting >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 16:39, Joe Schaefer wrote: > - Original Message > >> From: Jukka Zitting >> To: general@incubator.apache.org >> Sent: Tue, November 10, 2009 1:25:40 PM >> Subject: Re: Insanity. Apache Incubator should be about education (was: >> [PROPOSAL][VOTE] Subversion) >> >> Hi, >> >> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: >> > Unfortunately, some documentation needs to be brought in sync. >> > >> > See: http://incubator.apache.org/guides/graduation.html#checklist >> >> I'm nitpicking, but even there we only ask the podlings to >> "demonstrate ability to create Apache releases". >> >> > Per Joe, I think it makes sense to run podlings through a release to >> > teach them the ropes, rather than lump that onto Infrastructure. But I >> > also believe we should provide waivers when appropriate. >> >> Fair enough. >> >> As an alternative, how about submitting >> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for >> IPMC review? That should require no extra work from and no special >> waivers for Subversion. > > I think Greg and company intend to cut another subversion release in > the next 2-3 weeks. If we can get some part of that carried out on > apache mailing lists, I think it would alleviate a lot of the initial > concerns. Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The input that I received was that that was insufficient -- a branded release was necessary. I also pointed the IPMC at the three (primary) emails around the release of 1.6.6. Again, the input was "not good enough". So then I suggest a separate legal review, and request a wavier on making a release. Then the input is "ask us again later". *shrug* -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education
Jukka, Not so sure... because that dist may contain code that we may not allow. Greg, Is there any code in there that is not Apache compatible? i see some in the contrib section... http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean thanks, dims On 11/10/2009 04:25 PM, Jukka Zitting wrote: Hi, On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: Unfortunately, some documentation needs to be brought in sync. See: http://incubator.apache.org/guides/graduation.html#checklist I'm nitpicking, but even there we only ask the podlings to "demonstrate ability to create Apache releases". Per Joe, I think it makes sense to run podlings through a release to teach them the ropes, rather than lump that onto Infrastructure. But I also believe we should provide waivers when appropriate. Fair enough. As an alternative, how about submitting http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for IPMC review? That should require no extra work from and no special waivers for Subversion. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
- Original Message > From: Jukka Zitting > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 1:25:40 PM > Subject: Re: Insanity. Apache Incubator should be about education (was: > [PROPOSAL][VOTE] Subversion) > > Hi, > > On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: > > Unfortunately, some documentation needs to be brought in sync. > > > > See: http://incubator.apache.org/guides/graduation.html#checklist > > I'm nitpicking, but even there we only ask the podlings to > "demonstrate ability to create Apache releases". > > > Per Joe, I think it makes sense to run podlings through a release to > > teach them the ropes, rather than lump that onto Infrastructure. But I > > also believe we should provide waivers when appropriate. > > Fair enough. > > As an alternative, how about submitting > http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for > IPMC review? That should require no extra work from and no special > waivers for Subversion. I think Greg and company intend to cut another subversion release in the next 2-3 weeks. If we can get some part of that carried out on apache mailing lists, I think it would alleviate a lot of the initial concerns. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Hi, On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote: > Unfortunately, some documentation needs to be brought in sync. > > See: http://incubator.apache.org/guides/graduation.html#checklist I'm nitpicking, but even there we only ask the podlings to "demonstrate ability to create Apache releases". > Per Joe, I think it makes sense to run podlings through a release to > teach them the ropes, rather than lump that onto Infrastructure. But I > also believe we should provide waivers when appropriate. Fair enough. As an alternative, how about submitting http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for IPMC review? That should require no extra work from and no special waivers for Subversion. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
(i'm really short of time ATM so apologies in advance if i'm very slow to respond) On Tue, Nov 10, 2009 at 6:18 PM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 13:11, William A. Rowe Jr. > wrote: >> Greg Stein wrote: >>> >>> The IPMC is in charge of its operation. It can redefine the rules of >>> releases as it pleases. The three +1 rule was developed to show that >>> the PMC is "in charge" of the release, and is therefore legally liable >>> for it. The IPMC can do whatever it likes around releases, as long as >>> that process specifically claims or disclaims liability. >> >> The only individuals empowered to act on the foundation's behalf are >> members of committees. With the exception of board committees which >> are empowered to form subcommittees, all such individuals must be >> ratified (either by resolution or our favorite ACK game) by the BoD. >> >> A vote by 3 PPMC members is therefore not binding, not unless the board >> is prepared to ack/nak all appointments to PPMC's within Incubator. > > Understood. Nobody proposed that. I believe you missed the part of > another +1 from an IPMC member. IMHO the problem with getting 3 +1's is the time commitment required from reviewers. i estimate that helping a project get the first release right involves about 10 hours of my time. if i was certain that the release process and code had been well been well audited then i could be confident that i could just re-run the automated checking tools, take a look at README to answer any questions and review the mailing list to check that the PPMC was following it's own process. i think (see below) that this could be achieved if the IPMC required that a number of pre-requisites were passed (in order) before a release was allowed: 1. all licensing issues resolved to IPMC's satisfaction 2. full source audit approved by IPMC 3. full artifact audit approved by IPMC if this were done and documented then approving a release would only involve checking that the PPMC followed it's own rules and could be much more lightweight. it would mean creating a less flexible track for podlings with multiple hurdles. not sure whether that'd be better or not. - robert licensing issues - the legal team only approve licenses on demand. so, any licenses new to apache need to be reviewed and categorised. usually, licenses are first audited at release time. so, it's common for podlings to have first releases rejected and told to go away and ensure all licenses are approved but there's no real reason why this needs to happen. the most efficient process would be for mentors to collect licenses referenced by the code, compare each to the rules then propose a patch adding the license to the appropriate classification. this could all be done before or on entry. [source audit] headers etc -- the bit everyone gets wrong is writing down the licensing for every file that can't have a header so that auditors understand the provenance of the file. the routine should be either to add a header or add the file to some document. this could be fixed by a source audit at any time by experienced reviewers. IMHO it would be more convenient to schedule a source audit window (a few weeks long) asking IPMC reviewers to +1 the source before thinking about a release. (IMO the ideal would be to run the automated reviewer on every project and then post failure emails to this list but i ran out of energy for this idea.) [artifact audit] notices etc -- there are a number of fiddly reporting requirements that are required for apache releases. there isn't precise consensus on best practice and the rules set out principles. so, there's a lot of scope for arguments between members. this is doubly annoying for podlings. it's unheard of for this to be done exactly right first time (and i suspect that many apache projects wouldn't pass an IPMC audit on this one). auditing this requires release artifacts but providing that the podling has a solid, documented build process for releases then this could be audited without a live release. IMHO again, the best approach would be an audit window (after the source audit) for checking the release artifact. (IMO the ideal process would be to integrate automated artifact checking into the build bot stuff but again, i don't have the energy to push this forward) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
Now that you have explained :) +1 from me. -- dims On 11/10/2009 02:43 PM, Greg Stein wrote: LOL Well... the problem is that an "svn mv" from /incubator/subversion/ to /subversion/ introduces an artificial breakage in the history. It is actually quite disruptive for tracking history (which is very important to us). (and yes, because of that history issue, I personally have no problem putting podlings at the top-level in our repository; it *is* version control, and we can always remove failed podlings' code from anywhere) Cheers, -g On Tue, Nov 10, 2009 at 14:38, Davanum Srinivas wrote: Personally i am ok with #1, but i am not sure if "svn switch --relocate" too much of a burden for you guys :) On 11/10/2009 02:27 PM, Greg Stein wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Nov 10, 2009, at 2:27 PM, Greg Stein wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/ subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. That seems fine to me. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
LOL Well... the problem is that an "svn mv" from /incubator/subversion/ to /subversion/ introduces an artificial breakage in the history. It is actually quite disruptive for tracking history (which is very important to us). (and yes, because of that history issue, I personally have no problem putting podlings at the top-level in our repository; it *is* version control, and we can always remove failed podlings' code from anywhere) Cheers, -g On Tue, Nov 10, 2009 at 14:38, Davanum Srinivas wrote: > Personally i am ok with #1, but i am not sure if "svn switch --relocate" too > much of a burden for you guys :) > > On 11/10/2009 02:27 PM, Greg Stein wrote: >> >> There are two other issues to discuss for the Subversion podling: >> >> * moving the mailing lists directly to @subversion.apache.org >> * placing the source code at /subversion/ rather than >> /incubator/subversion/ >> >> We are hoping to minimize overall disruption to the community with a >> move to incubator space, then a move to apache space. >> >> Cheers, >> -g >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
The project status will stay there and be maintained as long as we're incubating. That's my initial draft to get it into the system. I need to spend more time with it (but have spent time getting other discussions/tasks "into the pipeline"). I'm just about out of that stuff, so will go update that some more :-) Regarding the project website itself... I think we'll just leave that at subversion.tigris.org until after graduation (I haven't brought it up w/ the community, whether we want to migrate pre-graduation, and (therefore) want to go straight to subversion.a.o) Thanks, -g On Tue, Nov 10, 2009 at 14:36, Deepal jayasinghe wrote: > How about the website ? (I can not find any information about the > project, mentors, committers etc.. ) > > http://incubator.apache.org/projects/subversion.html > > -Deepal >> There are two other issues to discuss for the Subversion podling: >> >> * moving the mailing lists directly to @subversion.apache.org >> * placing the source code at /subversion/ rather than /incubator/subversion/ >> >> We are hoping to minimize overall disruption to the community with a >> move to incubator space, then a move to apache space. >> >> Cheers, >> -g >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> > > > -- > Thank you! > > > http://blogs.deepal.org > http://deepal.org > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
Personally i am ok with #1, but i am not sure if "svn switch --relocate" too much of a burden for you guys :) On 11/10/2009 02:27 PM, Greg Stein wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
How about the website ? (I can not find any information about the project, mentors, committers etc.. ) http://incubator.apache.org/projects/subversion.html -Deepal > There are two other issues to discuss for the Subversion podling: > > * moving the mailing lists directly to @subversion.apache.org > * placing the source code at /subversion/ rather than /incubator/subversion/ > > We are hoping to minimize overall disruption to the community with a > move to incubator space, then a move to apache space. > > Cheers, > -g > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > -- Thank you! http://blogs.deepal.org http://deepal.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 14:23, Garrett Rooney
wrote:
> On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann
> wrote:
>> On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato
>> wrote:
>>
>>> Subversion client and server that doesn't use a DAV layer at all. The
>>> Subversion community has never released binaries -- ever -- not do we plan
>>> to.
>>
>> That would a completely new philosophy for an Apache project, which always
>> aimed
>> very heavily on distributions. It might either enforce to look at
>> legal aspects in a
>> different view - or lead to changing your philosophy. :-) Personally,
>> I don't see any
>> reason why things like creation of Windows binaries should be left to
>> outsiders. (Apart
>> from CollabNets business interests, which I wouldn't like to count.)
>
> Umm, how is it a "completely new philosophy for an Apache project"?
> There are a number of Apache projects that ship source without
> official binaries. APR and the Apache HTTPD server are two prime
> examples.
>
> Don't assume that the way the projects you're familiar with are run is
> the only way to run ASF projects.
Maybe it is the difference between shipping .jar files and (say)
Windows executables? I can easily see a misunderstanding there ("why
ship just .java files? why not a .jar?")
Cheers,
-g
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Two other issues to discuss for Subversion
There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann wrote: > On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: > >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. > > That would a completely new philosophy for an Apache project, which always > aimed > very heavily on distributions. It might either enforce to look at > legal aspects in a > different view - or lead to changing your philosophy. :-) Personally, > I don't see any > reason why things like creation of Windows binaries should be left to > outsiders. (Apart > from CollabNets business interests, which I wouldn't like to count.) Umm, how is it a "completely new philosophy for an Apache project"? There are a number of Apache projects that ship source without official binaries. APR and the Apache HTTPD server are two prime examples. Don't assume that the way the projects you're familiar with are run is the only way to run ASF projects. -garrett - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
Consider this withdrawn for now. I'll resubmit when we think we're nearing time for graduation. Cheers, -g On Tue, Nov 10, 2009 at 13:17, Greg Stein wrote: > Hello IPMC, > > The Subversion podling would like a waiver of the requirement to make > a release before graduation. > > As we understand this requirement, it is present in order to > demonstrate to the podling how releases are made at the ASF. > Packaging, licensing, signing, placement into the distrubtion/mirror > system, announcements, among others[1]. We believe that the Subversion > community already has a deep understanding of the Apache release > model, based on the following qualifications of several of its > committers/mentors: > > * Greg Stein has been a committer at Apache since before the > Foundation was started. He has been involved in releases of httpd and > APR, including time as Release Manager (RM) for APR. He helped to > establish the APR TLP and the Commons TLP (prior incarnation; now > defunct). Greg wrote the versioning guidelines for APR, which are also > in use by the Subversion project. Through his 8+ years on the Board, > he has read and reviewed reports from across the ASF about release, > IP, and infrastructure issues. > > * Justin Erenkrantz has been a committer since 2001, contributing to > httpd and APR, along with mentoring the stdcxx project when it was in > the Incubator. He has been the RM for both httpd and APR. In fact, > Justin wrote the initial guidelines for the release of httpd. Justin > has been part of Infrastructure almost since its inception as a > distinct group, which includes the provision of all the facilities to > actually make and distribute ASF releases. Justin has spent many years > on the Board, providing further insight to releases across the > Foundation. > > * Sander Striker has been a committer since 2001, contributing to APR > and then httpd. Sander acted as the RM for httpd releases, and also > held a stint as the VP for httpd. Add in his time spent with > Infrastructure and the Board, and he's been observing ASF releases for > many years. > > * Garrett Rooney has been a committer since 2004, contributing and > making releases of APR, and committing to httpd. He was also the VP of > APR for several years, and has mentored two Incubating projects. > > * Daniel Rall has been a committer since 2001, contributing to many > projects: Turbine, Fulcrum, Torque, and numerous Jakarta Commons > projects. He established the community around XML-RPC, brought it > through the Incubator, and maintained it for several years within the > XML Project. He also participated in some of the bootstrapping around > the Velocity and Maven projects, and participated on the Infra team. > > The Subversion community's belief is that we have ample experience to > guide us in making a release, when that time is arrives. There will > certainly be variances (e.g. mirroring) from our current established > procedures[2], but some simple fine-tuning should resolve that. The > bulk of the existing release process already meets and exceeds that a > typical Apache release. Niclas Hedman pointed out that the Subversion > community has produced 32 releases over the past four years, which > hopefully indicates a smooth, understood, and functional release > process. > > Cheers, > -g > > [1] one particular item is using a release as a gating/focal point for > legal review, but we feel that can be performed as an action > separate/distinct from performing a release > [2] http://subversion.tigris.org/release-process.html > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
- Original Message > From: Greg Stein > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 11:00:07 AM > Subject: Re: [VOTE] Request for Waiver of "Make a Release" requirement for > Incubator graduation > > On Tue, Nov 10, 2009 at 13:54, Joe Schaefer wrote: > > - Original Message > > > >> From: Luciano Resende > >> To: general@incubator.apache.org > >> Sent: Tue, November 10, 2009 10:51:44 AM > >> Subject: Re: [VOTE] Request for Waiver of "Make a Release" requirement for > Incubator graduation > >> > >> On Tue, Nov 10, 2009 at 10:17 AM, Greg Stein wrote: > >> > Hello IPMC, > >> > > >> > The Subversion podling would like a waiver of the requirement to make > >> > a release before graduation. > >> > > >> > As we understand this requirement, it is present in order to > >> > demonstrate to the podling how releases are made at the ASF. > >> > Packaging, licensing, signing, placement into the distrubtion/mirror > >> > system, announcements, among others[1]. We believe that the Subversion > >> > community already has a deep understanding of the Apache release > >> > model, based on the following qualifications of several of its > >> > committers/mentors: > >> > > >> > >> Should we hold this vote to actually graduation time ? Would it be > >> better to spend some of these debating energy to actually setup the > >> Subversion podling into the Apache infrastructure, as currently I see > >> no mailing lists, svn code import, etc... create the proper Apache > >> user accounts for the several new committers, etc and maybe still give > >> a chance to add new contributors... before worrying about this... > > > > Agreed. Starting the ball rolling by requesting a bunch of waivers is > > personally off-putting and bureaucratic. Something I'd like to see less > > off in the Incubator. > > /me shrugs > > Releases are the topic of the day. I wanted to get that whole > discussion behind us, and move onto something constructive. I understand the rationale, but as others point out the request feels premature. IMO this won't put anything to rest, as people who insist on a release as an exit requirement will vote -1 twice now instead of once (for the graduation vote). I support the needs you have outlined for the subversion project in regards to domain names, etc. *because* the mentors are going to work to push this thru the IPMC in record time. If it turns out the mentors fail in this effort I will be personally disappointed in them and more reluctant to consider special cases for the Incubator in the future. This does mean the mentors also need to gather consensus within the IPMC as well as the Subversion project to agree on graduation concerns. The tactful approach is via early and open discussion, not formal preagreements. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
I agree with the following, i don't think a waiver is needed right now... > "This is a graduation issue, why can't it just wait > until then and say in the graduation proposal there's not been a > release but its not necessary because of x y z." thanks, dims On 11/10/2009 01:49 PM, ant elder wrote: On Tue, Nov 10, 2009 at 6:17 PM, Greg Stein wrote: Hello IPMC, The Subversion podling would like a waiver of the requirement to make a release before graduation. As we understand this requirement, it is present in order to demonstrate to the podling how releases are made at the ASF. Packaging, licensing, signing, placement into the distrubtion/mirror system, announcements, among others[1]. We believe that the Subversion community already has a deep understanding of the Apache release model, based on the following qualifications of several of its committers/mentors: * Greg Stein has been a committer at Apache since before the Foundation was started. He has been involved in releases of httpd and APR, including time as Release Manager (RM) for APR. He helped to establish the APR TLP and the Commons TLP (prior incarnation; now defunct). Greg wrote the versioning guidelines for APR, which are also in use by the Subversion project. Through his 8+ years on the Board, he has read and reviewed reports from across the ASF about release, IP, and infrastructure issues. * Justin Erenkrantz has been a committer since 2001, contributing to httpd and APR, along with mentoring the stdcxx project when it was in the Incubator. He has been the RM for both httpd and APR. In fact, Justin wrote the initial guidelines for the release of httpd. Justin has been part of Infrastructure almost since its inception as a distinct group, which includes the provision of all the facilities to actually make and distribute ASF releases. Justin has spent many years on the Board, providing further insight to releases across the Foundation. * Sander Striker has been a committer since 2001, contributing to APR and then httpd. Sander acted as the RM for httpd releases, and also held a stint as the VP for httpd. Add in his time spent with Infrastructure and the Board, and he's been observing ASF releases for many years. * Garrett Rooney has been a committer since 2004, contributing and making releases of APR, and committing to httpd. He was also the VP of APR for several years, and has mentored two Incubating projects. * Daniel Rall has been a committer since 2001, contributing to many projects: Turbine, Fulcrum, Torque, and numerous Jakarta Commons projects. He established the community around XML-RPC, brought it through the Incubator, and maintained it for several years within the XML Project. He also participated in some of the bootstrapping around the Velocity and Maven prtingojects, and participated on the Infra team. The Subversion community's belief is that we have ample experience to guide us in making a release, when that time is arrives. There will certainly be variances (e.g. mirroring) from our current established procedures[2], but some simple fine-tuning should resolve that. The bulk of the existing release process already meets and exceeds that a typical Apache release. Niclas Hedman pointed out that the Subversion community has produced 32 releases over the past four years, which hopefully indicates a smooth, understood, and functional release process. Cheers, -g [1] one particular item is using a release as a gating/focal point for legal review, but we feel that can be performed as an action separate/distinct from performing a release [2] http://subversion.tigris.org/release-process.html -0 I'm not at all familiar with how the Subversion project works so as an IPMC member I don't see how I can decide this before they've even started incubating. This is a graduation issue, why can't it just wait until then and say in the graduation proposal there's not been a release but its not necessary because of x y z. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
On Tue, Nov 10, 2009 at 13:51, Luciano Resende wrote: > On Tue, Nov 10, 2009 at 10:17 AM, Greg Stein wrote: >> Hello IPMC, >> >> The Subversion podling would like a waiver of the requirement to make >> a release before graduation. >> >> As we understand this requirement, it is present in order to >> demonstrate to the podling how releases are made at the ASF. >> Packaging, licensing, signing, placement into the distrubtion/mirror >> system, announcements, among others[1]. We believe that the Subversion >> community already has a deep understanding of the Apache release >> model, based on the following qualifications of several of its >> committers/mentors: >> > > Should we hold this vote to actually graduation time ? Would it be > better to spend some of these debating energy to actually setup the > Subversion podling into the Apache infrastructure, as currently I see > no mailing lists, svn code import, etc... create the proper Apache > user accounts for the several new committers, etc and maybe still give > a chance to add new contributors... before worrying about this... We're three days into incubation. Votes are still running on the form for the repository, which bug tracker, mailing list migration, etc. While that discussion/voting is running, I can deal with some of these other issues dealing with graduation. ICLAs are arriving, the repos should be imported within a couple weeks, and account requests will go out in bulk before then. I'm simply trying to parallelize the many tasks. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
On Tue, Nov 10, 2009 at 13:54, Joe Schaefer wrote: > - Original Message > >> From: Luciano Resende >> To: general@incubator.apache.org >> Sent: Tue, November 10, 2009 10:51:44 AM >> Subject: Re: [VOTE] Request for Waiver of "Make a Release" requirement for >> Incubator graduation >> >> On Tue, Nov 10, 2009 at 10:17 AM, Greg Stein wrote: >> > Hello IPMC, >> > >> > The Subversion podling would like a waiver of the requirement to make >> > a release before graduation. >> > >> > As we understand this requirement, it is present in order to >> > demonstrate to the podling how releases are made at the ASF. >> > Packaging, licensing, signing, placement into the distrubtion/mirror >> > system, announcements, among others[1]. We believe that the Subversion >> > community already has a deep understanding of the Apache release >> > model, based on the following qualifications of several of its >> > committers/mentors: >> > >> >> Should we hold this vote to actually graduation time ? Would it be >> better to spend some of these debating energy to actually setup the >> Subversion podling into the Apache infrastructure, as currently I see >> no mailing lists, svn code import, etc... create the proper Apache >> user accounts for the several new committers, etc and maybe still give >> a chance to add new contributors... before worrying about this... > > Agreed. Starting the ball rolling by requesting a bunch of waivers is > personally off-putting and bureaucratic. Something I'd like to see less > off in the Incubator. /me shrugs Releases are the topic of the day. I wanted to get that whole discussion behind us, and move onto something constructive. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
Before graduation, I expect ALL podlings to, at some point, present the Incubator PMC with some artifacts that the podling community feels meets the Apache legal requirements. I don't care if said artifacts are a "release" or a nightly snapshot or a one off, but I expect to see such artifacts as part of the incubation process. Such review is to ensure that the podling has properly understood the legal bits. That IS part of the Incubator PMC's tasks. I'm not really sure if this is a -1 or a +1. I don't care about an actual release, but I do care about making sure artifacts are presented to the IPMC for complete review prior to graduation. Dan On Tue November 10 2009 1:17:41 pm Greg Stein wrote: > Hello IPMC, > > The Subversion podling would like a waiver of the requirement to make > a release before graduation. > > As we understand this requirement, it is present in order to > demonstrate to the podling how releases are made at the ASF. > Packaging, licensing, signing, placement into the distrubtion/mirror > system, announcements, among others[1]. We believe that the Subversion > community already has a deep understanding of the Apache release > model, based on the following qualifications of several of its > committers/mentors: > > * Greg Stein has been a committer at Apache since before the > Foundation was started. He has been involved in releases of httpd and > APR, including time as Release Manager (RM) for APR. He helped to > establish the APR TLP and the Commons TLP (prior incarnation; now > defunct). Greg wrote the versioning guidelines for APR, which are also > in use by the Subversion project. Through his 8+ years on the Board, > he has read and reviewed reports from across the ASF about release, > IP, and infrastructure issues. > > * Justin Erenkrantz has been a committer since 2001, contributing to > httpd and APR, along with mentoring the stdcxx project when it was in > the Incubator. He has been the RM for both httpd and APR. In fact, > Justin wrote the initial guidelines for the release of httpd. Justin > has been part of Infrastructure almost since its inception as a > distinct group, which includes the provision of all the facilities to > actually make and distribute ASF releases. Justin has spent many years > on the Board, providing further insight to releases across the > Foundation. > > * Sander Striker has been a committer since 2001, contributing to APR > and then httpd. Sander acted as the RM for httpd releases, and also > held a stint as the VP for httpd. Add in his time spent with > Infrastructure and the Board, and he's been observing ASF releases for > many years. > > * Garrett Rooney has been a committer since 2004, contributing and > making releases of APR, and committing to httpd. He was also the VP of > APR for several years, and has mentored two Incubating projects. > > * Daniel Rall has been a committer since 2001, contributing to many > projects: Turbine, Fulcrum, Torque, and numerous Jakarta Commons > projects. He established the community around XML-RPC, brought it > through the Incubator, and maintained it for several years within the > XML Project. He also participated in some of the bootstrapping around > the Velocity and Maven projects, and participated on the Infra team. > > The Subversion community's belief is that we have ample experience to > guide us in making a release, when that time is arrives. There will > certainly be variances (e.g. mirroring) from our current established > procedures[2], but some simple fine-tuning should resolve that. The > bulk of the existing release process already meets and exceeds that a > typical Apache release. Niclas Hedman pointed out that the Subversion > community has produced 32 releases over the past four years, which > hopefully indicates a smooth, understood, and functional release > process. > > Cheers, > -g > > [1] one particular item is using a release as a gating/focal point for > legal review, but we feel that can be performed as an action > separate/distinct from performing a release > [2] http://subversion.tigris.org/release-process.html > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
- Original Message > From: Luciano Resende > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 10:51:44 AM > Subject: Re: [VOTE] Request for Waiver of "Make a Release" requirement for > Incubator graduation > > On Tue, Nov 10, 2009 at 10:17 AM, Greg Stein wrote: > > Hello IPMC, > > > > The Subversion podling would like a waiver of the requirement to make > > a release before graduation. > > > > As we understand this requirement, it is present in order to > > demonstrate to the podling how releases are made at the ASF. > > Packaging, licensing, signing, placement into the distrubtion/mirror > > system, announcements, among others[1]. We believe that the Subversion > > community already has a deep understanding of the Apache release > > model, based on the following qualifications of several of its > > committers/mentors: > > > > Should we hold this vote to actually graduation time ? Would it be > better to spend some of these debating energy to actually setup the > Subversion podling into the Apache infrastructure, as currently I see > no mailing lists, svn code import, etc... create the proper Apache > user accounts for the several new committers, etc and maybe still give > a chance to add new contributors... before worrying about this... Agreed. Starting the ball rolling by requesting a bunch of waivers is personally off-putting and bureaucratic. Something I'd like to see less off in the Incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
On Tue, Nov 10, 2009 at 10:17 AM, Greg Stein wrote: > Hello IPMC, > > The Subversion podling would like a waiver of the requirement to make > a release before graduation. > > As we understand this requirement, it is present in order to > demonstrate to the podling how releases are made at the ASF. > Packaging, licensing, signing, placement into the distrubtion/mirror > system, announcements, among others[1]. We believe that the Subversion > community already has a deep understanding of the Apache release > model, based on the following qualifications of several of its > committers/mentors: > Should we hold this vote to actually graduation time ? Would it be better to spend some of these debating energy to actually setup the Subversion podling into the Apache infrastructure, as currently I see no mailing lists, svn code import, etc... create the proper Apache user accounts for the several new committers, etc and maybe still give a chance to add new contributors... before worrying about this... -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Greg Stein wrote: > I have no idea why the term "Board" even comes up in your response. > What's that got to do with my problems with the IPMC attempting to > impose make-work on the svn podling? Because when you post to a broad-list such as general@, you are communicating to all incubating podlings and many graduated (or sadly, retired) podlings as well. This is one very broad list where it's not possible to be a hat-flipper; your opinions necessarily carry the weight of a Director of the Foundation (until you hide out on a dev list ;-) Nobody was demanding make-work, you were demanding fast-track graduation. And then you flipped off the handle after someone suggested that the project demonstrate all the IP notices in an 'example package' had been correctly adjusted, relative to its new home. That was all. Nobody was expecting svn to do anything that hasn't been asked of all other recent podlings, and I hope they won't still. Please don't rant. Tweak if the process is wrong [for every podling to become aware of] or ask for justified exceptions, as you just did. Bill - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
On Tue, Nov 10, 2009 at 6:17 PM, Greg Stein wrote: > Hello IPMC, > > The Subversion podling would like a waiver of the requirement to make > a release before graduation. > > As we understand this requirement, it is present in order to > demonstrate to the podling how releases are made at the ASF. > Packaging, licensing, signing, placement into the distrubtion/mirror > system, announcements, among others[1]. We believe that the Subversion > community already has a deep understanding of the Apache release > model, based on the following qualifications of several of its > committers/mentors: > > * Greg Stein has been a committer at Apache since before the > Foundation was started. He has been involved in releases of httpd and > APR, including time as Release Manager (RM) for APR. He helped to > establish the APR TLP and the Commons TLP (prior incarnation; now > defunct). Greg wrote the versioning guidelines for APR, which are also > in use by the Subversion project. Through his 8+ years on the Board, > he has read and reviewed reports from across the ASF about release, > IP, and infrastructure issues. > > * Justin Erenkrantz has been a committer since 2001, contributing to > httpd and APR, along with mentoring the stdcxx project when it was in > the Incubator. He has been the RM for both httpd and APR. In fact, > Justin wrote the initial guidelines for the release of httpd. Justin > has been part of Infrastructure almost since its inception as a > distinct group, which includes the provision of all the facilities to > actually make and distribute ASF releases. Justin has spent many years > on the Board, providing further insight to releases across the > Foundation. > > * Sander Striker has been a committer since 2001, contributing to APR > and then httpd. Sander acted as the RM for httpd releases, and also > held a stint as the VP for httpd. Add in his time spent with > Infrastructure and the Board, and he's been observing ASF releases for > many years. > > * Garrett Rooney has been a committer since 2004, contributing and > making releases of APR, and committing to httpd. He was also the VP of > APR for several years, and has mentored two Incubating projects. > > * Daniel Rall has been a committer since 2001, contributing to many > projects: Turbine, Fulcrum, Torque, and numerous Jakarta Commons > projects. He established the community around XML-RPC, brought it > through the Incubator, and maintained it for several years within the > XML Project. He also participated in some of the bootstrapping around > the Velocity and Maven prtingojects, and participated on the Infra team. > > The Subversion community's belief is that we have ample experience to > guide us in making a release, when that time is arrives. There will > certainly be variances (e.g. mirroring) from our current established > procedures[2], but some simple fine-tuning should resolve that. The > bulk of the existing release process already meets and exceeds that a > typical Apache release. Niclas Hedman pointed out that the Subversion > community has produced 32 releases over the past four years, which > hopefully indicates a smooth, understood, and functional release > process. > > Cheers, > -g > > [1] one particular item is using a release as a gating/focal point for > legal review, but we feel that can be performed as an action > separate/distinct from performing a release > [2] http://subversion.tigris.org/release-process.html > -0 I'm not at all familiar with how the Subversion project works so as an IPMC member I don't see how I can decide this before they've even started incubating. This is a graduation issue, why can't it just wait until then and say in the graduation proposal there's not been a release but its not necessary because of x y z. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
Greg Stein wrote: > > The Subversion podling would like a waiver of the requirement to make > a release before graduation. > > As we understand this requirement, it is present in order to > demonstrate to the podling how releases are made at the ASF. > Packaging, licensing, signing, placement into the distrubtion/mirror > system, announcements, among others[1]. We believe that the Subversion > community already has a deep understanding of the Apache release > model +1; this checkpoint isn't needed for this specific project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Joe Schaefer wrote: > - Original Message > >> From: William A. Rowe Jr. >> To: general@incubator.apache.org >> Sent: Tue, November 10, 2009 10:08:40 AM >> Subject: Re: Insanity. Apache Incubator should be about education (was: >> [PROPOSAL][VOTE] Subversion) > >> Greg wrote: >>> Look at the context. Being asked to throw together some bits for a >>> "release". Oh, just any bits will do. But wait, since they aren't >>> quite proper, you don't really have to announce it to users. ... come >>> on, that is not education. That isn't teaching anybody anything. >> We don't disagree. So stick around long enough to make a real release that >> the Incubator PMC can validate, or come to a reasonable exception that the >> Incubator can accept. But don't go flying off into rants about process that >> the board has *charged* the Incubator with defining and enforcing :) > > Wait a second Bill. In the not-too-distant past there was no requirement > for a podling to cut a release. Infrastructure people pushed for there to > be one, and pushed to have the incubator releases on the mirrors, because it > turns out prior graduating projects needed to be trained by infra on how to > do this properly. They also needed to be alert for licensing snafus, that was why I support[ed] the 'requirement'. > The purpose of doing a release within the incubator has now morphed into > something a bit different, and not entirely for the better. I have been > paying attention to subversion release processes for years, and frankly we > should be adopting *their* methods here at Apache. We don't have anything > to teach them other than mirror mechanics, and that can be learned post- > graduation. Agreed in this case, w.r.t. SVN. But in the general case, this is still best taught while at the incubator. I'm responding to Greg's rant, not to a well-stated, well-reasoned appeal for an exception. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Mark Phippard wrote: > > I do not believe the project wants to be in the business of providing > binaries and we have an existing ecosystem of people that are > providing them successfully. As long as non-committer artifacts aren't hosted here, that is no trouble. If nobody on SVN wants to create them for shipping from the ASF dist pages then that is what will happen, none will ship :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Branko Čibej wrote: > > Wait a minute. Are you implying that the "project" *should* release > binaries? Wouldn't such a requirement apply to, say, APR, to keep this > close to home? s/should/may/ Greg pointed out I make win32 binaries and these are not mandated, I do so only because I trusted that typical win32 users wouldn't know a compiler if it bit them on the toe, and the httpd project/ASF lets me do this -for the project-. Yes, the release is a bunch of source code. The resulting binaries (or .jar file or whatever) is simply an artifact but is provided by the ASF, not I personally. My point is that we categorically do not host outside party binaries here (if you want, invite them to become committers). We need them bound by a CLA before an artifact they roll is posted on ASF infrastructure. > Certainly any volunteer with proper karma can build binaries from the > release tarballs, and if those binaries happen to pass muster wrt > ASF-mandated legalities, then from my understanding it should be OK to > host such binaries on ASF's infrastructure. But that's not the same as > the project releasing those binaries -- lack of digital sigs on them is > a dead giveaway. Howso? > How many APR and/or httpd commiters sign your Windows binary packages? Only one; my own gpg key, look at that chain of trust and you'll find at least 2 more httpd (apr) committers who have signed that key. I have never released any artifacts - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
I have no idea why the term "Board" even comes up in your response. What's that got to do with my problems with the IPMC attempting to impose make-work on the svn podling? On Tue, Nov 10, 2009 at 13:03, William A. Rowe Jr. wrote: > Greg Stein wrote: >> On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. >> wrote: >>> Greg Stein wrote: Podlings should be shepherded *out* rather than held *in*. >>> Hmmm... here you go again. Do you really believe there's a mentor here >>> who doesn't want to be 'done' with their task at hand, offering up a >>> functioning project for graduation? Mentors -do- exactly this, which >>> is why your rants continue to read as disingenuous and insulting. >> >> I'm not talking about mentors' desire to do this. I'm talking about >> the structures that appear to be in place which work *against* >> incubation and graduation. >> >> And if you want to call a rant against meaningless constraints and >> bureaucracy "insulting", then I'm okay with that. > > The fact is that mentors fix the process when it's broke. If there is > useless/worthless/redundant process going on here, then terrific! Tell > us, as a voice of the Board, what the Board is telling us we can drop. > > Or said another way, "patches welcome". > > I'm all for less work and less hassles. We would be happy to rubber stamp > our way all the way through graduation, if we believed that it build the > projects which would remain viable and preserve ASF culture into this > coming decade. > >>> We are glad the board has such confidence that the Incubator is producing >>> effect meritocracies that collaborate effectively. If your's is not the >>> minority opinion, there is a much larger 'Insanity' thread to begin, which >>> starts with [VOTE] and ends in "Dissolve Incubator?" >> >> My point above was the Board, at least in the past(*), has *not* been >> happy about the average duration. Go poll the Board today, if you'd >> like. > > Happiness and constructive feedback are orthogonal here. The board (or one > or more board members) have rang in on specific issues, and helped make some > problems go away, and created others. Feel free to constructively participate > in refining that process. > >> AFAIK, the Board has never expressed a lack of confidence in the >> Incubator, other than duration. > > That's good to hear, now bring us more suggestions that don't stack on > additional bureaucracy or bullet items to the process :) But don't sit and > holler that what has evolved is worthless. Launch a constructive dialog > about fine tuning it; evolution is an ongoing process. > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 13:02, Jukka Zitting wrote: > Hi, > > On Tue, Nov 10, 2009 at 7:40 PM, Greg Stein wrote: >> We're making a 1.6.7 release in the next 2-3 weeks, as I stated >> before. The Incubator can see how that works (I also gave pointers to >> 1.6.6). > > +1 Since Subversion release procedures already meet most Apache > policies, reviewing any past release and asking the Subversion > community for a plan on how to fix any potential issues should be > enough to satisfy concerns about the release process. I've formally asked for a Waiver of the release requirement. See another thread. > In fact our formal exit criteria [1] only requires that "release plans > are developed and executed in public by the community". There is no > fixed requirement that at least one incubating release really must > happen (there's just a question on whether such a requirement should > exist). Of course for most projects doing a release is the easiest way > to demonstrate that this and many other exit criteria have been > satisfied. > > [1] > http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements Unfortunately, some documentation needs to be brought in sync. See: http://incubator.apache.org/guides/graduation.html#checklist Per Joe, I think it makes sense to run podlings through a release to teach them the ropes, rather than lump that onto Infrastructure. But I also believe we should provide waivers when appropriate. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 13:11, William A. Rowe Jr. wrote: > Greg Stein wrote: >> >> The IPMC is in charge of its operation. It can redefine the rules of >> releases as it pleases. The three +1 rule was developed to show that >> the PMC is "in charge" of the release, and is therefore legally liable >> for it. The IPMC can do whatever it likes around releases, as long as >> that process specifically claims or disclaims liability. > > The only individuals empowered to act on the foundation's behalf are > members of committees. With the exception of board committees which > are empowered to form subcommittees, all such individuals must be > ratified (either by resolution or our favorite ACK game) by the BoD. > > A vote by 3 PPMC members is therefore not binding, not unless the board > is prepared to ack/nak all appointments to PPMC's within Incubator. Understood. Nobody proposed that. I believe you missed the part of another +1 from an IPMC member. -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
- Original Message > From: William A. Rowe Jr. > To: general@incubator.apache.org > Sent: Tue, November 10, 2009 10:08:40 AM > Subject: Re: Insanity. Apache Incubator should be about education (was: > [PROPOSAL][VOTE] Subversion) > Greg wrote: > > Look at the context. Being asked to throw together some bits for a > > "release". Oh, just any bits will do. But wait, since they aren't > > quite proper, you don't really have to announce it to users. ... come > > on, that is not education. That isn't teaching anybody anything. > > We don't disagree. So stick around long enough to make a real release that > the Incubator PMC can validate, or come to a reasonable exception that the > Incubator can accept. But don't go flying off into rants about process that > the board has *charged* the Incubator with defining and enforcing :) Wait a second Bill. In the not-too-distant past there was no requirement for a podling to cut a release. Infrastructure people pushed for there to be one, and pushed to have the incubator releases on the mirrors, because it turns out prior graduating projects needed to be trained by infra on how to do this properly. The purpose of doing a release within the incubator has now morphed into something a bit different, and not entirely for the better. I have been paying attention to subversion release processes for years, and frankly we should be adopting *their* methods here at Apache. We don't have anything to teach them other than mirror mechanics, and that can be learned post- graduation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Request for Waiver of "Make a Release" requirement for Incubator graduation
Hello IPMC, The Subversion podling would like a waiver of the requirement to make a release before graduation. As we understand this requirement, it is present in order to demonstrate to the podling how releases are made at the ASF. Packaging, licensing, signing, placement into the distrubtion/mirror system, announcements, among others[1]. We believe that the Subversion community already has a deep understanding of the Apache release model, based on the following qualifications of several of its committers/mentors: * Greg Stein has been a committer at Apache since before the Foundation was started. He has been involved in releases of httpd and APR, including time as Release Manager (RM) for APR. He helped to establish the APR TLP and the Commons TLP (prior incarnation; now defunct). Greg wrote the versioning guidelines for APR, which are also in use by the Subversion project. Through his 8+ years on the Board, he has read and reviewed reports from across the ASF about release, IP, and infrastructure issues. * Justin Erenkrantz has been a committer since 2001, contributing to httpd and APR, along with mentoring the stdcxx project when it was in the Incubator. He has been the RM for both httpd and APR. In fact, Justin wrote the initial guidelines for the release of httpd. Justin has been part of Infrastructure almost since its inception as a distinct group, which includes the provision of all the facilities to actually make and distribute ASF releases. Justin has spent many years on the Board, providing further insight to releases across the Foundation. * Sander Striker has been a committer since 2001, contributing to APR and then httpd. Sander acted as the RM for httpd releases, and also held a stint as the VP for httpd. Add in his time spent with Infrastructure and the Board, and he's been observing ASF releases for many years. * Garrett Rooney has been a committer since 2004, contributing and making releases of APR, and committing to httpd. He was also the VP of APR for several years, and has mentored two Incubating projects. * Daniel Rall has been a committer since 2001, contributing to many projects: Turbine, Fulcrum, Torque, and numerous Jakarta Commons projects. He established the community around XML-RPC, brought it through the Incubator, and maintained it for several years within the XML Project. He also participated in some of the bootstrapping around the Velocity and Maven projects, and participated on the Infra team. The Subversion community's belief is that we have ample experience to guide us in making a release, when that time is arrives. There will certainly be variances (e.g. mirroring) from our current established procedures[2], but some simple fine-tuning should resolve that. The bulk of the existing release process already meets and exceeds that a typical Apache release. Niclas Hedman pointed out that the Subversion community has produced 32 releases over the past four years, which hopefully indicates a smooth, understood, and functional release process. Cheers, -g [1] one particular item is using a release as a gating/focal point for legal review, but we feel that can be performed as an action separate/distinct from performing a release [2] http://subversion.tigris.org/release-process.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
Greg Stein wrote: > > The IPMC is in charge of its operation. It can redefine the rules of > releases as it pleases. The three +1 rule was developed to show that > the PMC is "in charge" of the release, and is therefore legally liable > for it. The IPMC can do whatever it likes around releases, as long as > that process specifically claims or disclaims liability. The only individuals empowered to act on the foundation's behalf are members of committees. With the exception of board committees which are empowered to form subcommittees, all such individuals must be ratified (either by resolution or our favorite ACK game) by the BoD. A vote by 3 PPMC members is therefore not binding, not unless the board is prepared to ack/nak all appointments to PPMC's within Incubator. Again, I still am not suggesting we want to take this one way or another. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Greg Stein wrote: > On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. > wrote: > >> Quite frankly, all svncorp releases could, with reasonable documentation >> [read: mailing list archives, CLA's and code grant] be licensed as ASF >> releases under the AL 2.0, irrespective of their internal artifact >> copyright statements. > > I doubt it. Those old releases are signed tarballs. We can't "reach > in" and alter the LICENSE file without re-signing the whole tarball, > and I think that would be a very bad idea. We don't. I didn't say re-licensed; I said additionally licensed. It's as simple as putting the tarballs into a directory which says "XYZ are further licensed under the Apache License 2.0". Nothing needs to be altered to give users a license. >> A proviso that 1.7.0 won't be approved without running it through RAT, >> either pre or post graduation seems sufficient. The process is better >> documented than 95% of ASF project release processes, so there's no issue. > > RAT can be run right now, and the podling can work against its > results. No issue there. The *release* of "something" is my pain > point. +1; although we both know that extra artifacts 'appear' magically during most assembly processes, and that has bit us before. > And yes, the PMC that will manage the svn project can/should have a > responsibility to use RAT. But if you "make that rule", then you > better impose it upon every PMC here at the ASF. That's effectively > what you're saying :-) No, I'm saying give SVN a pass on demonstrating the [already demonstrated] ability to have an effective release process; *contingent* upon running RAT on the first release artifact created after graduation. That's what I am saying. >> But ranting against your perception of Incubator's failure to EDUCATE and >> TEACH podlings how the ASF environment works is really quite disappointing, >> coming from you. > > Look at the context. Being asked to throw together some bits for a > "release". Oh, just any bits will do. But wait, since they aren't > quite proper, you don't really have to announce it to users. ... come > on, that is not education. That isn't teaching anybody anything. We don't disagree. So stick around long enough to make a real release that the Incubator PMC can validate, or come to a reasonable exception that the Incubator can accept. But don't go flying off into rants about process that the board has *charged* the Incubator with defining and enforcing :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Greg Stein wrote: > On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. > wrote: >> Greg Stein wrote: >>> >>> Podlings should be shepherded *out* rather than held *in*. >> Hmmm... here you go again. Do you really believe there's a mentor here >> who doesn't want to be 'done' with their task at hand, offering up a >> functioning project for graduation? Mentors -do- exactly this, which >> is why your rants continue to read as disingenuous and insulting. > > I'm not talking about mentors' desire to do this. I'm talking about > the structures that appear to be in place which work *against* > incubation and graduation. > > And if you want to call a rant against meaningless constraints and > bureaucracy "insulting", then I'm okay with that. The fact is that mentors fix the process when it's broke. If there is useless/worthless/redundant process going on here, then terrific! Tell us, as a voice of the Board, what the Board is telling us we can drop. Or said another way, "patches welcome". I'm all for less work and less hassles. We would be happy to rubber stamp our way all the way through graduation, if we believed that it build the projects which would remain viable and preserve ASF culture into this coming decade. >> We are glad the board has such confidence that the Incubator is producing >> effect meritocracies that collaborate effectively. If your's is not the >> minority opinion, there is a much larger 'Insanity' thread to begin, which >> starts with [VOTE] and ends in "Dissolve Incubator?" > > My point above was the Board, at least in the past(*), has *not* been > happy about the average duration. Go poll the Board today, if you'd > like. Happiness and constructive feedback are orthogonal here. The board (or one or more board members) have rang in on specific issues, and helped make some problems go away, and created others. Feel free to constructively participate in refining that process. > AFAIK, the Board has never expressed a lack of confidence in the > Incubator, other than duration. That's good to hear, now bring us more suggestions that don't stack on additional bureaucracy or bullet items to the process :) But don't sit and holler that what has evolved is worthless. Launch a constructive dialog about fine tuning it; evolution is an ongoing process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Hi, On Tue, Nov 10, 2009 at 7:40 PM, Greg Stein wrote: > We're making a 1.6.7 release in the next 2-3 weeks, as I stated > before. The Incubator can see how that works (I also gave pointers to > 1.6.6). +1 Since Subversion release procedures already meet most Apache policies, reviewing any past release and asking the Subversion community for a plan on how to fix any potential issues should be enough to satisfy concerns about the release process. In fact our formal exit criteria [1] only requires that "release plans are developed and executed in public by the community". There is no fixed requirement that at least one incubating release really must happen (there's just a question on whether such a requirement should exist). Of course for most projects doing a release is the easiest way to demonstrate that this and many other exit criteria have been satisfied. [1] http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 12:52 PM, William A. Rowe Jr. wrote: > Mark Phippard wrote: >> >> I gave counsel to the Eclipse Foundation and explained that they could >> provide a fully functioning JavaHL library to users with only EPL >> compatible code. Basically, you just need to build without Neon, BDB >> and libintl support. Of the three, the only thing an Eclipse client >> user needs is Neon, and Serf serves as a viable replacement. I do not >> know why they never chose to release a binary built this way. I can >> only assume that Igor and Polarion did not want to make these >> binaries. > > I suspect IBM's ICU lib could be substituted for libintl, and as there is > some traction on the idea of dumping apr-iconv, this would be a sensible > thing (since ICU is the heir apparent for non-iconv based platforms). We use this for translating error messages etc. I do not recall ICU having a feature like that. Not to mention how big it is. We have talked about using ICU in the past to improve Unicode support and deal with normalization issues. > I keep reading "The project doesn't release binaries". Who will, Tigris? Tigris is just a hosting service not an entity. > Collab? Yo momma? One of the greatest advantages is that committers who > wish to package binaries can do so under the ASF umbrella, something that > in this litigious society I would never consider doing now. There are lots of people that provide binaries. See here: http://subversion.tigris.org/getting.html#binary-packages For Windows, there are several sources (all free) and all with their own differences based on what it is that you want. > So is the "project doesn't release binaries" mantra a statement about the > past practices, a tacit or explicit contract in bringing this to the ASF, > or just the posters' personal preference? I do not believe the project wants to be in the business of providing binaries and we have an existing ecosystem of people that are providing them successfully. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
William A. Rowe Jr. wrote: > Mark Phippard wrote: > >> I gave counsel to the Eclipse Foundation and explained that they could >> provide a fully functioning JavaHL library to users with only EPL >> compatible code. Basically, you just need to build without Neon, BDB >> and libintl support. Of the three, the only thing an Eclipse client >> user needs is Neon, and Serf serves as a viable replacement. I do not >> know why they never chose to release a binary built this way. I can >> only assume that Igor and Polarion did not want to make these >> binaries. >> > > I suspect IBM's ICU lib could be substituted for libintl, and as there is > some traction on the idea of dumping apr-iconv, this would be a sensible > thing (since ICU is the heir apparent for non-iconv based platforms). > > I keep reading "The project doesn't release binaries". Who will, Tigris? > Collab? Yo momma? One of the greatest advantages is that committers who > wish to package binaries can do so under the ASF umbrella, something that > in this litigious society I would never consider doing now. > > So is the "project doesn't release binaries" mantra a statement about the > past practices, a tacit or explicit contract in bringing this to the ASF, > or just the posters' personal preference? > Wait a minute. Are you implying that the "project" *should* release binaries? Wouldn't such a requirement apply to, say, APR, to keep this close to home? Certainly any volunteer with proper karma can build binaries from the release tarballs, and if those binaries happen to pass muster wrt ASF-mandated legalities, then from my understanding it should be OK to host such binaries on ASF's infrastructure. But that's not the same as the project releasing those binaries -- lack of digital sigs on them is a dead giveaway. How many APR and/or httpd commiters sign your Windows binary packages? -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
Mark Phippard wrote: > > As an SVN committer, I can say that this is not something that is of > concern to me (and I dare say I probably speak for all or at least > most of the other committers when I say that). Thanks for that reassurance... > Finally, I will also add that we have had our SVN Corp for many years > now and that has always involved having five of our committers in > "Board of Director" roles for the corporation and that has not created > any problems of inequity. Another example of how SVN is already a bit unique in how we incubate. But I call this out on every occasion, because mentor-as-lead-developer leads segways into a BDfL more often than not. In this case I'm not really worried, because I know from experience that SVN committers don't shy away from expressing their opinions :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Mark Phippard wrote: > > I gave counsel to the Eclipse Foundation and explained that they could > provide a fully functioning JavaHL library to users with only EPL > compatible code. Basically, you just need to build without Neon, BDB > and libintl support. Of the three, the only thing an Eclipse client > user needs is Neon, and Serf serves as a viable replacement. I do not > know why they never chose to release a binary built this way. I can > only assume that Igor and Polarion did not want to make these > binaries. I suspect IBM's ICU lib could be substituted for libintl, and as there is some traction on the idea of dumping apr-iconv, this would be a sensible thing (since ICU is the heir apparent for non-iconv based platforms). I keep reading "The project doesn't release binaries". Who will, Tigris? Collab? Yo momma? One of the greatest advantages is that committers who wish to package binaries can do so under the ASF umbrella, something that in this litigious society I would never consider doing now. So is the "project doesn't release binaries" mantra a statement about the past practices, a tacit or explicit contract in bringing this to the ASF, or just the posters' personal preference? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 11:23, Kevan Miller wrote: > On Nov 10, 2009, at 10:44 AM, Greg Stein wrote: >... >> And that is exactly what I'd like to do. But when the Incubator >> *imposes* requirements of release that does not meet the project's own >> quality guidelines, for an audience of zero, then I call that >> "ridiculous make-work". That is my rant. That the Incubator-at-large >> is imposing crap on the podling, rather than teaching the podling what >> it means to be part of the ASF. > > IIRC, Martijn has offered a proper legal review in the place of a "release". > This sounded pretty reasonable to me. I would agree to that. I'm surprised > you haven't worked with his proposal, to find what I think would be a good > compromise. Yup. I've already stated that I have no problems with running RAT and working through those issues. Might have been hard to see in this long thread :-) > I agree with you that a release shouldn't be "make-work" -- it should be the > natural evolution of a community creating code. But I'm bit puzzled by your > extreme urgency for a fast incubator exit. Incubator overhead would seem to > be greatest for a release (which is not in your immediate plans, it seems). > Until then, overhead for board reports and voting in new committers/pmc > members would seem to be a minimal burden. Why *stay*? Incubator is not a home... it's a school. We're making a 1.6.7 release in the next 2-3 weeks, as I stated before. The Incubator can see how that works (I also gave pointers to 1.6.6). But the main release, under the Apache brand, is not until early next year sometime. I'd rather not wait until then. The reporting doesn't bother me. You can't possibly imagine how many reports to the Board I've read over the past 8+ years :-P Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 11:22, Leo Simons wrote: > On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein wrote: >... >> The IPMC is in charge of its operation. It can redefine the rules of >> releases as it pleases. The three +1 rule was developed to show that >> the PMC is "in charge" of the release, and is therefore legally liable >> for it. The IPMC can do whatever it likes around releases, as long as >> that process specifically claims or disclaims liability. > > Ok, that is interesting (and probably more workable than a big reorg). > I still think we should claim liability. > > Could we, for example, have a release process that is lazy-by-default > from the IPMC side and still claim that the ASF gets liability? Unfortunately, no. The IPMC has to be *active* in some way, in order to show oversight and responsibility. So the "lazy-by-default" won't work. But your suggestion below might. > for example, to release: > > 1) PPMC must vote for the release according to their rules (which > should at least match the 3 +1 / majority rule requirements) > 2) at least one PMC member must vote +1 (usually the mentor) This basically states, "The PPMC has followed our guidelines and processes, has been conducted under the purview of the IPMC, and at our direction. The IPMC hereby directs the PPMC to continue with their release." > 3) if there are no -1 votes, the PPMC sends the general@ list a > request for a release ACK, after they get that ACK from a PMC member, > they wait for 72 hours, and if there are still no -1s, the release is > approved. > 4) if there are any -1 votes, then the rule becomes the normal 3 +1s > from PMC members / majority Any -1 votes within the PPMC or from the IPMC should be a trigger. > Downside: > * more complex > * increased dependency on single person to teach the "basics" > > Upside: > * better reflects relationship between incubator and PPMC > * more responsibility for project > * hopefully fewer stalled releases Well.. let's call this the "expedited" form of release. It leaves the PPMC a bit more self-sufficient. I'd think that any first release would follow the "standard" release mechanic. After that, the expedited can be used unless a -1 arises. At that point, they have to follow the standard process (even if it all restarts). After that release concludes, they can switch back to expedited. I'd really want Roy to review some of this thinking. The real question is just how far the IPMC can delegate their oversight and authority. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
I like Leo's proposal. With PMC members mentoring multiple projects, it is really a burden to try and get 3 votes for a release. Shanti Leo Simons wrote: On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein wrote: On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wrote: Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. The IPMC is in charge of its operation. It can redefine the rules of releases as it pleases. The three +1 rule was developed to show that the PMC is "in charge" of the release, and is therefore legally liable for it. The IPMC can do whatever it likes around releases, as long as that process specifically claims or disclaims liability. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Downside: * more complex * increased dependency on single person to teach the "basics" Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases thoughts? Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:57 AM, Branko Čibej wrote: > Igor Burilo wrote: >> Michael, sure Neon and Serf are optional and it’s absolutely correct from >> the legal point of view. But in this case SVN should work without DAV >> support, which is important for end-users. >> >> When we talk about licensing issues we mean problem with entire SVN >> acceptance and distribution. In particular, it’s a big problem for Eclipse >> community and companies that stay behind this community. To accept SVN they >> require a legally clean pre-built solution. It means that at least JavaHL >> client should be EPL (Apache 2.0) compatible. Now it doesn’t because of >> Neon. Sure, someone can tell – build distribution yourself with Serf, but we >> understand that result isn’t guaranteed at the current moment, so this >> solution will not be accepted. Another approach to allow users build library >> by themselves will not work, because require knowledge and experience from >> end-users. >> > > I don't quite understand what you're getting at, but you appear to be > mixing up the concepts of "releasing" and "packaging". If the Eclipse > community requires a pre-built solution, then tough luck, they won't get > it from the Subversion project because we never have and never will > release anything but source code. If some package maintainer volunteers > to build binaries specifically for Eclipse, then said maintainer can do > it without including Neon or BDB or a few other optional bits and > pieces, and will end up with a functional Subversion client. I gave counsel to the Eclipse Foundation and explained that they could provide a fully functioning JavaHL library to users with only EPL compatible code. Basically, you just need to build without Neon, BDB and libintl support. Of the three, the only thing an Eclipse client user needs is Neon, and Serf serves as a viable replacement. I do not know why they never chose to release a binary built this way. I can only assume that Igor and Polarion did not want to make these binaries. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29 AM, Jochen Wiedmann wrote: > On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: > >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. > > That would a completely new philosophy for an Apache project, which always > aimed > very heavily on distributions. It might either enforce to look at > legal aspects in a > different view - or lead to changing your philosophy. :-) Personally, > I don't see any > reason why things like creation of Windows binaries should be left to > outsiders. (Apart > from CollabNets business interests, which I wouldn't like to count.) CollabNet did not even provide any binary until after Subversion 1.4 was out, so that was never a factor. The fact is that providing a generic Subversion binary is complicated. Some people want to run it with an Apache 2.2 server, some with Apache 2.0. Lots of people want to use the Python bindings, but which version etc. Anyone that has ever produced these binaries has had to deal with these issues and make these decisions about what they wanted to support with THEIR binary and packaging. The project (SVN developers) has just decided to stick with the tarballs and zips of the source code. We have always had volunteers that built and provided binaries for Windows that were available on tigris. I expect those volunteers may also want to provide them via the Apache mirrors once the project has moved. Although I guess they will need to build those binaries without things like Neon, BDB and libintl as well as any other dependencies that cannot be included. The point is that the subversion project will likely intend to just point at these volunteers that make binary distributions available -- including CollabNet. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
How to shorten the duration of incubation (Was: Insanity...)
Hi, On Tue, Nov 10, 2009 at 5:55 PM, Greg Stein wrote: > My point above was the Board, at least in the past(*), has *not* been > happy about the average duration. The way I see it, there are three main things we could do to shorten the average duration of incubation: 1) Relax the exit criteria: Especially the diversity requirement is a major barrier for many projects. There have been various calls to relax the diversity requirements, but so far I see no consensus on that. 2) Tighten the entry criteria: Many of the podlings that end up failing or taking a long time here are new projects that start from scratch or from previously closed codebases with weak or no existing project communities. We could significantly improve the average duration of incubation if we only accepted mature open source projects. 3) Increase the amount of mentoring: The lack of mentor time and better (not necessarily more) supporting documentation gives unnecessary administrational and procedural headaches (failed release votes, etc.) to many podlings. Without more volunteers there's not much we can do about 3, which leaves the entry and exit criteria as the variables we can control. I personally think that the exit criteria are good as they are (in hindsight, Abdera is a good example of a project that graduated with barely enough diversity of active committers), so if we do want to make the Incubator "work faster" my suggestion would be to start by raising our entry criteria. One way to do that would be to start requiring the three mentors to show higher levels of personal commitment than what we currently ask for. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Igor Burilo wrote: > C. Michael Pilato wrote: > >>> I certainly understand why license issues would be a concern. But I could >>> use an education about why this particular case matters. We currently >>> > ship > >>> Neon in a separate tarball from Subversion's core code for the convenience >>> of our users, but if that's a problem, we can stop doing so. Subversion >>> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >>> Subversion client and server that doesn't use a DAV layer at all. The >>> Subversion community has never released binaries -- ever -- not do we plan >>> to. So users and package maintainers are free to assemble Subversion with >>> the optional bits they care to provide for their consumers. >>> >>> Igor, is there a particular concern that you can elaborate on here if only >>> for my education? >>> > > Michael, sure Neon and Serf are optional and it’s absolutely correct from > the legal point of view. But in this case SVN should work without DAV > support, which is important for end-users. > > When we talk about licensing issues we mean problem with entire SVN > acceptance and distribution. In particular, it’s a big problem for Eclipse > community and companies that stay behind this community. To accept SVN they > require a legally clean pre-built solution. It means that at least JavaHL > client should be EPL (Apache 2.0) compatible. Now it doesn’t because of > Neon. Sure, someone can tell – build distribution yourself with Serf, but we > understand that result isn’t guaranteed at the current moment, so this > solution will not be accepted. Another approach to allow users build library > by themselves will not work, because require knowledge and experience from > end-users. > I don't quite understand what you're getting at, but you appear to be mixing up the concepts of "releasing" and "packaging". If the Eclipse community requires a pre-built solution, then tough luck, they won't get it from the Subversion project because we never have and never will release anything but source code. If some package maintainer volunteers to build binaries specifically for Eclipse, then said maintainer can do it without including Neon or BDB or a few other optional bits and pieces, and will end up with a functional Subversion client. > At the current moment SVN client can’t pass legal review on Eclipse (something I don't really care about, but) see above; we do not release any code with an incompatible license. > and it > means that SVN loosing its huge potential there. It’s a perfect example when > nice technology is blocked by legal tricks. So the perfect solution will be > to replace Neon by Serf, because it will resolve a lot of issues described > above with SVN acceptance. > Frankly I've heard so many interesting things about the Eclipse process from various sources that it appears to me that they're tripping themselves up on imaginary technicalities. The statements you made about Subversion's incompatibility with Eclipse seem bogus; since, as I said above, all the potentially conflicting parts are completely optional and do not have to be part of any binary package. What am I missing? -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:29, Jochen Wiedmann wrote: > On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: > >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. > > That would a completely new philosophy for an Apache project, which always > aimed > very heavily on distributions. It might either enforce to look at > legal aspects in a > different view - or lead to changing your philosophy. :-) Personally, > I don't see any > reason why things like creation of Windows binaries should be left to > outsiders. (Apart > from CollabNets business interests, which I wouldn't like to count.) > > Just recently, we had a very active discussion regarding Maven where > the emphasis > was laid very heavily on the distributable archives (binary and > source) as the endorsed > result of the release/vote process. In httpd, we release tarballs and zips. Then some committers volunteer prebuilts. wrowe always built Windows releases, but I don't think that was ever mandated. The svn release process also produces tarballs and zips (in case that wasn't clear). We just don't do prebuilts. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 10:29 AM, Jochen Wiedmann wrote: > On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato > wrote: > >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. > > That would a completely new philosophy for an Apache project, which always > aimed > very heavily on distributions. It might either enforce to look at > legal aspects in a > different view - or lead to changing your philosophy. :-) Personally, > I don't see any > reason why things like creation of Windows binaries should be left to > outsiders. (Apart > from CollabNets business interests, which I wouldn't like to count.) > > Just recently, we had a very active discussion regarding Maven where > the emphasis > was laid very heavily on the distributable archives (binary and > source) as the endorsed > result of the release/vote process. The reason we (Subversion) do not ship binaries is simple: we don't have the resources to meet the request, and most of our users use Subversion as part of a third-party tool, which most often *does* ship as a binary. We've supported community efforts to create binaries, even going so far as to host selected variants on our downloads page, but they are still not considered official artifacts of the project. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 11:16, Blair Zajac wrote: > > On Nov 10, 2009, at 7:10 AM, Greg Stein wrote: > >> On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato wrote: >>> ... >>> I certainly understand why license issues would be a concern. But I could >>> use an education about why this particular case matters. We currently ship >>> Neon in a separate tarball from Subversion's core code for the convenience >>> of our users, but if that's a problem, we can stop doing so. Subversion >>> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >>> Subversion client and server that doesn't use a DAV layer at all. The >>> Subversion community has never released binaries -- ever -- not do we plan >>> to. So users and package maintainers are free to assemble Subversion with >>> the optional bits they care to provide for their consumers. >>> >>> Igor, is there a particular concern that you can elaborate on here if only >>> for my education? >> >> If the Apache software is *non-functional* without the LGPL software, >> then you are effectively requiring downstream users to link themselves >> into the LGPL licensing. >> >> Since Subversion does not require any LGPL to function, then we should >> be just fine. I plan to run this past legal-discuss for verification >> (along with our optional GNOME, KDE, and BDB dependencies). I seem to >> recall from the legal web pages there is no specific mention of our >> case, so wanted to double-check and then possible add our use-case to >> those pages. >> >> Regarding serf and Neon, I think that serf will be just fine to have >> as a default. It has been totally functional for many of us (cmpilato >> is a serf skeptic :-P) > > Not yet though. It still fails in places that neon works. Anything besides 1.0 proxies? Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. > wrote: >> Leo Simons wrote: >>> >>> Here's what I understand: >>> >>> 1) Apache rule: all apache releases must be made by PMCs >>> 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s >>> 3) from #1 and #2 it follows that all incubator releases must be made >>> by the incubator PMC >> >>> If you see a way to fix this mess, please do. I suspect rule #1 is the >>> whopper that is just quite hard to get around and from it follows a >>> lot of other mess. I don't know exactly where that rule comes from, >>> but it is very old and it has always seemed very solid, too. IANAL. >> >> Mechanically, it's possible to recharter Incubator PMC as a board committee >> which has the authority to assemble and dissolve fully empowered PPMCs so >> they could begin binding votes from the outset. The 'P' would change from >> 'pre' to 'provisional'. I don't know if this is what we want to do, or not. > > The Board is trying to move away from Board committees. > > The IPMC is in charge of its operation. It can redefine the rules of > releases as it pleases. The three +1 rule was developed to show that > the PMC is "in charge" of the release, and is therefore legally liable > for it. The IPMC can do whatever it likes around releases, as long as > that process specifically claims or disclaims liability. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Downside: * more complex * increased dependency on single person to teach the "basics" Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases thoughts? Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato wrote: > Subversion client and server that doesn't use a DAV layer at all. The > Subversion community has never released binaries -- ever -- not do we plan > to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Just recently, we had a very active discussion regarding Maven where the emphasis was laid very heavily on the distributable archives (binary and source) as the endorsed result of the release/vote process. Jochen -- Germanys national anthem is the most boring in the world - how telling! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Nov 10, 2009, at 10:44 AM, Greg Stein wrote: On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. > wrote: Greg Stein wrote: The Apache Incubator is about EDUCATION. It is about TEACHING podlings how to work here at Apache. I'm a little confused. I'm reading a really long rant here, but I expect if you look at what nearly all mentors do in their respective podlings, this is exactly what they provide (granted, with wildly varying degrees of effort or attention). And that is exactly what I'd like to do. But when the Incubator *imposes* requirements of release that does not meet the project's own quality guidelines, for an audience of zero, then I call that "ridiculous make-work". That is my rant. That the Incubator-at-large is imposing crap on the podling, rather than teaching the podling what it means to be part of the ASF. IIRC, Martijn has offered a proper legal review in the place of a "release". This sounded pretty reasonable to me. I would agree to that. I'm surprised you haven't worked with his proposal, to find what I think would be a good compromise. I agree with you that a release shouldn't be "make-work" -- it should be the natural evolution of a community creating code. But I'm bit puzzled by your extreme urgency for a fast incubator exit. Incubator overhead would seem to be greatest for a release (which is not in your immediate plans, it seems). Until then, overhead for board reports and voting in new committers/pmc members would seem to be a minimal burden. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 9:16 AM, Mark Phippard wrote: > On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein wrote: >> On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato wrote: >>> ... >>> I certainly understand why license issues would be a concern. But I could >>> use an education about why this particular case matters. We currently ship >>> Neon in a separate tarball from Subversion's core code for the convenience >>> of our users, but if that's a problem, we can stop doing so. Subversion >>> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >>> Subversion client and server that doesn't use a DAV layer at all. The >>> Subversion community has never released binaries -- ever -- not do we plan >>> to. So users and package maintainers are free to assemble Subversion with >>> the optional bits they care to provide for their consumers. >>> >>> Igor, is there a particular concern that you can elaborate on here if only >>> for my education? >> >> If the Apache software is *non-functional* without the LGPL software, >> then you are effectively requiring downstream users to link themselves >> into the LGPL licensing. >> >> Since Subversion does not require any LGPL to function, then we should >> be just fine. I plan to run this past legal-discuss for verification >> (along with our optional GNOME, KDE, and BDB dependencies). I seem to >> recall from the legal web pages there is no specific mention of our >> case, so wanted to double-check and then possible add our use-case to >> those pages. >> >> Regarding serf and Neon, I think that serf will be just fine to have >> as a default. It has been totally functional for many of us (cmpilato >> is a serf skeptic :-P) > > He is not the only one :) > > That said, I think the point is why should the default matter? We can > either optionally use Neon or we cannot. Even if Neon is the default, > if someone builds with only Serf then it becomes the default. > > As Mike says, we do not provide binaries so we will not be asking to > distribute any of these libraries. We will need to find out if it is > OK to still supply our dependencies tarball for convenience. And if we can't ship the deps tarballs, you won't find me (the current release manager) shedding any tears. I don't have any statistics to back it up, but I tend to thinks the deps tarball is pretty underutilized. I don't think it would have a negative impact on our users or release process. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 7:10 AM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato wrote: >> ... >> I certainly understand why license issues would be a concern. But I could >> use an education about why this particular case matters. We currently ship >> Neon in a separate tarball from Subversion's core code for the convenience >> of our users, but if that's a problem, we can stop doing so. Subversion >> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. So users and package maintainers are free to assemble Subversion with >> the optional bits they care to provide for their consumers. >> >> Igor, is there a particular concern that you can elaborate on here if only >> for my education? > > If the Apache software is *non-functional* without the LGPL software, > then you are effectively requiring downstream users to link themselves > into the LGPL licensing. > > Since Subversion does not require any LGPL to function, then we should > be just fine. I plan to run this past legal-discuss for verification > (along with our optional GNOME, KDE, and BDB dependencies). I seem to > recall from the legal web pages there is no specific mention of our > case, so wanted to double-check and then possible add our use-case to > those pages. > > Regarding serf and Neon, I think that serf will be just fine to have > as a default. It has been totally functional for many of us (cmpilato > is a serf skeptic :-P) Not yet though. It still fails in places that neon works. Blair - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
C. Michael Pilato wrote: > >>I certainly understand why license issues would be a concern. But I could >>use an education about why this particular case matters. We currently ship >>Neon in a separate tarball from Subversion's core code for the convenience >>of our users, but if that's a problem, we can stop doing so. Subversion >>doesn't require Neon. Or Serf. You can have a perfectly valid, working, >>Subversion client and server that doesn't use a DAV layer at all. The >>Subversion community has never released binaries -- ever -- not do we plan >>to. So users and package maintainers are free to assemble Subversion with >>the optional bits they care to provide for their consumers. >> >>Igor, is there a particular concern that you can elaborate on here if only >>for my education? > Michael, sure Neon and Serf are optional and it’s absolutely correct from the legal point of view. But in this case SVN should work without DAV support, which is important for end-users. When we talk about licensing issues we mean problem with entire SVN acceptance and distribution. In particular, it’s a big problem for Eclipse community and companies that stay behind this community. To accept SVN they require a legally clean pre-built solution. It means that at least JavaHL client should be EPL (Apache 2.0) compatible. Now it doesn’t because of Neon. Sure, someone can tell – build distribution yourself with Serf, but we understand that result isn’t guaranteed at the current moment, so this solution will not be accepted. Another approach to allow users build library by themselves will not work, because require knowledge and experience from end-users. At the current moment SVN client can’t pass legal review on Eclipse and it means that SVN loosing its huge potential there. It’s a perfect example when nice technology is blocked by legal tricks. So the perfect solution will be to replace Neon by Serf, because it will resolve a lot of issues described above with SVN acceptance. -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26286015.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Adding Paul Querna as committer to Traffic Server
On Fri, Nov 6, 2009 at 7:21 AM, Leif Hedstrom wrote: > On Nov 5, 2009, at 11:13 PM, Bertrand Delacretaz wrote: > >> On Thu, Nov 5, 2009 at 6:22 PM, Leif Hedstrom wrote: >>> >>> Hi all, >>> >>> the Traffic Server podling "PMC" has deliberated hard, and we've decided >>> that it's best for everyone if we add Paul Querna as a committer to the >>> Traffic Server project. There were 10 binding +1 votes, one binding -0 >>> vote, >>> one non-binding +1 vote, and no -1 votes. >>> >>> Welcome Paul! >> >> Do you have 3 +1 votes from Incubator PMC members? >> >> I see only 2 in the list below...happy to be corrected if I'm missing >> something. > > Ah, no. So, I obviously didn't get this right, I asked a number of people > here what the appropriate process is, and got the impression we (the > podling) could vote on it, and notify the IPMC. But, if I understand you > correctly, we have to run the vote for adding Paul through the Incubator > PMC? Well, you certainly got it right for after graduation :). Cheers, Sander > If so, can the IPMC members please vote on adding Paul to the Traffic Server > committers list? > > Cheers, > > -- Leif > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wrote: > Leo Simons wrote: >> >> Here's what I understand: >> >> 1) Apache rule: all apache releases must be made by PMCs >> 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s >> 3) from #1 and #2 it follows that all incubator releases must be made >> by the incubator PMC > >> If you see a way to fix this mess, please do. I suspect rule #1 is the >> whopper that is just quite hard to get around and from it follows a >> lot of other mess. I don't know exactly where that rule comes from, >> but it is very old and it has always seemed very solid, too. IANAL. > > Mechanically, it's possible to recharter Incubator PMC as a board committee > which has the authority to assemble and dissolve fully empowered PPMCs so > they could begin binding votes from the outset. The 'P' would change from > 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. The IPMC is in charge of its operation. It can redefine the rules of releases as it pleases. The three +1 rule was developed to show that the PMC is "in charge" of the release, and is therefore legally liable for it. The IPMC can do whatever it likes around releases, as long as that process specifically claims or disclaims liability. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. wrote: > Greg Stein wrote: >> >> Yup. And I'll note that that "limbo" you describe has been an issue >> with the Board for a long while now. That is why the Board instructed >> the IPMC to request all podlings to list two items in their reports: >> >> 1) when did you arrive? >> 2) what is left? >> >> Specifically to focus the podling (and the IPMC) on the question of >> "WHY are you still in the Incubator?" >> >> Podlings should be shepherded *out* rather than held *in*. > > Hmmm... here you go again. Do you really believe there's a mentor here > who doesn't want to be 'done' with their task at hand, offering up a > functioning project for graduation? Mentors -do- exactly this, which > is why your rants continue to read as disingenuous and insulting. I'm not talking about mentors' desire to do this. I'm talking about the structures that appear to be in place which work *against* incubation and graduation. And if you want to call a rant against meaningless constraints and bureaucracy "insulting", then I'm okay with that. > We are glad the board has such confidence that the Incubator is producing > effect meritocracies that collaborate effectively. If your's is not the > minority opinion, there is a much larger 'Insanity' thread to begin, which > starts with [VOTE] and ends in "Dissolve Incubator?" My point above was the Board, at least in the past(*), has *not* been happy about the average duration. Go poll the Board today, if you'd like. AFAIK, the Board has never expressed a lack of confidence in the Incubator, other than duration. Cheers, -g (*) see "Incubator Reports" sent to Noel, IPMC, and board@ on Oct 12, 2006 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. wrote: > Greg Stein wrote: >> The Apache Incubator is about EDUCATION. It is about TEACHING podlings >> how to work here at Apache. > > I'm a little confused. I'm reading a really long rant here, but I expect > if you look at what nearly all mentors do in their respective podlings, > this is exactly what they provide (granted, with wildly varying degrees > of effort or attention). And that is exactly what I'd like to do. But when the Incubator *imposes* requirements of release that does not meet the project's own quality guidelines, for an audience of zero, then I call that "ridiculous make-work". That is my rant. That the Incubator-at-large is imposing crap on the podling, rather than teaching the podling what it means to be part of the ASF. > Quite frankly, all svncorp releases could, with reasonable documentation > [read: mailing list archives, CLA's and code grant] be licensed as ASF > releases under the AL 2.0, irrespective of their internal artifact > copyright statements. I doubt it. Those old releases are signed tarballs. We can't "reach in" and alter the LICENSE file without re-signing the whole tarball, and I think that would be a very bad idea. > A proviso that 1.7.0 won't be approved without running it through RAT, > either pre or post graduation seems sufficient. The process is better > documented than 95% of ASF project release processes, so there's no issue. RAT can be run right now, and the podling can work against its results. No issue there. The *release* of "something" is my pain point. And yes, the PMC that will manage the svn project can/should have a responsibility to use RAT. But if you "make that rule", then you better impose it upon every PMC here at the ASF. That's effectively what you're saying :-) > But ranting against your perception of Incubator's failure to EDUCATE and > TEACH podlings how the ASF environment works is really quite disappointing, > coming from you. Look at the context. Being asked to throw together some bits for a "release". Oh, just any bits will do. But wait, since they aren't quite proper, you don't really have to announce it to users. ... come on, that is not education. That isn't teaching anybody anything. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 10:28 AM, Niclas Hedhman wrote: > The binaries doesn't matter, Apache releases source code, licensed under > Apache license v2.0. And we only distribute certain licensed dependencies. > > As Greg said, we need to provide solutions that does not force downstream > users into the (L)GPL world. So, a project that requires these dependencies > are a no-no. Optionality is key here. > > As for the virality of some licenses it is also important to ensure that it > doesn't leak into Apache code bases. I don't think this is even close to be > the case here. > > IMHO, this looks like a simple case and legal-discuss@ should be able to > provide a definitive answer quickly. > > IIRC, redistributing the LGPL code would not be allowed. These things all make sense and given that Neon (and the other dependencies) are all optional then I do not think it should be an issue. The question I was asking, is why should it matter what the default is? The default only applies to someone that builds a binary that includes both Neon and Serf. The subversion project ought to be able to decide which library is the appropriate default in this situation. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
The binaries doesn't matter, Apache releases source code, licensed under Apache license v2.0. And we only distribute certain licensed dependencies. As Greg said, we need to provide solutions that does not force downstream users into the (L)GPL world. So, a project that requires these dependencies are a no-no. Optionality is key here. As for the virality of some licenses it is also important to ensure that it doesn't leak into Apache code bases. I don't think this is even close to be the case here. IMHO, this looks like a simple case and legal-discuss@ should be able to provide a definitive answer quickly. IIRC, redistributing the LGPL code would not be allowed. -- Niclas On 10 Nov 2009 23:17, "Mark Phippard" wrote: On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 09:... He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: gener...
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 3:23 AM, William A. Rowe, Jr. wrote: > Greg Stein wrote: >> >> Sponsors >> * Champion: Greg Stein > > Cool > >> * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel >> Rall > > Once again, caution against committers == mentors (== 'project leads'). > It puts certain committers above others, an inequitable situation. As an SVN committer, I can say that this is not something that is of concern to me (and I dare say I probably speak for all or at least most of the other committers when I say that). As Greg points out, of the nominated mentors, Greg is the only one that has been actively committing code in the last year. So it is great for us to have committers that have the experience (and are willing) to help mentor us through this process. Finally, I will also add that we have had our SVN Corp for many years now and that has always involved having five of our committers in "Board of Director" roles for the corporation and that has not created any problems of inequity. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 07:06, Leo Simons wrote: > On Tue, Nov 10, 2009 at 8:23 AM, William A. Rowe, Jr. > wrote: >> Greg Stein wrote: >>> >>> Sponsors >>> * Champion: Greg Stein >> >> Cool >> >>> * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel >>> Rall >> >> Once again, caution against committers == mentors (== 'project leads'). >> It puts certain committers above others, an inequitable situation. > > But it has the huge advantage of making sure that the mentors are > actively engaged all the time, know quite a lot about the podling's > situation, and are already well-known and trusted by the project's > community. I would say the very clear benefits far outweigh the > potential problems, and I prefer the model like that. > > Most communities have situations where certain people have more power > than others whether officially or in practice, and communities that > can't deal with that have other issues. Very well said! Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 03:23, William A. Rowe, Jr. wrote: >... >> * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel >> Rall > > Once again, caution against committers == mentors (== 'project leads'). > It puts certain committers above others, an inequitable situation. We have 70 committers. Of those 55 are (what the ASF would call) PMC members. The above four names are a *very* small portion of the "leadership" of the svn community. Justin and Sander are *way* more active here at the ASF than in the SVN community. They are present to "show the ropes" more than to assert themselves in the svn community. If anything, my role as Champion and the constant engagement here is altering my role within svn. But I don't actually worry about it because svn has operated for over nine years without ever having "leaders". We certainly have *more active* developers, which changes/morphs over time, but those developers have never been accorded anything more than any other developer in the community. > If the PPMC is 100% in support of 'respecting' this list of mentors with > respect to adapting to life-in-the-ASF, then fine. But it's a situation Yes, they are. The proposal was drafted mid-August. There has been plenty of time for the "PPMC" to review, discuss, and tweak. > that always concerns me. The incubator PMC could easily find mentors who > are supportive of this proposal, but not in dev/leadership roles within > the SVN community. > >> * Sponsor: > > I am certain the APR project would entertain a vote to sponsor this podling > through graduation, if that is useful. Thanks, but the general rule is that if you're going for TLP, then the Incubator is the sponsor. We don't intend to become a sub-project of APR :-P Listing the sponsor as the Board would be the best description here, but I think that would really require some kind of "sure" from the Board, which we don't have, nor do I think would be a good precedent. The Incubator is sort of a proxy for the Board here. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein wrote: > On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato wrote: >>... >> I certainly understand why license issues would be a concern. But I could >> use an education about why this particular case matters. We currently ship >> Neon in a separate tarball from Subversion's core code for the convenience >> of our users, but if that's a problem, we can stop doing so. Subversion >> doesn't require Neon. Or Serf. You can have a perfectly valid, working, >> Subversion client and server that doesn't use a DAV layer at all. The >> Subversion community has never released binaries -- ever -- not do we plan >> to. So users and package maintainers are free to assemble Subversion with >> the optional bits they care to provide for their consumers. >> >> Igor, is there a particular concern that you can elaborate on here if only >> for my education? > > If the Apache software is *non-functional* without the LGPL software, > then you are effectively requiring downstream users to link themselves > into the LGPL licensing. > > Since Subversion does not require any LGPL to function, then we should > be just fine. I plan to run this past legal-discuss for verification > (along with our optional GNOME, KDE, and BDB dependencies). I seem to > recall from the legal web pages there is no specific mention of our > case, so wanted to double-check and then possible add our use-case to > those pages. > > Regarding serf and Neon, I think that serf will be just fine to have > as a default. It has been totally functional for many of us (cmpilato > is a serf skeptic :-P) He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. -- Thanks Mark Phippard http://markphip.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato wrote: >... > I certainly understand why license issues would be a concern. But I could > use an education about why this particular case matters. We currently ship > Neon in a separate tarball from Subversion's core code for the convenience > of our users, but if that's a problem, we can stop doing so. Subversion > doesn't require Neon. Or Serf. You can have a perfectly valid, working, > Subversion client and server that doesn't use a DAV layer at all. The > Subversion community has never released binaries -- ever -- not do we plan > to. So users and package maintainers are free to assemble Subversion with > the optional bits they care to provide for their consumers. > > Igor, is there a particular concern that you can elaborate on here if only > for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Igor Burilo wrote: > > C. Michael Pilato wrote: >>> Our goal is to bring our Serf integration up to the quality (in terms of >>> both user experience and proper API adherence) of our Neon one so that > Serf >>> can safely become the new default DAV RA implementation, yes. It's mostly >>> there, but still contains a few gotchas. We've switched our trunk >>> (1.7-aimed) code to use Serf as the default if both it and Neon are found, >>> but that change could be reverted (restoring the use of Neon as the > default) >>> if we aren't able to iron out the Serf integration shortcomings in a > timely >>> fashion. > > Michael, this is a very good news and it's good that you work on it now, > because licensing issues (Neon license incompatibility) are very important > for us. Hope that you will manage to do it if for SVN 1.7. > > Thanks, Igor I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 8:23 AM, William A. Rowe, Jr. wrote: > Greg Stein wrote: >> >> Sponsors >> * Champion: Greg Stein > > Cool > >> * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel >> Rall > > Once again, caution against committers == mentors (== 'project leads'). > It puts certain committers above others, an inequitable situation. But it has the huge advantage of making sure that the mentors are actively engaged all the time, know quite a lot about the podling's situation, and are already well-known and trusted by the project's community. I would say the very clear benefits far outweigh the potential problems, and I prefer the model like that. Most communities have situations where certain people have more power than others whether officially or in practice, and communities that can't deal with that have other issues. In any case, a good way to offset any perceived risk is probably to have some lively discussion between the mentors and the rest of the incubator. So, risk mitigated, I say :) ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Mon, Nov 9, 2009 at 5:43 PM, Greg Stein wrote: > ...I am seeking a > waiver of the "make a release" "requirement". And you can simply wait > for me to send that, rather than continuing to speculate about whether > I'm going to rely on seniority or on experience I like that - at first, the tone of this thread (and subject line ;-) made me think that the subversion podling would be trying to get through incubation based on its own perception of what's right, as opposed to the Incubator's well-established policies. Now, subversion is certainly not your typical podling...I totally agree that it makes sense to handle its incubation in a slightly different way that usual. But as you indicate, deviations from the usual way of doing things must be approved by this PMC. Let's discuss you concrete requests for waivers and such once we have them. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
C. Michael Pilato wrote: > >>Our goal is to bring our Serf integration up to the quality (in terms of >>both user experience and proper API adherence) of our Neon one so that Serf >>can safely become the new default DAV RA implementation, yes. It's mostly >>there, but still contains a few gotchas. We've switched our trunk >>(1.7-aimed) code to use Serf as the default if both it and Neon are found, >>but that change could be reverted (restoring the use of Neon as the default) >>if we aren't able to iron out the Serf integration shortcomings in a timely >>fashion. > Michael, this is a very good news and it's good that you work on it now, because licensing issues (Neon license incompatibility) are very important for us. Hope that you will manage to do it if for SVN 1.7. Thanks, Igor -- View this message in context: http://old.nabble.com/-PROPOSAL--VOTE--Subversion-tp26203843p26280942.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Mon, Nov 9, 2009 at 4:56 PM, Justin Erenkrantz wrote: > ...Let me put it another way: if the IPMC accepts a proposal with one > mentor, then I'm fine with that one mentor acting on behalf of the > IPMC without the need to constantly go back to the IPMC for approval I see your point, and that's why I've been insisting several times that incoming podlings get three mentors. Problem is, mentors are not always present/active when a vote needs to happen. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
Leo Simons wrote: > > Here's what I understand: > > 1) Apache rule: all apache releases must be made by PMCs > 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s > 3) from #1 and #2 it follows that all incubator releases must be made > by the incubator PMC > If you see a way to fix this mess, please do. I suspect rule #1 is the > whopper that is just quite hard to get around and from it follows a > lot of other mess. I don't know exactly where that rule comes from, > but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Martijn Dashorst wrote: > > Would a waiver be possible for Diversity (large project dominated by 1 > or 2 vendors)? For the minimum required binding votes (small > communities of 2 committers)? Such things have been requested, and granted in the past, based on the demonstrated ability of the project to accept outside contributions and work towards a more diverse committer base and PMC. Should they later fail, the board will [as it has done before] step in, dissolve the PMC and reappoint a PMC based on actual contribution. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Greg Stein wrote: > > Yup. And I'll note that that "limbo" you describe has been an issue > with the Board for a long while now. That is why the Board instructed > the IPMC to request all podlings to list two items in their reports: > > 1) when did you arrive? > 2) what is left? > > Specifically to focus the podling (and the IPMC) on the question of > "WHY are you still in the Incubator?" > > Podlings should be shepherded *out* rather than held *in*. Hmmm... here you go again. Do you really believe there's a mentor here who doesn't want to be 'done' with their task at hand, offering up a functioning project for graduation? Mentors -do- exactly this, which is why your rants continue to read as disingenuous and insulting. We are glad the board has such confidence that the Incubator is producing effect meritocracies that collaborate effectively. If your's is not the minority opinion, there is a much larger 'Insanity' thread to begin, which starts with [VOTE] and ends in "Dissolve Incubator?" - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Joe Schaefer wrote: > >> From: Justin Erenkrantz >> >> Let me put it another way: if the IPMC accepts a proposal with one >> mentor, then I'm fine with that one mentor acting on behalf of the >> IPMC without the need to constantly go back to the IPMC for approval. >> -- justin > > For non-release issues, I'm fine with that. For releases I would still insist > on 3 +1's from IPMC members; if a podling can acquire those without coming > to gene...@incubator for final approval I could live with that (I'd need to > update the IPMC release guidelines tho). I'm not [fine with that]. If another person or two can't be bothered to verify the very few decisions-with-binding-votes (adding/subtracting people and of course, releasing code) against the PPMC's decision and rational, then there is a bigger problem that won't be addressed by just sweeping these votes out the front door. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Justin Erenkrantz wrote: > On Mon, Nov 9, 2009 at 3:26 PM, Martijn Dashorst > wrote: >> On Mon, Nov 9, 2009 at 3:15 PM, Justin Erenkrantz >> wrote: >>> To be clear, it's on the mentors to decide what is applicable and >>> necessary for graduation - not the IPMC as a whole. >> Nope... The whole IPMC has been tasked with oversight. The mentors are >> proxies for the whole IPMC. > > You can't have it both ways. By approving the proposal, the IPMC > delegates its oversight authority to the mentors. The IPMC then > confirms that the proper process was followed when it votes for > graduation. The mentors can ask for pre-approval for certain > 'waivers' like Greg is asking for - but it's unfair for a non-mentor > to try to tell a podling what it can or can not do. -- justin Whoa. Have you really been absent from Incubator for this long? Granted, each mentor is only -one- voice, each IPMC member is only -one- voice, with equal standing in the Incubator PMC and as ambassadors to the PPMC efforts. But a non-mentor has no less responsibility or authority to help work out a problem than a mentor does. Get down off the high horse before you hurt yourself ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Greg Stein wrote: > The Apache Incubator is about EDUCATION. It is about TEACHING podlings > how to work here at Apache. I'm a little confused. I'm reading a really long rant here, but I expect if you look at what nearly all mentors do in their respective podlings, this is exactly what they provide (granted, with wildly varying degrees of effort or attention). Quite frankly, all svncorp releases could, with reasonable documentation [read: mailing list archives, CLA's and code grant] be licensed as ASF releases under the AL 2.0, irrespective of their internal artifact copyright statements. A proviso that 1.7.0 won't be approved without running it through RAT, either pre or post graduation seems sufficient. The process is better documented than 95% of ASF project release processes, so there's no issue. But ranting against your perception of Incubator's failure to EDUCATE and TEACH podlings how the ASF environment works is really quite disappointing, coming from you. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Greg Stein wrote: > > The Subversion project would like to join the Apache Software > Foundation to remove the overhead of having to run its own > corporation. The Subversion project is already run quite like an > Apache project, and already counts a number of ASF Members amongst > its committers. +1 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
Greg Stein wrote: > > Sponsors > * Champion: Greg Stein Cool > * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel > Rall Once again, caution against committers == mentors (== 'project leads'). It puts certain committers above others, an inequitable situation. If the PPMC is 100% in support of 'respecting' this list of mentors with respect to adapting to life-in-the-ASF, then fine. But it's a situation that always concerns me. The incubator PMC could easily find mentors who are supportive of this proposal, but not in dev/leadership roles within the SVN community. > * Sponsor: I am certain the APR project would entertain a vote to sponsor this podling through graduation, if that is useful. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Craig L Russell wrote on Mon, 9 Nov 2009 at 14:12 -0800: > Hi Greg, > > I'm afraid that you have totally mistranslated my message and I have no idea > why. > > I'm not trying to pick a fight. > > I'm trying to be reasonable. > > I don't perceive your reaction as positive. > > I'm not going to continue this discussion until you have something concrete to > discuss. I voted to accept Subversion into the incubator. Your turn. > > Craig > > On Nov 8, 2009, at 5:25 PM, Greg Stein wrote: > > > The Apache Incubator is about EDUCATION. It is about TEACHING podlings > > how to work here at Apache. > > > > It is not about making podlings thoughtlessly follow checklists. ... > > > > On Fri, Nov 6, 2009 at 20:19, Craig L Russell wrote: > > > ... > > > As I thought I said earlier, *any* release that has proper Apache > > > packaging, licensing, and notices is fine with me. > > > We've had this discussion in the incubator before, for similar > > > reasons, and I think there is consensus that a formal review of a > > > podling release is a reasonable gate for graduation. No one needs to > > > believe that the release is stable, tested, reliable, etc.; it just > > > needs to be reviewed. Besides packaging, licensing, and notices, what else should be reviewed? > > > Also: Hyrum set up (some time ago) nightly tarballs. IIRC they are generated by the same scripts used to roll our stable releases, except that they are rolled straight from trunk (with the usual "may not compile" caveats). If packaging is the only issue, could these tarballs be inspected instead? Daniel (they're generated by tools/dist/nightly.sh. Hyrum's server that runs the script daily and publishes the output tarballs is temporarily offline, so no link to live nightly tarballs, sorry.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
