Re: [ALL] Valid reasons for blocking a release?

[Stian Soiland-Reyes]

I don't think a valid site or the odd missing file is enough to cancel
a release - but if there are multiple such issues it should also be
taken into consideration.

Even the odd -1 vote can be ignored if there are enough positive votes.

On 15 September 2016 at 12:42, Stefan Bodewig  wrote:
> 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 "README.md" and "CONTRIBUTING.md" _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
> distribution.
>
> 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 :-)
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Valid reasons for blocking a release?

[Stefan Bodewig]

On 2016-09-16, Gilles wrote:

> Is the site a valid reason?

to cancel a release? IMHO no.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Valid reasons for blocking a release?

[Gilles]

On Thu, 15 Sep 2016 09:20:14 -0700, Gary Gregory wrote:
On Thu, Sep 15, 2016 at 4:02 AM, 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".
It was when I did RM CM some years ago and found that some of the
instructions just did not work.  And that what worked either was
not mentioned (only those who "knew" could RM) or was the second
or third alternative way.

For newbies (and everyone else from your own words), that was
indeed the nightmare.

I thus initiated a single-step-by-single-step "howto" for CM that
did work.
And that should have been updated whenever something had to change
to make a release successful.

Who decided that "README.md" and "CONTRIBUTING.md" _had_ to be part
of the distribution files?

Did we vote on that?

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




You'd have to wonder why.
"Our release process is a nightmare" is not an answer to that 
question.


That the instructions which many RM follow are so poor that a single
RC is rare is no reason to infer that any release should suffer from
the same bias.

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.



Ahem, the site:

https://home.apache.org/~erans/commons-rng-1.0-RC1-site/

says:

"*There isn't any release yet.*
Work is currently performed actively towards release 1.0: See our
issue-tracking system. "

The site reflects what to expect from the sources, like the reports.

If I checkout the 1.0 source tag (or src zip) and build it, I'm going 
to
think right away that I got the WRONG tag or wrong src zip because it 
says

so on the tin "*There isn't any release yet."*


What's the point of coming back to something which I acknowledged
when you noticed it the first time:
  http://markmail.org/message/wrdtdaruxzpumrbz
?

Is the site a valid reason?
IMO, no, because it can broken and fixed at any time, not in
relation with a release.

If you think otherwise, then we should set up a vote every time
someone wants to upgrade the web site.

The site is a best effort service for users, not a source release.


Gilles



Gary




The files are there, to fill their role on Github and on Apache!

Stian just noticed that they were missing from the distribution
files, and in _that_ context (e.g. someone who want to compile
from source), they do not have any purpose.

Please check your facts before using such a word: I can happily
take that I'm not an expert on random number generators but not
so happily that I don't pay attention to the detail.

I will prepare RC2, but I find it totally disproportionate, as
there was strictly no reason to do it.


Gilles

Gary


On Sep 14, 2016 7:32 AM, "Gilles"  
wrote:


On Wed, 14 Sep 2016 14:53:29 +0100, Stian Soiland-Reyes wrote:


On 14 September 2016 at 10:14, Gilles 


wrote:

This is a [VOTE] for releasing Apache Commons Rng 1.0 (from RC1).

Commit ID the tag points at:
  f8d23082607b9f2c7be7f489eb09627722440ee5



Thanks, Gilles!

I'm afraid my vote is: -0 as the source zip is missing README.md 
and

CONTRIBUTING.md and the site is not updated.


The site can, and will be fixed, "live" (as it must be done anyway 
for

the link to the Javadoc, see below).

Everything else looks


good though!


Checked:

+1 checksums
+1 signatures
+1 source zip vs tar.gz
+1 binaries zip vs tar.gz
+1 mvn apache-rat:check (if using ignores from )



I don't understand the "if" clause.
Report is clean when generated as part of "mvn site".

+1 maven repo matches source (on -src.tar, -src.zip)


+1 mvn clean install
+1 LICENSE/NOTICE
+1 javadoc


http://home.apache.org/~erans/commons-rng-1.0-RC1-site/apido
cs/index.html
+1 RELEASE-NOTES  (Should it mention that this was in math 
before?)




No point IMHO.
There isn't a single file that was not significantly changed
and most are new.

It was developed within the CM repository but the code was never
released as part of CM.

