Good catch on storm-903. I'll take a closer look.
-Taylor > On Aug 3, 2015, at 7:25 PM, 임정택 <[email protected]> wrote: > > Thanks all. > > I also think that it is really painful to backport something. That's why I > asked about what version lines we'll consider from other thread. > Seems like we're sure about releasing official version of 0.10.0 and > phasing out 0.9.x lines. > I'll backport bugfixes to only 0.10.x-branch and let you know when I > finished. > > Before start releasing 0.10.0, we may take a look at STORM-903 > <https://issues.apache.org/jira/browse/STORM-903>, which seems to be not > finished. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > > 2015-08-04 5:36 GMT+09:00 P. Taylor Goetz <[email protected]>: > >> Thanks for putting together this list Jungtaek. >> >> Back-porting is a pain, and the more the 0.9.x, 0.10.x and master lines >> diverge, the harder it gets. >> >> I propose we back-port the 4 fixes you identified for the 0.10 branch, and >> start discussing releasing 0.10.0 (final, not beta). >> >> Once 0.10.0 is out, I think we can start phasing out the 0.9.x line. The >> idea was to continue to support 0.9.x while 0.10.0 stabilized and allow >> early upgraders had a chance to kick the tires and report any glaring >> issues. IMO more than enough time has passed and we should move forward >> with a 0.10.0 release. >> >> In terms of the who and when of back porting, the general principle I’ve >> followed is that once a patch has been merged, it is a candidate for >> back-porting, and that any committer can do that since the patch had >> already been reviewed and accepted. I don’t think a separate pull request >> is necessary. In fact, I think extra pull requests for back-porting makes >> JIRA/Github issues a little messy and confusing. >> >> IMO the only time we need back-port pull requests is: >> >> a) A non-committer contributor is requesting a patch be applied to an >> earlier version. >> b) A committer back-ported a patch with a lot of conflicts, and feels it >> warrants further review before committing. Basically a way of saying “This >> merge was messy. Could others check my work?” >> >> If things go wrong at any time, there’s always “git revert”. >> >> I don’t think we need to codify any of this in our BYLAWS unless there is >> some sort of conflict, which for now there isn’t. If we feel the need to >> document the process I feel documenting it README/wiki entry should >> suffice. I’m more in favor of mutual trust among committers than hard and >> fast rules. Once a particular practice gets formalized in our bylaws, it >> can be very difficult to change. >> >> -Taylor >> >> >>> On Aug 3, 2015, at 12:56 PM, Derek Dagit <[email protected]> >> wrote: >>> >>> Dealing with branches is a pain, and it is good we are paying attention >> to >>> back-porting. It is good to bring it up for discussion, and I agree >> checking >>> with those who do releases is a reasonable thing to do. >>> >>> I do not think there are special restrictions on back-porting fixes to >> previous >>> branches. I would be comfortable with the normal rules for a pull >> request. >>> >>> Effort is one cost, and we could eventually run into some more >> challenging >>> merge conflicts as well. There are multiple things to consider, and I >> think it >>> is a judgment call. >>> >>> On the other hand, if it does become clear that clarifying principles >> helpful >>> in our BYLAWS, then I am all for it. If we commit to supporting specific >>> branches with certain kinds of fixes, then we need to stick to such a >>> commitment. >>> >>> -- >>> Derek >>> >>> >>> ----- Original Message ----- >>> From: Parth Brahmbhatt <[email protected]> >>> To: "[email protected]" <[email protected]> >>> Cc: >>> Sent: Monday, August 3, 2015 11:26 AM >>> Subject: Re: [DISCUSS] Backport bugfixes (to 0.10.x / 0.9.x) >>> >>> Given how huge 0.10 release was I feel trying to back port all bug fixes >>> and testing that it does not brake something else might turn out to be a >>> huge PITA. I think going with a stable 0.10 release might be the best >>> solution for now. >>> >>> I don’t think back porting requires confirmation however given we will >>> probably have to do release for each version where back porting was done >>> it is probably best to notify Release manager and discuss options. I >> agree >>> having a rule/bylaw would help clarify things for future. >>> >>> Thanks >>> Parth >>> >>> >>>> On 8/2/15, 4:30 PM, "임정택" <[email protected]> wrote: >>>> >>>> Bump. Does anyone have opinions about this? >>>> >>>> I already did back-port some bugfixes (not in list) into 0.10.x and >> 0.9.x >>>> lines, but I'm not 100% sure that it is preferred way. >>>> Seems like we don't have explicit rules about doing back-port. Only >> thing >>>> I >>>> know is Taylor was (or has been) a gatekeeper. >>>> >>>> Now I really want to know that it still need to be confirmed by Taylor >>>> before doing back-port. >>>> >>>> Thanks, >>>> Jungtaek Lim (HeartSaVioR) >>>> >>>> >>>> 2015-07-28 8:27 GMT+09:00 임정택 <[email protected]>: >>>> >>>>> Hi all, >>>>> >>>>> Recently I see many bugfixes are only merged to master, or >>>>> 0.10.x-branch. >>>>> >>>>> Since 0.10.0-beta1 introduces huge changeset, and it contains a lot of >>>>> bugfixes, I think we can consider backporting them to 0.9.x-branch >>>>> before >>>>> releasing 0.9.6. >>>>> >>>>> I create a sheet and write down bugfix issues which could be >> backported, >>>>> and status of issue. (what versions it is applied, and what versions it >>>>> can >>>>> be applied) >>>>> >>>>> >>>>> >>>>> >> https://docs.google.com/spreadsheets/d/1KQrOlqk1hlE2oDmXFY34lJaY0PU7V5uxq >>>>> 9U1vfIhLq4/edit?usp=sharing >>>>> >>>>> Please let me know whenever you find missing spots or wrong contents. >>>>> >>>>> There seems to be other approach: >>>>> - release stable version of 0.10.0, and drop plan to release 0.9.6 so >>>>> that >>>>> let all users who want bugfix release move to 0.10.0 >>>>> >>>>> Since a lot of bugfix issues are waiting for backporting, alternative >>>>> approach may be make sense. >>>>> >>>>> I'm open to hear any thoughts, so please share your opinions. >>>>> >>>>> Thanks, >>>>> Jungtaek Lim (HeartSaVioR) >>>>> >>>>> to. Taylor >>>>> I don't know I can do backport without your confirmation. (by each >>>>> issue) >>>>> If you want to decide about backporting yourself, I'll follow you. >>>>> >>>> >>>> >>>> >>>> -- >>>> Name : 임 정택 >>>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net >>>> Twitter : http://twitter.com/heartsavior >>>> LinkedIn : http://www.linkedin.com/in/heartsavior >> >> > > > -- > Name : 임 정택 > Blog : http://www.heartsavior.net / http://dev.heartsavior.net > Twitter : http://twitter.com/heartsavior > LinkedIn : http://www.linkedin.com/in/heartsavior
