Re: [DISCUSS] Lucene/Solr release management

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 cal

Re: [DISCUSS] Lucene/Solr release management

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 b

Re: [DISCUSS] Lucene/Solr release management

: This ASF release policy says that remote release building is problematic : - read the full text for nuance though: : Strange. i thought the policy of only building RCs on committer controlled hardware was regarding to 3rd

Re: [DISCUSS] Lucene/Solr release management

> On Jun 1, 2016, at 6:21 PM, Chris Hostetter 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 scr

Re: [DISCUSS] Lucene/Solr release management

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

Re: [DISCUSS] Lucene/Solr release management

: 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

Re: [DISCUSS] Lucene/Solr release management

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 w

Re: [DISCUSS] Lucene/Solr release management

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

Re: [DISCUSS] Lucene/Solr release management

> On May 31, 2016, at 9:29 PM, Chris Hostetter 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 HERE > that

Re: [DISCUSS] Lucene/Solr release management

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

Re: [DISCUSS] Lucene/Solr release management

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

Re: [DISCUSS] Lucene/Solr release management

+1 Google sheets is good for a start. Thanks Steve! On Sat, May 28, 2016 at 8:21 PM, Steve Rowe 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’v

Re: [DISCUSS] Lucene/Solr release management

+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 wrote: > Now that the 6.0.1 release is out the door, I'm thinking of ways to > improve/simplify the release process. > > After m

[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