[TSC-133] Unmanaged Project Milestones and Communication Created: 06/Aug/18  Updated: 06/Aug/18

Status: Open
Project: tsc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Medium
Reporter: Brian Freeman Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Recently the transportPCE project ran into an issue with dependencies in Flourine and getting the work done to be part of the flourine distribution. It led to a discussion of how project changes are communicated and the overall timeline.

 

The below description is for discussion of the problem and to generate possible solutions for Unmanaged Projects. Some of the passionate participants are on vacation this week so input might be limited.

 

Here is a set of topics/questions for dicussion based on that experience and the managed-release process

 

https://docs.opendaylight.org/en/stable-oxygen/release-process/managed-release.html (couldnt find a Flourine form)

 

  1. The current release plan has very few requirements on Unmanaged Projects so that the load on them is very small.
  2. As long as the project has its integration references in place “one week before RC0” they would be part of the distribution.
  3. Unmanaged projects still have to do a repo:add to actually be installed in an instance but otherwise are packaged with the rest of the projects.
  4. Note that RC0 isnt defined in the release process page referenced on the wiki
  1. The Project Timeline does not provide any guidance on how Managed Project changes would be communicated to the Unmanaged projects
  2. The Major Milestones of:
  3. CSIT Checkpoint
  4. Middle Checkpoint
  5. Code Freeze
  6. Final Checkpoint
  1. It would seem that there aught to be a checkpoint with the Unmanaged Projects that are trying to be part of the release at the Middle checkpoint to check on Managed Project Dependencies
  2. When Managed Projects do analysis for code impacts there should be a project to request unmanaged project feedback or at least notification.
  3. A JIRA ticket might make the most sense for targeted changes but for something like removing model’s as was the issue in Flourine might need a reminder on a weather page or something other than an email
  1. Unmanaged Projects are dependent on changes to underlying API’s and models in many cases so waiting till the last week before RC0 is not sufficient.
  2. In those case, the Unmanaged Projects should have a check point where they can find out about API and Model changes that affect them and to plan accordingly.
  1. Unmanaged Projects in theory can make releases after the formal release but there is nothing in the release timeline
  2. Should Unmanaged Projects have a specific X weeks after SR0 for their final integration against the Managed Project Base ?
  3. Should Unmanaged Projects have a specific checkpoint at Middle checkpoint to self identify that they want to be included and thus to be engaged in any API/Model changes in advance of Code Freeze ?

 



 Comments   
Comment by Luis Gomez [ 06/Aug/18 ]

Here is the right link for Fluorine:
https://docs.opendaylight.org/en/latest/release-process/managed-release.html?highlight=managed%20project

I agree we have to change current documentation to include:

1. Clear statement that SM projects can join the official distribution release (formal Release or SR) as long as:

  • They are in the distribution when first Managed RC is created. Note that today we do not show RC milestones in the release plan, so how can we make this more clear?
  • They produce a release and they add it into the distribution in the designated window: normally the week after Managed projects have released. Note that today we do not show this week in the release plan, so how can we make this more clear?

2. Recommended time for SM projects to integrate with Managed (if they want to join the official distribution release):

  • For those wanting to be in the Release distribution (master branch), the middle checkpoint seems like the maximum date to do so.
  • For those wanting to be in the SR distribution (stable branch), the previous release date (e.g. Formal release if they want to be in SR1) seems the maximum date to start the integration.

3. Where to find release cycle changes:

  • Before the release, weather page should include API and other important changes. I think we need some stability by the end of the release cycle so should we set a milestone where API and other disruptive changes should be avoided? maybe Middle checkpoint.
  • After the release, the release notes should also include this information.

Please feel free to comment on this.

Generated at Wed Feb 07 20:45:16 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.