Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 11:43 PM, Daniel Kulp dk...@apache.org wrote: Actually, the vote was kind of withdrawn to update it to new descriptors. Thus, its not available yet. In anycase, no need to spam all the PMCs, especially those not using Maven. Just keep an eye on the annou...@maven list. When available, it will be announced there. Why not sent it through bo...@? All Chairs are subscribed to that list, several board members have in the past raised concerns about the releases created using maven. This would unequivocally show that maven has delivered a working solution, and notify all PMC chairs of the general Apache parent pom. They are responsible for communicating that with their own community IMO if it is applicable. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On 12 Nov 2009, at 03:16, Greg Stein wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. +1, having experienced both, IMVHO RTC shrinks a community to a core team of dedicated and highly knowledgeable committers. CTR expands and educates a community not least because committed mistakes demand fixing by the committer and then anyone who can fix the bug. The only downside is that occasionally trunk wont build/run and if trunk is close to production that probably matters. Shindig is mostly RTC, and was very close to big production. Sling is mostly CTR Ian Cheers, -g On Wed, Nov 11, 2009 at 11:09, Matthieu Riou matth...@offthelip.org wrote: Hi guys, What's the take of other mentors and the IPMC on podlings practicing RTC? I'm asking because some seem to see it as a blocker for graduation whereas I see it much more as a development methodology with little community impact and therefore no real influence on graduation. Strong opinions here? Thanks, Matthieu - 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: Review-Then-Commit
Ian Boston schrieb: not least because committed mistakes demand fixing by the committer and then anyone who can fix the bug. The only downside is that occasionally trunk wont build/run and if trunk is close to production that probably matters. I think another downside is, that (maybe depending on the community) in reality a proper review often doesn't happen in the case of CTR and in the case of performance/scalability this can be very bad, because the actual problems are often detected at a very late stage and then it can be very hard to solve these issues, because the code has already advanced too far. I see the postive sides of CTR re community and progress, but I think it requires some additional rules, guidelines in order to make it work. Cheers Michael Shindig is mostly RTC, and was very close to big production. Sling is mostly CTR Ian Cheers, -g On Wed, Nov 11, 2009 at 11:09, Matthieu Riou matth...@offthelip.org wrote: Hi guys, What's the take of other mentors and the IPMC on podlings practicing RTC? I'm asking because some seem to see it as a blocker for graduation whereas I see it much more as a development methodology with little community impact and therefore no real influence on graduation. Strong opinions here? Thanks, Matthieu - 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: Review-Then-Commit
Michael Wechner wrote: Ian Boston schrieb: not least because committed mistakes demand fixing by the committer and then anyone who can fix the bug. The only downside is that occasionally trunk wont build/run and if trunk is close to production that probably matters. I think another downside is, that (maybe depending on the community) in reality a proper review often doesn't happen in the case of CTR and in the case of performance/scalability this can be very bad, because the actual problems are often detected at a very late stage and then it can be very hard to solve these issues, because the code has already advanced too far. I see the postive sides of CTR re community and progress, but I think it requires some additional rules, guidelines in order to make it work. As a matter of fact, at Directory, we are using CTR since the beginning, and we have had to define those rules. It's pretty easy : - if it does not compile locally, don't commit - when you commit, always try to do it in a way a simple revert restore the previous state - when doing some heavy refactoring, do it in a branch - add some integration tests early in the process - for new committers, check their commits until they are trustable - define some code rules (syntax, comments, etc) followed by everyone. That's pretty much it, and it work quite well considering the project size (325 000 slocs as of today...) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 7:16 PM, Greg Stein gst...@gmail.com wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. +1, thanks for writing this all out Greg, your thoughts about RTC for 'trunk' type branches is exactly inline with my own -- it doesn't mean there should be a decrease in end quality, but it definitely does stifle several potential aspects of the community. This is my concern with regards to Cassandra, based on my own experiences with CTR/RTC at Apache and other projects. Thanks, Paul - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 8:16 PM, Greg Stein gst...@gmail.com wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. +1 Very well said, Greg. Bruce -- perl -e 'print unpack(u30,D0G)u8...@4vyy95R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
Why not sent it through bo...@? All Chairs are subscribed to that list, several board members have in the past raised concerns about the releases created using maven. This would unequivocally show that maven has delivered a working solution, and notify all PMC chairs of the general Apache parent pom. They are responsible for communicating that with their own community IMO if it is applicable. Well, I feel like if I email board@, then I should be talking to _the board_ and not everyone else in the room. The promotion of this release would naturally be noted in the next board report, as where the previous changes when we made them inside the maven project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, 2009-11-12 at 08:44 +0100, Justin Erenkrantz wrote: I think part of Cassandra's problem is that they do releases directly from trunk and don't have a 'stable' et al branch. No, this isn't (has never been) true. https://svn.apache.org/repos/asf/incubator/cassandra/branches/ The cassandra-0.4 branch alone has seen 3 releases so far. -- Eric Evans eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, 2009-11-12 at 07:16 +, ant elder wrote: so about 6 months ago to try to help with problems they were having, and since then 99% of the commits have been made by only two people. I assume you're referring to Jonathan Ellis and myself, and I'm not sure that's exactly fair. There are only 4 active committers, and of the 4, Jonathan and I spend the most time committing patches contributed by people who can't, and quite often the review was conducted by someone else who doesn't have commit rights and we are simply acting as a proxy. This results in a lot of svn commits made by us, for contributions that are not technically ours. As a convention, we typically put something like Patch by $author; reviewed by $reviewer for $issue_id in the change description. I just went through the commits scraping out those messages and it looks like Jonathan and I account for a little more than 60%, not 99%. -- Eric Evans eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, 2009-11-11 at 22:16 -0500, Greg Stein wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I agree with this, and as a Cassandra committer I have in the past protested our use of RTC. However, the current work-flow *in practice* is more about having someone, anyone, give changes a once over (making sure they build, that tests pass, that they do what they claim, etc), before committing. I agree with you, but tabled my protest because in practice what we have is working, doesn't seem to be a barrier to contribution, and everyone seems happy with it (even the casual contributors). I actually work with these people on a daily basis, and I trust that when/if it actually does become a problem, that people will be open to changing it. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. Cassandra is in incubation, so by all means, use the IPMC group-mind to smash the individual, excited, and free-thinking Cassandra contributors into submission. -- Eric Evans eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, ant elder wrote: so about 6 months ago to try to help with problems they were having, and since then 99% of the commits have been made by only two people. I assume you're referring to Jonathan Ellis and myself, and I'm not sure that's exactly fair. There are only 4 active committers, and of the 4, Jonathan and I spend the most time committing patches contributed by people who can't, and quite often the review was conducted by someone else who doesn't have commit rights and we are simply acting as a proxy. This results in a lot of svn commits made by us, for contributions that are not technically ours. As a convention, we typically put something like Patch by $author; reviewed by $reviewer for $issue_id in the change description. I just went through the commits scraping out those messages and it looks like Jonathan and I account for a little more than 60%, not 99%. -- Eric Evans eev...@rackspace.com So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? That's pretty much what they're doing about right now but as you know, it takes some time to establish a good patch history. I really don't thin Cassandra should be accused of being bad at attracting and voting in new committers. Given how they started they're definitely better at it than most podlings. Matthieu ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 10:36 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@rackspace.com wrote: I agree with you, but tabled my protest because in practice what we have is working, doesn't seem to be a barrier to contribution, and everyone seems happy with it (even the casual contributors). I wouldn't say everyone. This whole thread started because at least one person is not happy with it. We had a long discussion about this on cassandra-dev. If I remember correctly, everyone who actually contributes code to the project expressed a preference for the current lightweight RTC appraoch. -Jonathan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@rackspace.com wrote: ... I agree with this, and as a Cassandra committer I have in the past protested our use of RTC. However, the current work-flow *in practice* is more about having someone, anyone, give changes a once over (making sure they build, that tests pass, that they do what they claim, etc), before committing. I agree with you, but tabled my protest because in practice what we have is working, doesn't seem to be a barrier to contribution, and everyone seems happy with it (even the casual contributors). I wouldn't say everyone. This whole thread started because at least one person is not happy with it. I actually work with these people on a daily basis, and I trust that when/if it actually does become a problem, that people will be open to changing it. This actually scares me a bit. That a discussion of methodology is happening among a few people at work, rather than among everybody on the mailing list. ... My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. Cassandra is in incubation, so by all means, use the IPMC group-mind to smash the individual, excited, and free-thinking Cassandra contributors into submission. My opinion was asked, and I answered. Please don't ascribe more to it than that. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, ant elder wrote: so about 6 months ago to try to help with problems they were having, and since then 99% of the commits have been made by only two people. I assume you're referring to Jonathan Ellis and myself, and I'm not sure that's exactly fair. There are only 4 active committers, and of the 4, Jonathan and I spend the most time committing patches contributed by people who can't, and quite often the review was conducted by someone else who doesn't have commit rights and we are simply acting as a proxy. This results in a lot of svn commits made by us, for contributions that are not technically ours. As a convention, we typically put something like Patch by $author; reviewed by $reviewer for $issue_id in the change description. I just went through the commits scraping out those messages and it looks like Jonathan and I account for a little more than 60%, not 99%. -- Eric Evans eev...@rackspace.com So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@gmail.com wrote: So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? It's a long tail sort of thing. We follow the convention Johan suggested of assigning the Jira issue to the author of the change, so e.g. for 05 the contributions look like this: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=Next The main name that stands out there to me that is not already a committer is Gary Dusbabek, who has been working on Cassandra for about a week now but who I expect will be nominated soon at this rate. The other top contributors are already committers. -Jonathan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:36 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@rackspace.com wrote: ... I agree with this, and as a Cassandra committer I have in the past protested our use of RTC. However, the current work-flow *in practice* is more about having someone, anyone, give changes a once over (making sure they build, that tests pass, that they do what they claim, etc), before committing. I agree with you, but tabled my protest because in practice what we have is working, doesn't seem to be a barrier to contribution, and everyone seems happy with it (even the casual contributors). I wouldn't say everyone. This whole thread started because at least one person is not happy with it. And that person isn't a committer but a user. Note that I agree with some of your remarks (and his), my point though is that it's up to the PMC to figure it out and it shouldn't be more than an advice for them to take into account. Not a graduation blocker. I actually work with these people on a daily basis, and I trust that when/if it actually does become a problem, that people will be open to changing it. This actually scares me a bit. That a discussion of methodology is happening among a few people at work, rather than among everybody on the mailing list. I think the work above was work-as-in-developing, not work-as-in-workplace. Matthieu ... My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. Cassandra is in incubation, so by all means, use the IPMC group-mind to smash the individual, excited, and free-thinking Cassandra contributors into submission. My opinion was asked, and I answered. Please don't ascribe more to it than that. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@gmail.com wrote: So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? It's a long tail sort of thing. We follow the convention Johan suggested of assigning the Jira issue to the author of the change, so e.g. for 05 the contributions look like this: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=Next That JIRA report shows a range of contributors that many TLPs would be envious of, and it shows a quite different picture from the commit history, eg: http://www.svnsearch.org/svnsearch/repos/ASF/search?from=20090801to=20091231path=%2Fincubator%2Fcassandra It would be great to get more of those contributors actually doing the commits though, maybe modifying the current commit process as is being suggested in this thread could help get that to happen. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, 2009-11-12 at 11:36 -0500, Greg Stein wrote: I agree with you, but tabled my protest because in practice what we have is working, doesn't seem to be a barrier to contribution, and everyone seems happy with it (even the casual contributors). I wouldn't say everyone. This whole thread started because at least one person is not happy with it. You're right, I wasn't being very precise with my wording. Overwhelming majority, or people actually doing the work would have been better. I actually work with these people on a daily basis, and I trust that when/if it actually does become a problem, that people will be open to changing it. This actually scares me a bit. That a discussion of methodology is happening among a few people at work, rather than among everybody on the mailing list. Maybe this is another case of me not being precise enough with my wording. I routinely collaborate with the members of the Cassandra community, on IRC and mailing lists, (not at my place of employment). My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. Cassandra is in incubation, so by all means, use the IPMC group-mind to smash the individual, excited, and free-thinking Cassandra contributors into submission. My opinion was asked, and I answered. Please don't ascribe more to it than that. Sure, but the IPMC is in a position of power, and can impose it's will upon the project (including CTR vs. RTC), right? -- Eric Evans eev...@rackspace.com - 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 Nov 10, 2009, at 10:08 PM, Niclas Hedhman wrote: On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: 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. I agree that diversity is a derivative requirement however, I think that there should be a list of all the committers and their company affiliation, if they are being paid to work on the project, for every project web site. I know that it's being done with varying degrees. But if we're going explicitly downplay diversity requirements for some projects then I think we need to be diligent on being upfront on the community makeup. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:55 AM, ant elder antel...@apache.org wrote: On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@gmail.com wrote: So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? It's a long tail sort of thing. We follow the convention Johan suggested of assigning the Jira issue to the author of the change, so e.g. for 05 the contributions look like this: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=Next That JIRA report shows a range of contributors that many TLPs would be envious of, and it shows a quite different picture from the commit history, eg: http://www.svnsearch.org/svnsearch/repos/ASF/search?from=20090801to=20091231path=%2Fincubator%2Fcassandra Evan and Jonathan are the most active committers but still I can see quite a few: patch by Jaakko Laine and jbellis patch by Scott White; reviewed by Brandon Williams patch by Jaakko Laine; reviewed by jbellis patch by Gary Dusbabek; reviewed by eevans And that's only going as far as 2 days ago. So is the problem only what the commit log looks like if you only look at who committed the patch? Matthieu It would be great to get more of those contributors actually doing the commits though, maybe modifying the current commit process as is being suggested in this thread could help get that to happen. ...ant - 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 Wed, Nov 11, 2009 at 06:18, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein gst...@gmail.com 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. It is about TEACHING them what are the important aspects of development at Apache. About SHOWING them each of the items to be aware of. It is not about blind adherence to rules and procedure without regard to the podling's experience. It is about LEARNING who the podling is, what they do, what they have done, and what they are capable of, and producing a TEACHING experience for that podling so that they can be an effective and proper project here at the ASF. --- I was thinking, hey. no problem. we can go a bit out of our way and produce a release tuned for the Incubator needs and made a suggestion. That didn't satisfy some people, so further requirements were thrown in. hmm, I thought, well... that shouldn't be too much more of a burden. And then I received Craig's email below, and it brought me back to sanity. I had been forced off the path, and now realize just how crazy it is. On Fri, Nov 6, 2009 at 20:19, Craig L Russell craig.russ...@sun.com 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. Please let me translate: ANY release is fine, even if that release DOES NOT satisfy the project's ESTABLISHED LEVELS OF QUALITY. Shoot. All we want is *something*. Oh, and since it has completely inferior quality, it doesn't even have to be distributed! See how easy that is! Oh, never mind, that if we don't put it into the regular distribution channels, and don't make the regular announcements, then YOU'RE NOT DOING A REAL APACHE RELEASE. Nope. No way. The key question in my mind is What tasks does subversion need to undertake as part of its moving to the ASF so that any release it produces conforms to the ASF's policy on releases?. This itself is really part of the whole IP due diligence in bringing any code base here to the ASF IMO. So for example you're going to have to go through the pain of conforming to the policy on license headers for source files and the NOTICE and LICENSE files etc. I would expect that you would do that as part of the incubating process. I don't know how subversion actually creates its source release, but I would assume its a pretty trivial effort to create a an example/internal source distro that could be reviewed. This is what I think Craig was asking and it seemed to me like he was agreeing with your *internal release* suggestion - so I think you did him a big disservice with this rant. The only way reason I can think that you would object to this (because of the effort) is if you didn't plan to sort out subversion to conform to ASF policy before graduation. If you do plan to sort out all these things before graduation then its simply a case of running whatever command(s) you use to create the source distro on subversion's trunk and providing it for people to review. And I assume (and I believe Craig did as well) that that sort of *internal release* would be a pretty trivial effort and not much of a burden to ask. If you don't plan to sort these things out prior to graduation then thats probably the real argument (waiver) you need to get agreement on from the IPMC (rather than release). That's not a release. I've been asking to skip the *release* requirement. Construct a tarball for legal review? Not a problem. We're going to be integrated into the ASF buildbot network almost as soon as the repository migrates. That thing chunks out tarballs, apparently. Not sure if it puts those on svn.apache.org/snapshots/, but that's where I'd like to see them. One of the committers runs nightlies, so we can easily migrate that process. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
Eric Evans wrote: Sure, but the IPMC is in a position of power, and can impose it's will upon the project (including CTR vs. RTC), right? I have no clue whether the IPMC can impose such a decision. But I'm very, very certain that it should not even consider trying. It's better to ask the podling's PMC to address concerns and let them work it out, than simply telling them that we see this problem, and here's how you will fix it. That would be rather counterproductive, the idea is to ensure the project can live independently once it has graduated. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[last call] svn repository moving Sunday (was: Two other issues to discuss for Subversion)
It looks like we might be moving the code repository over on Sunday(!). Thus, my query about source code placement has a finite window for further discussion :-) Over the past two days, it sounds like nobody has any particular object to the svn code being loaded directly to /subversion. (yes, it is still under purview of the IPMC) Is there any further discussion or concerns before we pull the trigger? fwiw, the software grant should arrive tmw, and ICLAs are being recorded as we speak. Thanks, -g On Tue, Nov 10, 2009 at 14:27, Greg Stein gst...@gmail.com 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
Re: Two other issues to discuss for Subversion
Thanks, and yes: agreed on the rationale. And have no fears. We aren't going to back out. And I'm not seeing that the ASF would boot us. So that just means we need to work through it :-) On Wed, Nov 11, 2009 at 19:17, Leo Simons m...@leosimons.com wrote: On Tue, Nov 10, 2009 at 7:27 PM, Greg Stein gst...@gmail.com 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 think a good thing we started here is to dig back in memory to find the core reasons why the process is what it is and make sure we stick to what's important. I think we have two main reasons to have the incubator name in most those places normally: 1) make clear to users what the status of a project is, i.e. where incubation is implying that a project may not become an apache project or that it may not be quite safe legally yet or it may not have a healthy community behind it or we don't have the trademarks yet or whatever 2) protect the apache brand (you know...if an incubating project goes up in flames, well, that's ok, we told you that might happen) 3) make it easier to keep a tight leash on PR I would argue we are not very worried about subversion being unsafe for use by the general public :-). Similarly, the main thing that would hurt our brand is if the subversion community would decide to cancel the incubation process (because apache really sucks, you know...). The most important thing these days is probably clear messaging on the relevant website(s). So, as long as y'all make sure to do that good stuff (be clear to users and protect the involved brands), I think what infrastructure goes where exactly, can be up to infra@, in this case. And y'all are talking to PRC anyway about any press stuff. I see no real risks. cheers, 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: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:44, Matthieu Riou matthieu.r...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, ant elder wrote: so about 6 months ago to try to help with problems they were having, and since then 99% of the commits have been made by only two people. I assume you're referring to Jonathan Ellis and myself, and I'm not sure that's exactly fair. There are only 4 active committers, and of the 4, Jonathan and I spend the most time committing patches contributed by people who can't, and quite often the review was conducted by someone else who doesn't have commit rights and we are simply acting as a proxy. This results in a lot of svn commits made by us, for contributions that are not technically ours. As a convention, we typically put something like Patch by $author; reviewed by $reviewer for $issue_id in the change description. I just went through the commits scraping out those messages and it looks like Jonathan and I account for a little more than 60%, not 99%. -- Eric Evans eev...@rackspace.com So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? That's pretty much what they're doing about right now but as you know, it takes some time to establish a good patch history. I really don't thin Cassandra should be accused of being bad at attracting and voting in new committers. Given how they started they're definitely better at it than most podlings. Easy there... nobody is accusing anybody of anything. You asked a question, and people have answered. Some of those answers have come with concerns. That generates discussion. I think it is good for any project to review why it is operating *differently* than the majority of projects here at the ASF. Why is it special? Are those special considerations actually masking a problem underneath? Are those special processes going to hinder the free and inclusive participation and community-building that we like to see in our projects? It's fair to ask those questions, especially of a podling. But please don't misconstrue discussion as accusation. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:01 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:44, Matthieu Riou matthieu.r...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, ant elder wrote: so about 6 months ago to try to help with problems they were having, and since then 99% of the commits have been made by only two people. I assume you're referring to Jonathan Ellis and myself, and I'm not sure that's exactly fair. There are only 4 active committers, and of the 4, Jonathan and I spend the most time committing patches contributed by people who can't, and quite often the review was conducted by someone else who doesn't have commit rights and we are simply acting as a proxy. This results in a lot of svn commits made by us, for contributions that are not technically ours. As a convention, we typically put something like Patch by $author; reviewed by $reviewer for $issue_id in the change description. I just went through the commits scraping out those messages and it looks like Jonathan and I account for a little more than 60%, not 99%. -- Eric Evans eev...@rackspace.com So about 40% of the committed code is coming from others and reviewed by others - great - why not make some of those others committers? That's pretty much what they're doing about right now but as you know, it takes some time to establish a good patch history. I really don't thin Cassandra should be accused of being bad at attracting and voting in new committers. Given how they started they're definitely better at it than most podlings. Easy there... nobody is accusing anybody of anything. Ah, sorry if that came across too strongly, I didn't mean it that way. I just meant that I haven't seen a problem in the way Cassandra was attracting committers. So that was definitely discussion as well on my side :) Matthieu You asked a question, and people have answered. Some of those answers have come with concerns. That generates discussion. I think it is good for any project to review why it is operating *differently* than the majority of projects here at the ASF. Why is it special? Are those special considerations actually masking a problem underneath? Are those special processes going to hinder the free and inclusive participation and community-building that we like to see in our projects? It's fair to ask those questions, especially of a podling. But please don't misconstrue discussion as accusation. Cheers, -g
Re: How to shorten the duration of incubation (Was: Insanity...)
2009/11/10 Jukka Zitting jukka.zitt...@gmail.com: 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. The new community development project is focussing on creating a continuous mentoring programme based on the highly successful GSoC programme. Whilst the project is to focus on mentoring of individuals not initially attached to a project I suspect the materials and processes we create will be of significant value to the mentoring of new community members entering via podlings. To this end Noel has requested that he be made a member of the Community Development PMC, he will almost certainly be voted in once the projects mailing lists are set up. In other words, #3 may not be possible right now, but I hope that we can improve on this area in the future. Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein gst...@gmail.com wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I think this entirely depends on how quickly you get an R. I've worked for $BIGCOs that do CTR and have really stifling cultures and $SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum which is more sustainable because the explicit review means at least one other person knows what it is that you're doing so there's some instant knowledge sharing to reduce the risk of blind alleys and the bus factor. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I'd flip this around and look at it from the PoV of a not-yet-committer. RTC means everybody goes through basically the same process - (raise jira), hack, submit patch, patch gets reviewed, patch gets committed regardless of whether they have a commit bit or not. CTR means there is a qualitative difference in workflows between committers and non-committers. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). I'm sorry you found it that way, I don't think it has to be that way though. :/ My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. I think that sort of group mentality is problematic regardless of review model, it's perhaps a bit more commonly found in RTC but I don't think it's inherent to the system (you can insert your own Monty Python reference here if you want). The main benefit I've always found for RTC (beside being slightly flatter, as outlined above), is that it means that the review actually happens and can be seen to have happened. CTR often falls by the wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try and support this and still ended up with something like 50 jiras in ready to review state. While it's possible that somebody read the code and couldn't be bothered to click the button, I think it's much more likely that they're basically unreviewed. There's also a number of Jiras that are essentially review comments that have been kicking around for ages. A number of large, venerable projects run with RTC for a number of reasons. I know a lot of people dislike it due to prior bad experience, that it stifles them, holds up progress etc. To them I say http://git-scm.com ;) - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
Yup. We have all had different experiences, and I certainly acknowledge it is possible to have a successful RTC model in place. The real problem is that there is always a success story for any position. See? It works here. And there are *so* many factors that go into that success, beyond the simple tradeoff of CTR vs RTC. So it is very difficult to objectively compare/contrast models. We can sit around and throw out our own experiences, but those won't necessarily apply to Cassandra. Personally, I'm suspect of any RTC here at the ASF. In this specific case, it sounds like more committers and a return to CTR could be good. The 99% commit statistic (no matter *how* you want to break down the patch-from-others) is worrying. Why aren't other committers present and participating in that patch application? (or their own work) btw, if a community is not running smoothly, then referring people to git-scm is totally the wrong solution: fix the community, rather than sending people off to their own corners with their own branches, all working independently rather than together. My biggest problem with Git isn't the tech (which is great!), but the social aspects of a default workflow that stresses individualism rather than cooperation. Cheers, -g On Thu, Nov 12, 2009 at 17:46, Aidan Skinner aidan.skin...@gmail.com wrote: On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein gst...@gmail.com wrote: Not a strong opinion, but I think that RTC hampers the free-flow of ideas, experimentation, evolution, and creativity. It is a damper on expressivity. You maneuver bureaucracy to get a change in. CTR is about making a change and discussing it. But you get *forward progress*. I think this entirely depends on how quickly you get an R. I've worked for $BIGCOs that do CTR and have really stifling cultures and $SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum which is more sustainable because the explicit review means at least one other person knows what it is that you're doing so there's some instant knowledge sharing to reduce the risk of blind alleys and the bus factor. I also feel that RTC will tend towards *exclusivity* rather than the Apache ideal of *inclusivity*. That initial review is a social and mental burden for new committers. People are afraid enough of submitting patches and trying to join into a development community, without making them run through a front-loaded process. I'd flip this around and look at it from the PoV of a not-yet-committer. RTC means everybody goes through basically the same process - (raise jira), hack, submit patch, patch gets reviewed, patch gets committed regardless of whether they have a commit bit or not. CTR means there is a qualitative difference in workflows between committers and non-committers. I've participated in both styles of development. RTC is *stifling*. I would never want to see that in any Apache community for its routine development (branch releases are another matter). I'm sorry you found it that way, I don't think it has to be that way though. :/ My opinion is that it is very unfortunate that Cassandra feels that it cannot trust its developers with a CTR model, and pushes RTC as its methodology. The group-mind smashes down the creativity of the individual, excited, free-thinking contributor. I think that sort of group mentality is problematic regardless of review model, it's perhaps a bit more commonly found in RTC but I don't think it's inherent to the system (you can insert your own Monty Python reference here if you want). The main benefit I've always found for RTC (beside being slightly flatter, as outlined above), is that it means that the review actually happens and can be seen to have happened. CTR often falls by the wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try and support this and still ended up with something like 50 jiras in ready to review state. While it's possible that somebody read the code and couldn't be bothered to click the button, I think it's much more likely that they're basically unreviewed. There's also a number of Jiras that are essentially review comments that have been kicking around for ages. A number of large, venerable projects run with RTC for a number of reasons. I know a lot of people dislike it due to prior bad experience, that it stifles them, holds up progress etc. To them I say http://git-scm.com ;) - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - 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: [last call] svn repository moving Sunday (was: Two other issues to discuss for Subversion)
Forgot to list the Infrastructure ticket, in case you would like to follow the migration more closely: https://issues.apache.org/jira/browse/INFRA-2321 On Thu, Nov 12, 2009 at 13:41, Greg Stein gst...@gmail.com wrote: It looks like we might be moving the code repository over on Sunday(!). Thus, my query about source code placement has a finite window for further discussion :-) Over the past two days, it sounds like nobody has any particular object to the svn code being loaded directly to /subversion. (yes, it is still under purview of the IPMC) Is there any further discussion or concerns before we pull the trigger? fwiw, the software grant should arrive tmw, and ICLAs are being recorded as we speak. Thanks, -g On Tue, Nov 10, 2009 at 14:27, Greg Stein gst...@gmail.com 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
[last call] setting up Subversion mailing lists (was: Two other issues to discuss for Subversion)
Joe Schaefer asked if he could set up the mailing lists this weekend. The discussion seemed to end, with no particular opposition, so I filed an Infrastructure ticket to track the creation of the mailing lists: https://issues.apache.org/jira/browse/INFRA-2324 At this time, we're setting up just five mailing lists: dev, users, commits, announce, and private. All lists will be hosted on @subversion.apache.org. The Subversion community is still discussing the migration strategy to these lists. Various options[1] around auto-replies, subscribing one list to another, etc etc. We're also discussing the migration of the archives, which will happen at a later time. In discussions with Infra, we've determined that we can begin using the new lists immediately (and we will), and then we'll mesh the list archives together later. You can watch the Infra ticket, and I will also follow up to this list after the creation is complete so that you can subscribe. Cheers, -g [1] but shifting subscribers w/o consent is not among them :-) On Tue, Nov 10, 2009 at 14:27, Greg Stein gst...@gmail.com 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
Re: Insanity. Apache Incubator should be about education
Hi, On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein gst...@gmail.com wrote: Plan: raise an issue, and we fix it. Not sure what else you're looking for. I was just pointing out that if you want to do the release review based on an existing 1.6.x release, I wouldn't expect it to be fully compliant with Apache policies (license headers, etc.) and would accept a plan on how those issues will be (or already are being) resolved in the first Apache release of Subversion (1.7.0?). To me that would satisfy the release-related exit criteria we have. I'm also fine with the other proposed ways of satisfying or waiving those exit criteria. BR, Jukka Zitting - 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
On Nov 12, 2009, at 9:05 PM, Jukka Zitting wrote: Hi, On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein gst...@gmail.com wrote: Plan: raise an issue, and we fix it. Not sure what else you're looking for. I was just pointing out that if you want to do the release review based on an existing 1.6.x release, I wouldn't expect it to be fully compliant with Apache policies (license headers, etc.) and would accept a plan on how those issues will be (or already are being) resolved in the first Apache release of Subversion (1.7.0?). To me that would satisfy the release-related exit criteria we have. FWIW, the Subversion nightly server is back online: http://orac.ece.utexas.edu/pub/svn/nightly/ The cron job used to generate those tarballs uses the exact same rolling scripts we use to generate standard releases, so those tarballs could be used to test whatever non-process-related qualifications for release people want to see. -Hyrum - 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
On Thu, Nov 12, 2009 at 22:05, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein gst...@gmail.com wrote: Plan: raise an issue, and we fix it. Not sure what else you're looking for. I was just pointing out that if you want to do the release review based on an existing 1.6.x release, I wouldn't expect it to be fully compliant with Apache policies (license headers, etc.) and would accept a plan on how those issues will be (or already are being) resolved in the first Apache release of Subversion (1.7.0?). To me that would satisfy the release-related exit criteria we have. I'm also fine with the other proposed ways of satisfying or waiving those exit criteria. Sigh. You've just looped right back around. I offered a demonstration of the 1.6.x releases as a demonstration of our *process*. But that was deemed unacceptable. The Apache-branded stuff is trunk or 1.7, which has no scheduled release. No release was deemed unacceptable. If you want to review *bits* rather than *release process*, then you can take a look at trunk/ or the nightlies that we'll soon produce. If you want release process *and* Apache-branding, then the svn community is not prepared to provide that, nor do I think it necessary (see the deferred vote for waiving a release). But your above paragraph is some conflation of release practices, legal review, and how this fits into graduation requirements. And I just got done with a frustrating several days on that issue. What do you want? ugh, -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
Greg Stein wrote: If you want to review *bits* rather than *release process*, then you can take a look at trunk/ or the nightlies that we'll soon produce. If you want release process *and* Apache-branding, then the svn community is not prepared to provide that, nor do I think it necessary (see the deferred vote for waiving a release). Want? I'd express that as 'demand', knowing this committee. But don't be disheartened, I can see where 1) release process demonstration and 2) branding demonstration are two entirely seperate processes in this somewhat unusual case. On your other subject, svn and lists and site at subversion.apache.org, that is a problem but not insurmountable. If we move 1) the lists to subversion.apache.org [it's just a discussion, right? Only publicized on the original site] for overview, then 2) move the svn [so all commits track to @s.a.o discussions], and 2) stage the final site [leaving the *current* site primary until graduation] for review, and move that last on graduation day, I don't see a problem with not creating a slew of incubator.apache.org/subversion/ resources. This could all happen in weeks if not days, and should be least-disruptive to the well-established community. Are folks OK with this? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
svn website (was: Insanity. Apache Incubator should be about education)
On Fri, Nov 13, 2009 at 00:14, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... On your other subject, svn and lists and site at subversion.apache.org, that is a problem but not insurmountable. If we move 1) the lists to subversion.apache.org [it's just a discussion, right? Only publicized on the original site] for overview, Sure. In-process, per INFRA-2324. then 2) move the svn [so all commits track to @s.a.o discussions], Yup. Will happen as part of the repo move. See INFRA-2321. and 2) stage the final site [leaving the *current* site primary until graduation] for review, and move that last on graduation day, I don't see a problem with not creating a slew of incubator.apache.org/subversion/ resources. We're not sure what we'd like to do about website migration right now. Discussion is still occurring in the community. Status quo is: all pages are at http://subversion.tigris.org/, and the status page is on the incubator site. If we want to break out of that status quo, then we'll need to determine the publishing setup (eg. svnpubsub), where that is sourced from, and then to ensure the proper Incubator branding. Our current pages are all framed within the tigris.org infrastructure. Some discussion has started on a new layout/style for the content of our pages. Right now, I'd characterize the community as, we know there is no rush to move the website before graduation -- the two actions are independent. that said, having subversion.apache.org available to start playing around with is attractive. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn website (was: Insanity. Apache Incubator should be about education)
Greg Stein wrote: We're not sure what we'd like to do about website migration right now. Discussion is still occurring in the community. The bottom line is that we are in sync in terms of what aught to move into ASF and have 'formal recognition' ASAP. E.g. a mailing list is trivial, svn is not a release, and publishing the website/distros is a significant (IPMC approved) jump ahead. So there seems to be no flaw in your scheme :) Right now, I'd characterize the community as, we know there is no rush to move the website before graduation -- the two actions are independent. that said, having subversion.apache.org available to start playing around with is attractive. and best yet, ask users to shift each resource only once. I hope we adopt this approach for all mature incoming incubator items, and formulate it into a smooth process. Thanks for blazing a trail :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: maven releases at Apache (what does this have to do with: [PROPOSAL][VOTE] Subversion)
For unrelated reasons, I today split out the Apache-ness part of the Maven release process (still syncing): http://maven.apache.org/developers/release/apache-release.html It could still use more work, but that's all I have time for right now if someone wants to patch it (eg, to explain the parent POM reference needed), or move it to /dev, or whatever. That means there's a document that can be up to date for anyone wanting to do a Maven based release at Apache at a given time. To track common infrastructure, new plugins, and so on, I suggest subscribing to annou...@maven.apache.org. For example, we've just had: http://mail-archives.apache.org/mod_mbox/maven-announce/200911.mbox/%3c4afc90a0.7020...@apache.org%3e (we don't seem to be announcing parent POMs there, so that should change in the future). I believe that's enough to track what is needed, and much more appropriate than trying to follow it on board@, pmcs@, committers@, or gene...@incubator which are not the right forums. Does that work for those concerned about it? We could entertain creating another list @maven, or post notices to infrastructure@, but I don't see the added value... Cheers, Brett On 13/11/2009, at 2:13 AM, Brian Fox wrote: Why not sent it through bo...@? All Chairs are subscribed to that list, several board members have in the past raised concerns about the releases created using maven. This would unequivocally show that maven has delivered a working solution, and notify all PMC chairs of the general Apache parent pom. They are responsible for communicating that with their own community IMO if it is applicable. Well, I feel like if I email board@, then I should be talking to _the board_ and not everyone else in the room. The promotion of this release would naturally be noted in the next board report, as where the previous changes when we made them inside the maven project. - 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
