Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Message-ID: <555CD535.80007@gmail.com>
Date: Wed, 20 May 2015 14:40:53 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: Ease of making release candidates (was: Javadocs in binary
 "release")
References: <555CBD0F.9000907@gmail.com>
 <CAL5zq9beK0p6KC+rjy74UgznOa_j1Ts7tHy1TMgTu7kMYny7Hw@mail.gmail.com>
In-Reply-To: 
 <CAL5zq9beK0p6KC+rjy74UgznOa_j1Ts7tHy1TMgTu7kMYny7Hw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I don't see automation and prerequisites as being mutually exclusive. 
Any sort of automation can still valid the necessary prereqs.

I understand that keeping as close to the normal `mvn release:prepare 
release:perform` is desirable. It's reasonable to hope that people know 
the inner workings of Maven, but I think it's a losing battle to push 
for that to be the norm. The automatic GPG caching is a nice inclusion 
in --create-release-candidate that lets me walk away from my terminal 
faster, but aside from that, it's just a wrapper to not force everyone 
to understand how Maven works. IMO, there's value in that.

Having a non-interactive command is very useful IMO. What does it assume 
now? You referring to the assumed-available gpg-agent? Whether it's a 
script or a Makefile is just details to me -- just changes how I invoke 
it, not what the net effect.

A big issue that bothered me for 1.7.0 is the lack of clarity in how the 
maven-release-plugin interacts with our branching strategy. We talked 
about this on IRC (which I tried to capture[1] in a recent addition). 
How can we improve the complete RC picture there?

The other half of me wanting to fork off this convo is that there's also 
more to making a release than just making the release candidate. I 
probably had 30+ commits to CMS over the past week (granted some of 
which were me just editing content on CMS), but we have a lot of steps 
which are now just copying files from the release, committing to the 
site repo. I'd love to see more done for automation here that can reduce 
the pain for the post-RC work.

[1] http://accumulo.apache.org/releasing.html#create-the-candidate

Christopher wrote:
> I agree with making it automated as much as possible. I'm just talking
> about how to kick off that automation.
> There are, after all, prerequisites, and we aren't going to be able to
> satisfy all of those.
>
> Part of the power that Maven offers when it is used to automate things
> like releases, is standardized, familiar tooling, which isn't
> project-specific. When a user realizes that all they have to do is run
> "mvn release:prepare release:perform" on *every* project they
> participate in, that's much better than a separate "make_rc.sh",
> "build.sh", etc. for each different project. When executing a maven
> command is how the automation is triggered (instead of a script which
> does little more than execute the maven command), I think developers
> benefit from gaining a bit of insight into what they are actually
> doing... without adding complexity.
>
> There are some things we can't really automate. And, as far as I'm
> concerned, our build.sh already makes some assumptions it shouldn't
> about a user running a gpg-agent. We could easily provide a contrib
> script which caches the gpg key in the gpg-agent, and offer that as a
> convenience. But if a user already has their key in a gpg-agent (like
> gnome-keyring-daemon), we shouldn't assume we have something to do.
>
> One compromise might be to leave the build.sh script in place, but
> make it more interactive, so we can prompt and inform, rather than
> assume. For the inform part, this would be similar to a Makefile,
> which displays what is executing as it executes (for that matter, we
> can actually use a Makefile rather than use build.sh).
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, May 20, 2015 at 12:57 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>> (forking to its own thread)
>>
>> Oh dear, and here I was about to recommend that we have an end2end script
>> that does _all_ of the updated things that I wrote down last night.
>>
>> For context, HBase has a make_rc.sh script that devs can use to make a
>> release candidate.
>>
>> https://github.com/apache/hbase/blob/master/dev-support/make_rc.sh
>>
>> We should be aiming for as much automation as possible. While I can
>> understand your desire for developers to actually understand what they're
>> doing, I think we need to focus on making as easy as possible. That will
>> help make sure _anyone_ can make a release, not just those who understand
>> all of the intricacies.
>>
>> Christopher wrote:
>>> One thing I was thinking: I'd prefer people not use build.sh script. I
>>> think it kind of discourages lack of understanding what's going on.
>>> And... it doesn't really automate things much. The most helpful thing
>>> it does is cache your gpg key in your gpg-agent. After that, it's a
>>> maven one-liner.
>>>
>>> What do you think about updating the releasing page to describe what
>>> build.sh does, rather than encourage its use?
>>>
>>> --
>>> Christopher L Tubbs II
>>> http://gravatar.com/ctubbsii
>>