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