On 10/26/17 12:32, Savolainen, Petri (Nokia - FI/Espoo) wrote: > 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. >
I pushed master to next. So we can stage ready patches there. If somebody wants to help, please send pool requests. Maxim. > -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 >>> >
