Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
Hi, Quick note at 6AM. (always dangerous to send email 15 min after getting up). How about if I just drop my concerns about the lack of an rc, and just ask - is there any way we can issue a release Velocity 1.5 with the anakia documentation fixed? It's a small patch to two files to fix the xdoc that has already been applied to trunk. Again, I'd be happy to do the release - perhaps we could get the site ready, archive it, then copy the release over when ready? I really like the new site organization. I assume these Maven issues are a temporary thing. If it becomes too onerous we might just back out the specific site features in the short term. WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
Keep sending mail early in the morning! I find this one very constructive. Le mercredi 31 janvier 2007 à 06:20 -0800, Will Glass-Husain a écrit : Hi, Quick note at 6AM. (always dangerous to send email 15 min after getting up). How about if I just drop my concerns about the lack of an rc, and just ask - is there any way we can issue a release Velocity 1.5 with the anakia documentation fixed? It's a small patch to two files to fix the xdoc that has already been applied to trunk. 1.5 is a good marketing choice... keep it simple... the very few people enough curious to find the download link of the not yet public 1.5 release should be clever enough to correctly update their dependencies and shouldn't be drastically impacted by the missing docfix in Anakia. Claude Again, I'd be happy to do the release - perhaps we could get the site ready, archive it, then copy the release over when ready? I really like the new site organization. I assume these Maven issues are a temporary thing. If it becomes too onerous we might just back out the specific site features in the short term. WILL - 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 Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 10:09 AM, Henning P. Schmiedehausen wrote: Geir Magnusson Jr. [EMAIL PROTECTED] writes: because Maven2 has issues and that's what the current site is being built with. i've tried to get it working on my machine, but no luck yet. Then I'd argue this shouldn't be our site until this is fixed :) Geir, sorry for me starting to lose my patience here, but this is the thing: Between November '06 and now I tried to make the new velocity project site and the engine docs to be an as good user experience as can be. I put a lot of work in this using maven. There have been a number of things sprouted from here that you can review under site/tools. I also found enough bugs in maven and its components to fill a small folder. That is how open source works. Especially open source that tries to be somewhat on the Leading wave. Up until now, all you did was saying I don't like this. I'm concerned about this. I'd argue that we do it differently. I don't recall. I'm usually not that prescient. The thing is: That is not helping. Actually, it is frustrating in a big way. I'd like you to spent some time to take a look at what is there, not what you would like to have (and then seem to expect to appear automagically). I didn't ask you to change anything, IIRC. If you find things missing, being less than ideal, I'd encourage you to either a) fix it b) open issues for it Please review wheter doing neither a) nor b) but just leaning back and saying I'd argue that this should not be our site until it is fixed is really a constructive and encouraging way to work in a (regrettably small) developer community. Henning - what you are saying is that you broke it and you want me to fix it? I'm not sure I like that. I tend to believe that except when people agree to do the contrary, it's a good idea to ensure that any works-in-progress remain uncommitted, or in a branch or whiteboard, to ensure that there's a working configuration available to anyone to work with. I haven't commented on the site, the quality of it or anything like that. I simply noted surprise that we have a site that only you can build, and noted that maybe that shouldn't actually be the official project site until that's fixed. geir Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - 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 Velocity 1.5 (again, this time for real. :-) )
On 1/31/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Ok, I didn't want to step on Henning's toes by doing this too soon. I'm guessing he's wrapping up and getting ready for his big trip. We can address the site update immediately following the release. if he's planning to do the fixes and put up a new test build, i haven't heard him say it. at this point, i think it'd be a nice gesture of cooperation if you were to step up and help. Incidentally, the press release is coming along. The PRC has given useful comments. I'm still working on getting a quote from a commercial user. Claude has agreed to be the European contact for the press and I'll be listed as the US contact. that's great! perhaps we could put out a request for commercial soundbites on the user list? WILL On 1/31/07, Nathan Bubna [EMAIL PROTECTED] wrote: If you're willing to do the release, go for it. Put the fixes in the VELOCITY_1.5_BRANCH, roll a test build, upload it, point us to it, and then call for a vote. Updating the site is a secondary thing. We can figure that out when we get to it. - 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 Velocity 1.5 (again, this time for real. :-) )
Hi all, Reluctantly, I vote -1. I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type example must end with a '' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Tue, 2007-01-30 at 14:53 -0800, Will Glass-Husain wrote: Hi all, Reluctantly, I vote -1. I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. I did discuss this in some depth with Will on IRC. He explained me his reasons for the vote in depth I respect them. Here is my response: - The problem with the anakia.html file is apparent and obvious. So we have a single file for a quite obscure part of Velocity missing. It is fixed on the site (http://velocity.apache.org/engine/releases/velocity-1.5/anakia.html) so if anyone is really looking for this file and can not find it in the downloaded distribution, it is available online. To me, this is no show stopper. It is a wart. We have a number of them (I can readily think of at least one more broken link on the bundled pages). - The release feels rushed. As I wrote, yes in part it is because I want to get it out before end of January. We have been dragging that release for so long that we might make the vaporware top 10 at some point. I'd like to get over with it. If we have warts, we can release 1.5.1 which fix them. Aiming for perfection IMHO does not cut the cake. Good is enough and we can always do the next release. We can find a reason not to release every time we try. - The issues we have are *solely* with documentation. No code is involved. - Re-releasing 1.5 is IMHO not possible. We have rolled tarballs and jars which have been available from http://people.apache.org/dist/velocity/1.5/ Some people are bound to have downloaded them and they might even spread. We can denounce them as not officially released but if we re-roll 1.5 tarballs, we will end up with bug reports against bogus versions. Telling me that I did a lot of work is nice. I know it. Velocity did cut seriously into my spare time lately and I want to spend this time for coding, not doing release and documentation chores. There has not much response been in terms of helping with docs and while most people are already talking about the grand new Velocity 2.0, we want to get an actual release for 1.x first. BTW: I don't actually buy into the smooth transition argument anyway, however I can not really reinforce it. If you have an app that uses 1.4 or 1.3 for a long time and you just drop 1.5 in, you are in for a surprise. There is always dependency upgrading (which we could have stated more prominently in the release, but we do have it on the web site now (http://velocity.apache.org/engine/devel/upgrading.html, once the mirror caught up), so adding that link in the announcement is IMHO fine. As a compromise, I'd like to propose to keep the 1.5 release and call it Release candidate in the same way as httpd calls it's releases x.y.z and assigns them levels of quality such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following.
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and Settings\wglass\Desktop\velocity-1.5\bin\docs [anakia] Input: anakia.xml [anakia] [anakia] Error: The end-tag for element type example must end with a '' delimiter. [anakia]Line: 117 Column: 60 On 1/28/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: ... I did discuss this in some depth with Will on IRC. He explained me his reasons for the vote in depth I respect them. Here is my response: - The problem with the anakia.html file is apparent and obvious. So we have a single file for a quite obscure part of Velocity missing. It is fixed on the site (http://velocity.apache.org/engine/releases/velocity-1.5/anakia.html) so if anyone is really looking for this file and can not find it in the downloaded distribution, it is available online. To me, this is no show stopper. It is a wart. We have a number of them (I can readily think of at least one more broken link on the bundled pages). - The release feels rushed. As I wrote, yes in part it is because I want to get it out before end of January. We have been dragging that release for so long that we might make the vaporware top 10 at some point. I'd like to get over with it. If we have warts, we can release 1.5.1 which fix them. Aiming for perfection IMHO does not cut the cake. Good is enough and we can always do the next release. We can find a reason not to release every time we try. +1 - The issues we have are *solely* with documentation. No code is involved. - Re-releasing 1.5 is IMHO not possible. We have rolled tarballs and jars which have been available from http://people.apache.org/dist/velocity/1.5/ Some people are bound to have downloaded them and they might even spread. We can denounce them as not officially released but if we re-roll 1.5 tarballs, we will end up with bug reports against bogus versions. eh... if you think so. i wouldn't say we released it even once, much less worry about re-releasing. we can call the next test build 1.5, 1.5.0 or 1.5.1, as far as i'm concerned. Telling me that I did a lot of work is nice. I know it. Velocity did cut seriously into my spare time lately and I want to spend this time for coding, not doing release and documentation chores. There has not much response been in terms of helping with docs and while most people are already talking about the grand new Velocity 2.0, we want to get an actual release for 1.x first. Sorry, been busy with VelocityTools 1.3. :( BTW: I don't actually buy into the smooth transition argument anyway, however I can not really reinforce it. If you have an app that uses 1.4 or 1.3 for a long time and you just drop 1.5 in, you are in for a surprise. There is always dependency upgrading (which we could have stated more prominently in the release, but we do have it on the web site now (http://velocity.apache.org/engine/devel/upgrading.html, once the mirror caught up), so adding that link in the announcement is IMHO fine. As a compromise, I'd like to propose to keep the 1.5 release and call it Release candidate in the same way as httpd calls it's releases x.y.z and assigns them levels of quality such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following. hmm. not thrilled about switching release procedures midway, but if you won't release Velocity 1.5 as final/GA/whatever, then i want to see some sort of release. so, i suppose i'll give this plan a: +1 This would mean that we reduce our planned 'press campaign' to an announcement on the dev list and the RSS feed and run the real thing for 1.5.1. I will not release if we have a -1 vote even if we do have three PMC +1 votes. I know the 'Apache rules' would back me here, but I would feel uncomfortable to do this without unanimous consent from the PMC members. Will felt strong enough about this to not just abstain but to vote -1, so we should try to resolve this and get him to retract his vote. To be honest, i'm bummed about this. I think there is wisdom in the rules. If Will feels strongly enough to -1 this, then he should feel strongly enough to address his concerns, upload a 1.5.1 test build and vote to have it released ASAP to supersede the 1.5 release. I did pull the release archives from people.apache.org. If we can resolve this on short notice, good. If not, we are basically stuck with Mid-March as the next possible release date (and a third vote) if I should do the release or someone else stepping up as release manager. Will should be able to scratch his itches quickly. Mid-march is a long time to wait for such small tweaks. If he doesn't step up with a 1.5.1 test build and vote before then, then i may take a shot at it. I'd like to hear opinions from others to that. I'd also like to encourage you to lobby Will to withdraw his -1 :-) Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 12:52 AM, Nathan Bubna wrote: On 1/30/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jan 30, 2007, at 11:24 PM, Henning Schmiedehausen wrote: ... As a compromise, I'd like to propose to keep the 1.5 release and call it Release candidate in the same way as httpd calls it's releases x.y.z and assigns them levels of quality such as (Alpha) (Beta) (Release Candidate) (General Availability). So this would then be Velocity 1.5 (Release Candidate) with probably Velocity 1.5.1 (General Availability) following. No - that's confusing. 1.5 RC would be followed by 1.5 GA eh.. only if we're talking about a vote to just re-label 1.5. if we make changes to the distro (even for docs) and roll a new release, We didn't release this, so it doesn't matter, IMO. then we need a new number. since we're only talking about doc changes, 1.5.1 seems appropriate and would be likely to get voted as GA. - 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 Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 1:52 AM, Will Glass-Husain wrote: Hi, Knew I'd be unpopular the moment I hit send. You did the right thing. This is what the oversight processes here at the ASF are about. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. That's why I advocate having no manual steps to re-create the release. If you are lucky, you have everything happen in HEAD. Then, tag *that*, and do misc tweaks if needed. Also, the vote or delay was simply due to special circumstances, not regular practice. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). I think an rc1 should be as perfect as much as possible as well - calling it RC means (to me) - this is what we'd like to release, anything obvious we missed? and engage the public on it. That's what we used to do, IIRC, around here :) So yeah, this could be RC1, but to do that, I'd prefer to see something sane done like velocity/engine/branches/1.5 tags/1.5RC1 and have that released w/ RC1 in the right places. Then we wait until Henning gets back from lounging about for 6 weeks :) fix anything the community found, and go for 1.5 geir best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: I thought about this a little more. There's a couple things we can do that I'd support. (1) Figure out a way to call this release something other than Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. (2) Take a little time to make the minor fix required, then release the software. I can step up to do this over the next few days. I think Henning was concerned we'd need to rebuild the site and he's the only one that can do that. If I managed the release, I'd probably want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks later. Why is he the only one that can do the site? (3) Henning remains release manager and we wait until March for the release. We could leave the VELOCITY_1.5_BRANCH up so that the release is ready to go. We can also direct users interested in 1.5 specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir I'm sure our European community is long abed, I'll look for comments from them in the morning. WILL On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors. (no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. no, no. we still like you. just not your decision. :) Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. review and fix away! 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon hold on, i'm dropping this email and starting another. we have to get our terms and release processes straight or we'll never find consensus. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors.(no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is it not? I can't adequately express my admiration of Henning's efforts in the last 6 months to get this out. This must be frustrating. I take responsibility myself for not thinking through the implications of the release process when Henning proposed a month ago we issue a release at the end of January. Taking responsibility in the open source world means only one thing, if you ask me. Doing the work. If you're going to take responsibility for this by re-doing this whole process to your satisfaction either by repeating the 1.5 test build and vote or by letting 1.5 go and releasing a 1.5.1, then i won't protest. But please don't just sit back and critique at the last minute. That's not just frustrating, it's obnoxious. However, the good news is that the recent momentum was effective. We are right at the doorway to a new release with many new features. The code is branched and close to perfect. it is not close to perfect, nor will it ever be, but i believe it will get better faster if you don't obsess about it being perfect. Docs are set, readme is present. With a little more checking (and fixing minor issues like this one), we can type ant dist in early March and create the new release. WILL [1] [echo] [anakia] Transforming into: C:\Documents and
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On 1/30/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Jan 31, 2007, at 3:48 AM, Will Glass-Husain wrote: I thought about this a little more. There's a couple things we can do that I'd support. (1) Figure out a way to call this release something other than Velocity 1.5, e.g. Velocity 1.5rc1 and issue the release immediately. Can we do this without a 3 day vote? See my other response. Why the rush? If Henning has to go vacation, then you do the RC1 stuff, and we'll wait until he gets back for the 1.5 GA release. (2) Take a little time to make the minor fix required, then release the software. I can step up to do this over the next few days. I think Henning was concerned we'd need to rebuild the site and he's the only one that can do that. If I managed the release, I'd probably want to do Velocity 1.5rc1 first and then Velocity 1.5 two weeks later. Why is he the only one that can do the site? because Maven2 has issues and that's what the current site is being built with. i've tried to get it working on my machine, but no luck yet. (3) Henning remains release manager and we wait until March for the release. We could leave the VELOCITY_1.5_BRANCH up so that the release is ready to go. We can also direct users interested in 1.5 specific features to that svn branch. Right. Do the fixes in the branch, then make a tag/1.5rc1 build, vote and release as RC1. When Henning gets back, do 1.5 GA. Advantage is that people get to beat 1.5RC1 about for a month. geir I'm sure our European community is long abed, I'll look for comments from them in the morning. WILL On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Knew I'd be unpopular the moment I hit send. Three quick notes. 1) don't think the changes are big. But I think the distro should be reviewed and fixed. A bad hyperlink on the main menu, in our first release in 3 years, looks sloppy and conveys an inaccurate impression of the quality of our product. 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. I don't like it. 3) I'd be happy to vote +1 if we could call this Velocity 1.5rc1. But given the historic significance of this release, I urge us to release Velocity 1.5 in a professional distro without obvious errors. (no need to immediately issue Velocity 1.5.1). best, WILL On 1/30/07, Nathan Bubna [EMAIL PROTECTED] wrote: On 1/30/07, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi all, Reluctantly, I vote -1. :( I tested the release. It compiled fine, ant test ran fine under JDK 1.5 and 1.6, worked with Velocity Tools 1.2. But when I checked all the hyperlinks, the anakia page was missing. There's an error when generating the page and it was left out of the distribution [1]. C'mon. Anakia's documentation is anything but hard to find. I'm all for getting things right, but not for holding back releases based on one missing doc. I'd rather you let Henning release 1.5 now and release 1.5.1 yourself next week. I'm concerned about two things. I'm concerned about a prominent bad link on the main menu, and I'm concerned the last minute vote on the final release might not have uncovered additional problems. We've a chance to make a major impression on the Java world with this prominent release and I want this to be very smooth installation for both new users and the typical existing user who wants to upgrade. We can't cower in fear of unknown bugs. Fix what you know and care about, then let's get this thing moving again. My recommendation is to delay the release until there's time to fix these doc issues and for more thorough testing. Mid-March seems fine. For the shallow bugs theory to work, we need to issue a release candidate that everyone can work with. This doesn't need to be an actual release, just a binary distribution we can test. After a few weeks we should be assured the details are 100% set. How about two betas and a test build? That's what we've had. This release has had much time to prepare. More time won't kill us, but let's not pretend things are ever likely to be 100% set. Trust me, if i cared enough, i could start combing thru the docs of almost any major project you like and find dozens of errors. Same goes for most code. Final releases will never be perfect, but the shallow bugs theory won't work if we don't get *them* out there. Far fewer people bother with release candidates and betas. Incidentally, I disagree with Henning's comment that the beta2 had no errors. Actually, beta2 had a serious error in the build process in which ant test failed when run from the actual distribution. It worked from the source distribution but not the released package. No one found this problem for a month. And it's fixed, is
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
Just to clarify... 2) Unlike V-tools, we did not have a test build. Instead, the final package was created with the choice vote yes, or delay the release. no. we did have a test build and veltools did not. test build == unreleased build to be tested then voted upon What I meant is that there was no opportunity to offer fixes upon this build before voting. Due to the timing, Henning put that last touches on the build then called for a vote. Obviously, I'd much prefer to just have added the missing page to the Velocity 1.5 branch, but according to our recently clarified rules, I can't fix this and have this vote apply to that fix. We have to vote on a specific distribution. As a side question, is there a required voting period? It seems pretty obvious to me that we could do another vote and with everyone saying yes quickly, perhaps allowing Henning to still make this happen. Though I'd like to see an rc, I wouldn't insist on it. WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
On Sun, 2007-01-28 at 23:25 +0100, Henning Schmiedehausen wrote: [X] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
+1 Matthijs Lambooy Malcolm Edgar wrote: +1 regards Malcolm Edgar On 1/29/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - 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] -- Matthijs Lambooy CrossmarX BV, Amsterdam http://www.crossmarx.com +31654771926 skype callto://matthijslambooy xmpp:[EMAIL PROTECTED] http://www.zoook.nl laat zien wat je te koop hebt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Velocity 1.5 (again, this time for real. :-) )
+1 This is the first valid +1 since the three previous ones where BEFORE 00:00 MET... (Ok, just jokin') Claude Le dimanche 28 janvier 2007 à 23:25 +0100, Henning Schmiedehausen a écrit : Due to a misunderstanding in the vote procedure, we actually have to repeat the release vote, because we should vote only on really rolled releases. The candidate for the Apache Velocity 1.5 release is available from http://people.apache.org/dist/velocity/1.5/ Shall we release this code base as Apache Velocity 1.5 [ ] +1 Yes. [ ] 0 I still don't care. [ ] -1 No, because . Vote period is Monday, Jan 29th 0:00 MET to Wednesday, Jan 31st 0:00 MET Best regards Henning - 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]
