: I was thinking of an alternative documentation/form/to-do list thingy : that could provide not just examples, but exact command lines to run. : Such a sort of filled-out template thing (is it a “notebook”? not sure : what to call it) could provide a running reminder of where the RM is in : the process (e.g. checkboxes for items), along with space for notes for : each item, and could be scriptable, to fill out command lines with RC : numbers and git commit hashes, and to select the appropriate task : branches (e.g. for major/minor/bugfix releases).
As someone who has gone out of my way to avoid doing a full release of lucene-solr for the precise reasons that it intimidated the fuck out of me, i'm the last person to criticise opinions on how to improve the process from folks who have actually gone through it themselves (and recently!) but changing where/how a big ass long list of manual steps is tracked doesn't really seem like very significant progress towards making life easier for the RMs. if keeping track of what's already been done (and making it easier to make notes on problematic bits as they happen) then it seems like just cloning the "ReleaseTodo" page before the release, and adding a big <h1>**** HERE ****</h1> that moves down the page as the RM steps through things, and <font color=RED>NOTE: ...</font> to things above the HERE marker that had problems ... then when the release is done, folks can discuss/edit the original ReleaseTodo page based on the red notes. If that sounds hackish to folks i would agree with them -- but it seems only slightly more hackish to me then tracking all of this in some other todo list tool, or a giant spreedsheet, and wouldn't require porting the existing docs into some other tool. My alternative straw man suggestion would be to make imcremental progress on simplifying the steps by writing small scripts to automated as many of the steps as possible, and merge those scripts when/where possible as we get more confident in them -- with the end goal being that ASF jenkins could run the whole thing with a few simple paramaterized jobs that are run on demand by RMs... the "create new major branch" job, the "create new minor branch" job, and the "create RC" job. I know i've suggested this before, and folks who have been RMs many times have told me it's a bad idea to trust automation for all of this -- but we should at least be able to automate *some* of it. Even if folks don't agree with the idea of letting scripts commit things or pushing RCs to the dist repo, there's still very little reason i can think of not to have scripts that *generate* & echo the exact commands based on the type of build so it's trivial for the RM to run them manually. (as a trivial example of this in practice, consider the publish-solr-ref-guide.sh and archive-solr-ref-guide.sh scripts in dev-tools. A ref guide RM doesn't have to remember the exact SVN commands based on the version # being released, or cut/paste the commands from a doc and edit them to use the correct version# and RC# -- the scripts take that info on the command line and generates the exact svn commands to run -- including any "svn rm" commands needed to clean up old RCs based on "svn list http:///..."; -- ready to copy/paste exactly as is) The fact that we're using git now, where having all branches "locally" on the RM's machine is the default beahvior, should make a lot of this really easy. Consider the "Update Version Numbers in the Source Code" section of the doc, with it's conditional logic about major releases, minor releases, bug fix releases, and the list branches that diff commands need run on in all of these cases. Couldn't we script this down to a "run-addversion-on-needed-branches.sh ~/my-lucene/checkout --next-release X.Y.Z" that looks at the passed in X.Y.Z version# and does all the neccessary "git co ...", "addVersion.py ...", and "git add ..." needed in ~/my-lucene/checkout bassed on the branches it finds? leaving the (local) working status of the ~/my-lucene/checkout repo ready for the user to review & test as they see fit, so all they have to do is "git push" to the ASF repo. (it could even end by echoing out the "git push origin master branch_6x ..." command the user should run with a list of every branch it touched) if having a "checklist" is something RMs think would really be helpful -- why not at least automate the creation / processing of the checklist as much as possible with some simple scripts? Imagine having a simple JSON file in our repo listing all the steps and some metadata about when/why they matter, along with a release-checklist.py script... release-checklist.py 6.1.0 RC0 - makes a copy of the checklist JSON in some file that is .gitignore'd - updates the JSON to note that we're working on 6.1.0, RC0 - deletes any stuff from the JSON that's only applicable for an X.0.0 - deletes any stuff that's only applicable when there are previous RCs release-checklist.py next - echo's out the next thing the RM should do - or, when possible, runs a script for the next step, which should echo out what it did and how to check/test the results - if the last item on the checklist isn't marked "done" do nothing, instead remind the RM what the last step was so they can check it (or re-run it manually if it was a script and they had to manually fix something) release-checklist.py done - update the JSON to note the last step is "done" ...maybe initially the JSON file is just a bunch of links to individual wiki pages/sub-section with info on what to run -- but gradually we can convert those into little helper scripts that are run with the $version and $rc_num passed in, so they can echo out the *exact* commands for the user w/o risk of typos, (and maybe eventually even exec some of those commands directly) Some of these steps could even update the JSON checklist with additional metadata for use by later steps -- ie: the step that runs "buildAndPushRelease.py" could record the current SHA on the branch being built, so that a later step which does the "git tag ..." (or echo's out hte "git tag..." command for the RM to run manually) could include that and save the RM from needing to to look it up and edit the command. -Hoss http://www.lucidworks.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
