On 26/10/17 09:57, Savolainen, Petri (Nokia - FI/Espoo) wrote: > We need one branch that holds all new API changes before those are released > (> 4 months currently): either it's master or api-next. If we change API > development to master, then applications would need follow the latest release > branch instead of master. At least previous there was resistance to change > master into API development branch.
Yes, I understand that. That is why I proposed to have api-next being regularly rebased on top of master. Doing that monthly (or after release) should be enough. This way we will see all pending patches easily. > Separate topic branches for API changes won't scale ... we would not have a > common view (e.g. for 4 months) what the API is before all those are merged > together. Implementation changes are easier in topic branches as there's less > dependency to other files and applications (other files and apps already > agree what the API is). Topic branches would would allow easier tracking of patches pending into master. So we will know that ``these branches were merged into api-next during this development cycle but were not merged into master, so we should consider them''. > Api-next does not cause the problem (big delta), it's caused by the lack of > steady release cycle. The big delta won't go away before we have a short > enough release cycle (merge often => small delta). > > -Petri > > > >> -----Original Message----- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill >> Fischofer >> Sent: Wednesday, October 25, 2017 6:53 PM >> To: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org> >> Subject: Re: [lng-odp] API-next branch >> >> I'm all for using topic branches, especially since we've switched to >> GitHub >> and most contributors are now familiar with it and using pull requests >> rather than raw patches sent to the mailing list. The whole reason for >> api-next was to separate in-progress API changes from regular maintenance >> patches since they were all mixed together on the mailing list. The PR >> structure is much cleaner in that regard. >> >> IPsec in particular clearly could have been a separate branch. We've >> talked >> about doing this in the context of 2.0 as well since that's also going to >> involve some major subsystems that could benefit from collaborative >> development before being merged back into the 2.0 main development branch. >> >> >> On Wed, Oct 25, 2017 at 10:39 AM, Dmitry Eremin-Solenikov < >> dmitry.ereminsoleni...@linaro.org> wrote: >> >>> Hello, >>> >>> I tried to actually check, which patches are sitting in the api-next. >>> And actually I failed >>> to do that in a timely manner. git cherry produces a list of patches, >>> that contains a lot of patches, which already landed to the master. >>> >>> Quick proposal would be to stop using api-next as a long-lived branch >>> which received updates from master and rather use it as a branch being >>> regularly rebased on top of current master. >>> >>> Another possiblity would be to abandon api-next completely, develop >>> features on topic branches, which get merged to master, rather than to >>> api-next. At least this would save us from situations, when there is >>> API definition (or change), but no actual implementation behind. >>> >>> -- >>> With best wishes >>> Dmitry >>> -- With best wishes Dmitry
