The general idea was to address the issue of patch tracking during freezes. During general development, there are patches going in with different targets, including: * bug fixes which we want for any affected branch; * technical debt reduction; * new features.
The recommended approach in most cases is to push a patch to master, then cherry-pick it (with adaptations as necessary) to the target branches, and the target branch is determined by the release we want to get a fix into; most of the times that’s: * master only for the next GA; * stable/whatever for the next SR of whatever, or the next GA when master becomes stable. But the stable branch reduces its role during freezes (it doesn’t change its definition, which is still to receive patches for the next release), and during a freeze we end up with an extra target, SR+1, which doesn’t have a home. That was what the proposed extra branch was supposed to fix; and obviously it required discussion which is what is happening now. Master doesn’t have to be the wild west for it to become less than useful for SR+1: new features and technical debt reduction patches are typically patches which don’t belong in SR+1, but do belong in master, and can be added without breaking any gating jobs (and should be done thus). By not having an SR+1 branch, we force projects to use master for SR+1, limiting new feature development and refactoring efforts (and this is true whether we consider that to be good or bad), or to keep track of all the patches in master which are SR+1 candidates, with a lot of extra work picking stuff out again (which also increases the risk of missing fixes we want for SR+1). The idea was for this SR+1 branch to be short-lived; after the stable branch thaws, it would be rebased on top of it and become the stable branch. This would preserve tagging history in the main stream of commits too. Another way of looking at it, which is used in many projects, is that we cut a GA branch from the stable branch, and stabilise that — so the stable branch is always SR+1, and each specific release gets a specific stabilisation branch. Perhaps everyone had understood this already ;-). Regards, Stephen On Thu, 31 Jan 2019 12:15:27 +0200 Ariel Adam <aa...@redhat.com> wrote: > Based on my experience adding additional branches becomes a nightmare > to maintain overtime and we will eventually discover that patches are > missing from the different branches (and usually the patches that > mater to us :-). The topic of the master being a wild west should be > addressed with proper gating jobs and accountability of the community > to what they push in. > > My 2 cents. > > Thanks. > > > On Thu, Jan 31, 2019 at 11:00 AM <guillaume.lamb...@orange.com> wrote: > > > I agree with most Sam’s comments but I share Thanh’s feeling that > > having a separate branch for SR1,SR2,etc is a bad idea > > > > and that we’d better keep on using tag on the stable/release branch > > for that. > > > > I think a branch called testing/neon would make more sense than > > several stable/neon-srX. > > > > About CI available resources, that’s another topic but a good point. > > It would be a pity if we can’t improve the situation because we > > don’t have enough HW resources for that. > > > > Perhaps we need to start to rethink how it is done. I remember some > > discussion at the last DDF about that. > > > > > > > > BR > > > > Guillaume > > > > > > > > *From:* Thanh Ha [mailto:thanh...@linuxfoundation.org] > > *Sent:* jeudi 31 janvier 2019 00:33 > > *To:* Sam Hague > > *Cc:* LAMBERT Guillaume TGI/OLN; Stephen Kitt; > > t...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; > > discuss@lists.opendaylight.org *Subject:* Re: [OpenDaylight > > Discuss] [OpenDaylight TSC] Stable branches etc. > > > > > > > > On Wed, Jan 30, 2019 at 6:17 PM Sam Hague <sha...@redhat.com> wrote: > > > > On Wed, Jan 30, 2019 at 12:36 PM Thanh Ha > > <thanh...@linuxfoundation.org> wrote: > > > > How is the intermediate branch used in practice though? and what I > > mean is does all the patches on this branch then get moved over to > > the stable/branch when it is unlocked or does it run in parallel > > with the stable/branch? > > > > Yes, it would be another branch running in parallel just like > > stable/neon, maybe a stable-neon/sr1. What could work is those > > patches that go on the stable/neon would be immediately > > cherry-picked to the sr branch to reduce regressions. But it is up > > to the project how they cherry-pick patches since the sr1 branch > > would not be locked. > > > > > > > > Should be clear here than that this proposal goes directly against > > the other desire I've heard from the community to have git tags > > appear on the branch. By having release specific branches like > > neon-sr1 that means we definitely won't be able to have the release > > tag appear on the neon branch for example as we will have a further > > branch split with neon-sr1. > > > > > > > > This may not be a big deal since we currently don't have tags on > > branches but there's been a few threads discussing how to tweak the > > workflow to allow that which this proposal sounds like it will work > > against the other desire. > > > > > > > > Regards, > > > > Thanh > > > > > > > > What I'm concerned about is that it needs more jobs and becomes yet > > another branch we are actively maintaining. Using up more CI > > resources which we are actively trying to reduce. > > > > It could be short-lived, once stable/neon is released it is locked, > > stopped jobs and eventually removed and you only have the sr1 > > branch left. It is only during this code freeze to release that the > > stable branch would last since you have the sr1 branch at the same > > time which would be the longer living branch. > > > > > > > > Regards, > > > > Thanh > > > > > > > > On Wed, Jan 30, 2019 at 9:31 AM Sam Hague <sha...@redhat.com> wrote: > > > > On Wed, Jan 30, 2019 at 5:03 AM <guillaume.lamb...@orange.com> > > wrote: > > > > Hi Stephen > > > > I am sharing your feedback and thinks it would make a lot of sense. > > Many linux distros use something similar to deal with staging > > packages in their repo, e.g. Fedora with stable/branched/rawhide > > repos or Debian with stable/testing/unstable repos. > > With only one (master) branch, it is difficult for downstream > > projects to deal with both the new features to develop and needed > > migrations for the next release at the same time. > > An intermediate branch may allow a better synchronization with the > > upstream projects as long as ongoing evolution are made available > > through nexus. > > > > This is a good point and was a similar reason for needing a branch. > > This has hit us every release where the stable branch is pulled and > > master goes forward, but downstreams still want to continue > > working. They can't since the stable branch is locked and master > > becomes the wild west. Some of this could be alleviated with more > > reliable planning - getting code in earlier and tested - but that > > is hard with limited resources. An intermediate branch would > > provide a place to keep working to finish things and make it into > > the sr1 and not try to cram something in at the last minute on the > > stable branch. > > > > > > Best Regards > > Guillaume > > > > -----Original Message----- > > From: tsc-boun...@lists.opendaylight.org [mailto: > > tsc-boun...@lists.opendaylight.org] On Behalf Of Stephen Kitt > > Sent: mardi 29 janvier 2019 17:25 > > To: t...@lists.opendaylight.org; discuss@lists.opendaylight.org > > Cc: netvirt-...@lists.opendaylight.org > > Subject: [OpenDaylight TSC] Stable branches etc. > > > > Hi, > > > > In last week’s TSC call we had a brief discussion around the use of > > branches. One issue that comes up regularly is what to use the > > various branches for, and it occurred to me that we might be > > missing a branch (groan). > > > > When we start the freeze, we cut stable branches, and since we’re > > trying to be ever more rigorous, those stable branches are only > > supposed to receive fixes for blocking bugs. What master is used > > for then is up to each project, but typically it ends up receiving > > patches for the next release cycle (Sodium now). What’s missing in > > this scenario is somewhere to queue patches for the next service > > release (Neon SR1), at least until the freeze is over and we thaw > > the stable branches. > > > > Of course each project can set such a branch up manually if they so > > wish, but I’m wondering if projects would be interested in this as > > a general approach. > > > > Thoughts? > > > > Regards, > > > > Stephen > > > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without > > authorisation. If you have received this email in error, please > > notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > TSC mailing list > > t...@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/tsc > > > > _______________________________________________ > > Discuss mailing list > > Discuss@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/discuss > > > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler a l'expediteur et le > > detruire ainsi que les pieces jointes. Les messages electroniques > > etant susceptibles d'alteration, Orange decline toute > > responsabilite si ce message a ete altere, deforme ou falsifie. > > Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should > > not be distributed, used or copied without authorisation. If you > > have received this email in error, please notify the sender and > > delete this message and its attachments. As emails may be altered, > > Orange is not liable for messages that have been modified, changed > > or falsified. Thank you. > > > > _______________________________________________ > > TSC mailing list > > t...@lists.opendaylight.org > > https://lists.opendaylight.org/mailman/listinfo/tsc > >
pgpzKo5y7crWD.pgp
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
