Re: [VOTE] Release Regexp 1.5
Niall Pemberton wrote: 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: Thanks, Niall. Corrected. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Henri Yandell wrote: 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. That is a tough crowd and I don't think I have enough skills to convince them on anything. OTOH, you can. It's pity though that ASF is loosing its values. Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
- Original Message - From: Rahul Akolkar [EMAIL PROTECTED] To: Jakarta General List general@jakarta.apache.org Sent: Tuesday, March 20, 2007 7:39 AM Subject: 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] Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Henri, I appreciate what you did to help the POI project stand up and meet Apache requirements. It is an ongoing process - I think the subproject is close to doing it correctly and having a successful release! Cheers! Dave Fisher On Mar 19, 2007, at 10:58 PM, Henri Yandell wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 3/20/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: Henri Yandell wrote: 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. That is a tough crowd and I don't think I have enough skills to convince them on anything. OTOH, you can. It's pity though that ASF is loosing its values. Problem is that that's the crowd who need to be convinced. Otherwise we're just sitting here spinning around and around. It's less that it's losing its values and more that it's increasingly pushing to have one set of values. ancient history - very concise Apache begat itself. Then it begat Jakarta somehow. Things were good. Then Apache looked at Jakarta and it was not pleased for things were not the same. It argued with itself and declared that things would be the same. All was good. /ancient history modern history The next day Apache looked at itself and was shocked and amazed to find that declaring all things to be equal had not made things equal. In the Outer Rim there were projects and committers who had not heard the declaration and were not doing things in the same way. Indeed they had the temerity to do things the same way they'd always done things. Apache was not happy. /modern history future history Apache gets married, finds a little house in the suburbs and raises little apachlets. But that's another story. /future history So not losing values - these are Jakarta values that we relinquished 5 years ago. On the OTOH... I've not got the patience for such convincing atm :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
As long as the analogies are going I thought I'd continue the story with more of my own even further in history Things continue for a while. Mike is happy, Apache is happy. All is well. Mike continues his life long passion of being a master carpenter and Apache helps raise the family. What could be better? ...Then one day Mike comes into his workshop and finds that someone has taken it upon themselves to add two more clamps to his existing two clamps on the piece he is currently working on. That's odd...What the hell? Mike confronts Apache. Oh that, yes we've all decided that from now on you'll need to use exactly twice the number of clamps you normally do. You see - Codehauses husband Bob had a little accident the other day. Nothing fatal but no one wants to take any chances...I'm sure you understand. Mike protested, thought that maybe it was bad that Bob had such a scare but why did that have to affect him? It was of no use. Apache had made up her mind and that was final.. Mike went back to his shop and tried this for a few daysBut eventually he just couldn't do it anymore. He pleaded with Apache again but still she refused. Said that a decision had been made for the good of all and he'd just have to accept it or move out. Eventually Mike did move out. You see, Apache had the unfortunate luck to marry someone with aspbergers. If you don't know what that means a very easy reference would be the beloved Mr. Spock. Quite funny I know, but if you actually are Spock there's nothing funny about it. Just like there was nothing funny about Mike placing extra clamps on his equipment when he knew there was absolutely no point in doing it other than pleasing his beloved Apache and her insufferable friends. No ...you might as well ask a dog to stop sniffing other dogs asses, a computer to stop computing ..He had no choice. It wasn't something he could live with no matter how much he loved Apache. . /even further in history On 3/20/07, Henri Yandell [EMAIL PROTECTED] wrote: snipped future history Apache gets married, finds a little house in the suburbs and raises little apachlets. But that's another story. /future history So not losing values - these are Jakarta values that we relinquished 5 years ago. On the OTOH... I've not got the patience for such convincing atm :) Hen - 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
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]
Re: [VOTE] Release Regexp 1.5
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. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
Henri Yandell wrote: snip/ PS I noticed that you forgot to vote this year :-) http://marc.info/?l=jakarta-generalm=11231425543 Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
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
Hm,
I hate to spoil you here but according to a recent board discussion,
some discussion on [EMAIL PROTECTED] and a completely botched release
attempt in Velocity land:
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; personally I do prefer Vote-then-Release myself but
that seems to be the way it is.
On the release itself I'm +1, on the procedure I prefer to abstain. :-)
Best regards
Henning
On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
Hi All,
With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
[2], with other various optimizations to compiler and runtime, and with
previous
release published sometime back in 2005 [3], now is the best, or at the very
least, really good time to to cut next, 1.5 release of the venerable Jakarta
Regexp package.
Please try out current svn (r517970) version [4] and test for any regressions,
and vote for a release. Regexp test suite can be run by issuing 'ant test' in
the checkout directory, and does not take even 3 seconds to complete.
Interactive testing can be done by using applet version [5].
The only known incompatibility with Regexp 1.4 is that pre-compiled RE
programs
created with 'recompile' utility [6] for patterns containing reluctant
closures
are not compatible with trunk. But, that should not be a problem since they
did
not work correctly before anyway [7].
My vote for the release is +1.
Thanks,
Vadim
[1] http://jakarta.apache.org/regexp/changes.html
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
[3] http://marc.info/?l=jakarta-regexp-devm=112429683615736
[4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
[5] http://jakarta.apache.org/regexp/applet.html
[6]
http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/java/org/apache/regexp/recompile.java
[7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux,
|gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 14/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Henning Schmiedehausen wrote:
Hm,
I hate to spoil you here but according to a recent board discussion,
some discussion on [EMAIL PROTECTED] and a completely botched release
attempt in Velocity
My condolences to you...
land:
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.
personally I do prefer Vote-then-Release myself but
that seems to be the way it is.
Agree. Doing otherwise is putting carriage before the horse. The closest I can
do to satisfy old ladies drinking tea is this rc trunk build [2]. Of course
those are not the files to be distributed: to get those, I actually would have
to do release first. And that would put me in catch 22 situation. Hence these RC
builds have to suffice.
On the release itself I'm +1, on the procedure I prefer to abstain. :-)
Thanks! Now need one more before starting tagging. Also I think I need to update
headers as per [3], is that correct?
You also need a NOTICE file [3]
The LICENSE and NOTICE files ought to go into the jar as well, as the
jar may well be used on its own.
License should be LICENSE [3]
Vadim
[1] http://jakarta.apache.org/commons/releases/release.html
[2] http://people.apache.org/~vgritsenko/regexp/
It would be nice if the MD5 files used the more standard format:
9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
so that MD5 tools can process the file automatically.
[3] http://www.apache.org/legal/src-headers.html
Best regards
Henning
On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
Hi All,
With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
[2], with other various optimizations to compiler and runtime, and with
previous
release published sometime back in 2005 [3], now is the best, or at the very
least, really good time to to cut next, 1.5 release of the venerable Jakarta
Regexp package.
Please try out current svn (r517970) version [4] and test for any
regressions,
and vote for a release. Regexp test suite can be run by issuing 'ant test' in
the checkout directory, and does not take even 3 seconds to complete.
Interactive testing can be done by using applet version [5].
The only known incompatibility with Regexp 1.4 is that pre-compiled RE
programs
created with 'recompile' utility [6] for patterns containing reluctant
closures
are not compatible with trunk. But, that should not be a problem since they
did
not work correctly before anyway [7].
My vote for the release is +1.
Thanks,
Vadim
[1] http://jakarta.apache.org/regexp/changes.html
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
[3] http://marc.info/?l=jakarta-regexp-devm=112429683615736
[4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
[5] http://jakarta.apache.org/regexp/applet.html
[6]
http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/java/org/apache/regexp/recompile.java
[7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
-
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 14/03/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 LICENSE and NOTICE files ought to go into the jar as well, as the jar may well be used on its own. Added both files to the META-INF directory of the jar file. License should be LICENSE [3] Yep, it is there [1]. Exact copy. The LICENSE and NOTICE files are now in the zip and jar, but they show up for me as License and Notice. Ideally they should be in capitals. [2] http://people.apache.org/~vgritsenko/regexp/ It would be nice if the MD5 files used the more standard format: 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip so that MD5 tools can process the file automatically. Which tools you have in mind? All tools known and available to me (locally and on p.a.o) produce the output MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8 The only exception is 'md5 -r', but it does not put '*' before file name. The '*' is supposed to be used for binary files; otherwise use ' ' (space). The ones I have seen are: http://en.wikipedia.org/wiki/Md5sum http://mirror.href.com/thestarman/DOS/MD5progs.html#format http://www.fourmilab.ch/md5/ Also the Tomcat MD5s (for example). Thanks for all the feedback. Files, now using r518169, are re-built and re-uploaded [2]. Vadim [1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE [2] http://people.apache.org/~vgritsenko/regexp/ - 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
sebb wrote:
The LICENSE and NOTICE files are now in the zip and jar, but they show
up for me as License and Notice. Ideally they should be in capitals.
They are:
[EMAIL PROTECTED] ~/public_html/regexp $ tar -tzf
jakarta-regexp-1.5-dev.tar.gz | grep dev/[^dsx]
jakarta-regexp-1.5-dev/LICENSE
jakarta-regexp-1.5-dev/NOTICE
jakarta-regexp-1.5-dev/README
[EMAIL PROTECTED] ~/public_html/regexp $ unzip -l jakarta-regexp-1.5-dev.zip |
grep dev/[^dsx]
11357 03-14-07 10:05 jakarta-regexp-1.5-dev/LICENSE
302 03-14-07 10:05 jakarta-regexp-1.5-dev/NOTICE
901 03-14-07 10:05 jakarta-regexp-1.5-dev/README
[EMAIL PROTECTED] ~/public_html/regexp $ unzip jakarta-regexp-1.5-dev.zip
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar
[EMAIL PROTECTED] ~/public_html/regexp $ unzip -l
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar | grep -v org
Archive: jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar
Length Date TimeName
0 03-14-07 10:04 META-INF/
106 03-14-07 10:04 META-INF/MANIFEST.MF
11357 03-14-07 09:52 META-INF/LICENSE
302 10-31-06 22:36 META-INF/NOTICE
---
62348 24 files
[2] http://people.apache.org/~vgritsenko/regexp/
It would be nice if the MD5 files used the more standard format:
9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
so that MD5 tools can process the file automatically.
Which tools you have in mind? All tools known and available to me
(locally and on p.a.o) produce the output
MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
The only exception is 'md5 -r', but it does not put '*' before file name.
The '*' is supposed to be used for binary files; otherwise use ' ' (space).
The ones I have seen are:
http://en.wikipedia.org/wiki/Md5sum
It's not found on apache boxes.
http://mirror.href.com/thestarman/DOS/MD5progs.html#format
http://www.fourmilab.ch/md5/
That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer
it more. I guess that's exactly what you had in mind.
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
On 14/03/07, Vadim Gritsenko [EMAIL PROTECTED] wrote: sebb wrote: The LICENSE and NOTICE files are now in the zip and jar, but they show up for me as License and Notice. Ideally they should be in capitals. They are: [EMAIL PROTECTED] ~/public_html/regexp $ tar -tzf jakarta-regexp-1.5-dev.tar.gz | grep dev/[^dsx] jakarta-regexp-1.5-dev/LICENSE jakarta-regexp-1.5-dev/NOTICE jakarta-regexp-1.5-dev/README Sorry, just discovered that Winzip was being helpful and converting the file name... [2] http://people.apache.org/~vgritsenko/regexp/ It would be nice if the MD5 files used the more standard format: 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip so that MD5 tools can process the file automatically. Which tools you have in mind? All tools known and available to me (locally and on p.a.o) produce the output MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8 The only exception is 'md5 -r', but it does not put '*' before file name. The '*' is supposed to be used for binary files; otherwise use ' ' (space). The ones I have seen are: http://en.wikipedia.org/wiki/Md5sum It's not found on apache boxes. Some / most users are not on apache boxes... http://mirror.href.com/thestarman/DOS/MD5progs.html#format http://www.fourmilab.ch/md5/ That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer it more. I guess that's exactly what you had in mind. Well, either format will do for humans. The format I am suggesting is supported as input to some programs that can be used to check the MD5s - is the other format usable as input? If so, which program(s)? But anyway: +1 to the release S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Regexp 1.5
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 LICENSE and NOTICE files ought to go into the jar as well, as the jar may well be used on its own. Added both files to the META-INF directory of the jar file. License should be LICENSE [3] Yep, it is there [1]. Exact copy. [2] http://people.apache.org/~vgritsenko/regexp/ It would be nice if the MD5 files used the more standard format: 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip so that MD5 tools can process the file automatically. Which tools you have in mind? All tools known and available to me (locally and on p.a.o) produce the output MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8 The only exception is 'md5 -r', but it does not put '*' before file name. Thanks for all the feedback. Files, now using r518169, are re-built and re-uploaded [2]. Vadim [1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE [2] 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
+1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
