commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Date Mon, 14 Oct 2013 05:39:55 GMT
On Sun, Oct 13, 2013 at 7:09 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell <flamefew@gmail.com> wrote:
>
> > I propose release votes be simple revision based requests and involve no
> > artifact churn :)
> >
>
> Hen,
>
> This is a pretty good idea.
>
> But I still think that artifact churn will be a necessary process in order
> to get enough valid QA on the artifacts.  But it should be possible to get
> a source artifact out without so much pain.
>

It's up to the those voting I think. ie) they do the churn, not someone
central.

I say:  "Lang 3.2 is ready"
You decide your bar is to make sure the changelog looks good (thus checking
the changelog is up to date) and you raise objections over some quick hack
I snuck in.
Phil's bar is that the source must build, tests are good and that the clirr
report ensures backwards compat. So he runs the clirr report and the
general build, then deep dives into the tests and uses cobertura to let him
decide if our quality is regressing.
This continues through others and we reach a consensus after some tweaks
that trunk is ready and now called 3.2 and is ready for packaging. I think
it's important than when people vote, they indicate their steps. That way
the release manager can tell whether or not a vote is deep or shallow.

What this stops us talking about is the announcement email, the website,
the packaging, whether somebody did gpg right or put it in the right place
in Maven and so on ad infinitum. It also stops all of those having to be
the same person - which I think is huge. And it stops us prepping those
every time to have what is hopefully a vote about the code. Which is huge
squared.

The release is when we tag the code - then the release manager has a list
of other things that need to be done and can be asking for help on those
instead of having to learn each item. That allows people to specialize in
those areas and improve them as they (the subgroup) see fit. There are
negatives - the packaging may find a problem in the original source. The
tag for 3.2 may have the wrong maven id and we'll have to decide how we
want to handle it (ie: 3.2.1 or heretical editing of a tag). We may have
releases that don't get all the bells and whistles placing them in whatever
location. The only issues that should show up in the packaging are issues
related to the packaging - it shouldn't, in theory, affect anything
important about the code itself.  Suffice to say - I think those 'bugs' are
worth the efficiency.

Hmmm - I've gone from off hand remark while juggling children to serious
opinion :)

Hen

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