Hey Ben, -----Original Message-----
From: Benjamin Mahler <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, June 13, 2013 7:32 PM To: "[email protected]" <[email protected]> Subject: Re: [DISCUSS] Release process on wiki >On Thu, Jun 13, 2013 at 7:29 PM, Mattmann, Chris A (398J) < >[email protected]> wrote: > >> Hey Andy, >> >> -----Original Message----- >> >> From: Andy Konwinski <[email protected]> >> Reply-To: "[email protected]" >><[email protected] >> > >> Date: Thursday, June 13, 2013 11:35 AM >> To: "[email protected]" <[email protected]> >> Subject: Re: [DISCUSS] Release process on wiki >> >> >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). >> >> The big problem with only having docs in the code is that contributors >> must become committers/PMC members in order to write docs, which isn't >> very scalable. >> > >Well to be clear, they can write docs as non-committers, but they cannot >commit them. Right? Yep totally right, you are correct. Anyone can write docs, but they aren't "Apache Mesos docs, produced by the PMC/committers". We can commit docs from contributors just like code; and in doing so we should consider VOTE'ing those peeps in. My point is that there is more of a barrier to committing doc patches/etc. in my experience than simply letting people edit a wiki. That said, editing the wiki doesn't work for everyone so we should just support both -- having the wiki isn't really hurting anyone and it may encourage some people (at least like me that like Confluence and are fine with wikis) to write some docs; capture stuff and contribute docs. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> I would just do both (we do it in Apache OODT). I've had the complete >> opposite >> experience btw. It has to do with release schedules/cycles. In Apache >> OODT, >> we released really fast for a long time (we released 22 different >>versions >> of Apache OODT File Manager before it came to Apache and when it was >> internal >> to JPL) -- but then slowed down a bit (now only release every 3-6 >>months). >> Because of this our website docs (which we keep in Maven XDoc) are quite >> stale. >> Our wiki on the other hand (Confluence) has our best docs; contributors >> can >> sign up for an account and start contributing (now that we have admin >>perms >> on the wiki it's easy to add people; infra not needed). >> >> So I think it just depends and shouldn't be either or, IMHO. >> >> Cheers, >> Chris >> >> >> > >> >Do others have opinions about this? >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 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 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> > >> > >> >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? >> >> >>> > > >> >> >> >>> > > >> >> >> >>> > > >> >> >>> > > >> >> >>> > >> >> >>> >> >> > >> >> >> >> >> >>
