On 30/01/2019 15:30, Sam Hague wrote: > > > On Wed, Jan 30, 2019 at 5:03 AM <guillaume.lamb...@orange.com > <mailto: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.
We really need to address the 'wild west' aspect here -- and we need concrete examples from past two releases. Based on the release schedule, the next release is not open, which certainly is not a wild card to wreak havoc on downstreams -- so who and why is causing it?! > 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. Well, I take the position that limited resources dictate limited code churn and more incremental feature delivery. This includes the hard task of culling deliverables early. The additional branch really works in exactly the opposite direction: rather than the features being postponed to the next GA release, they are pushed out to SR1 (and SR2, etc.). That breaks the strong reading of the SimRel schedule, really. What I mean is that in the past the GA release was postponed by up to three months to cope with "things just happening", with the hope being that such events would become ever rarer. That has not generally happened and today we have SimRel which is not time-flexible. That time-flexibility meant that feature delivery problems would get masked (i.e. you'd get 8-12 weeks more time in a particular cycle). With that flexibility gone, though, there are only two options I can see: 1) the SimRel schedule works for a particular project 2) the SimRel schedule does not work for a particular project I think we are dealing with a case of 2) here, and the question is whether: a) SimRel schedule needs to be fixed b) the project's upstreams need to be fixed c) the project needs to be fixed One final note: unlike MRI and self-managed projects, projects in autorelease build have no control over how/when they consume upstream changes nor when they release. I believe this is a major component of the pain here. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
