accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Ease of making release candidates (was: Javadocs in binary "release")
Date Wed, 20 May 2015 17:11:29 GMT
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
>
>

Mime
View raw message