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<[email protected]> 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
