On Tue, 30 Dec 2014 03:05:57 +0000, sebb wrote:
On 30 December 2014 at 02:40, Gilles <gil...@harfang.homelinux.org> wrote:
On Tue, 30 Dec 2014 01:38:12 +0000, sebb wrote:

On 30 December 2014 at 01:29, Gilles <gil...@harfang.homelinux.org> wrote:

On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote:


That thread gets deep. :)

I just wanted to comment on "releasing only
source is faster because of less checks". I disagree with that, most release delay/time is due to preparation work. Failed (binary) checks are typically for a reason which would also be present in the source
(especially the POM), so it does not really reduce the number of
rework.



RM is a streamlined procedure: so, if you do (say) 10 steps rather
than 15, it will objectively take less time, and this is compounded
by the additional tests which should (ideally) be performed by the
reviewers. [Thus delaying the release.]

(At least not in most cases, so two votes will actually make us
more work not less).



The additional work exactly amounts to sending _one_ additional mail.


No.

Both source and binary release need to be checked and voted on.
And the votes need to be tallied, and successful releases have to be
published, and unsuccessful ones dropped.


Yes, so?

I was just pointing out that separate source and binary releases are
more than just an additional e-mail.

The total effort is bigger.
Also it's usually less efficient to split the same jobs over two
sessions because of the extra prep.
Which is easier - committing the same change to two files as one
commit or two at different times?

If a certain RC would be vetoed only because of a problem with the
binaries?  The source could have otherwise been released.

Yes, but how frequent is that?
Usually there is an issue with the source that has caused the issue.

Besides, how many Commons users want just the source?


Checking the source release requires (for the reviewer) downloading
all the artifacts and tags.
If the releases are separated in time some of this may have to be
repeated.


What "may have to be repeated" exactly?

Downloading the tag is one step that may have to be repeated.
I also check the sigs against the current KEYS file by loading that
into a temp GPG keyring.

You wouldn't have to repeat whatever has been succesfully voted on.
If source was released, you'd only have to check the binaries (signature),
not the repository.


Even for the RM role, it is more work overall.

Then, as I noted,
 * some releases will be done as before (same work)
 * some releases will be "source only" (less work)
* some releases will be two-steps, possibly performed by two different
   people (i.e. less work for each RM)

Of course, each release means some work has to be done; then IIUC your
point, the fewer releases the better. :-}


I'm sorry, but I think you are glossing over several stages in your
presentation of the process.

If you really think your process is going to save work, please detail
the exact stages necessary in both cases.


Why do you see this in black or white?

I'm not; I'm trying to understand the two approaches in order to
compare them.

I never (and I repeated that several times already) intended to ask
that all RM perform a two-step procedure: Anyone willing to RM as usual
will obviously do it as he pleases.

Every time the issue of "we should release more often" comes up, almost everyone agrees. Every time a discussion occurs on the RM issue, several
people complain about the complexity of the procedure.
I then propose something to _try_ and improve that situation (sometimes) and suddenly, the current procedure is found more efficient than ever.

That is not an accurate summary of what I wrote.

It is an interpretation of the consequence of what you write: no gain
whatsoever, in no circumstances.
You cannot prove that, yet you ask me to prove that there could be a
gain; it's not fair.

I just don't see how performing the release in separate stages is
going to help reduce the total work done.

This is black and white. My position is that, in some cases (however
rare maybe-but-we-don't-know-since-you-don't-even-want-to-try), it
might be useful to vote on a source-only release.

You gave one example (linux distributions), I gave one (urgent fix/feature). Why should we argue on the overall time saved, or not, rather than agree
on the principle (even if it proves useless _most_ of the time)?

This information will be needed anyway as documentation if it is ever
agreed upon.


For source-only release, the information is the same as compiled by Luc (leaving out the Nexus-related steps and possibly replacing the bunch of files copied to "https://dist.apache.org/repos/dist"; with the tarball
referred to previously).

IMO, the contradiction is obvious between talk of releasing source-only and nit-picking that amounts to actually refuse to consider source-only
releases.


No, I am not nitpicking for the sake of it; I just don't understand
what you hope to gain, given that most end users will want the
convenience of a binary release.

Cf. above.
If some reviewers are afraid of the supposed added work, they simply
don't vote for a source release; and wait until a RM provides the
binaries so they can do their overall checks as usual.  Same work,
_exactly_.
[A flaw discovered in the "binaries" vote would prevent the release
of those artefacts and, for "convenience" users, the version would
never have existed in practice. The veto would eventually lead to a
new (bumped version) source release. Same procedure as the current
one, _exactly_.]

My proposal does not remove anything from anyone, it only adds more
possibilities.  What's wrong with that, please?


Gilles

Good night,

Gilles


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

Reply via email to