https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/RELENG-91 releng <p>Luis has idea to make job parallel to autorelease (which will only build managed projects) that also adds some project, like an unmanaged project. This job could run all the time, like autorelease, to give feedback. It will give unmanaged projects feedback about their snapshot integration with managed projects. The job would just add the unmanaged project's snapshot artifact to the managed distro and serve up a resulting distro for projects to test. There would not be verifications on the RelMang side to take care of, it's up to the project to check if the resulting distro works.</p> RELENG-91

Create job to build dist of MR + unmanaged project

Improvement Medium Resolved Done Luis Gomez Daniel Farrell Thu, 12 Apr 2018 02:29:31 +0000 Fri, 22 Nov 2019 00:16:20 +0000 Fri, 22 Nov 2019 00:16:20 +0000 0 4 <p>This job can use Managed distribution SNAPSHOT or Release, depending on whether we recommend Unmanaged projects to develop new code on Managed SNAPSHOT or Release. Lets see this in detail:</p> <p>1) Unmanaged projects to develop on managed SNAPSHOT:</p> <ul class="alternate" type="square"> <li>This means tight SNAPSHOT integration between managed and unmanaged during release cycle: unmanaged projects will suffer same turbulences as managed but after managed releases, unmanaged can release almost immediately after as there is no need of additional integration time.</li> </ul> <p>The workflow could be something like this:</p> <ul class="alternate" type="square"> <li>Unmanaged master branch will be based on managed master branch.</li> <li>Unmanaged projects will cut stable branch (e.g. stable/fluorine) before they produce a major release based on Managed stable release (e.g. Fluorine or Fluorine SR1).</li> <li>Unmanaged stable branch (e.g. stable/fluorine) will be based on Managed stable branch (e.g. stable/fluorine). SR creation is optional for Unmanaged projects.</li> </ul> <p>2) Unmanaged projects to develop on managed Release:</p> <ul class="alternate" type="square"> <li>This means release integration between managed and unmanaged during release cycle: unmanaged projects will develop on stable code but they will need additional integration time between managed release and unmanaged release.</li> </ul> <p>The workflow could be something like this:</p> <ul class="alternate" type="square"> <li>Unmanaged master branch will be based on latest stable release (e.g. Oxygen SR1 -&gt; SR2 -&gt; Fluorine).</li> <li>Unmanaged projects will need an integration window by the end of release cycle to test major Managed release update (e.g. Oxygen SR3 -&gt; Fluorine)</li> <li>Unmanaged projects will cut stable branch (e.g. stable/fluorine) before they produce a major release based on Managed stable release (e.g. Fluorine or Fluorine SR1).</li> <li>Unmanaged stable branch (e.g. stable/fluorine) will be based on Managed stable release (e.g. Fluorine SR1). SR creation is optional for Unmanaged projects.</li> </ul> <p>What should we recommend 1) or 2)</p> <p>For 2, could the UM project work against Fluorine much earlier? I would think we need a good release earlier in our cycle. Or do we think that release is going to be bad. In which case they really need to be building against snapshot's until the MR becomes stable?</p> <p>I am thinking we need both 1 and 2 depending on what the UM's want to do and how quickly we can build a stable, current MR. I could see some more active UM's wanting to be closer to MR and I could see some not doing the work until later in the cycle so they would just keep working against a previous MR. If they want to make it into the release they need to transition to something more recent so they would switch to 1.</p> <p>I would like to avoid building full distribution + verification for both scenarios 1) and 2) so what if UM projects can use both but:</p> <ul class="alternate" type="square"> <li>Full distribution build + verification will be done for scenario 1) as this facilitates the UM project integration with MR.</li> <li>In case UM project prefers 2) and also wants to be released within the full distribution, we recommend the project to switch to 1) one month before MR produces a major releases.</li> <li>For CSIT UM projects can use local distribution or full distribution if they opt for 1) and local distribution or MR release distribution if they pick 2).</li> </ul> <p>This is very confusing to me for some reason. <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>I'm not sure how UM projects consuming the release of Managed projects really works. Doesn't that mean there<br/> will be an entirely different release/distribution that we put out every release cycle? As an example, let's assume<br/> Fluorine is released and we start Neon. The UM projects will be working and basing their projects during the Neon<br/> cycle on Fluorine MR artifacts. Then when we get to the end of Neon and do our MR, we also have to do an UM<br/> release which is based on Fluorine? I'm obviously confused... </p> <p>But, if I'm not confused, then I think I would prefer the case where we just do 1) and UM projects need to build<br/> and develop based on the SNAPSHOT artifacts. At the end of the release all the projects that are building ok,<br/> make the release. Otherwise they are out. that is the simple way we've described it before. How these projects<br/> build is all we are talking about in this JIRA right? sorry if this is not helping the conversation.</p> <p>Right, I think ultimately we want UM projects to do 1) IF they want to be released in the full distribution, otherwise they can do whatever they want. In general there will be 2 jobs for UM Continuous integration:</p> <ul class="alternate" type="square"> <li>CSIT using repo-url parameter will allow UM projects to run CSIT regardless on how they base their code.</li> <li>Full distribution build and verification for UM projects interested in being released in the full distribution.</li> </ul> <p>No, the UM job should already be building against Fluorine right? Just happens they don't update to Neon. But the key here - is they are not in a MR - they are still on Fluorine and they really don't have a release. They are simply using the existing job to ensure their stuff builds.</p> <p>+1</p> <p>I think how we have it written is something like "they have to be snapshot integrated by &lt;date&gt;, building with the MR projects".</p> <p>I think the idea for this Jira is just a job that builds MR + 1 UM project (or set?) to give feedback about their integration.</p> <p>Agreed, that is how I interpreted this jira - how does a UM project verify it works with Managed so that it could eventually be included, or just give the UM an idea if it works. The UM could be a set as in if that UM has other dependencies that is wants to know also work. But the idea is we provide a basic framework for the UM and they add to it if needed - but the UM owns this work.</p> <p>I think this wad fixed in Flourine release.</p> Development Epic Link RELENG-93 Rank 0|i03d87: