commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [all] Together, and bricks apart
Date Fri, 02 Dec 2005 18:35:47 GMT
On 12/2/05, Phil Steitz <> wrote:
> On 11/30/05, Mario Ivankovits <> 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:
> 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

> > 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message