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