Grokbase Groups Lucene dev May 2016
FAQ
: 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/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 12 | next ›
Discussion Overview
groupdev @
categorieslucene
postedMay 28, '16 at 2:51p
activeJun 1, '16 at 11:38p
posts12
users6
websitelucene.apache.org

People

Translate

site design / logo © 2017 Grokbase