On Sun, Oct 13, 2013 at 7:09 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell <flame...@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
