+1, Ben M's 2nd comment below echoes my own. I would just do both. Let contributions and time decide; rather than just picking one.
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: Thursday, June 13, 2013 12:29 PM To: "[email protected]" <[email protected]> Subject: Re: [DISCUSS] Release process on wiki >+1 for the repo, although we must have an easy way for users to view the >markdown in the browser. > >One thing that does bother me is the increased barrier to entry for any >non-committers to modify the docs, they need to know how to check out the >git repository, send a review, etc. > > >On Thu, Jun 13, 2013 at 12:05 PM, Vinod Kone <[email protected]> wrote: > >> +1 for everything in the repo. >> >> >> On Thu, Jun 13, 2013 at 11:35 AM, Andy Konwinski >><[email protected] >> >wrote: >> >> > Thanks Chris. >> > >> > I just cleaned up that wiki home page a little bit more too. As I >> mentioned >> > in the release process discussion thread before we forked this >> discussion, >> > I'm skeptical about the value of using the wiki instead of just >>keeping >> > anything that might go on the wiki in the docs folder with the rest of >> the >> > docs. >> > >> > My opinion is based on our past experience as a project community with >> > wikis. In the history of the Mesos project, we had a wiki and it got >>very >> > stale so we decided to just migrate to keeping things in the docs dir >>(so >> > it would be version controlled too). >> > >> > Do others have opinions about this? >> > >> > >> > On Wed, Jun 12, 2013 at 7:22 PM, Mattmann, Chris A (398J) < >> > [email protected]> wrote: >> > >> > > Guys, I created the page here: >> > > >> > > https://cwiki.apache.org/confluence/display/MESOS/Release+Process >> > > >> > > >> > > We should probably work to make it look more like the OODT one here: >> > > >> > > https://cwiki.apache.org/confluence/display/OODT/Release+Process >> > > >> > > >> > > In terms of level of detail. >> > > >> > > Thanks! >> > > >> > > 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: <Mattmann>, jpluser <[email protected]> >> > > Date: Wednesday, June 12, 2013 5:53 PM >> > > To: "[email protected]" >><[email protected]> >> > > Subject: [DISCUSS] Release process on wiki >> > > >> > > >+1, Ben H note subject line change. >> > > > >> > > >I'm waiting for INFRA to resolve: >> > > > >> > > >https://issues.apache.org/jira/browse/INFRA-6348 >> > > > >> > > > >> > > >So I can just add the release process per below as I understand it >> > > >and we can document it there. >> > > > >> > > >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 Hindman <[email protected]> >> > > >Reply-To: "[email protected]" >> > > ><[email protected]> >> > > >Date: Wednesday, June 12, 2013 4:22 PM >> > > >To: mesos <[email protected]> >> > > >Subject: Re: [DISCUSS] Release process >> > > > >> > > >>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? >> > > >>> > > >> >> > > >>> > > >> >> > > >>> > > >> > > >>> > > >> > > >>> > >> > > >>> >> > > > >> > > >> > > >> > >>
