> On Apr 20, 2017, at 5:04 AM, Szymon Janc <[email protected]> wrote: > > 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 <[email protected]> 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
