I was initially, in a call a few weeks ago, a bit vocal if I remember correctly about how I felt better project isolation with non-SNAPSHOT was important, but meanwhile I've gotten somewhat "used to" it being how it is in ODL, and I'm even thinking that perhaps too much isolation among projects could become a bad thing for speed of innovation and progress in ODL's future?
Taking just as little examples the Checkstyle work, or a minor yangtools performance improvement - it's actually great how everyone immediately benefits from that the next day, through the "fast" way we currently continuously integrate the entire kaboodle through SNAPSHOT all the time. If we do move to something more "phased", I'd love to see the discussion include actual timelines we have in mind... Say if someone proposes a change to odl-parent and yangtools, how soon / late will it be before higher up projects like ovsdb and netvirt get to profit from them after a master merge? A week? A month? Three months? Anything than a week would be too long IMHO! And when new fixed releases of root projects such as odl-parent or yangtools are released, then one problem we may soon face, and I've seen in other large code bases, is that it's possible for projects to lag behind and thus start diverge more than we'd want them re. what versions of lower depencies they us - say, just as an example, e.g. ovsdb switching to a newer yangtools than netvirt or some other project - this could become interesting? Unnecessarily painful? On a practical note, does anyone have a clearer idea how we could do "semantic versioning combined with downstream projects using a fixed version range" ? I'd love to see some sort of POC about that, because... I'm not yet convinced how this is technically possible! OSGi has this idea, but what we currently do in the build is not grab dependencies through a real OSGi resolver (à la p2 or OBR or so), but through classic Maven - which only has either fixed versions, or SNAPSHOT. Unless I'm missing something here. On a perhaps slightly tangential note, what is a minor PITA today is "just" the constant re-downloading of every single org.opendaylight.* JAR dependency, all the time. This could give some a certain feeling of slowness in local development perhaps? I wonder if before going fully phased, there are things that could be done to improve that? Two specific thoughts: 1. When nothing changes 1 day in odl-parent or yangtools, do we currently still push new SNAPSHOT every night or so? We should not. 2. Simple infra stuff... to me download from e.g. Maven central appear faster than from nexus.opendaylight.org, is that right? If so would looking into some sort of CDN or a few official Mirrors, be of any value? Just a thought. Regards, M. Tx, M. -- Michael Vorburger <[email protected]> | IRC: vorburger @freenode | ~ = http://vorburger.ch On Sat, Jul 9, 2016 at 12:35 AM, Anil Vishnoi <[email protected]> wrote: > 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 > >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
