I think it's a good idea to build a small team from offset-0/1/2 and try out the pilot. That will help us quickly to figure out the unknowns. Probably We should start with asking projects if they want to volunteer for this pilot?
On Thu, Jul 7, 2016 at 6:18 AM, Colin Dixon <[email protected]> wrote: > This has been out for two weeks without any comment, so I'll chime in a > bit. > > See more inline. > > --Colin > > On Thu, Jun 23, 2016 at 2:28 AM, Phil Robb <[email protected]> > wrote: > >> Hello: >> >> I took an action item from the TSC to kick off a thread about potentially >> changing our release process for the Carbon release and what that might >> look like. >> >> We have had discussions for some time on shortening our release cadence >> from 6-8 months to something much shorter such as 2 months (Fast). This >> discussion often goes in conjunction with the idea of decoupling the >> different sets of projects that make up Offset-0, Offset-1, and Offset-2 >> projects, so that each of those is released separately in a staged manner >> (Phased). We have also talked about various methods of building >> OpenDaylight so that we do not have to have strict enforcement of specific >> versions of each project being identified for a given simultaneous release >> (semantic-versioning). >> >> Changing to one or more of the above release characteristics for the >> Carbon release is the question at hand. An immediate set of follow-up >> questions then are: >> - What projects would need to change first, and what would they need to >> do? >> > > I would imagine things would have to start at the root of our dependency > tree with odlparent and yangtools. I would guess that semantic versioning > combined with downstream projects using a fixed version range instead of a > fixed version would be the first step, but I'd love to hear if I'm wrong > > We could have migrated projects produce both SNAPSHOTs (via the normal > merge job) and release artifacts (via a periodic, e.g., weekly, job and/or > a manual release job), so that both systems could exist side by side and > people could rely on either the fixed version range or SNAPSHOTs. We'd need > the autorelease scripts to handle that and make sure that we get the right > release versions of everything, but it might be pretty easy. (That does > mean we'd need to include releng/autorelease in the effort as well.) > > Note that while the above really talks about phased, migrated projects > would be free to have their own release cadence and thus be fast if they > wanted regardless of the simultaneous release cadence. > > >> - Is there a "pilot" effort we can run to try things out, and if so, >> who/what are the logical people/projects to run such a pilot? >> > > Robert and Stephen with odlparent and yangtools would seem to be the > logical choice. > > >> - Once the initial work/pilot(s) are complete, what do all other projects >> have to do to make this transition work? >> > > If we do the above and I'm right about it, nothing unless they want to. > > >> - Can we get to a decision as a group our plan for this transition by the >> time we start the Carbon release, or is this something we need to >> plan/execute over a couple of release cycles before the transition is >> complete? >> > > My intuition is that given where we are in the Boron release and the > runway we have to plan Carbon, the most we can realistically aim for in > Carbon would be to get a solid pilot of a few projects. > > >> Please chime in with your thoughts and any corrections to the comments >> above. As we know from past experience it is much better to talk and >> decide what we're going to do in the next release cycle WELL IN ADVANCE of >> the completion of the current cycle. So if you have thoughts/comments on >> these potential changes, make them now. If we can't get to transition plan >> on these potential changes soon, then we'll need to put a "traditional" >> release plan for Carbon in place as a fall back. >> > > I agree here. My personal take would be to post a "traditional" Carbon > release plan that looks like Beryllium so that we can provide fair notice > and time to plan for it. Then, we can have a separate fast/phased pilot > release plan that exists alongside it so that we can try to make progress. > By and large the two should be orthogonal. > > >> Thanks, >> >> Phil. >> -- >> Phil Robb >> Sr. Director Of Technical Operations >> OpenDaylight Project >> (O) 970-229-5949 >> (M) 970-420-4292 >> Skype: Phil.Robb >> >> _______________________________________________ >> TSC mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/tsc >> >> > > _______________________________________________ > TSC mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/tsc > > -- Thanks Anil
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
