Hi, It's not so trivial to draw a line what is a small change. E.g. one word change in documentation may be a big change for an application: "ODP maintains packet order during operation X" vs "... does not maintain order ..."
So, it's much simpler if all API changes go through the same branch, and that branch is released often. One of the largest motivation to change to github was to enable easy (and fast) release cycle, since all commits are always check automatically in Travis. So, there should be now less work to make a release. Tomorrow is the last Friday of the month and a perfect day for making a release (1.16) of everything that is ready in api-next... Maybe it's only couple of new APIs and some typo corrections, but it still makes the delta that much smaller. -Petri From: Maxim Uvarov [mailto:maxim.uva...@linaro.org] Sent: Thursday, October 26, 2017 10:30 AM To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com> Cc: Bill Fischofer <bill.fischo...@linaro.org>; Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>; lng-odp-forward <lng-odp@lists.linaro.org> Subject: Re: [lng-odp] API-next branch 1. we have api-next branch to collect all api changes with implementation in tests in one places. A lot of people said that it's useful. 2. Yes it's hard to find patches which are in api-next and not in master. 3. New API acceptance period is not very clean. If we can improve that than probably we will resolve merge issue. I.e. my proposal is - if feature is complete (api, impl, tests) and accepted (members can implement it) all patches for this feature should be moved to master branch. No need to wait for release date. From other point there is no need for small api changes (like debug prints, pktio capabilities, small improvements) stage in api-next. They can go directly to master. The other deal is complex things which need several months for review. This should go to staging branch api-next . To help with back port we can use github issues. Where one entry will be one feature. And place in the comments all commit id's related to this feature. It's also possible to do some automation for that. How about that? Maxim. On 26 October 2017 at 09:57, Savolainen, Petri (Nokia - FI/Espoo) <mailto:petri.savolai...@nokia.com> 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. 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). 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:mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Bill > Fischofer > Sent: Wednesday, October 25, 2017 6:53 PM > To: Dmitry Eremin-Solenikov <mailto:dmitry.ereminsoleni...@linaro.org> > Cc: lng-odp-forward <mailto: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 < > mailto: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 > >
