TSC@lists.opendaylight.org | [release] ODL release model

Home Messages Hashtags Subgroups

Date Date 1 - 4 of 4

[release] ODL release model

Robert Varga #13239 On 15/10/2020 21:48, Luis Gomez wrote: Overall, I like the model but before we can take it for a TSC approve, we need to: - Proper define the 2 project groups (requirements, etc) - Select which projects are Platform today (the rest are Plugins/Apps). - Define the process to move a project from 1 group to another. - Create release schedule for the 2 groups. - Analyze changes in CSIT: Most likely we will need Plugins/Apps projects to generate their own karaf distribution to test patches and stable branches. Yeah, except the TSC does not have the mandate for most of these things. Remember, the TSC gets a say only in two cases: - project lifecycle events (creation, graduation, etc.) - project SimRel participation requirements In everything else, the TSC simply cannot interfere with a project, unless the project has lost all its committers. I understand that all the autorelease years have skewed your perception, but actually the TSC cannot force a project to release. While MSI projects are released through autorelease, which is controlled by TSC, the actual mechanics is that projects in autorelease have delegated the authority to release them, not given it up. MRI/SM projects just revoked that delegation and are in charge of their releases, as originally intended. As for testing -- distributions are being created and deployed for most projects as part of the best practices layout + maven-merge job kinks. Those provide the baseline for 'per-usecase' testing. integration/distribution still needs to run the 'everything together' testing it does... as that is the real test of whether SimRel is properly integrated. Regards, Robert
More All Messages By This Member
Luis Gomez #13240 I also do not think TSC can obligate a project to release but I think we have to set some rules for functioning together, for example Platform projects should define a set of release versions for Plugin/Apps to consume during the development cycle, also if these versions change (bug fix, etc), communicate this in advance and update the information (e.g. in platform version docs). These are the kind of requirements I am talking about. BR/Luis toggle quoted message Show quoted text On Oct 15, 2020, at 3:05 PM, Robert Varga <nite@...> wrote: On 15/10/2020 21:48, Luis Gomez wrote: Overall, I like the model but before we can take it for a TSC approve, we need to: - Proper define the 2 project groups (requirements, etc) - Select which projects are Platform today (the rest are Plugins/Apps). - Define the process to move a project from 1 group to another. - Create release schedule for the 2 groups. - Analyze changes in CSIT: Most likely we will need Plugins/Apps projects to generate their own karaf distribution to test patches and stable branches. Yeah, except the TSC does not have the mandate for most of these things. Remember, the TSC gets a say only in two cases: - project lifecycle events (creation, graduation, etc.) - project SimRel participation requirements In everything else, the TSC simply cannot interfere with a project, unless the project has lost all its committers. I understand that all the autorelease years have skewed your perception, but actually the TSC cannot force a project to release. While MSI projects are released through autorelease, which is controlled by TSC, the actual mechanics is that projects in autorelease have delegated the authority to release them, not given it up. MRI/SM projects just revoked that delegation and are in charge of their releases, as originally intended. As for testing -- distributions are being created and deployed for most projects as part of the best practices layout + maven-merge job kinks. Those provide the baseline for 'per-usecase' testing. integration/distribution still needs to run the 'everything together' testing it does... as that is the real test of whether SimRel is properly integrated. Regards, Robert
More All Messages By This Member
Robert Varga #13241 On 16/10/2020 00:24, Luis Gomez wrote: I also do not think TSC can obligate a project to release but I think we have to set some rules for functioning together, for example Platform projects should define a set of release versions for Plugin/Apps to consume during the development cycle, also if these versions change (bug fix, etc), communicate this in advance and update the information (e.g. in platform version docs). These are the kind of requirements I am talking about. Right, but we already have this defined -- and it is the SimRel participation rules for all MRI projects -- irrespective of any other label that may be perceived as relating to a particular project ;) Regards, Robert
More All Messages By This Member
Luis Gomez #13242 I think this could be done just before a release milestone (e.g. for a RC) but difficult to achieve in a continuous way like in AR today, specially when projects will have freedom for updating their upstream versions (like SM projects today). toggle quoted message Show quoted text integration/distribution still needs to run the 'everything together' testing it does... as that is the real test of whether SimRel is properly integrated.
More All Messages By This Member

1 - 4 of 4

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms