commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [ALL] Valid reasons for blocking a release?
Date Thu, 15 Sep 2016 11:42:56 GMT
On 2016-09-15, Gilles wrote:

> On Wed, 14 Sep 2016 07:41:01 -0700, Gary Gregory wrote:
>> "I'd rather not redo the release steps just for files that are
>> meaningful only when browsing the code repository mirror at
>> Github."

>> I know our release process is a pain, so maybe we should see if we
>> can
>> improve it. This needs a separate thread.

> I'm not the one who complains regularly that the release process
> is a "nightmare".

I don't share this sentiment. There are a quite a few manual steps, but
I don't believe they can be avoided.

Then again I've cut enough releases to know which alternative has worked
for me.

My workflow is different enough that it likely never is the first option
you find in the docs. At least when uploading stuff to Nexus it is not
even listed as alternative at all (I use an upload bundle). I didn't
want to pollute the instructions with even more alternatives.

> Who decided that "" and "" _had_ to be part
> of the distribution files?

I don't think anybody decided that. What I'd expect (I didn't
participate in the RNG vote, sorry) is that the source distribution
matches the git tag. And I think this was what Stian brought up. It's
not about the two files but about the difference between tag and

We've probably never formally said the two should match either, it's
just what I'd expect. Why would anybody want to exclude anything from
the source distribution that is inside or SCM?

>> It's rare to release without more than one RC.

> You'd have to wonder why.

One thing RMs tend to forget is that there is no veto on a release
vote. If you've got enough +1s you can simply go ahead if you disagree
with the occasional -1.

>> It looks pretty lame IMO if the first thing you see, our site or
>> github, is wrong or missing info. It could make one wonder about
>> overall attention to detail...

> Nothing _looks_ lame.

Please mind Gary's "IMO" in the paragraph above.

"lame" is hardly objective :-)


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

View raw message