Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 366466

Summary:	[pmi] Represent coordinated releases in the project management infrastructure
Product:	Community	Reporter:	Wayne Beaton <wayne.beaton>
Component:	Project Management & Portal	Assignee:	Portal Bugzilla Dummy Inbox <portal-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	david_williams
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:
Bug Blocks:	363868

Description Wayne Beaton

2011-12-12 17:14:41 EST

Provide a first-class notion of a coordinated release in the new Project Management Infrastructure. The annual Simultaneous Release, aka "Release Train", is an example of this. I'm thinking of a generalized mechanism that might let us, for example, create an eventual "Runtime Coordinated Release".

How big a deal are coordinated releases? Who can create them? Does it make sense, for example, for the Modeling Project to create it's own coordinated release without involvement from the planning council?

What sorts of things should a coordinated release keep track of? Name, description, date seem obvious. A notion of a chain of coordinated releases also seems obvious, so coordinated releases should keep track of a previous/next release.

A direct connection between an individual project's release and the coordinated release also seems obvious (in the case where a project release joins a coordinated release, the coordinated release's date should override anything explicitly set by the project). 

As part of the workflow to join a coordinated release, we may need some oversight from a governing body. Before joining today's Simultaneous Release, a project must announce their intent to join and--effectively--get permission from the Planning Council.

Perhaps coordinated release should have an optional "opt in before" date and some notion of ownership. The general case is screaming for some sort of participation policy management, but that sounds way too heavyhanded for our wants and needs.

Comment 1 Wayne Beaton

2011-12-12 23:05:49 EST

(In reply to comment #0)
> Perhaps coordinated release should have an optional "opt in before" date and
> some notion of ownership. The general case is screaming for some sort of
> participation policy management, but that sounds way too heavyhanded for our
> wants and needs.

In keeping with the combined themes of keeping the new implementation as simple as possible, and trusting committers to do the right thing, I think that the right solution is to provide a text field for participation rules along with the ability for a coordinated release owner to remove a participant.

Comment 2 David Williams

2011-12-12 23:54:22 EST

I think its fine if some portal tools help projects coordinate "off-cycle" releases, not to mention aide the yearly Simultaneous Release. But some care may be needed in wording, as I think the Planning Council, as part the EMO, as defined by the bylaws and Eclipse Development process, is defined as the "governing body" of the "Eclipse Release Plan" and the yearly Simultaneous release. Put another way, I would not want the generalized notion of coordinated release to dilute the meaning or importance and "marketing appeal" of the yearly release (well, I mean unless that's your intent ... which I guess would be a larger discussion than Portal tools ... some Process discussion as well?).

But, to emphasize it, I could imagine it could be useful for some projects to have a coordinated off-cycle release ... such as "Dali" and "DTP" might want to coordinate a release in December (where Dali depends on some changes in DTP). While most practical examples I can think of would be "just a few" projects, and might not need too much infrastructure, it doesn't hurt to design the system to handle all cases. But, I'd use care with the terminology and positioning so it does not give the impression there are "multiple release trains" throughout the year which, if taken to the extreme, would be almost as bad as each project "doing their own thing" in an uncoordinated fashion.

But, again, good idea to model the general case, of which the yearly Simultaneous Release is one case. Perhaps others could come up with some anticipated "real life use cases" (that do or don't change the bylaws or Development Process) to help guide the design and process. [You know, to avoid "over designing" the system.]

I hope these comments are helpful.

Comment 3 Wayne Beaton

2012-04-03 15:11:20 EDT

If we do decide to extend the concept of release coordination, we will need to make a clear separation between "official" simultaneous releases coordinated by the planning council and other coordination.

Regardless of what we decide, we should make the notion as generic as possible (i.e. don't artificially constrain simultaneous releases to a particluar date, or a particular frequency as these sorts of things may change in the future).

Comment 4 Wayne Beaton

2013-03-03 00:24:27 EST

I'm marking this as FIXED. As we discover deficiencies and enhancement opportuntiies, we'll open new bugs.