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 Thu, 01 Dec 2005 03:29:48 GMT
On 11/30/05, Niall Pemberton <> wrote:
> On 12/1/05, Stephen Colebourne <> wrote:
> > Release managers are also facing tougher release checkers now IMHO. For
> > instance, I haven't ignored configuration, but haven't had the time to
> > check it out properly (way too much to do). I try to only give a +1 if I
> > genuinely am happy. Perhaps I'm now applying too high a standard? Its a
> > tough balance.
> Adding to what Stephen said, voting +1 to me means at a minimum you're
> indicating knowledge of the code and/or an intention to support it in
> some way. For me I can do that on only 3 to 5 of the Commons
> components. A good example is FileUpload - as a user I would like to
> see a release, but I only recently looked at a bit of the code and
> made a minor contribution. When it comes to a vote I'm not sure
> whether I'll vote for it or not as I don't think I have the time to
> actually provide any support. Is this the generally accepted criteria
> or do others follow more or less lenient criteria?

I think most people voting +1 are _not_ saying they're prepared to support
it. Rather, they're saying something more like "I've checked out the
proposed distribution, and didn't see any issues, so I'm happy for the
Commons Foo team to release it as is". How much work is behind each +1 I'm
sure varies from person to person. Some, like Stephen, are putting more
effort into checking out the builds than they used to, while I'm sure others
are more lenient.

I hope I'm not wrong on this. If I am, and you're right, Niall, then I might
as well give up on ever getting another FileUpload release out the door,
based on how few people other than myself have ever touched the code base
over the last several years.

Martin Cooper

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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