It might make sense to move the discussion around wiki stuff to a different thread, i.e., "[DISCUSS] wiki". I'd like to not pollute Vinod's request for comments re: deleting branches 0.12.x and 0.13.x.
On Wed, Jun 12, 2013 at 4:08 PM, Andy Konwinski <[email protected]>wrote: > On Wed, Jun 12, 2013 at 3:58 PM, Vinod Kone <[email protected]> wrote: > > > OK. Since we have decided to not have remote release branches, I'm going > to > > delete 0.12.x and 0.13.x branches from the repo by EOD. If anyone has > > objections, please let us know. > > > > > > On Thu, Jun 6, 2013 at 12:40 PM, Mattmann, Chris A (398J) < > > [email protected]> wrote: > > > > > BTW, kick ass that you brought it to list and discussed. Boom! > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Chris Mattmann, Ph.D. > > > Senior Computer Scientist > > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > > Office: 171-266B, Mailstop: 171-246 > > > Email: [email protected] > > > WWW: http://sunset.usc.edu/~mattmann/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Adjunct Assistant Professor, Computer Science Department > > > University of Southern California, Los Angeles, CA 90089 USA > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Benjamin Mahler <[email protected]> > > > Reply-To: "[email protected]" < > > [email protected] > > > > > > > Date: Wednesday, June 5, 2013 1:10 PM > > > To: "[email protected]" <[email protected]> > > > Cc: Benjamin Hindman <[email protected]>, Vinod Kone < > > [email protected]> > > > Subject: Re: [DISCUSS] Release process > > > > > > >Vinod, BenH and I chatted at length about our branching / tagging > > strategy > > > >for releases. So I'm taking it here for further discussion. > > > > > > > >We currently were using branches of the style 0.12.x to track the > > progress > > > >of the 0.12.x line of releases. This stemmed from the svn days of > mesos, > > > >and has several flaws: > > > > > > > >1. We sometimes need to amend history on that branch, either due to > > > >mistakes or due to #2 here. > > > >2. RC N is not necessarily fast-forward-able from RC N-1. > > > >3. Users sometimes use these branches (and we don't provide any > > guarantees > > > >on their validity currently). > > > > > > > >We are considering using a cleaner linux-style approach, where tags > are > > > >used for release candidates, and releases. For an example, see: > > > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/refs/tags > . > > > >Rather than having 0.12.x as a branch, we will have tags 0.12.0-rc1, > > > >0.12.0-rc2, 0.12.0, etc as we produce RCs and releases. > > > > > > > >The process would be as follows: > > > > > > > >1. Tag a candidate: 0.12.0-rc1. > > > >2. Call a VOTE to release RC1. > > > >3. If successful, release and tag 0.12.0 from 0.12.0-rc1. > > > >4. Otherwise, progress with 0.12.0-rc2 by creating a local branch off > of > > > >0.12.0-rc1 and applying the necessary commits. > > > > > > > >History can be seen using 'git log 0.12.0-rc1..0.12.0-rc2'. > > > > > > > >This means tags are immutable, and a source of truth for the RCs and > > > >releases. > > > > > > > >For now, I will be punting on removing the 0.12.x branch, and will > > simply > > > >create a 0.12.0-rc1 tag to call a VOTE with. But I'd like to gather > > > >thoughts, +1's or -1's. > > > > > > > >There's no documentation that I know of. So, yes documenting the > > checklist > > > >> is a great idea. > > > >> Also note, that we create branches of the form "0.12.x" instead of > > > >> "0.12.0". This makes it easy to cherry pick commits for future bug > fix > > > >> releases and release candidates. > > > >> Also, you might want to checkout the release.sh script (if there are > > > >>some > > > >> updates to it) from the master branch into 0.12.x. > > > > > > > > > > > > > > > >On Tue, Jun 4, 2013 at 7:50 PM, Mattmann, Chris A (398J) < > > > >[email protected]> wrote: > > > > > > > >> Looking good, Ben M! > > > >> > > > >> Thanks for throwing this up! I've prefixed the subject line > > > >> with a [DISCUSS] thread. Not a requirement by any means but > > > >> makes it nice when looking in mail-archives.apache.org and > > > >> other threaded browsers to see like minded discussion threads :) > > > >> > > > >> So, putting this up on a wiki would be great. > > > >> Looking at: > > > >> > > > >> http://incubator.apache.org/projects/mesos.html > > > >> > > > >> > > > >> We have a confluence wiki here: > > > >> > > > >> https://cwiki.apache.org/confluence/display/MESOS/Index > > > >> > > > >> > > > >> I don't have karma to edit it (need to remove the docs exist > > > >> at Github part). > > > I have karma to edit it (and was the one that requested it). I updated the > broken link. I believe it is still true that the easiest way for folks to > view the documentation is by using the html version that github > automatically convers from markdown to HTML for us at > https://github.com/apache/incubator-mesos/blob/trunk/docs/Home.md > > So I'm not sure we want to remove that link entirely. I'm actually in favor > of keeping all of the documentation in the docs folder the way it currently > is (we only recently migrated it off of the github.com/mesos/mesos wiki) > and just making a new file in that directory to document our release > process. In my experience, when a project actively tries to support a wiki > it just makes things more confusing. > > I agree that it is confusing to have it set up and not use it though, so I > propose that we consider killing the confluence wiki and saying on our > status page that we don't support a wiki. > > Andy > > > > I'm working with infra to get karma. Once I > > > >> get it we should add a release process page there that simply > > > >> copies the below :) > > > >> > > > >> Either way +1 to proceed with step #1. > > > >> > > > >> Cheers, > > > >> Chris > > > >> > > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > >> Chris Mattmann, Ph.D. > > > >> Senior Computer Scientist > > > >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > > >> Office: 171-266B, Mailstop: 171-246 > > > >> Email: [email protected] > > > >> WWW: http://sunset.usc.edu/~mattmann/ > > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > >> Adjunct Assistant Professor, Computer Science Department > > > >> University of Southern California, Los Angeles, CA 90089 USA > > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Benjamin Mahler <[email protected]> > > > >> Reply-To: "[email protected]" > > > >><[email protected] > > > >> > > > > >> Date: Tuesday, June 4, 2013 7:23 PM > > > >> To: Benjamin Hindman <[email protected]>, Vinod Kone > > > >><[email protected]> > > > >> Cc: "[email protected]" < > [email protected]> > > > >> Subject: Release process. > > > >> > > > >> >Now that 0.11.0 is out, we should continue freeing up the backlog > and > > > >> >proceed with 0.12.0. I'll be taking care of this release and I'd > like > > > >>to > > > >> >document the release process to make it easier for others to help > out > > > >>with > > > >> >releases in the future. Is there already documentation somewhere? > > > >>Here's > > > >> >what I've inferred: > > > >> > > > > >> >1. First I'll gather the JIRA tickets for the CHANGELOG. > > > >> > > > > >> >2. Send out a review / commit the CHANGELOG updates. > > > >> > > > > >> >3. Cherry pick the CHANGELOG onto 0.12.0. > > > >> > > > > >> >4. Run 'git checkout 0.12.0 && ./support/release.sh 0.12.0 1'. > > > >> > > > > >> >5. Mail [email protected] and > > > >> >[email protected] a VOTE. > > > >> > > > > >> >6. After a successful VOTE, add it to the website(s)? > > > >> > > > > >> >7. Upload the jar to artifactory, I see Vinod is having issues with > > > >>that > > > >> >at > > > >> >the moment. > > > >> > > > > >> >Missing anything? > > > >> > > > >> > > > > > > > > >
