Guys I have some thoughts for this coming soon hopefully tonight Sent from my iPhone
On Jun 13, 2013, at 1:22 PM, "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? >> >>
