Re: Making up policy on the fly
a release check list would be nice On Sun, Aug 23, 2009 at 10:01 AM, ant elderant.el...@gmail.com wrote: On Sat, Aug 22, 2009 at 12:50 AM, Noel J. Bergmann...@devtech.com wrote: Joe Schaefer wrote: ant elder wrote: - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. The pejorative aside, I concur that Ant's suggestion is not the right way to go, because graduation is too late to instill Best Practice. We want practices to be ingrained, not performed as a one-off in order to graduate. Ok, but IMHO one thing that is getting ingrained into poddlings and observers right now is that we have lots and lots of rules and regulations, often undocumented and/or with no obvious consensus, and that the Incubator can be like a bureaucratic government department from hell where obscure requirements are randomly brought up to make getting releases done take as much work as possible. Surely that is not what we want a major part of our interface to the rest of the world to look like? I've been trying to come up with concrete suggestion for things to try, what are other suggestions on how to improve things? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Fri, Aug 21, 2009 at 7:32 AM, ant elderantel...@apache.org wrote: On Thu, Aug 20, 2009 at 12:01 PM, Niall Pembertonniall.pember...@gmail.com wrote: If there are improvements that can be made to policy/docs then great, but complaining about feedback rather than appreciating that someone took the trouble to review a release is a mistake IMO. Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ - make complying with best practices a graduation requirement not a release requirement Some more suggestions: - When issues come up during release reviews we often debate them here instead of getting documented answers from those that know so perhaps we should make more use of the ASF Legal Affairs Committee JIRA space - https://issues.apache.org/jira/browse/LEGAL - Use VOTE threads for voting. This is I think accepted best practice but quite often in our release vote threads we get posts with a list of issues but no vote and it can be hard to determine which if any are considered blocking problems that require a respin. I know I've been guilty of this too. Would it help if we all try to be clearer in our reviews and actually include a vote, or at least state precisely which issues need clarification before we'd vote? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Sat, Aug 22, 2009 at 12:50 AM, Noel J. Bergmann...@devtech.com wrote: Joe Schaefer wrote: ant elder wrote: - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. The pejorative aside, I concur that Ant's suggestion is not the right way to go, because graduation is too late to instill Best Practice. We want practices to be ingrained, not performed as a one-off in order to graduate. Ok, but IMHO one thing that is getting ingrained into poddlings and observers right now is that we have lots and lots of rules and regulations, often undocumented and/or with no obvious consensus, and that the Incubator can be like a bureaucratic government department from hell where obscure requirements are randomly brought up to make getting releases done take as much work as possible. Surely that is not what we want a major part of our interface to the rest of the world to look like? I've been trying to come up with concrete suggestion for things to try, what are other suggestions on how to improve things? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Thu, Aug 20, 2009 at 11:25 AM, Marcel Offermansmarcel.offerm...@luminis.nl wrote: On Aug 20, 2009, at 10:12 , ant elder wrote: On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretazbdelacre...@apache.org wrote: I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. [...] I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Bertrand's analogy about educating kids highlights the problem. No two parents raise their children in exactly the same way and if lots of them all give their interpretation about values and best practices the message can become quite confusing to these kids. So is there anything that can be done to streamline that? Like having just the mentors of the project vote on the release, instead of everybody? If the mentors do a bad job, hold them accountable directly without confusing the project. Does that make any sense? Greetings, Marcel It does make sense to me, we probably can't and shouldn't prohibit any one from voting but what would help towards that is the suggestion earlier in this thread to have the release vote held on just the poddlings dev list with only notification to gene...@. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Thu, Aug 20, 2009 at 12:01 PM, Niall Pembertonniall.pember...@gmail.com wrote: On Thu, Aug 20, 2009 at 9:12 AM, ant elderant.el...@gmail.com wrote: On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretazbdelacre...@apache.org wrote: On Wed, Aug 19, 2009 at 7:15 PM, Ted Leungtwle...@sauria.com wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) And I agree with Ted that it's often very hard for podlings (or even mentors) to find out what those best practices are, without reading tons of sometimes stale discussions here. Something like legal's previously asked questions (http://apache.org/legal/resolved.html) would help a lot. We could discuss things like this LICENSE and NOTICE matter here, vote on the outcome and document the question and answer there, with a permanent URL that points to the question. I'm willing to help maintain such a page if people think that's a good idea. -Bertrand Having trouble finding where to reply on this thread so I'll just go here at the bottom... I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. The debate about separate vs single LICENSE files has become a bit of a distraction, even in the recent Cassandra release that was just one of a whole list of issues brought up. I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Could we make following best practices what ever we decide those are a graduation requirement instead of a release requirement? So releases which don't clearly violate some ASF policy are voted out quickly and its the poddling graduation that is delayed until they've done a release we're all happy with. I understand theres frustration, but usually its short_term - once a podling has resolved the issues that people raise then the next release should be easier / have less comments. All these issues about whether something is or is not policy or just someones view of best practice is, in my experience, what happens elsewhere in projects when it comes to releases. At the end of the day if you want someone to vote +1 on a release then release managers need to address peoples feedback. If they ignore feedback that is nice-to-have but not absolute requirements then they risk that person not voting or bothering to review a release next time. Being a release manager takes patience and judgement/negotiation about whether something needs to be fixed for a release or can be left till next time and this is something that will happen once a project graduates and not just here. There are two differences between here and elsewhere releases that are making that not work so well here: 1) The group of people reviewing Incubator releases is much more variable compared to a TLP PMC 2) The people voting on Incubator releases are usually not on the poddling dev/commit lists so don't give input during the release preparation If there are improvements that can be made to policy/docs then great, but complaining about feedback rather than appreciating that someone took the trouble to review a release is a mistake IMO. Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ - make complying with best practices a graduation requirement not a release requirement I'll go start a separate thread on the first of those to see what people think. ...ant Niall - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Fri, Aug 21, 2009 at 2:32 PM, ant elderantel...@apache.org wrote: - hold the release votes on the poddling mailing lists not general@ - make complying with best practices a graduation requirement not a release requirement +1, with a big IF; there are no legal requirements (which needs to be well defined) missing. 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: Making up policy on the fly
- Original Message From: ant elder antel...@apache.org To: general@incubator.apache.org Sent: Friday, August 21, 2009 2:32:39 AM Subject: Re: Making up policy on the fly Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ At one point or another I thought that might be an improvement. Having seen how many podling releases fail to pass the vote on gene...@incubator has me thinking otherwise. Until the gene...@incubator votes are little more than rubber stamps of the votes conducted on the podling's dev list, I wouldn't be in favor of such a change. - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. It's simply a good idea, and in the project's best interests to do so, because it is a precondition for getting +1's from several IPMC members. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Fri, Aug 21, 2009 at 2:47 PM, Joe Schaeferjoe_schae...@yahoo.com wrote: - Original Message From: ant elder antel...@apache.org To: general@incubator.apache.org Sent: Friday, August 21, 2009 2:32:39 AM Subject: Re: Making up policy on the fly Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ At one point or another I thought that might be an improvement. Having seen how many podling releases fail to pass the vote on gene...@incubator has me thinking otherwise. Until the gene...@incubator votes are little more than rubber stamps of the votes conducted on the podling's dev list, I wouldn't be in favor of such a change. But i think this might be one of the reasons thats causing the poddling reviews and votes to be less than perfect - they're seen to have so little value. I've seen at least one poddling not bother with a formal vote on their dev list and just going straight to a vote on general@, and I expect some mentors dont bother checking during the poddling vote very carefully these days as they know its general@ where it all happens. Isn't to stop that mindset one of the reasons why the poddling committer/ppmc dual voting process got changed to be just one vote on the poddling lists? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On 21/08/2009, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: ant elder antel...@apache.org To: general@incubator.apache.org Sent: Friday, August 21, 2009 2:32:39 AM Subject: Re: Making up policy on the fly Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ At one point or another I thought that might be an improvement. Having seen how many podling releases fail to pass the vote on gene...@incubator has me thinking otherwise. Until the gene...@incubator votes are little more than rubber stamps of the votes conducted on the podling's dev list, I wouldn't be in favor of such a change. The votes that count for a release are IPMC member votes; seems to me that the vote must be put to the whole IPMC, even if most of them don't vote. If the vote were only on the podling list, then only IPMC members who happened to be on the list would see the vote - the other IPMC members would effectively be disenfranchised. The IPMC might as well be disbanded at that point. - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. It's simply a good idea, and in the project's best interests to do so, because it is a precondition for getting +1's from several IPMC members. - 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: Making up policy on the fly
- Original Message From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Friday, August 21, 2009 10:15:44 AM Subject: Re: Making up policy on the fly On 21/08/2009, Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Friday, August 21, 2009 2:32:39 AM Subject: Re: Making up policy on the fly Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ At one point or another I thought that might be an improvement. Having seen how many podling releases fail to pass the vote on gene...@incubator has me thinking otherwise. Until the gene...@incubator votes are little more than rubber stamps of the votes conducted on the podling's dev list, I wouldn't be in favor of such a change. The votes that count for a release are IPMC member votes; seems to me that the vote must be put to the whole IPMC, even if most of them don't vote. If the vote were only on the podling list, then only IPMC members who happened to be on the list would see the vote - the other IPMC members would effectively be disenfranchised. The IPMC might as well be disbanded at that point. Well that's the way things are done in other TLPs with subprojects: the vote on the subproject's candidates is carried out on the subproject's dev list. But I can see your point, especially because these podlings really don't map to subprojects. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On 21/08/2009, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Friday, August 21, 2009 10:15:44 AM Subject: Re: Making up policy on the fly On 21/08/2009, Joe Schaefer wrote: - Original Message From: ant elder To: general@incubator.apache.org Sent: Friday, August 21, 2009 2:32:39 AM Subject: Re: Making up policy on the fly Several improvements have been suggested on this thread so far, the two mains ones are: - hold the release votes on the poddling mailing lists not general@ At one point or another I thought that might be an improvement. Having seen how many podling releases fail to pass the vote on gene...@incubator has me thinking otherwise. Until the gene...@incubator votes are little more than rubber stamps of the votes conducted on the podling's dev list, I wouldn't be in favor of such a change. The votes that count for a release are IPMC member votes; seems to me that the vote must be put to the whole IPMC, even if most of them don't vote. If the vote were only on the podling list, then only IPMC members who happened to be on the list would see the vote - the other IPMC members would effectively be disenfranchised. The IPMC might as well be disbanded at that point. Well that's the way things are done in other TLPs with subprojects: the vote on the subproject's candidates is carried out on the subproject's dev list. AFAIK in Jakarta, actual release votes are always sent to both the dev list and the general list. Most of the actual votes tend to be on the dev list, but the general list sometimes gets involved, and the result will always be posted to both. But I can see your point, especially because these podlings really don't map to subprojects. - 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: Making up policy on the fly
Ted Leung wrote: Joe Schaefer wrote: If we tell you something is best-practice, why do *we* have to defend ourselves? Who is WE and YOU? WE the ASF? WE the Infra Team? YOU a podling? YOU a fellow ASF Member? Shouldn't people *know* what the actual position of the foundation is before running around casting foundation votes? Feel free to bring that up on members@ the next time we vote for Members and Directors. As far as I know, the only condition to being put on this PMC is that a member ask to be added. I must correct you, Ted. That was NOT imposed on the PMC. We voted to impose that on ourselves. I believe that it was the correct decision, although I do take that into account when voting on new Members. This PMC operates by quoting written ASF policy to podlings so that the podlings can do the *right* thing. +1 This PMC is a major part of our interface to the rest of the world. That face should be fair, consistent, repeatable, and as free of frustration and controversy as possible. +1 That said, there is no single right side to this discourse. I'm addressing tone in a seperate e-mail, but there is good intent on all sides of this discussion. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Making up policy on the fly
Joe Schaefer wrote: ant elder wrote: - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. The pejorative aside, I concur that Ant's suggestion is not the right way to go, because graduation is too late to instill Best Practice. We want practices to be ingrained, not performed as a one-off in order to graduate. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Friday, August 21, 2009 7:50:42 PM Subject: RE: Making up policy on the fly Ted Leung wrote: Joe Schaefer wrote: If we tell you something is best-practice, why do *we* have to defend ourselves? Who is WE and YOU? WE the ASF? WE the Infra Team? YOU a podling? YOU a fellow ASF Member? We being Sebb and I as members of the Infra team. You being the folks on this mailing list. Infra is responsible for overseeing foundation-wide policy for releases and more generally distributions. Shouldn't people *know* what the actual position of the foundation is before running around casting foundation votes? Feel free to bring that up on members@ the next time we vote for Members and Directors. Members and Directors don't vote on releases, that is the responsibility of a PMC member. It is particularly troubling to me that so few folks in the IPMC are actually familiar with the foundation's position on distributions and releases. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: Noel J. Bergman n...@devtech.com To: general@incubator.apache.org Sent: Friday, August 21, 2009 7:50:42 PM Subject: RE: Making up policy on the fly Joe Schaefer wrote: ant elder wrote: - make complying with best practices a graduation requirement not a release requirement This sounds silly as complying with best practices is neither a graduation requirement nor a release requirement. The pejorative aside, I concur that Ant's suggestion is not the right way to go, because graduation is too late to instill Best Practice. We want practices to be ingrained, not performed as a one-off in order to graduate. Then how about we spend some time documenting them, especially when we see people not behaving according to best practices, instead of leaving all the dirty work to Robert? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Wed, Aug 19, 2009 at 7:15 PM, Ted Leungtwle...@sauria.com wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) And I agree with Ted that it's often very hard for podlings (or even mentors) to find out what those best practices are, without reading tons of sometimes stale discussions here. Something like legal's previously asked questions (http://apache.org/legal/resolved.html) would help a lot. We could discuss things like this LICENSE and NOTICE matter here, vote on the outcome and document the question and answer there, with a permanent URL that points to the question. I'm willing to help maintain such a page if people think that's a good idea. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Wed, Aug 19, 2009 at 8:52 PM, Joe Schaeferjoe_schae...@yahoo.com wrote: - Original Message From: Ted Leung twle...@sauria.com To: general@incubator.apache.org Sent: Wednesday, August 19, 2009 2:34:50 PM Subject: Re: Making up policy on the fly On Aug 19, 2009, at 11:17 AM, Joe Schaefer wrote: Why do we need someone to dig up a URL to believe what infrastructure people have been saying consistently? If we tell you something is best-practice, why do *we* have to defend ourselves? Why aren't the people on the IPMC actually *required* to read /dev/release.html as a precondition to being put on this PMC? Shouldn't people *know* what the actual position of the foundation is before running around casting foundation votes? As far as I know, the only condition to being put on this PMC is that a member ask to be added. We don't have any kind of criteria to be on the PMC. If you think that we need some additional policy for that, be my guest. As far as infrastructure people needing to defend themselves: This PMC operates by quoting written ASF policy to podlings so that the podlings can do the *right* thing. It's not a matter of questioning you or anyone else on infrastructure. What we tell people is there are rules here. If we want to be known as a fair, level-playing-field organization, those rules need to be written down. This PMC is a major part of our interface to the rest of the world. That face should be fair, consistent, repeatable, and as free of frustration and controversy as possible. How's this for writing down the rules: http://incubator.apache.org/guides/releasemanagement.html#best-practice-license To be honest I've not heard much of the ...or at a minimum referenced... bit before, thats not to say other docs do not say this, just I wasn't aware that was a minimum requirement and I think other TLPs with separate licence files may not be doing that. Wouldn't it be better to just get that legal JIRA about this resolved and if the out come is use a single LICENSE then we just insist on that? Also, the first sentence should probably mention something about ...as long as they meet the requirements of the ASF 3rd party licensing policies. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretazbdelacre...@apache.org wrote: On Wed, Aug 19, 2009 at 7:15 PM, Ted Leungtwle...@sauria.com wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) And I agree with Ted that it's often very hard for podlings (or even mentors) to find out what those best practices are, without reading tons of sometimes stale discussions here. Something like legal's previously asked questions (http://apache.org/legal/resolved.html) would help a lot. We could discuss things like this LICENSE and NOTICE matter here, vote on the outcome and document the question and answer there, with a permanent URL that points to the question. I'm willing to help maintain such a page if people think that's a good idea. -Bertrand Having trouble finding where to reply on this thread so I'll just go here at the bottom... I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. The debate about separate vs single LICENSE files has become a bit of a distraction, even in the recent Cassandra release that was just one of a whole list of issues brought up. I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Could we make following best practices what ever we decide those are a graduation requirement instead of a release requirement? So releases which don't clearly violate some ASF policy are voted out quickly and its the poddling graduation that is delayed until they've done a release we're all happy with. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Yes. If knowing about the policy means wading through all the old board resolutions (like with the @author -policy, which is not mentioned anywhere on the web site - who knows how many other such policies we have that a podling does not know of?), it creates a very frustrating situation - not to mention a very inconsistent situation where copying another podling or an existing Apache TLP results in the wrong way. Could we make following best practices what ever we decide those are a graduation requirement instead of a release requirement? So releases which don't clearly violate some ASF policy are voted out quickly and its the poddling graduation that is delayed until they've done a release we're all happy with. +1. /Janne - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
Hi, On Thu, Aug 20, 2009 at 10:12 AM, ant elderant.el...@gmail.com wrote: I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. That's an area where I think the mentors should (and in many cases, including this one, do) step up to defend the podling. After all, the mentors should have already reviewed the release (or whatever other action) by the podling and found it acceptable before it hits gene...@. For example, it was good to see the Pivot mentors defending the project in the recent graduation vote. Disagreements here simply highlight areas where we and the podlings can learn more, and hopefully lead to improved documentation or clarified policy later on. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 20, 2009, at 10:12 , ant elder wrote: On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretazbdelacre...@apache.org wrote: I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. [...] I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Bertrand's analogy about educating kids highlights the problem. No two parents raise their children in exactly the same way and if lots of them all give their interpretation about values and best practices the message can become quite confusing to these kids. So is there anything that can be done to streamline that? Like having just the mentors of the project vote on the release, instead of everybody? If the mentors do a bad job, hold them accountable directly without confusing the project. Does that make any sense? Greetings, Marcel
Re: Making up policy on the fly
On Thu, Aug 20, 2009 at 9:12 AM, ant elderant.el...@gmail.com wrote: On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretazbdelacre...@apache.org wrote: On Wed, Aug 19, 2009 at 7:15 PM, Ted Leungtwle...@sauria.com wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) And I agree with Ted that it's often very hard for podlings (or even mentors) to find out what those best practices are, without reading tons of sometimes stale discussions here. Something like legal's previously asked questions (http://apache.org/legal/resolved.html) would help a lot. We could discuss things like this LICENSE and NOTICE matter here, vote on the outcome and document the question and answer there, with a permanent URL that points to the question. I'm willing to help maintain such a page if people think that's a good idea. -Bertrand Having trouble finding where to reply on this thread so I'll just go here at the bottom... I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. The debate about separate vs single LICENSE files has become a bit of a distraction, even in the recent Cassandra release that was just one of a whole list of issues brought up. I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Could we make following best practices what ever we decide those are a graduation requirement instead of a release requirement? So releases which don't clearly violate some ASF policy are voted out quickly and its the poddling graduation that is delayed until they've done a release we're all happy with. I understand theres frustration, but usually its short_term - once a podling has resolved the issues that people raise then the next release should be easier / have less comments. All these issues about whether something is or is not policy or just someones view of best practice is, in my experience, what happens elsewhere in projects when it comes to releases. At the end of the day if you want someone to vote +1 on a release then release managers need to address peoples feedback. If they ignore feedback that is nice-to-have but not absolute requirements then they risk that person not voting or bothering to review a release next time. Being a release manager takes patience and judgement/negotiation about whether something needs to be fixed for a release or can be left till next time and this is something that will happen once a project graduates and not just here. If there are improvements that can be made to policy/docs then great, but complaining about feedback rather than appreciating that someone took the trouble to review a release is a mistake IMO. Niall ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Wed, Aug 19, 2009 at 6:11 AM, Ralph Goersralph.go...@dslextreme.com wrote: On Aug 18, 2009, at 5:13 PM, Joe Schaefer wrote: - Original Message From: Ralph Goers ralph.go...@dslextreme.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 8:00:00 PM Subject: Re: Making up policy on the fly On Aug 18, 2009, at 4:22 PM, Craig L Russell wrote: So I found it: http://www.apache.org/dev/release.html Please take a look at http://www.apache.org/dev/release.html#distributing-code-under-several-licenses [1] If this document is not normative, please let me know. Granted, it says should and not must, so if there is a discussion presumably it's about whether should means must. Otherwise, let's shut this discussion down and start following the rules. OK then. There is something wrong with how hard that was to find though. And you're right, instead of If An Artifact Contains Code Under Several Licenses, Should It Contain Several License Files? it would be much better if it read If An Artifact Contains Code Under Several Licenses, May It Contain Several License Files?. However, I think we should pretend it does. It's written the way it is because we are aware that not all Apache projects comply with the recommendation. Being ambiguous is no way to set policy. +1. And i'd go further and say while the ASF does not have a clear policy on something that is an ASF issue then the IPMC should not be trying to make up our own, and, we should be trying to shield poddlings from these ambiguities. If we run into issues of unclear policy then take it to legal-discuss@ or board@ or where ever is appropriate but in the meantime let poddlings release as long as they aren't violating existing policy. We all know that release early release often is good but thats really difficult for poddlings as release votes so often run into these types of problems. One thing I think might help is to change the IPMC poddling release voting process in the same way that the committer voting process was changed recently - allow release votes to be held on the poddling mailing lists and all they need is 3 binding votes from IPMC members and they only need to bring it to general@ if they can't get enough binding votes. Comments? ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Tue, Aug 18, 2009 at 17:53, ant elderant.el...@gmail.com wrote: For a while now on general@ we've had people come along during a poddling release votes and raise issues about things that aren't backed up by clear ASF policy or reasonably obvious consensus in behaviour of existing TLPs. Often poddlings just buckle and do a respin as thats easier than debating the point and that has caused the raised issues to be misunderstood as a real problems and it becomes a sort of defacto policy. I don't think we should be blocking poddling releases based on the whims of who ever happens to be active at the time on gene...@. I'd rather see people speaking up, so (potential) issues can be discussed and resolved than people not reviewing release candidates at all, not caring for the project - or even worst - rubberstamping releases with their +1s without even taking a closer look at the release artifacts, for example by judging from the release vote thread, everything looks ok, so here's my +1. Keep whiming! ;-) Its causing lots of frustrations and doesn't make us look particularly smart. Are we? Anyone who easily gets frustrated with objections and confrontations should not be here at the Incubator anyway, that's my advice. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 18, 2009, at 11:34 PM, Janne Jalkanen wrote: I remember when the policy regarding @author tags was set several years ago. Plenty of projects were using them to identify developers. Is this documented anywhere? All I could find was a number of discussions referencing such a decision, but I could not find an actual document which states the policy towards @author-tags. http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt . Discussion item F. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Wed, Aug 19, 2009 at 9:38 AM, Ralph Goersralph.go...@dslextreme.com wrote: On Aug 18, 2009, at 11:34 PM, Janne Jalkanen wrote: I remember when the policy regarding @author tags was set several years ago. Plenty of projects were using them to identify developers. Is this documented anywhere? All I could find was a number of discussions referencing such a decision, but I could not find an actual document which states the policy towards @author-tags. http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt. Discussion item F. Which says Recommend strongly that @author is avoided; but leave it to each PMC to make the final call with their respective communities.. That's typical of many things that some of us consider policies, which are in fact only (possibly strong) recommendations. IMHO, the Incubator PMC should not (in general) be picky with such things provided a particular podling's mentors support the podling's way of doing things. -Bertrand (haven't read this thread fully yet, just jumping in) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Wed, Aug 19, 2009 at 7:52 AM, sebbseb...@gmail.com wrote: And I don't mean to imply that you are suggesting that a release should be blocked due to that. Not quite, but I am saying that the release should be blocked until the LICENSE file either contains a copy of each different licence or has a link to each different license. Geez, what a thread, and like Bertrand I have not managed to read every detail of every opinion. So, although I agree that the pointers or full text should be available in LICENSE/NOTICE, I would approve a podling release IFF the change has been committed to SVN, i.e. a non-blocking, action-required item. If any 3rd party license information is missing in its entirety, then block. IMVHO, it is conflicts like this that makes Incubator work less fun... but that said, sebb, ant, others, I like your provenance of going through so many podling release efforts... 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: Making up policy on the fly
Hi Ant, On Aug 19, 2009, at 12:23 AM, ant elder wrote: On Wed, Aug 19, 2009 at 6:11 AM, Ralph Goersralph.go...@dslextreme.com wrote: On Aug 18, 2009, at 5:13 PM, Joe Schaefer wrote: - Original Message From: Ralph Goers ralph.go...@dslextreme.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 8:00:00 PM Subject: Re: Making up policy on the fly On Aug 18, 2009, at 4:22 PM, Craig L Russell wrote: So I found it: http://www.apache.org/dev/release.html Please take a look at http://www.apache.org/dev/release.html#distributing-code-under-several-licenses [1] If this document is not normative, please let me know. Granted, it says should and not must, so if there is a discussion presumably it's about whether should means must. Otherwise, let's shut this discussion down and start following the rules. OK then. There is something wrong with how hard that was to find though. And you're right, instead of If An Artifact Contains Code Under Several Licenses, Should It Contain Several License Files? it would be much better if it read If An Artifact Contains Code Under Several Licenses, May It Contain Several License Files?. However, I think we should pretend it does. It's written the way it is because we are aware that not all Apache projects comply with the recommendation. Being ambiguous is no way to set policy. +1. And i'd go further and say while the ASF does not have a clear policy on something that is an ASF issue then the IPMC should not be trying to make up our own, and, we should be trying to shield poddlings from these ambiguities. I'd go exactly the other direction. The fact that policy has should instead of must tells me that best practice is to do the should but for historical reasons, it's not a requirement. Historically some PMCs have not done the should and we can't go back and change history, but going forward, projects should comply. The incubator should be the place where should becomes must so as to align newcomers to Apache with best practice. If there's some very good reason for a podling to eschew best practice, then let's hear it. Craig If we run into issues of unclear policy then take it to legal-discuss@ or board@ or where ever is appropriate but in the meantime let poddlings release as long as they aren't violating existing policy. We all know that release early release often is good but thats really difficult for poddlings as release votes so often run into these types of problems. One thing I think might help is to change the IPMC poddling release voting process in the same way that the committer voting process was changed recently - allow release votes to be held on the poddling mailing lists and all they need is 3 binding votes from IPMC members and they only need to bring it to general@ if they can't get enough binding votes. Comments? ...ant - 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: Making up policy on the fly
On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is. Ted - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: William A. Rowe, Jr. wr...@rowe-clan.net To: general@incubator.apache.org Sent: Wednesday, August 19, 2009 1:01:04 PM Subject: Re: Making up policy on the fly Craig L Russell wrote: On Aug 19, 2009, at 12:23 AM, ant elder wrote: +1. And i'd go further and say while the ASF does not have a clear policy on something that is an ASF issue then the IPMC should not be trying to make up our own, and, we should be trying to shield poddlings from these ambiguities. I'd go exactly the other direction. The fact that policy has should instead of must tells me that best practice is to do the should but for historical reasons, it's not a requirement. Historically some PMCs have not done the should and we can't go back and change history, but going forward, projects should comply. The incubator should be the place where should becomes must so as to align newcomers to Apache with best practice. If there's some very good reason for a podling to eschew best practice, then let's hear it. Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. Quit looking at the exceptions; but the Poo project does it this way!; because Poo might have it wrong, but the board isn't compelled at this time to fix it because the fix might do more harm than good. In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities in collaborative, meritocratic manner that survives competitors working together on the same code, and from the mistakes of other projects. E.g. it is the board's opinion that @author tags harm the evolution of software, adding individual 'ownership' to pieces of code which are the project's now. Exceptions were granted to not disrupt *existing* ASF projects; there was no exception granted for incoming projects. This is why mentoring is an active, not a passive task. Amen to all of the above. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
Ted Leung wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is. This thread is arguing over things which have an established *right* way. LICENSE is for the license documents. NOTICE is for mandatory attributions. README and similar are for other errata the user should be aware of. This is what our legal-savvy people determined as absolute policy. @author tags do interfere with collaborative meritocracy; all of my code here is now the communities' code. I have no more right to control, but the same amount of control over the ongoing changes to that code as my fellow PMC members; and there comes a day that the file's code is no longer substantially mine, but other authors who's names would be more significant than mine due to their substantial improvements. The author tags, unlike svn/cvs history, do not reflect this well. When code is refactored and split, which author tags go with? Am I credited/blamed for a file who's contents were never my own code but additions to a file I first authored? This list is for discussing why best practices are best practices here at the ASF, and working out of policies (small 'p') are really the policy or a best practice or not really a requirement at all. I agree we sometimes stumble into this territory, but I haven't seen so much of this recently. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: Ted Leung twle...@sauria.com To: general@incubator.apache.org Sent: Wednesday, August 19, 2009 1:15:05 PM Subject: Re: Making up policy on the fly On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is. We who? Robert has done an outstanding job of documenting what the right way is. The only people who can't agree to it are people who refuse to acknowledge his work on this issue. Frankly looking at the commit history to releasemanagement.xml I could care less what their opinion is- they've had years to express it in that document and utterly failed to do so. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 19, 2009, at 10:49 AM, Joe Schaefer wrote: when we can't even agree / document what that *right* way is. We who? Robert has done an outstanding job of documenting what the right way is. The only people who can't agree to it are people who refuse to acknowledge his work on this issue. Frankly looking at the commit history to releasemanagement.xml I could care less what their opinion is- they've had years to express it in that document and utterly failed to do so. I agree that Robert has done an outstanding job of documenting the right way. But in the days long cassandra thread that sparked this one, no one ever brought up that URL that Craig finally dug up yesterday. Until yesterday I think that some people didn't know (or agree with) the *right* way. It has nothing to do with acknowledging Robert's work.If we are going to come down on the podlings for not following the rules, then we should make sure that we give them straight talk on what the *right* definitive rules are. That clearly didn't happen in this case. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
Hi Ted, On Aug 19, 2009, at 10:15 AM, Ted Leung wrote: On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote: Exactly. The incubator enforces Best Practices even when these are poorly documented or incomplete, and discusses why they should be normalized. And how is this PMC supposed to enforce something which might be incomplete or contradictory? I have no problem with enforcement, but I have a lot of problems with saying In the meantime, we have dozens of projects who are here to learn the *right* way to build code and communities when we can't even agree / document what that *right* way is. There are many guides in the incubator that we can put this information into, once we agree on the right way. In this case, we have a documented Apache best practice that is a bit hard to find. Putting this information into incubator documents is the next logical step. Craig Ted - 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: Making up policy on the fly
On Aug 19, 2009, at 11:17 AM, Joe Schaefer wrote: - Original Message From: Ted Leung twle...@sauria.com To: general@incubator.apache.org Sent: Wednesday, August 19, 2009 2:06:08 PM Subject: Re: Making up policy on the fly On Aug 19, 2009, at 10:49 AM, Joe Schaefer wrote: when we can't even agree / document what that *right* way is. We who? Robert has done an outstanding job of documenting what the right way is. The only people who can't agree to it are people who refuse to acknowledge his work on this issue. Frankly looking at the commit history to releasemanagement.xml I could care less what their opinion is- they've had years to express it in that document and utterly failed to do so. I agree that Robert has done an outstanding job of documenting the right way. But in the days long cassandra thread that sparked this one, no one ever brought up that URL that Craig finally dug up yesterday. Why do we need someone to dig up a URL to believe what infrastructure people have been saying consistently? If we tell you something is best- practice, why do *we* have to defend ourselves? Why aren't the people on the IPMC actually *required* to read /dev/release.html as a precondition to being put on this PMC? Shouldn't people *know* what the actual position of the foundation is before running around casting foundation votes? As far as I know, the only condition to being put on this PMC is that a member ask to be added. We don't have any kind of criteria to be on the PMC. If you think that we need some additional policy for that, be my guest. As far as infrastructure people needing to defend themselves: This PMC operates by quoting written ASF policy to podlings so that the podlings can do the *right* thing.It's not a matter of questioning you or anyone else on infrastructure. What we tell people is there are rules here. If we want to be known as a fair, level-playing-field organization, those rules need to be written down.This PMC is a major part of our interface to the rest of the world. That face should be fair, consistent, repeatable, and as free of frustration and controversy as possible. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: Ted Leung twle...@sauria.com To: general@incubator.apache.org Sent: Wednesday, August 19, 2009 2:34:50 PM Subject: Re: Making up policy on the fly On Aug 19, 2009, at 11:17 AM, Joe Schaefer wrote: Why do we need someone to dig up a URL to believe what infrastructure people have been saying consistently? If we tell you something is best-practice, why do *we* have to defend ourselves? Why aren't the people on the IPMC actually *required* to read /dev/release.html as a precondition to being put on this PMC? Shouldn't people *know* what the actual position of the foundation is before running around casting foundation votes? As far as I know, the only condition to being put on this PMC is that a member ask to be added. We don't have any kind of criteria to be on the PMC. If you think that we need some additional policy for that, be my guest. As far as infrastructure people needing to defend themselves: This PMC operates by quoting written ASF policy to podlings so that the podlings can do the *right* thing.It's not a matter of questioning you or anyone else on infrastructure. What we tell people is there are rules here. If we want to be known as a fair, level-playing-field organization, those rules need to be written down.This PMC is a major part of our interface to the rest of the world. That face should be fair, consistent, repeatable, and as free of frustration and controversy as possible. How's this for writing down the rules: http://incubator.apache.org/guides/releasemanagement.html#best-practice-license - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 19, 2009, at 12:52 PM, Joe Schaefer wrote: How's this for writing down the rules: http://incubator.apache.org/guides/releasemanagement.html#best-practice-license I'd rearrange the wording of the second paragraph: All the licenses on all the files to be included within the package should be included, or at a minimum referenced (discouraged but acceptable for now), in the LICENSE document. This LICENSE file (courtesy of Apache HTTPD) is a good example. The Apache License is at the top of the LICENSE document. After that, the license for each non- Apache licensed component is included, along with a clear explanation of which files that license applies to.
Re: Making up policy on the fly
- Original Message From: ant elder ant.el...@gmail.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 11:53:25 AM Subject: Making up policy on the fly For a while now on general@ we've had people come along during a poddling release votes and raise issues about things that aren't backed up by clear ASF policy or reasonably obvious consensus in behaviour of existing TLPs. Incubator is free to set it's own policy, so long as it's in line with ASF policy. Anyone who's suffered through the releasemanagement.xml guide can get a reasonable picture of what goes in the LICENSE file, and that's in line with what both Sebb and I are saying. FTR, neither one of us has cast a vote on the cassandra release. Sebb isn't even on the IPMC AFAICT, so what exactly is your problem with him speaking up? Often poddlings just buckle and do a respin as thats easier than debating the point and that has caused the raised issues to be misunderstood as a real problems and it becomes a sort of defacto policy. I don't think we should be blocking poddling releases based on the whims of who ever happens to be active at the time on gene...@. Whims my ass, what's being discusssed is best practice, as documented by this PMC. Its causing lots of frustrations and doesn't make us look particularly smart. If there's not clear ASF policy saying something must not happen then we should let them release, especially when other TLPs are doing the same thing. For the recent LICENSE and NOTICE file issues the current policy allows for the different approaches, different TLPs use different approaches, there's not been consensus on a single approach, and there are relevant JIRAs open with legal that aren't yet resolved. Shouldn't we not be preempting any resolution about this and let poddlings release until the policy is clarified? People are free to speak their minds and argue out their points as they see fit. What actually counts are the votes, and people are free to cast those as they see fit. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
Hi Ant, On Aug 18, 2009, at 8:53 AM, ant elder wrote: For the recent LICENSE and NOTICE file issues the current policy allows for the different approaches, different TLPs use different approaches, there's not been consensus on a single approach, and there are relevant JIRAs open with legal that aren't yet resolved. Please correct me, but the recent discussion about LICENSE and NOTICE wrt release was a release that did not have licenses for third party projects that are part of the release, neither in LICENSE nor in NOTICE. We can discuss (and will continue to do so) where the best place is for licenses, notices, and copyrights (sometimes these are one and the same) but to omit them entirely is just wrong. Craig Craig L Russell Incubator PMC, DB PMC, OpenJPA PMC c...@apache.org http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Making up policy on the fly
On Tue, Aug 18, 2009 at 5:19 PM, Craig L Russellcraig.russ...@sun.com wrote: Hi Ant, On Aug 18, 2009, at 8:53 AM, ant elder wrote: For the recent LICENSE and NOTICE file issues the current policy allows for the different approaches, different TLPs use different approaches, there's not been consensus on a single approach, and there are relevant JIRAs open with legal that aren't yet resolved. Please correct me, but the recent discussion about LICENSE and NOTICE wrt release was a release that did not have licenses for third party projects that are part of the release, neither in LICENSE nor in NOTICE. We can discuss (and will continue to do so) where the best place is for licenses, notices, and copyrights (sometimes these are one and the same) but to omit them entirely is just wrong. Craig The release _did_ include all the third party licenses, as seperate license files in the lib/license directory. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
- Original Message From: Craig L Russell craig.russ...@sun.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 12:19:42 PM Subject: Re: Making up policy on the fly Hi Ant, On Aug 18, 2009, at 8:53 AM, ant elder wrote: For the recent LICENSE and NOTICE file issues the current policy allows for the different approaches, different TLPs use different approaches, there's not been consensus on a single approach, and there are relevant JIRAs open with legal that aren't yet resolved. Please correct me, but the recent discussion about LICENSE and NOTICE wrt release was a release that did not have licenses for third party projects that are part of the release, neither in LICENSE nor in NOTICE. We can discuss (and will continue to do so) where the best place is for licenses, notices, and copyrights (sometimes these are one and the same) but to omit them entirely is just wrong. The licenses *are* included in the distribution in the lib/licenses directory. That's not a problem in and of itself. The problem is that that location isn't referenced by the LICENSE file itself, and *all* our documentation assumes that all relevant licenses for a distribution are listed or referenced by that file. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
Hi Ant, I didn't intend to make up stuff on the fly, especially policy. After having been through the fine points of LICENSE vs. NOTICE so many times, I thought the consensus was to put *all* licenses into the top level LICENSE file. But having just scoured the official public pages promulgating policy, I can't find it. Let's continue the discussion. I still believe that it's bad form to put licenses in several places in distributions because users might not find them and thereby not know what they're getting. Craig On Aug 18, 2009, at 9:19 AM, Craig L Russell wrote: Hi Ant, On Aug 18, 2009, at 8:53 AM, ant elder wrote: For the recent LICENSE and NOTICE file issues the current policy allows for the different approaches, different TLPs use different approaches, there's not been consensus on a single approach, and there are relevant JIRAs open with legal that aren't yet resolved. Please correct me, but the recent discussion about LICENSE and NOTICE wrt release was a release that did not have licenses for third party projects that are part of the release, neither in LICENSE nor in NOTICE. We can discuss (and will continue to do so) where the best place is for licenses, notices, and copyrights (sometimes these are one and the same) but to omit them entirely is just wrong. Craig Craig L Russell Incubator PMC, DB PMC, OpenJPA PMC c...@apache.org http://db.apache.org/jdo 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: Making up policy on the fly
- Original Message From: Ralph Goers ralph.go...@dslextreme.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 8:00:00 PM Subject: Re: Making up policy on the fly On Aug 18, 2009, at 4:22 PM, Craig L Russell wrote: So I found it: http://www.apache.org/dev/release.html Please take a look at http://www.apache.org/dev/release.html#distributing-code-under-several-licenses [1] If this document is not normative, please let me know. Granted, it says should and not must, so if there is a discussion presumably it's about whether should means must. Otherwise, let's shut this discussion down and start following the rules. OK then. There is something wrong with how hard that was to find though. And you're right, instead of If An Artifact Contains Code Under Several Licenses, Should It Contain Several License Files? it would be much better if it read If An Artifact Contains Code Under Several Licenses, May It Contain Several License Files?. However, I think we should pretend it does. It's written the way it is because we are aware that not all Apache projects comply with the recommendation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 18, 2009, at 5:13 PM, Joe Schaefer wrote: - Original Message From: Ralph Goers ralph.go...@dslextreme.com To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 8:00:00 PM Subject: Re: Making up policy on the fly On Aug 18, 2009, at 4:22 PM, Craig L Russell wrote: So I found it: http://www.apache.org/dev/release.html Please take a look at http://www.apache.org/dev/release.html#distributing-code-under-several-licenses [1] If this document is not normative, please let me know. Granted, it says should and not must, so if there is a discussion presumably it's about whether should means must. Otherwise, let's shut this discussion down and start following the rules. OK then. There is something wrong with how hard that was to find though. And you're right, instead of If An Artifact Contains Code Under Several Licenses, Should It Contain Several License Files? it would be much better if it read If An Artifact Contains Code Under Several Licenses, May It Contain Several License Files?. However, I think we should pretend it does. It's written the way it is because we are aware that not all Apache projects comply with the recommendation. Being ambiguous is no way to set policy. I don't really care whether the license file contains all the license text or points to other licenses, but by saying should it basically says This is our preferred way of doing it, but if you are doing something else no one is going to stop you. Since it doesn't say what the other options are that would imply that even having to search for the other license files is OK too, as long as they are somewhere the user can find. How about PMC's should vote on releases? Maybe we should just leave it at PMCs should vote on the source code for a release. Apache projects should use the Apache license. Yes, this gets ridiculous, but if you don't say what is acceptable and what is not then don't bother to say anything at all. I remember when the policy regarding @author tags was set several years ago. Plenty of projects were using them to identify developers. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
