On 12/2/05, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On 11/30/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Phil Steitz wrote: > > > For me +1 means pretty much what Martin describes above. I check the > > > release contents, make sure required elements are there and in jars, > > > make sure there is nothing funny included. I test the builds, > > > validate sigs, etc and inspect the web site and, if present, > > > clirr/jdiff and look carefully at the release notes. I also review > > > the javadoc, maven reports and POM. I do try to learn a little more > > > with each release that I review; > > Thats true, I'll learn with every release review too, but can do this > > only if another one complains about this and that. > > If I read the stuff you do to check a release I am shocked, damn much > > work to do. > > > > At least one of you "release checkers" ;-) should setup a wiki to > > describe every step to do, this helps the release manager and those > > checking it. > > Especially if you are a newbie in the release cycle it might be a great > > start AND it defines standards. > > That was the intention of the releases pages: > http://jakarta.apache.org/commons/releases/index.html > > When I get out from under water, I will add a final "checklist" type > section, or someone else can. That is a good idea. > > > One thing which drives me crazy is that I dont know what to do to make a > > project ready for a release. > > I have to wait if anyone complains on an RC and even then, in case of > > [vfs] the real release blocker were uncovered while voting for 1.0 - > > after we have had a couple of month one RC after another! > > I agree that this is frustrating and don't have a great answer. See > comments at end below. The same thing just happened to me in [math]. > After a couple of RCs a major issue that was really a problem with 1.0 > was raised and it took a while to get it fixed. To me, this is a > consequence of not wanting to release with significant known issues, > which is sort of an unwritten rule which we tend to follow in commons. > See Martin's response below on "fix later". My view, shared by (I > think) most others is that there has to be a very good reason to do > that. At least on the components that I have worked on (see list > below), we tend to get the real issues closed before release and to > stop releases when they show up during the vote or RC testing. > > > And e.g. we started to discuss if we have to convert line-endings - > > after years (!) of commons releases - and we were not able to have a > > vital discussion about this little topic. > > In the "old days" we kept lf line endings on all the source files in > cvs and hand-rolled ant scripts were used to put crlf on the .txt > files in the zips. Between maven and svn's eol=native, that is no > longer possible or at least immediate. The real question (see other > response) is do we care about this? From lack of response to [poll] > thread, could be the answer is no.
This is an interesting comment, and indicates that we haven't done things consistently across Commons components (which isn't altogether surprising). All along - including in the old days of CVS - I've worked with CR-LF line ends, and that includes quite a few releases of several different components. So with the change to SVN, I haven't been doing anything differently... > > > These are really demotivating things! > > > Agreed and sorry if we seem to be making things harder rather than > easier. Patches - or direct commits to - the releases page and any > other suggestions to make things easier are most welcome. > > > > One other comment that I have on the issue of voting on releases is > that the core problem here is lack of component-committed volunteers, > IMHO. I remember a couple of years back when we discussed whose votes > were binding on component releases. Hen made the interesting comment > that he felt that committers not working on the component should vote > and their votes were as important / even more important than those of > the project team. We have now devolved to the point where without > these votes, we will in some cases not be able to get 3 binding +1's. > This is not good. Somehow we have to reengage as Rahul pointed out at > the top of this thread. IMO, what this tells us is the Commons isn't scaling, and that doesn't surprise me at all. In the "old days", there were a *lot* fewer components. Right now, I count 35 components in Proper and 9 more active components in the Sandbox (excluding the ones Henri is about to make dormant). That is a lot of stuff! Very few people, if any, are going to keep tabs on all of it, and most are likely to only track a handful, if that. When Commons was much smaller, the community was much more integrated, in that there was more overlap between the pieces (people-wise, not code-wise), and so we all watched each others' backs. We're no longer in that state. The inability to scale, is, in my opinion, an issue the ASF as a whole is also facing. Unfortunately, as with Commons, I don't have any good ideas. Other than to consciously stop growing, that is, but that doesn't appear to be a popular direction. -- Martin Cooper It might be a good idea for each of us to > take stock of the components that we can really +1 releases for (in > Neil's sense) and then see where the gaps are. By "us" I mean the > whole community. Anyone who is willing to review releases, respond to > bug reports, answer user questions, submit patches, or improve docs is > encouraged to step up. We need help! > > I will start. All I can really support right now are [math], [lang], > [collections] in commons proper and [id] in sandbox. One day when I > have more time and courage, I would like to jump into [beanutils] to > help save it from drowning under unresolved bugs and both [functor] > and [graph2] in the sandbox (possibly absorbing one or both into > [math]), but for now the four above are all I can really stay on top > of. > > To record this kind of info, we might add a list of active volunteers > to the Wiki page for each component. Does this sound like a good > idea? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
