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
signature.asc
Description: Message signed with OpenPGP using GPGMail