-1 git tag vs source zip

   source zip is missing README.md and CONTRIBUTING.md (and doc, 
which

I think it's correct to exclude)
-1 binaries vs source
binaries zip is missing README.md and CONTRIBUTING.md (and 
doc,

which I think it's correct to exclude)



Are those a mandatory part of the distribution?
Commons Math was never released with those files.

I'd rather not redo the release steps just for files that are
meaningful only when browsing the code repository mirror at
Github.

-1 README missing from both source and 

Re: [ALL] Valid reasons for blocking a release? (Was: [REMINDER][VOTE][RC1] Release Commons Rng 1.0)

[Gary Gregory]

On Thu, Sep 15, 2016 at 4:02 AM, 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".
> It was when I did RM CM some years ago and found that some of the
> instructions just did not work.  And that what worked either was
> not mentioned (only those who "knew" could RM) or was the second
> or third alternative way.
>
> For newbies (and everyone else from your own words), that was
> indeed the nightmare.
>
> I thus initiated a single-step-by-single-step "howto" for CM that
> did work.
> And that should have been updated whenever something had to change
> to make a release successful.
>
> Who decided that "README.md" and "CONTRIBUTING.md" _had_ to be part
> of the distribution files?
>
> Did we vote on that?
>
> It's rare to release without more than one RC.
>>
>
> You'd have to wonder why.
> "Our release process is a nightmare" is not an answer to that question.
>
> That the instructions which many RM follow are so poor that a single
> RC is rare is no reason to infer that any release should suffer from
> the same bias.
>
> 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.
>

Ahem, the site:

https://home.apache.org/~erans/commons-rng-1.0-RC1-site/

says:

"*There isn't any release yet.*
Work is currently performed actively towards release 1.0: See our
issue-tracking system. "

The site reflects what to expect from the sources, like the reports.

If I checkout the 1.0 source tag (or src zip) and build it, I'm going to
think right away that I got the WRONG tag or wrong src zip because it says
so on the tin "*There isn't any release yet."*

Gary



> The files are there, to fill their role on Github and on Apache!
>
> Stian just noticed that they were missing from the distribution
> files, and in _that_ context (e.g. someone who want to compile
> from source), they do not have any purpose.
>
> Please check your facts before using such a word: I can happily
> take that I'm not an expert on random number generators but not
> so happily that I don't pay attention to the detail.
>
> I will prepare RC2, but I find it totally disproportionate, as
> there was strictly no reason to do it.
>
>
> Gilles
>
> Gary
>>
>> On Sep 14, 2016 7:32 AM, "Gilles"  wrote:
>>
>> On Wed, 14 Sep 2016 14:53:29 +0100, Stian Soiland-Reyes wrote:
>>>
>>> On 14 September 2016 at 10:14, Gilles 
 wrote:

 This is a [VOTE] for releasing Apache Commons Rng 1.0 (from RC1).
> Commit ID the tag points at:
>   f8d23082607b9f2c7be7f489eb09627722440ee5
>
>
 Thanks, Gilles!

 I'm afraid my vote is: -0 as the source zip is missing README.md and
 CONTRIBUTING.md and the site is not updated.


>>> The site can, and will be fixed, "live" (as it must be done anyway for
>>> the link to the Javadoc, see below).
>>>
>>> Everything else looks
>>>
 good though!


 Checked:

 +1 checksums
 +1 signatures
 +1 source zip vs tar.gz
 +1 binaries zip vs tar.gz
 +1 mvn apache-rat:check (if using ignores from )


>>> I don't understand the "if" clause.
>>> Report is clean when generated as part of "mvn site".
>>>
>>> +1 maven repo matches source (on -src.tar, -src.zip)
>>>
 +1 mvn clean install
 +1 LICENSE/NOTICE
 +1 javadoc


 http://home.apache.org/~erans/commons-rng-1.0-RC1-site/apido
 cs/index.html
 +1 RELEASE-NOTES  (Should it mention that this was in math before?)


>>> No point IMHO.
>>> There isn't a single file that was not significantly changed
>>> and most are new.
>>>
>>> It was developed within the CM repository but the code was never
>>> released as part of CM.
>>>
>>> -1 git tag vs source zip
>>>
source zip is missing README.md and CONTRIBUTING.md (and doc, which
 I think it's correct to exclude)
 -1 binaries vs source
 binaries zip is missing README.md and CONTRIBUTING.md (and doc,
 which I think it's correct to exclude)


>>> Are those a mandatory part of the distribution?
>>> Commons Math was never released with those files.
>>>
>>> I'd rather not redo the release steps just for files that are
>>> meaningful only when browsing the code repository mirror at
>>> Github.
>>>
>>> -1 README missing from both source and bniaries
>>>
 -1 site stlil says "There isn't any release yet" etc on front page.


>>> This was noticed by 

Re: [ALL] Valid reasons for blocking a release?

[Stefan Bodewig]

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 "README.md" and "CONTRIBUTING.md" _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
distribution.

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 :-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ALL] Valid reasons for blocking a release? (Was: [REMINDER][VOTE][RC1] Release Commons Rng 1.0)

[Gilles]

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".
It was when I did RM CM some years ago and found that some of the
instructions just did not work.  And that what worked either was
not mentioned (only those who "knew" could RM) or was the second
or third alternative way.

For newbies (and everyone else from your own words), that was
indeed the nightmare.

I thus initiated a single-step-by-single-step "howto" for CM that
did work.
And that should have been updated whenever something had to change
to make a release successful.

Who decided that "README.md" and "CONTRIBUTING.md" _had_ to be part
of the distribution files?

Did we vote on that?


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


You'd have to wonder why.
"Our release process is a nightmare" is not an answer to that question.

That the instructions which many RM follow are so poor that a single
RC is rare is no reason to infer that any release should suffer from
the same bias.

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.

The files are there, to fill their role on Github and on Apache!

Stian just noticed that they were missing from the distribution
files, and in _that_ context (e.g. someone who want to compile
from source), they do not have any purpose.

Please check your facts before using such a word: I can happily
take that I'm not an expert on random number generators but not
so happily that I don't pay attention to the detail.

I will prepare RC2, but I find it totally disproportionate, as
there was strictly no reason to do it.


Gilles


Gary

On Sep 14, 2016 7:32 AM, "Gilles"  
wrote:



On Wed, 14 Sep 2016 14:53:29 +0100, Stian Soiland-Reyes wrote:

On 14 September 2016 at 10:14, Gilles 


wrote:


This is a [VOTE] for releasing Apache Commons Rng 1.0 (from RC1).
Commit ID the tag points at:
  f8d23082607b9f2c7be7f489eb09627722440ee5



Thanks, Gilles!

I'm afraid my vote is: -0 as the source zip is missing README.md 
and

CONTRIBUTING.md and the site is not updated.



The site can, and will be fixed, "live" (as it must be done anyway 
for

the link to the Javadoc, see below).

Everything else looks

good though!


Checked:

+1 checksums
+1 signatures
+1 source zip vs tar.gz
+1 binaries zip vs tar.gz
+1 mvn apache-rat:check (if using ignores from )



I don't understand the "if" clause.
Report is clean when generated as part of "mvn site".

+1 maven repo matches source (on -src.tar, -src.zip)

+1 mvn clean install
+1 LICENSE/NOTICE
+1 javadoc


http://home.apache.org/~erans/commons-rng-1.0-RC1-site/apidocs/index.html
+1 RELEASE-NOTES  (Should it mention that this was in math before?)



No point IMHO.
There isn't a single file that was not significantly changed
and most are new.

It was developed within the CM repository but the code was never
released as part of CM.

-1 git tag vs source zip
   source zip is missing README.md and CONTRIBUTING.md (and doc, 
which

I think it's correct to exclude)
-1 binaries vs source
binaries zip is missing README.md and CONTRIBUTING.md (and doc,
which I think it's correct to exclude)



Are those a mandatory part of the distribution?
Commons Math was never released with those files.

I'd rather not redo the release steps just for files that are
meaningful only when browsing the code repository mirror at
Github.

-1 README missing from both source and bniaries

-1 site stlil says "There isn't any release yet" etc on front page.



This was noticed by Gary.
The site is not part of the release and can be fixed anytime (which
I'll do before the announcement).

"Javadoc 1.0" link in menu is broken.




That is always the case; it is also to be fixed when the files are
in their proper place (i.e. not in the RM's "~/public_html").


Regards,
Gilles


Tested with


$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-36-generic", arch: "amd64", 
family:

"unix"





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,