Re: [VOTE] Release Regexp 1.5
Vadim, that is not the point. The procedure in itself is flawed. There might be files now, but the procedure still has to be aligned to ASF wide guide lines. Before you wonder/think about conspiracy theories: Yes, I brought the board (i.e. Henri) attention to this. It is necessary to change the commons release procedures and if you think that experiences of other PMCs (Velocity) don't count, let's try with a board opinion. Best regards Henning Vadim Gritsenko schrieb: Henri Yandell wrote: 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet. Vote has passed, so now actual files are made, and are available at the same location [1]. Vadim [1] http://people.apache.org/~vgritsenko/regexp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design| Velocity - Turbine Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Henning Schmiedehausen wrote: Vadim, that is not the point. The procedure in itself is flawed. You missed it too :) Existing procedure might be flawed in somebody's opinion, and I'm not arguing that it is ideal, but proposed procedure is even worse. It makes any release impossible: release packages can be made available only after the release itself is made. This makes me think that such procedure comes from the camp not taking SCM seriously. Since the objective of the change to the process is to verify steps done by RM, the only viable procedure, in my view, is - (1) vote on SVN rev number (with packages made available), (2) tagging and building a release, (3) quick vote on resulting files. It's quick sine no actual software testing need to be performed, just verify that zip unzips and tar untars. Vadim There might be files now, but the procedure still has to be aligned to ASF wide guide lines. Before you wonder/think about conspiracy theories: Yes, I brought the board (i.e. Henri) attention to this. It is necessary to change the commons release procedures and if you think that experiences of other PMCs (Velocity) don't count, let's try with a board opinion. Best regards Henning Vadim Gritsenko schrieb: Henri Yandell wrote: 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet. Vote has passed, so now actual files are made, and are available at the same location [1]. Vadim [1] http://people.apache.org/~vgritsenko/regexp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Or even better, let everyone follow their own procedures while loosely fitting into a less restrictive set of obvious guidelines wrt licensing / distribution locations /etc - so the rest of us don't have to be punished because one or two projects are having issues getting releases out On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Henning Schmiedehausen wrote: Vadim, that is not the point. The procedure in itself is flawed. You missed it too :) Existing procedure might be flawed in somebody's opinion, and I'm not arguing that it is ideal, but proposed procedure is even worse. It makes any release impossible: release packages can be made available only after the release itself is made. This makes me think that such procedure comes from the camp not taking SCM seriously. Since the objective of the change to the process is to verify steps done by RM, the only viable procedure, in my view, is - (1) vote on SVN rev number (with packages made available), (2) tagging and building a release, (3) quick vote on resulting files. It's quick sine no actual software testing need to be performed, just verify that zip unzips and tar untars. Vadim There might be files now, but the procedure still has to be aligned to ASF wide guide lines. Before you wonder/think about conspiracy theories: Yes, I brought the board (i.e. Henri) attention to this. It is necessary to change the commons release procedures and if you think that experiences of other PMCs (Velocity) don't count, let's try with a board opinion. Best regards Henning Vadim Gritsenko schrieb: Henri Yandell wrote: 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet. Vote has passed, so now actual files are made, and are available at the same location [1]. Vadim [1] http://people.apache.org/~vgritsenko/regexp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Henning Schmiedehausen wrote: Vadim, that is not the point. The procedure in itself is flawed. You missed it too :) Existing procedure might be flawed in somebody's opinion, and I'm not arguing that it is ideal, but proposed procedure is even worse. It makes any release impossible: release packages can be made available only after the release itself is made. This makes me think that such procedure comes from the camp not taking SCM seriously. Since the objective of the change to the process is to verify steps done by RM, the only viable procedure, in my view, is - (1) vote on SVN rev number (with packages made available), (2) tagging and building a release, (3) quick vote on resulting files. It's quick sine no actual software testing need to be performed, just verify that zip unzips and tar untars. I think one also needs to check that: * that the various signature files are present and correct * the zips and tars contain the same files as each other * the zips and tars and contained jars contain the required NOTICE and LICENSE files * the source archive includes all the required sources from SVN * the bin archive includes all the required files (apart from any documented dependencies) I don't think these can be determined directly from the contents of an SVN rev number, so need to be checked after a potential release has been built. == As to release voting: Surely the most important thing is to ensure that a build is not released to the general public - i.e. not put in the dist tree - before the vote has passed. So long as the build files are in a private area - e.g. the RM's public_html directory - (and maybe are named as pre-release) the vote can be done on the actual files. S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
sebb wrote: On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: resulting files. It's quick sine no actual software testing need to be performed, just verify that zip unzips and tar untars. I think one also needs to check that: * that the various signature files are present and correct * the zips and tars contain the same files as each other * the zips and tars and contained jars contain the required NOTICE and LICENSE files * the source archive includes all the required sources from SVN * the bin archive includes all the required files (apart from any documented dependencies) (This is done by ant, btw, and so is 99% reproducible) I don't think these can be determined directly from the contents of an SVN rev number, so need to be checked after a potential release has been built. Hence I mentioned 'quick check of release files'. Would satisfy even procedure extremists. == As to release voting: Surely the most important thing is to ensure that a build is not released to the general public - i.e. not put in the dist tree - before the vote has passed. So long as the build files are in a private area - e.g. the RM's public_html directory - (and maybe are named as pre-release) the vote can be done on the actual files. Actual files, as you might have noticed, are impossible to produce before release is tagged. To tag a release, a vote must pass. Best you could do is to produce 'rc' build off of trunk. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: sebb wrote: On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: resulting files. It's quick sine no actual software testing need to be performed, just verify that zip unzips and tar untars. I think one also needs to check that: * that the various signature files are present and correct * the zips and tars contain the same files as each other * the zips and tars and contained jars contain the required NOTICE and LICENSE files * the source archive includes all the required sources from SVN * the bin archive includes all the required files (apart from any documented dependencies) (This is done by ant, btw, and so is 99% reproducible) It's the other 1% that is the problem ... I don't think these can be determined directly from the contents of an SVN rev number, so need to be checked after a potential release has been built. Hence I mentioned 'quick check of release files'. Would satisfy even procedure extremists. == As to release voting: Surely the most important thing is to ensure that a build is not released to the general public - i.e. not put in the dist tree - before the vote has passed. So long as the build files are in a private area - e.g. the RM's public_html directory - (and maybe are named as pre-release) the vote can be done on the actual files. Actual files, as you might have noticed, are impossible to produce before release is tagged. To tag a release, a vote must pass. Best you could do is to produce 'rc' build off of trunk. Surely voting on creating a tag (if this is necessary) is completely different from voting on a release? S - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
sebb wrote: Surely voting on creating a tag (if this is necessary) Absolutely. Any release tag must be a community decision == vote is required. is completely different from voting on a release? Not to me. Voting on a release (on a tag) signifies that software is in a state where it can be released to general public. Voting on a files (produced from release tag) is a mechanical vote on correctness of files produced by ant. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: sebb wrote: Surely voting on creating a tag (if this is necessary) Absolutely. Any release tag must be a community decision == vote is required. is completely different from voting on a release? Not to me. Voting on a release (on a tag) signifies that software is in a state where it can be released to general public. Voting on a files (produced from release tag) is a mechanical vote on correctness of files produced by ant. AFAIK, the ASF rules are that files must not be released to the general public without a formal vote by the PMC on the release, which I take to mean voting on the files which are proposed to be released. Requiring consensus on tagging seems sensible, but I'm not sure it is required. The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. The first vote (on tagging) seems to me to be something that relates mainly to committers working on the project. The second vote has to involve PMC members; others can vote, but their votes generally do not count (though I guess a -1 would need to be investigated). Seems to me that there needs to be formal documentation of the required and recommended release processes. S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. On 3/19/07, sebb [EMAIL PROTECTED] wrote: snipped The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Regexp 1.5
sebb wrote on Monday, March 19, 2007 3:09 PM: On 19/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: sebb wrote: Surely voting on creating a tag (if this is necessary) Absolutely. Any release tag must be a community decision == vote is required. is completely different from voting on a release? Not to me. Voting on a release (on a tag) signifies that software is in a state where it can be released to general public. Voting on a files (produced from release tag) is a mechanical vote on correctness of files produced by ant. AFAIK, the ASF rules are that files must not be released to the general public without a formal vote by the PMC on the release, which I take to mean voting on the files which are proposed to be released. Requiring consensus on tagging seems sensible, but I'm not sure it is required. The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. The first vote (on tagging) seems to me to be something that relates mainly to committers working on the project. The second vote has to involve PMC members; others can vote, but their votes generally do not count (though I guess a -1 would need to be investigated). And since no-one wants to vote twice, the vote is done on the released artifacts in the RM's private area (or a more official staging area). This includes also that the version is already tagged. If for whatever reason the vote does not pass we can drop the version from the SCM again ... since it did not represent a valid release anymore. Seems to me that there needs to be formal documentation of the required and recommended release processes. - Jörg BTW: I did not vote, exactly because I should have to check out from svn - and nobody can guarantee me that I have a proper environment to check the release I build myself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 19/03/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? I don't have the references to hand, but I believe it is something to do with providing some form of legal protection. There may be other reasons as well. Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. As far as I know, only one formal vote is actually required by the ASF; this must be by the PMC on the release itself. On 3/19/07, sebb [EMAIL PROTECTED] wrote: snipped The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
I have a thought that may not be an immediate solution. Isn't the correctness of a release from a build point of view a testable condition? Shouldn't this be built in to the build system. The apache servers would not allow an invalid package. They define the pattern. Isn't this GUMP? Not knowing details but seeing emails. Otherwise you are cloaking a software challenge within adminstratium (http://en.wikipedia.org/wiki/Administratium) (Sorry, if I'm a little incoherent, I'm finishing an ironman front to back website release for work with last minute untested boss changes and bug fixes in the fortran - model went from 1 to 5 modes ) Regards, Dave Fisher On Mar 19, 2007, at 9:55 AM, sebb wrote: On 19/03/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? I don't have the references to hand, but I believe it is something to do with providing some form of legal protection. There may be other reasons as well. Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. As far as I know, only one formal vote is actually required by the ASF; this must be by the PMC on the release itself. On 3/19/07, sebb [EMAIL PROTECTED] wrote: snipped The problem here seems to be that it is not possible to use one vote to do both; therefore it seems to me that the sensible thing to do is to have two votes. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Sure, of course it's ok for the ASF to dictate policies - I just hope it's ok for me to question them / point out their flaws. So the real problem as far as I can tell is making sure a release is legitimately licensed. There are other things like software quality, but I guess it's assumed (by me at least) that we're all trying to release as high a caliber of software as we are able given our resources / time. Somehow this still doesn't feel like a legitimate problem, or at least it is not consistent with the rest of our daily practices. ..Like committing a change to subversion. As far as I can tell there is no legal difference between subversion repositories and released software - is there? Isn't the end goal to prevent any naughty code coming out of apache period? Non conforming code sitting in subversion would appear to be just as guilty as anything else...So given your current logic shouldn't we all be required to have a PMC vote for each commit made into the repo? It just feels like we're being treated a little bit like incompetents in some way. Like maybe someone accidentally made a bad release once or twice and so we must all suffer the same solution that they have. Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. On 3/19/07, J Aaron Farr [EMAIL PROTECTED] wrote: Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
I think we have to remember that the ASF provides an important legal umbrella here. By setting policies which we follow (which of course can be debated), it prevents us from being sued if an SCO-type situation develops. This would be a low-probability, but extremely catastrophic event, especially since developers could be sued directly if they were operating independently. The PMC plays an important role in shielding individual developers from liability by approving releases according to defined policies. WILL On 3/19/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Sure, of course it's ok for the ASF to dictate policies - I just hope it's ok for me to question them / point out their flaws. So the real problem as far as I can tell is making sure a release is legitimately licensed. There are other things like software quality, but I guess it's assumed (by me at least) that we're all trying to release as high a caliber of software as we are able given our resources / time. Somehow this still doesn't feel like a legitimate problem, or at least it is not consistent with the rest of our daily practices. ..Like committing a change to subversion. As far as I can tell there is no legal difference between subversion repositories and released software - is there? Isn't the end goal to prevent any naughty code coming out of apache period? Non conforming code sitting in subversion would appear to be just as guilty as anything else...So given your current logic shouldn't we all be required to have a PMC vote for each commit made into the repo? It just feels like we're being treated a little bit like incompetents in some way. Like maybe someone accidentally made a bad release once or twice and so we must all suffer the same solution that they have. Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. On 3/19/07, J Aaron Farr [EMAIL PROTECTED] wrote: Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain 415 440-7500x89 [EMAIL PROTECTED] www.forio.com
Re: [VOTE] Release Regexp 1.5
You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. I may be wrong, but the ASF already has agreements with all committers and PMCs. So, anyone slipping in malicious code into a release has already agreed not to do it. Anyone doing so is tagged. This means that any of these mistakes are bugs. And while we want everything to be perfect, not everything is that way. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. So each project requires 3 release managers? The vote to release should appoint a release manager, and the manager should make the release. Their word is their bond. Who wants the reputation as a screw up? If the PMCs delegate it to another person then karma is reflected. It is completely appropriate for the ASF to set guidelines on release procedures. Appropriate as long as they don't treat contributers like children. The ASF should have policies that enable open source, and not discourage it. If someone screws up too many releases then the community can take away their karma. The ASF should automate all those bit manipulations. Didn't someone in this thread say that ant does 99% of it? Regards, Dave Fisher -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Jesse Kuhnert wrote: Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. Make that two of us. ASF today indeed contains much more Administratium (thanks Dave, great link!) than it used to. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote: Sure, of course it's ok for the ASF to dictate policies - I just hope it's ok for me to question them / point out their flaws. So the real problem as far as I can tell is making sure a release is legitimately licensed. There are other things like software quality, but I guess it's assumed (by me at least) that we're all trying to release as high a caliber of software as we are able given our resources / time. Somehow this still doesn't feel like a legitimate problem, or at least it is not consistent with the rest of our daily practices. ..Like committing a change to subversion. As far as I can tell there is no legal difference between subversion repositories and released software - is there? Isn't the end goal to prevent any naughty code coming out of apache period? Non conforming code sitting in subversion would appear to be just as guilty as anything else...So given your current logic shouldn't we all be required to have a PMC vote for each commit made into the repo? It just feels like we're being treated a little bit like incompetents in some way. Like maybe someone accidentally made a bad release once or twice and so we must all suffer the same solution that they have. Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. Jesse, You are certainly not alone. I have always been of an option that the content of the SVN repository is what truly represents the source code of ASF software, with packaged releases merely being versioned snapshots officially endorsed by the project committers and the respective PMC and recommended for use by the end users. I am not a legal expect by any stretch of imagination but I think ASF may be equally liable for any given revision in its official SVN repository as for its packaged releases. In Commons HttpClient / HttpComponents land we historically voted on SVN revisions and published release packages based on a lazy consensus if no one raised complaints about the content of the release packages. Oleg On 3/19/07, J Aaron Farr [EMAIL PROTECTED] wrote: Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Nathan Bubna [EMAIL PROTECTED] writes: that said, i would love to see some more automation of signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe Henk Penning does have some automated signature checking set up, but that's all i know of, and it only happens after the release is out. anyone frustrated with the process is quite welcome to step up and hack up something to ease the frustration. :) ARAT helps: http://code.google.com/p/arat/ And again you can code up a lot of this in Ant or use some of Maven's plugins. -- jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Ok so I'm a liar...I did want to point out that from my experience even the most formal voting process won't get the desired results - that everyone on the project certifies and checks that the binaries going out are good. More than likely 90% of the time everyone just votes yes or no and trusts that the person managing the release knows what they are doing. .but these are small points. Still, they do point to the voting process being meaningless other than all of the PMC's putting their names on it if it should go poorly. (though in a true team sort of mindset you'd think that this would always be the case with / without votes / other processes...) Automation is good. Esp. if it lets us opt to always trust committer X managing a release once and let a diligent little script do everything else for else without any intervention. That would be great and would bring me back to where I already was. ;) On 3/19/07, Nathan Bubna [EMAIL PROTECTED] wrote: snipped the actual bits that are distributed as an officially endorsed release do not have the luxury of diffs sent to the development lists, nor are they easily controlled from a central location. the releases are extensively mirrored by servers all over the place. releases are nigh impossible to recall. thus, with the broader audience, the consequences for problems are greatly magnified and are not easily remedied. snipped -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Ok so I'm a liar...I did want to point out that from my experience even the most formal voting process won't get the desired results - that everyone on the project certifies and checks that the binaries going out are good. More than likely 90% of the time everyone just votes yes or no and trusts that the person managing the release knows what they are doing. .but these are small points. ah, you say the glass is 90% empty, others might say it is 10% full. :) at least, release-then-vote provides the opportunity for oversight of the actual binaries to be released. Still, they do point to the voting process being meaningless other than all of the PMC's putting their names on it if it should go poorly. (though in a true team sort of mindset you'd think that this would always be the case with / without votes / other processes...) meaning can be quite relative. as this process is in large part due to legal, CYA necessities, meaningless things such as the mere opportunity for oversight of those bits and any actual (and perhaps even perceived) PMC oversight are important to the foundation. our best bet here is to automate the oversight as much as possible to ease the burden of the process. i will definitely be giving this ARAT tool a look. Automation is good. Esp. if it lets us opt to always trust committer X managing a release once and let a diligent little script do everything else for else without any intervention. That would be great and would bring me back to where I already was. ;) On 3/19/07, Nathan Bubna [EMAIL PROTECTED] wrote: snipped the actual bits that are distributed as an officially endorsed release do not have the luxury of diffs sent to the development lists, nor are they easily controlled from a central location. the releases are extensively mirrored by servers all over the place. releases are nigh impossible to recall. thus, with the broader audience, the consequences for problems are greatly magnified and are not easily remedied. snipped -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? Not me. We don't have absurd procedures, so we're already there. For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. PMCs are not about rubber-stamping anything. They are about project oversight and responsibility. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. Interesting perspective. But my reading of the first couple of sentences of this page suggests otherwise: http://www.apache.org/foundation/ -- Martin Cooper Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On Mon, 2007-03-19 at 19:01 +0100, Oleg Kalnichevski wrote: [... on vote-then-release ...] Trust me, I have done my share of releases this way, too. The thing is, that while it was/is common practice, there are ASF-wide guidelines that are not there to hinder people / add administrative barriers / whatever but to provide two things: * Oversight * Legal shielding That is the difference between your private pet peeve that releases as it wishes and a legal entity as the ASF, its acting officers (board / PMC chairs) and its committers. From a technical PoV, I'm fully with you. However, this is not a technical issue as you have probably found out by now. Best regards Henning In Commons HttpClient / HttpComponents land we historically voted on SVN revisions and published release packages based on a lazy consensus if no one raised complaints about the content of the release packages. Oleg On 3/19/07, J Aaron Farr [EMAIL PROTECTED] wrote: Jesse Kuhnert [EMAIL PROTECTED] writes: You have to be kidding me.. The only problem I see is that people are all caught up in policies / processes but I've yet to hear what the actual root problem is. I'm sure it's intended to somehow prevent something nasty that has happened in the past but these policies don't have any logic that I'm able to follow. Why does the ASF need to dictate how we vote on releases? Maybe I'm just having a bad morning, but for some reason this really rubs me the wrong way and feels extremely inefficient. The problem is that Vote-Then-Release leaves opportunities for the small details to get missed and you end up with a sloppy release. Examples include non-signed distributables, incomplete legal notices, missing or incorrect hashes. The worst is someone slipping in some malicious code in between the time the vote is cast and the release is made. When a PMC votes on a release they should be approving the exact bits that hit the mirrors. That vote binds the ASF to be _legally_ responsible. The only way to have sufficient and appropriate oversight is to give the PMC a chance to check that these final steps of a release have been properly handled. Otherwise the PMC risks releasing a half baked product. It is completely appropriate for the ASF to set guidelines on release procedures. -- jaaron (who is not on the Jakarta PMC) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Martin Cooper wrote: On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? Not me. We don't have absurd procedures, so we're already there. I consider tag before vote as absurd. For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. PMCs are not about rubber-stamping anything. They are about project oversight and responsibility. Oversight and responsibility is happening before you tag. They are part of day to day work. Mechanical checks for NOTICE and LICENSE files preceding approval for distribution stamp happen after. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. Interesting perspective. Thanks. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. lack of legal protection can be pretty detrimental to a software development community. i'd say it's an essential, non-secondary part of the ASF's fostering of dev communities. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? Not me. We don't have absurd procedures, so we're already there. I consider tag before vote as absurd. Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. By the way, if you really want to change any of this, burying the discussion in a vote thread on this list isn't the best way to go about it. -- Martin Cooper For example: community votes for a release, RM tags a release (and prepares files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition change process), done. PMCs are not about rubber-stamping anything. They are about project oversight and responsibility. Oversight and responsibility is happening before you tag. They are part of day to day work. Mechanical checks for NOTICE and LICENSE files preceding approval for distribution stamp happen after. And the big one. The main goal ASF exists for is fostering software development communities. With second goal being software released in the process. And the legal part here is an *evil necessity*, it is *not* a goal. Interesting perspective. Thanks. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. This whole thread is absurd. There is no technical issue here. cvs tag FOOBAR_1_0_RC1 ant scp... ...crickets... cvs TAG FOOBAR_1_0 ssh... mv FOOBAR_1.0-RC1... FOOBAR_1.0-final... -andy -- From Windows/Exchange to Linux/Meldware Buni Meldware Communication Suite Email, Calendaring, ease of configuration/administration http://buni.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Martin Cooper wrote: On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Martin Cooper wrote: Those sites provide infrastructure, but absolutely no legal protection. Who says there is no way to combine legal protection and non-absurd procedures? Not me. We don't have absurd procedures, so we're already there. I consider tag before vote as absurd. Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. You tagging -- voluntarism; you tagging after a vote -- community supported decision. By the way, if you really want to change any of this, burying the discussion in a vote thread on this list isn't the best way to go about it. If there is no consensus, there is no point of pushing it. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
I always prefer to optimize my loops by unrolling them and doing each step differently. Funny to talk about pattern matching in a regexp thread :-D Burnt from my release time to have Yegor chew through some POI bugs ... Regards, Dave On Mar 19, 2007, at 5:41 PM, Andrew C. Oliver wrote: Yeah, well I consider voting on something that doesn't exist yet to be absurd. So there we are. This whole thread is absurd. There is no technical issue here. cvs tag FOOBAR_1_0_RC1 ant scp... ...crickets... cvs TAG FOOBAR_1_0 ssh... mv FOOBAR_1.0-RC1... FOOBAR_1.0-final... -andy -- From Windows/Exchange to Linux/Meldware Buni Meldware Communication Suite Email, Calendaring, ease of configuration/administration http://buni.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/14/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: sebb wrote: Also I think I need to update headers as per [3], is that correct? You also need a NOTICE file [3] Updated license headers, added NOTICE to zip/tar.gz. The NOTICE file is missing the copyright statement - see: http://www.apache.org/legal/src-headers.html Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/18/07, Henri Yandell [EMAIL PROTECTED] wrote: On 3/14/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Henning Schmiedehausen wrote: You actually have to roll and sign a tarball/zip ball on which the vote happens. Release-then-Vote seems to be the only accepted way by the board these days; Thankfully, neither events in velocity-private nor board feelings apply here. Either Jakarta PMC votes for it or receives an resolution, before that happens, existing procedures [1] stay. There are (to my knowledge) three types of vote/release styles that have been happening at the ASF. 1) A vote to do a release, with no sign of release files. This is how this thread started and it's against ASF policy. 2) A vote on release-candidate files (or -dev in your case), and then a release that is trusted to be a repeat of the process used. This is currently a grey area policy-wise, and is where this release moved to with the ~/vgritsenko/*-dev files. 3) Creating the actual files that are going to be released and voting on them. There's pressure to go this way, but it's not the policy yet. personally I do prefer Vote-then-Release myself but that seems to be the way it is. Release-then-Vote has some nice parts, the actual release is really easy. That's nice if the release process has been painful as it means I don't have to remember how to do the damn thing. Vote-then-Release is nice in that you don't end up doing as many vote builds. Other parts of the ASF seem to do a release where they make a build and if it passes a vote it goes out, if it doesn't then they up the bugfix number and do it again (I don't think anyone actually has a build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that the version number doesn't show. Very confusing as a user I think. Mostly at this stage the mandate is that we have to be voting on release files, not on Hey, how about a release. This has been a pointless thread. Most of the people on the thread are Members, so if someone could kick it off on members@ then I think you'll see a much more informed discussion going on. This 'how we release' conversation has been bouncing around the ASF for 4 months now, the above is my best grok on the summary. I've not seen anyone yet speaking in favour of a view that we should have a vote on the idea of releasing and then someone does it when they can. Please bring that up on members@ Vadim - good luck. The reason for members existing (imo) is to provide a backbone to an otherwise disparate and completely unrelated huge set of communities. That means showing a bit more empathy and a bit less round and round arguments. Course, I'm grumpy and I've got zero patience for reading mailing list threads over 5 emails nowadays for some reason. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/19/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Something being a good idea and being required ASF policy are really very different things. The suffering is in the implication that I'm not already being careful. That we're not all supposed to be slightly better than average developers with the apache branding and all. The fact that it's ok to send me emails telling me I'm part of a problem project because I haven't followed some new guidelines put in place because of other peoples mistakes - mistakes I haven't even made is really just insulting and annoying. snip/ Unsure what emails, annoyances etc. you were talking about so I tried to look at Tapestry list archives (I guess thats what you are refering to?) -- specifically looked for things like votes, discussions about releases etc. Now I can't find a vote for v5.0.3 (maybe I missed it, maybe votes are on the private list -- I don't know), but if what you are saying above is that there is no need to vote at all, that goes against what has been described elsewhere in this thread as community consensus, and appears completely different from the discussion here (timing of the vote). -Rahul I wonder how often these kinds of emails come out on the google code or sourceforge lists? :/ On 3/19/07, Niall Pemberton [EMAIL PROTECTED] wrote: snipped There are all sorts of things that can go wrong when cutting a release - an example the other day - Tomcat 5.5.23 had/has a problem because the RM didn't have a jar in his local environment - its not a guarantee I know (Tomcat produce artifacts to vote on before release!) - but the more pairs of eyes checking out the distro before it goes out has got to be a good thing. Its not about incompetance, just catching mistakes before rather than after. I also don't get your suffering point - most projects can produce a RC quickly - Tag Build - doesn't take long - so where is the suffering in doing that before calling a vote? Niall -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]