You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Steve Rowe <sa...@gmail.com> on 2016/05/28 14:51:00 UTC
[DISCUSS] Lucene/Solr release management
Now that the 6.0.1 release is out the door, I'm thinking of ways to improve/simplify the release process.
After many incremental automation improvements (thanks to all past RMs who’ve worked on them!), the process is still lengthy, cumbersome, and error prone.
The documentation <http://wiki.apache.org/lucene-java/ReleaseTodo> attempts to balance completeness with brevity, and fails in both directions, i.e. it's a (hopefully useful) compromise.
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).
Does this sound to other past RMs like it would help?
If so, does anybody know of an existing solution that would work? Or of other projects that attempt something similar?
I was thinking a spreadsheet would come pretty close, but not everybody uses the same spreadsheet software, so sharing/maintenance would be a problem. But maybe Google’s spreadsheet software (Sheets) would work?
--
Steve
www.lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1 to do something here! Google's Sheets seems like a good way to start?
Mike McCandless
http://blog.mikemccandless.com
On Sat, May 28, 2016 at 10:51 AM, Steve Rowe <sa...@gmail.com> wrote:
> Now that the 6.0.1 release is out the door, I'm thinking of ways to
> improve/simplify the release process.
>
> After many incremental automation improvements (thanks to all past RMs
> who’ve worked on them!), the process is still lengthy, cumbersome, and
> error prone.
>
> The documentation <http://wiki.apache.org/lucene-java/ReleaseTodo>
> attempts to balance completeness with brevity, and fails in both
> directions, i.e. it's a (hopefully useful) compromise.
>
> 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).
>
> Does this sound to other past RMs like it would help?
>
> If so, does anybody know of an existing solution that would work? Or of
> other projects that attempt something similar?
>
> I was thinking a spreadsheet would come pretty close, but not everybody
> uses the same spreadsheet software, so sharing/maintenance would be a
> problem. But maybe Google’s spreadsheet software (Sheets) would work?
>
> --
> Steve
> www.lucidworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [DISCUSS] Lucene/Solr release management
Posted by Anshum Gupta <an...@anshumgupta.net>.
bq. "are you doing a major/minor/bugfix release?"
That is easy to guess by just looking at the version #. 7.0 = major, 6.1 =
minor, 6.0.2 = bug fix
It might be an overkill to think at this point but it was non-trivial to do
a 5x release after 6.0 was out. There was a bunch of things there that were
judgement calls e.g. should we update the home page news on the website.
Should the latest version change to 5x after the 6x release, etc.
P.S: We can choose to ignore handling this i.e. doing a 5x release when 6.0
is already out or 6x when 7.0 comes out. At least for now.
On Wed, Jun 1, 2016 at 11:19 AM, Upayavira <uv...@odoko.co.uk> wrote:
> My thoughts (from someone not prepared at the mo to do the work) -
>
> How about creating a wizard? Asks you questions, "are you doing a
> major/minor/bugfix release?", "What is the version number?" and have it
> respond with commands that you must execute in a different window?
>
> It seems to me that a lot of the confusion in the documentation is about
> deciding which branch of the docs you should be following at any one
> time, so the above could reduce that particular bit of complexity.
>
> Upayavira
>
> On Wed, 1 Jun 2016, at 07:11 PM, Steve Rowe wrote:
> >
> > > On May 31, 2016, at 9:29 PM, Chris Hostetter <ho...@fucit.org>
> wrote:
> > >
> > > 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.
> >
> > The main thing I was hoping to achieve was not requiring RMs to figure
> > how to substitute the right stuff into the example commands themselves,
> > but rather have some software do it for them. The other stuff would be
> > nice too, but are of lesser importance IMHO. (In-situ notes would be
> > helpful for remembering what needs fixing; and a checklist would be
> > helpful for the interrupted RM: on some releases, some steps never got
> > completed.)
> >
> > I agree that copy/pasting from a display format into the command line is
> > not all that helpful, but that’s already the current situation.
> >
> > > 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.
> >
> > +1 to increase automation.
> >
> > Many of the current manual tasks are individually fairly simple, so
> > scripting them (individually anyway) has seemed in the past to me like
> > overkill.
> >
> > I’m not sure we want Jenkins to do this stuff.
> >
> > > 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.
> >
> > +1 to this step. This is better than a spreadsheet (or similar)
> > generating them, because inspection is still possible prior to running,
> > and running is simpler (type in the script name vs. copy/paste a bunch of
> > commands).
> >
> > > 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.
> >
> > +1. Some notes:
> >
> > 1. I think if used this will become the de facto source of RM
> > documentation, so it will have to be able to do a full listing of all
> > steps, maybe also the steps that *aren’t* included too for the given
> > release type, so that the RM can see/verify the full context.
> >
> > 2. The JSON file shouldn’t be stored in the source tree; several steps
> > look for/assure clean checkouts. Maybe a configurable location with a
> > default uner /tmp/releases/X.Y.Z/ (already used by at least one release
> > script now).
> >
> > 3. Some things can be safely done out of order, while others have
> > prerequisites. Maybe the script could somehow make these dependencies
> > visible? Skipping and out of order completion (and progress for some
> > manual multi-step things) should be supported as well.
> >
> > --
> > Steve
> > www.lucidworks.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anshum Gupta
Re: [DISCUSS] Lucene/Solr release management
Posted by Upayavira <uv...@odoko.co.uk>.
My thoughts (from someone not prepared at the mo to do the work) -
How about creating a wizard? Asks you questions, "are you doing a
major/minor/bugfix release?", "What is the version number?" and have it
respond with commands that you must execute in a different window?
It seems to me that a lot of the confusion in the documentation is about
deciding which branch of the docs you should be following at any one
time, so the above could reduce that particular bit of complexity.
Upayavira
On Wed, 1 Jun 2016, at 07:11 PM, Steve Rowe wrote:
>
> > On May 31, 2016, at 9:29 PM, Chris Hostetter <ho...@fucit.org> wrote:
> >
> > 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.
>
> The main thing I was hoping to achieve was not requiring RMs to figure
> how to substitute the right stuff into the example commands themselves,
> but rather have some software do it for them. The other stuff would be
> nice too, but are of lesser importance IMHO. (In-situ notes would be
> helpful for remembering what needs fixing; and a checklist would be
> helpful for the interrupted RM: on some releases, some steps never got
> completed.)
>
> I agree that copy/pasting from a display format into the command line is
> not all that helpful, but that’s already the current situation.
>
> > 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.
>
> +1 to increase automation.
>
> Many of the current manual tasks are individually fairly simple, so
> scripting them (individually anyway) has seemed in the past to me like
> overkill.
>
> I’m not sure we want Jenkins to do this stuff.
>
> > 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.
>
> +1 to this step. This is better than a spreadsheet (or similar)
> generating them, because inspection is still possible prior to running,
> and running is simpler (type in the script name vs. copy/paste a bunch of
> commands).
>
> > 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.
>
> +1. Some notes:
>
> 1. I think if used this will become the de facto source of RM
> documentation, so it will have to be able to do a full listing of all
> steps, maybe also the steps that *aren’t* included too for the given
> release type, so that the RM can see/verify the full context.
>
> 2. The JSON file shouldn’t be stored in the source tree; several steps
> look for/assure clean checkouts. Maybe a configurable location with a
> default uner /tmp/releases/X.Y.Z/ (already used by at least one release
> script now).
>
> 3. Some things can be safely done out of order, while others have
> prerequisites. Maybe the script could somehow make these dependencies
> visible? Skipping and out of order completion (and progress for some
> manual multi-step things) should be supported as well.
>
> --
> Steve
> www.lucidworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Chris Hostetter <ho...@fucit.org>.
: This ASF release policy says that remote release building is problematic
: - read the full text for nuance though:
: <http://www.apache.org/dev/release.html#owned-controlled-hardware>
Strange.
i thought the policy of only building RCs on committer controlled hardware
was regarding to 3rd party hardware (like building on EC2) -- i thought
building on ASF hardware has always been allowed. (I know once upon a time
people would compile builds for some projects on people.apache.org)
FWIW: Hadoop Core evidently uses a Jenkins job like i described to build
their RCs -- that's where i got the idea in the first place...
https://wiki.apache.org/hadoop/HowToRelease
https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder/
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Steve Rowe <sa...@gmail.com>.
> On Jun 1, 2016, at 6:21 PM, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> : I’m not sure we want Jenkins to do this stuff.
>
> FWIW: some of the reasons i've argued in the past that having (ASF)
> jenkins execute as much as possible as a script, rather then just
> requiring the RM to run the exact same scripts locally, was to help reduce
> the amount of data the RM had to transfer over the wire between their
> local machine and the internet.
>
> For example...
>
> If there was a parameterized jenkins job to "build an RC" give na branch +
> sha, that automatically committed the artifacts to the dist repo w/o any
> *.asc files, then the RM would have to download the artifacts from each RC
> (just like any other tester) but the only thing the RM would have to
> "upload" is the *.asc files they generated once they artifacts have been
> vetted.
This ASF release policy says that remote release building is problematic - read the full text for nuance though: <http://www.apache.org/dev/release.html#owned-controlled-hardware>
--
Steve
www.lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Chris Hostetter <ho...@fucit.org>.
: I\u2019m not sure we want Jenkins to do this stuff.
FWIW: some of the reasons i've argued in the past that having (ASF)
jenkins execute as much as possible as a script, rather then just
requiring the RM to run the exact same scripts locally, was to help reduce
the amount of data the RM had to transfer over the wire between their
local machine and the internet.
For example...
If there was a parameterized jenkins job to "build an RC" give na branch +
sha, that automatically committed the artifacts to the dist repo w/o any
*.asc files, then the RM would have to download the artifacts from each RC
(just like any other tester) but the only thing the RM would have to
"upload" is the *.asc files they generated once they artifacts have been
vetted.
Likewise things like publishing the javadocs (or pushing jars to maven
central) could be jenkins jobs that would (fail if *.asc files weren't
found & validated then) simply copy from ASF hardware (jenkins) to ASF
hardware (svn website repo) -- no need to worry about bandwidth limiations
between the RM and the outside world.
...but i'm happy to drop that idea for now, and just focus on better
"documenting" the process via "scripts that tell you exact commands to
exec" for now ... gotta walk before we can run.
-Hoss
http://www.lucidworks.com/
Re: [DISCUSS] Lucene/Solr release management
Posted by Steve Rowe <sa...@gmail.com>.
So I changed my mind: I think calling the script manageRelease.py was premature, since it only did the one thing, so I’ve renamed it to releasedJirasRegex.py and cleaned it up a bit.
If we decide to go the central script route, we can add manageRelease.py then. That script will likely just call out to other (standalone) scripts; it probably won’t hold any task implementations.
--
Steve
www.lucidworks.com
> On Jun 24, 2016, at 7:56 PM, Steve Rowe <sa...@gmail.com> wrote:
>
> I think rather than have a bunch of scripts, one per task, we could have a single one that takes commands and does stuff based on the command.
>
> In this spirit, I’ve created dev-tools/scripts/manageRelease.py, which only does one thing right now: makes regexes for all JIRAs included in a release by parsing the CHANGES.txt files. (This is to simplify the task of figuring out which JIRAs in a release are duplicated in CHANGES.txt under previously unreleased versions - with a regex, you can do a search/match-all in a regex-aware editor and very quickly find matching JIRAs under other releases.) The script will need work to accept commands to do other things, though: I didn’t put anything in place to do the command-switching thing.
>
> If we don’t want to go this way, we can rename manageRelease.py to releasedJiraRegexes.py or something.
>
> --
> Steve
> www.lucidworks.com
>
>> On Jun 1, 2016, at 2:36 PM, Chris Hostetter <ho...@fucit.org> wrote:
>>
>>
>> : 1. I think if used this will become the de facto source of RM
>> : documentation, so it will have to be able to do a full listing of all
>> : steps, maybe also the steps that *aren’t* included too for the given
>> : release type, so that the RM can see/verify the full context.
>>
>> wouldn't that just be a matter of reading the "original" JSON that's
>> commited into dev-tools (ie: not hte copy currently being worked through)
>>
>> : 2. The JSON file shouldn’t be stored in the source tree; several steps
>> : look for/assure clean checkouts. Maybe a configurable location with a
>> : default uner /tmp/releases/X.Y.Z/ (already used by at least one release
>> : script now).
>>
>> ok, sure ... i was suggesting it could be explicitly .gitignored, but i'm
>> not hung up on the details.
>>
>> : 3. Some things can be safely done out of order, while others have
>> : prerequisites. Maybe the script could somehow make these dependencies
>> : visible? Skipping and out of order completion (and progress for some
>> : manual multi-step things) should be supported as well.
>>
>> sure ... again: these seem like minor details to the boarder goal of
>> "script everything, including the checklist"
>>
>> If this is a goal folks think make sense, then frankly scripting the
>> checklist itself seems like it should be something we worry about waaaay
>> down the road.
>>
>> Starting with "add more scripts that echo the exact commands to
>> copy/paste based on the version# + RC# of the release" seems like where
>> the first big wins could come from...
>>
>> Examples:
>>
>> updateVersionNumbersOnAllAffectedBranches.py 6.2.0 ~/lucene/my-checkout
>> 1. looks at the list of branches/tags in ~/lucene/my-checkout
>> 2. echos the exact list of "git co", "addVersion.py",
>> and "git commit" commands you should run based on 6.2.0 being
>> a minor release
>> 3. warns you if any expected backcompat indexes are missing on
>> any branches
>> 4. echos the "git push origin ..." command listing all affected
>> branches
>> 5. if you run it again, after running some of the commands,
>> only echos the commands that are still needed
>>
>> tagAndPublish.py lucene-solr-6.2.0-RC2 DEADBEEF
>> 1. echos the exact tag command to run
>> 2. echos the exact svm mv && svn rm commands for the dist repo
>> - including rm'ing RC0 and RC1 if they still exist
>> 3. echos the exact ant commands to publish to maven
>> 4. echos the instructions/url to close & release on maven central
>> 5. echos the "git push origin ..." command for the tag
>> 6. if you run it again, after running some of the commands,
>> checks that the tag matches DEADBEEF, and only echos the commands
>> that are still needed
>>
>> etc...
>>
>>
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Steve Rowe <sa...@gmail.com>.
I think rather than have a bunch of scripts, one per task, we could have a single one that takes commands and does stuff based on the command.
In this spirit, I’ve created dev-tools/scripts/manageRelease.py, which only does one thing right now: makes regexes for all JIRAs included in a release by parsing the CHANGES.txt files. (This is to simplify the task of figuring out which JIRAs in a release are duplicated in CHANGES.txt under previously unreleased versions - with a regex, you can do a search/match-all in a regex-aware editor and very quickly find matching JIRAs under other releases.) The script will need work to accept commands to do other things, though: I didn’t put anything in place to do the command-switching thing.
If we don’t want to go this way, we can rename manageRelease.py to releasedJiraRegexes.py or something.
--
Steve
www.lucidworks.com
> On Jun 1, 2016, at 2:36 PM, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> : 1. I think if used this will become the de facto source of RM
> : documentation, so it will have to be able to do a full listing of all
> : steps, maybe also the steps that *aren’t* included too for the given
> : release type, so that the RM can see/verify the full context.
>
> wouldn't that just be a matter of reading the "original" JSON that's
> commited into dev-tools (ie: not hte copy currently being worked through)
>
> : 2. The JSON file shouldn’t be stored in the source tree; several steps
> : look for/assure clean checkouts. Maybe a configurable location with a
> : default uner /tmp/releases/X.Y.Z/ (already used by at least one release
> : script now).
>
> ok, sure ... i was suggesting it could be explicitly .gitignored, but i'm
> not hung up on the details.
>
> : 3. Some things can be safely done out of order, while others have
> : prerequisites. Maybe the script could somehow make these dependencies
> : visible? Skipping and out of order completion (and progress for some
> : manual multi-step things) should be supported as well.
>
> sure ... again: these seem like minor details to the boarder goal of
> "script everything, including the checklist"
>
> If this is a goal folks think make sense, then frankly scripting the
> checklist itself seems like it should be something we worry about waaaay
> down the road.
>
> Starting with "add more scripts that echo the exact commands to
> copy/paste based on the version# + RC# of the release" seems like where
> the first big wins could come from...
>
> Examples:
>
> updateVersionNumbersOnAllAffectedBranches.py 6.2.0 ~/lucene/my-checkout
> 1. looks at the list of branches/tags in ~/lucene/my-checkout
> 2. echos the exact list of "git co", "addVersion.py",
> and "git commit" commands you should run based on 6.2.0 being
> a minor release
> 3. warns you if any expected backcompat indexes are missing on
> any branches
> 4. echos the "git push origin ..." command listing all affected
> branches
> 5. if you run it again, after running some of the commands,
> only echos the commands that are still needed
>
> tagAndPublish.py lucene-solr-6.2.0-RC2 DEADBEEF
> 1. echos the exact tag command to run
> 2. echos the exact svm mv && svn rm commands for the dist repo
> - including rm'ing RC0 and RC1 if they still exist
> 3. echos the exact ant commands to publish to maven
> 4. echos the instructions/url to close & release on maven central
> 5. echos the "git push origin ..." command for the tag
> 6. if you run it again, after running some of the commands,
> checks that the tag matches DEADBEEF, and only echos the commands
> that are still needed
>
> etc...
>
>
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Chris Hostetter <ho...@fucit.org>.
: 1. I think if used this will become the de facto source of RM
: documentation, so it will have to be able to do a full listing of all
: steps, maybe also the steps that *aren\u2019t* included too for the given
: release type, so that the RM can see/verify the full context.
wouldn't that just be a matter of reading the "original" JSON that's
commited into dev-tools (ie: not hte copy currently being worked through)
: 2. The JSON file shouldn\u2019t be stored in the source tree; several steps
: look for/assure clean checkouts. Maybe a configurable location with a
: default uner /tmp/releases/X.Y.Z/ (already used by at least one release
: script now).
ok, sure ... i was suggesting it could be explicitly .gitignored, but i'm
not hung up on the details.
: 3. Some things can be safely done out of order, while others have
: prerequisites. Maybe the script could somehow make these dependencies
: visible? Skipping and out of order completion (and progress for some
: manual multi-step things) should be supported as well.
sure ... again: these seem like minor details to the boarder goal of
"script everything, including the checklist"
If this is a goal folks think make sense, then frankly scripting the
checklist itself seems like it should be something we worry about waaaay
down the road.
Starting with "add more scripts that echo the exact commands to
copy/paste based on the version# + RC# of the release" seems like where
the first big wins could come from...
Examples:
updateVersionNumbersOnAllAffectedBranches.py 6.2.0 ~/lucene/my-checkout
1. looks at the list of branches/tags in ~/lucene/my-checkout
2. echos the exact list of "git co", "addVersion.py",
and "git commit" commands you should run based on 6.2.0 being
a minor release
3. warns you if any expected backcompat indexes are missing on
any branches
4. echos the "git push origin ..." command listing all affected
branches
5. if you run it again, after running some of the commands,
only echos the commands that are still needed
tagAndPublish.py lucene-solr-6.2.0-RC2 DEADBEEF
1. echos the exact tag command to run
2. echos the exact svm mv && svn rm commands for the dist repo
- including rm'ing RC0 and RC1 if they still exist
3. echos the exact ant commands to publish to maven
4. echos the instructions/url to close & release on maven central
5. echos the "git push origin ..." command for the tag
6. if you run it again, after running some of the commands,
checks that the tag matches DEADBEEF, and only echos the commands
that are still needed
etc...
-Hoss
http://www.lucidworks.com/
Re: [DISCUSS] Lucene/Solr release management
Posted by Steve Rowe <sa...@gmail.com>.
> On May 31, 2016, at 9:29 PM, Chris Hostetter <ho...@fucit.org> wrote:
>
> 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.
The main thing I was hoping to achieve was not requiring RMs to figure how to substitute the right stuff into the example commands themselves, but rather have some software do it for them. The other stuff would be nice too, but are of lesser importance IMHO. (In-situ notes would be helpful for remembering what needs fixing; and a checklist would be helpful for the interrupted RM: on some releases, some steps never got completed.)
I agree that copy/pasting from a display format into the command line is not all that helpful, but that’s already the current situation.
> 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.
+1 to increase automation.
Many of the current manual tasks are individually fairly simple, so scripting them (individually anyway) has seemed in the past to me like overkill.
I’m not sure we want Jenkins to do this stuff.
> 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.
+1 to this step. This is better than a spreadsheet (or similar) generating them, because inspection is still possible prior to running, and running is simpler (type in the script name vs. copy/paste a bunch of commands).
> 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.
+1. Some notes:
1. I think if used this will become the de facto source of RM documentation, so it will have to be able to do a full listing of all steps, maybe also the steps that *aren’t* included too for the given release type, so that the RM can see/verify the full context.
2. The JSON file shouldn’t be stored in the source tree; several steps look for/assure clean checkouts. Maybe a configurable location with a default uner /tmp/releases/X.Y.Z/ (already used by at least one release script now).
3. Some things can be safely done out of order, while others have prerequisites. Maybe the script could somehow make these dependencies visible? Skipping and out of order completion (and progress for some manual multi-step things) should be supported as well.
--
Steve
www.lucidworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [DISCUSS] Lucene/Solr release management
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 \u201cnotebook\u201d? 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/
Re: [DISCUSS] Lucene/Solr release management
Posted by Anshum Gupta <an...@anshumgupta.net>.
Thanks for starting this Steve!
I think your intention here to create a parallel documentation is because
the current documentation is (or at least was) broken at multiple places
and unless someone knew where to look/fix, the path forward isn't obvious.
I'm +1 on that.
I really think we need more automation and if not complete automation, on
the lines of what Hoss suggested, have the release scripts spit out the
commands to be executed without the RM needing to remember all of it. The
RM should _ideally_ only be bothered about the release version and timing
of the release. Having a bunch of manual steps there doesn't really help
anyone. I agree that the script shouldn't automatically push stuff but a
local commit should work just fine.
In terms of documenting, I liked the idea that you and me discussed during
the 5.5.1 release about having the essentials in a doc (wiki or whatever)
but having details documented in the script itself.
On Sat, May 28, 2016 at 7:51 AM, Steve Rowe <sa...@gmail.com> wrote:
> Now that the 6.0.1 release is out the door, I'm thinking of ways to
> improve/simplify the release process.
>
> After many incremental automation improvements (thanks to all past RMs
> who’ve worked on them!), the process is still lengthy, cumbersome, and
> error prone.
>
> The documentation <http://wiki.apache.org/lucene-java/ReleaseTodo>
> attempts to balance completeness with brevity, and fails in both
> directions, i.e. it's a (hopefully useful) compromise.
>
> 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).
>
> Does this sound to other past RMs like it would help?
>
> If so, does anybody know of an existing solution that would work? Or of
> other projects that attempt something similar?
>
> I was thinking a spreadsheet would come pretty close, but not everybody
> uses the same spreadsheet software, so sharing/maintenance would be a
> problem. But maybe Google’s spreadsheet software (Sheets) would work?
>
> --
> Steve
> www.lucidworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anshum Gupta
Re: [DISCUSS] Lucene/Solr release management
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
+1
Google sheets is good for a start. Thanks Steve!
On Sat, May 28, 2016 at 8:21 PM, Steve Rowe <sa...@gmail.com> wrote:
> Now that the 6.0.1 release is out the door, I'm thinking of ways to
> improve/simplify the release process.
>
> After many incremental automation improvements (thanks to all past RMs
> who’ve worked on them!), the process is still lengthy, cumbersome, and
> error prone.
>
> The documentation <http://wiki.apache.org/lucene-java/ReleaseTodo>
> attempts to balance completeness with brevity, and fails in both
> directions, i.e. it's a (hopefully useful) compromise.
>
> 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).
>
> Does this sound to other past RMs like it would help?
>
> If so, does anybody know of an existing solution that would work? Or of
> other projects that attempt something similar?
>
> I was thinking a spreadsheet would come pretty close, but not everybody
> uses the same spreadsheet software, so sharing/maintenance would be a
> problem. But maybe Google’s spreadsheet software (Sheets) would work?
>
> --
> Steve
> www.lucidworks.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Regards,
Shalin Shekhar Mangar.