Community
Participate
Working Groups
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.
(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.
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.
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).
I'm marking this as FIXED. As we discover deficiencies and enhancement opportuntiies, we'll open new bugs.
