Absolutely agree. I also think we will need a place where proposed non-release editions can prove their worth and possibly attain release status. Integration project is the logical place for that proc

Completely agree here, though the closer we get to Helium release, the less value a stable release will have. Historically, by the time we cut the Hydrogen release, we knew that there will need to be

Hi Mathieu, yes, this will have implications on how we package, test and deliver our code, but I think we need to transition gradually. From that transition perspective, defining it as a distribution

Hello TSC members, in the name of BGPCEP committers I would like to ask you to consider the newly-proposed TCP-MD5 project as a pre-M3 split of BGPCEP functionality delivered in Helium release. We wou

+1, it should have been split into multiple projects ages ago. I strongly suggest controller committers start actively plan the splitting strategy, such that they can start executing on it as soon as

Forgot to CC: the TSC mailing list. Sorry for the confusion. Bye, Robert

I think these three kind of build on top of each other, so I think it might make sense to overflow Ed's switch/device model to Tuesday just to give the Monday topics sink in. So while I think we can c

Hello Phil, thanks for updating the slides and keeping general track of this. After glancing through the agenda, several thoughts pop to mind: I think Salon 5's back-to-back sessions really zero in on

While I agree with the lessons, I think the release structure has to change. The API freeze/code freeze structure leads to features being rushed at the last minute, often with inadequate quality, just

(Long rant warning. Proposal is by no means complete, but attempts to propose general mechanics and highlights challenges which are intertwined.) Unfortunately, we have a larger inter-project problem

I do not agree. Changes to odlparent have the capacity to incur huge amounts of breakage across the board, which is not easy to diagnose. Slight misalignment in seeming unrelated components causing cl

I am afraid that the way we are doing releases today runs contrary to the technical goals we need to achieve. Both the release, autorelease and inter-project setup prevent projects from freely issuing

I tend to think that the individual projects should just ship modular things. The integration project should be the one defining what the defaults in the Simultaneous Release are. At the end of the da

Sorry for being ignorant: where can we see there auto-release job? Is there a wiki describing it? All I found was https://wiki.opendaylight.org/view/CrossProject:AutoRelease which does not seem to be

I have updated https://wiki.opendaylight.org/view/CrossProject:AutoRelease to point to the jobs. Thanks, Robert

I have started addressing this particular issue. As it turns out, reworking dependency management renders our current way of building karaf features utterly unusable, since the artifact versions disap

Hello, There are plenty of good reasons to not do this. All of them stem from the fact that the root pom is where your build project-wide build starts, whereas a pom's parent specifies the equivalent

Ditto. While doing javadoc:aggregate for bgpcep I looked precisely for this and I simply could not find it. That's when I realized that, unlike in many a build system, the directory hierarchy and arti

Agreed. Rather than doing the technically wrong thing, I think we really need a well-written guidelines to project structure, which not only dictates what, but also details why. I will add this to the

I think the TSC should clearly communicate its schedule for coming up with the schedule, so that projects know how long the vacuum is going to be and can plan/execute accordingly. Bye, Robert