Hey Ben M., Thanks. My philosophy is that it's great to see a "Roadmap" report on JIRA which really shows what is coming up when. Also setting Fix Version initially indicates your "intended" but not "required" version where the fix will show up in (and makes generating .txt file CHANGELOG files a snap).
So, I would say set it when the issue is created, and then if it changes and isn't cherry picked for that same version (and comes earlier or later) that's fine too. It's better to have some value. Fix version = what version you intend for the fix to be in. Affects version = the *released* version of the software where this bug/update/etc. applies to. HTH! 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, May 9, 2013 11:13 AM To: "[email protected]" <[email protected]> Subject: Re: [jira] [Updated] (MESOS-422) Master leader election should be more robust to stale ephemeral nodes >Great, should we only set 'Fix Version' when a fix is ready? There's also >'Affects Version' as well. > > >On Thu, May 9, 2013 at 10:44 AM, Mattmann, Chris A (398J) < >[email protected]> wrote: > >> Thanks Ben M. no worries. Anyones I see come by or while answering >>emails >> that don't >> have Fix Version I've been trying to guess what they are -- for things >> like this >> I'll set all to 0.13.0 then we can cherry pick to 0.12.0 ones that we >> want. I'll >> also continue working on pathology for 0.11.0. >> >> 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, May 9, 2013 7:30 AM >> To: "[email protected]" <[email protected]> >> Subject: Re: [jira] [Updated] (MESOS-422) Master leader election should >>be >> more robust to stale ephemeral nodes >> >> >Hey Chris, we have prepared 0.12.0 for release but it's in the backlog >> >until the VOTE passes for 0.11.0. So any unfixed issues like this won't >> >land until 0.13.0 at the earliest unless we cherry-pick them. I was >>going >> >to update these but JIRA is down. =/ >> > >> >On Wed, May 8, 2013 at 11:43 PM, Chris A. Mattmann (JIRA) >> ><[email protected]>wrote: >> > >> >> >> >> [ >> >> >> >> >> >>https://issues.apache.org/jira/browse/MESOS-422?page=com.atlassian.jira.p >> >>lugin.system.issuetabpanels:all-tabpanel] >> >> >> >> Chris A. Mattmann updated MESOS-422: >> >> ------------------------------------ >> >> >> >> Fix Version/s: 0.12.0 >> >> >> >> - guess fix version >> >> >> >> > Master leader election should be more robust to stale ephemeral >>nodes >> >> > >>--------------------------------------------------------------------- >> >> > >> >> > Key: MESOS-422 >> >> > URL: >>https://issues.apache.org/jira/browse/MESOS-422 >> >> > Project: Mesos >> >> > Issue Type: Bug >> >> > Components: master >> >> > Reporter: Bill Farner >> >> > Assignee: Benjamin Mahler >> >> > Priority: Minor >> >> > Fix For: 0.12.0 >> >> > >> >> > >> >> > When a leading master exits abruptly, it may fatefully restart and >> >>think >> >> it's the leader. If particularly unlucky, this could result in a >>set of >> >> masters that are indefinitely unstable. >> >> > Sequence of events: >> >> > - Master process becomes leader >> >> > - Master process exits, session expiration counter begins >> >> > - Master process restarts, reads leader node contents, and decides >> >>it's >> >> the leader (based on PID equality) >> >> > - Previous master session expires, node is deleted >> >> > - Master decides a different master is leader, commits suicide >> >> > - Rinse, repeat for newly-created master node >> >> > The salient fact here is that leaders should be concerned with >>"did i >> >> create the leader node" (ignoring node data) while clients want to be >> >> apprised of leader's node data. >> >> > Relevant code: >> >> > >> >> >> >> >> >>https://github.com/apache/mesos/blob/trunk/src/detector/detector.cpp#L548 >> >> > ZK leader election recipe, for reference: >> >> > >>http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection >> >> >> >> -- >> >> This message is automatically generated by JIRA. >> >> If you think it was sent incorrectly, please contact your JIRA >> >> administrators >> >> For more information on JIRA, see: >> >>http://www.atlassian.com/software/jira >> >> >> >>
