Re: [DISCUSS] Release policy update for handling feature branches
> On Apr 20, 2017, at 5:04 AM, Szymon Jancwrote: > > Hi, > > On Friday, 14 April 2017 21:07:04 CEST will sanfilippo wrote: >> I think you are correct about this. Someone needs to determine which pull >> requests against master need to get merged into the various branches. >>> On Apr 14, 2017, at 11:54 AM, aditi hilbert wrote: >>> >>> Hi all, >>> >>> It’s good to see our Release policy going into effect post 1.0 release. >>> The develop branch is gone and feature branches have emerged. Smaller >>> changes are being merged into the master branch which is now relatively >>> up to date. Most of the feature branches are going to be long-lived, so >>> wanted to discuss how to manage them efficiently. >>> >>> Typically, there is an “owner” for each feature branch who oversees the >>> merges into that branch and periodically updates it with changes from >>> master to keep it aligned with master and leverage recent changes. >>> Currently we have “bluetooth5” - so we would need an owner for that. I >>> can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on >>> separate feature branches. >>> >>> Please share your thoughts, concerns, suggestions. And do we have a >>> volunteer for owning the “bluetooth5” feature branch? :) >>> >>> thanks, >>> aditi > > I agree that there should be a dedicated person responsible for each of > feature branch. I can handle bluetooth5 branch for time being :-) > > As for how it should be done I'd see it that master is periodically merged > back into feature branch. The rule of thumb would be that feature branch > would > be always ready to be merged back into master without conflicts. > Agreed. > How does this sound? > Sounds great! Thank you for volunteering to keep the bluetooth5 branch up to date with master. aditi > -- > pozdrawiam > Szymon Janc
Re: [DISCUSS] Release policy update for handling feature branches
Hi, On Friday, 14 April 2017 21:07:04 CEST will sanfilippo wrote: > I think you are correct about this. Someone needs to determine which pull > requests against master need to get merged into the various branches. > > On Apr 14, 2017, at 11:54 AM, aditi hilbertwrote: > > > > Hi all, > > > > It’s good to see our Release policy going into effect post 1.0 release. > > The develop branch is gone and feature branches have emerged. Smaller > > changes are being merged into the master branch which is now relatively > > up to date. Most of the feature branches are going to be long-lived, so > > wanted to discuss how to manage them efficiently. > > > > Typically, there is an “owner” for each feature branch who oversees the > > merges into that branch and periodically updates it with changes from > > master to keep it aligned with master and leverage recent changes. > > Currently we have “bluetooth5” - so we would need an owner for that. I > > can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on > > separate feature branches. > > > > Please share your thoughts, concerns, suggestions. And do we have a > > volunteer for owning the “bluetooth5” feature branch? :) > > > > thanks, > > aditi I agree that there should be a dedicated person responsible for each of feature branch. I can handle bluetooth5 branch for time being :-) As for how it should be done I'd see it that master is periodically merged back into feature branch. The rule of thumb would be that feature branch would be always ready to be merged back into master without conflicts. How does this sound? -- pozdrawiam Szymon Janc
Re: [DISCUSS] Release policy update for handling feature branches
I think you are correct about this. Someone needs to determine which pull requests against master need to get merged into the various branches. > On Apr 14, 2017, at 11:54 AM, aditi hilbertwrote: > > Hi all, > > It’s good to see our Release policy going into effect post 1.0 release. The > develop branch is gone and feature branches have emerged. Smaller changes are > being merged into the master branch which is now relatively up to date. Most > of the feature branches are going to be long-lived, so wanted to discuss how > to manage them efficiently. > > Typically, there is an “owner” for each feature branch who oversees the > merges into that branch and periodically updates it with changes from master > to keep it aligned with master and leverage recent changes. Currently we have > “bluetooth5” - so we would need an owner for that. I can see other > connectivity stacks (e.g. LoRa, sub-GHz) being built on separate feature > branches. > > Please share your thoughts, concerns, suggestions. And do we have a volunteer > for owning the “bluetooth5” feature branch? :) > > thanks, > aditi > > > > > >