Bugzilla – Full Text Bug Listing
| Summary: | [pmi] Once "on" sim rel flag should remain on until project opts out | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Project Management & Portal | Assignee: | Portal Bugzilla Dummy Inbox <portal-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, contact, daniel_megert, ed, gunnar, john.arthorne, konstantin, pwebster, sbouchet, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=387760 | ||
| Whiteboard: | |||
|
Description
David Williams
I'm on the fence with this one. While I agree with "once in, always in", reality oftentimes conflicts with this and projects do fall off the release train. I think some explicit involvement is a good thing. Asking projects to confirm that they're still in is a very small thing. The converse (though a corner case) is more challenging. How do we identify that a project is no longer responsive and needs to be explicitly removed? By what process would we even detect that a project isn't participating? And then who is responsible for chasing the project down? In the new project management infrastructure, I envision having a "what's interesting" page that is customized for every user. A committer/project lead could find an entry on this page with text to the effect of "You were on Juno last year, are you prepared to commit to Koala? Click here." or something to that effect (note that I am putting my vote in for the name of the 2013 release). That same message would be included in a weekly mail out. Yes, I think it is a "minor" request for enhancement, if there is such a thing.
One thing that might help is to have more values than "in or out" ... so, there could be, say, an "assumed in" (since in previous) vs. "in" (set by project lead). In some ways, the list would be "more accurate" during M1, M2, M3, and could still ask for explicit "confirmation" by M4.
> How do we identify that a project is no longer responsive and needs to be
> explicitly removed? By what process would we even detect that a project isn't
> participating? And then who is responsible for chasing the project down?
This is done be Planning Council chair, for anyone not in M4 build ... they are "out", if they have not otherwise been responsive. (So, guess you'd need some other possible "out" values ... "out - never in", "out - opted out after being in" and "out - assumed out by Planning Council". ... whew, does sound complicated :)
I just wanted to capture the possibility of automating more and making things easier, since two project leads brought it up on cross-project list.
Feel free to close as "won't fix" or transform it into a requirement for your "what's interesting" page (which admit ... I don't quite "see" yet in my minds eye :) ... but ... could possibly provide good reminders for things like this?
(In reply to comment #1) > I think some explicit involvement is a good thing. Asking projects to confirm > that they're still in is a very small thing. While that sounds good in theory it does not reflect how the release train works. The aggregation build contains all projects from last year. The list isn't cleaned up. If flipping the switch in the portal is required then the aggregation build need to somehow get that metadata in order to disable submissions that did not flip the switch yet. Otherwise it's inconsistent and that is confusing. I guess that I'm concerned (perhaps incorrectly) about a hypothetical inactive project that automatically gets pushed from last year's simultaneous release into this year's. The hypothetical inactive project's old p2 repository persists and--since they used relatively broad version ranges on their bundles--everything pieces together quite nicely during aggregation and no builds break. We don't notice this increasing more-and-more hypothentical project until they don't submit an IP Log. After a couple of weeks of me trying to contact them and being as helpful and understanding as possible, we give up and decide that they're really not participating. We yank them during the RC period, killing hypothetical downstream consumers and one or more of the packages in the process. Or am I just being ridiculous (which I acknowledge is a possibility). We're at a point were we can redesign this to be whatever we need it to be. I think that it serves everybody to keep the complexity as minimal as possible. (In reply to comment #4) > We're at a point were we can redesign this to be whatever we need it to be. I > think that it serves everybody to keep the complexity as minimal as possible. I don't think it needs to be re-designed. I think it should just be fixed to be consistent. I see two options: 1) Fix the portal to inherit the settings from the last release. 2) Fix the aggregation process so that all contributions are cleared when a new release begins. Frankly, with option one situations as described in comment 4 are much more likely to arise than with option two. However, option two is too late for Juno but can start with Juno+1. I can see the merits of changing the aggregation process so that projects are not aggregated until they actively "join" the train. (I am not offering to do the programming required to automate that, so projects would still have to set the flag, and then get their project back in the build). I reason its done the way it is (to start the next one, with a copy of the last one) is partially to save the projects the trouble, but also to help encourage the cultural thinking of "once in, always in" ... to communicate if there is a change. But, if the consensus is to wait until an active choice each year, I (or others) can start the yearly aggregation "fresh" each year. [I personally don't think the scenario in comment #4 is possible ... or, if it is ... that's a sad statement of how out of touch PMCs and Project Leads are :) ... but, I'll admit, there was one year a project "stayed in" until M4 before I heard they were not planning to participate .... that is, they did not "actively" communicate with the community that they were leaving the train. So, it's' not ridiculous ... just sort of the 1 chance out of 1000 case, IMHO]. With Juno experience, I've come to change my mind. Mostly. Partially due to vast quantity, and partially due to the complications that come from projects reorganizing and changing names, making it confusing to "traceback" from file name to project. (such as mjt is still in a file named dsdp-mjt even though dsdp is no more, and mjt is under sequoyah project. Plus, it seems projects simply don't want or don't know to broadly announce they are dropping out. (such as sequoyah, this year). So, I propose for Kepler, it could could start off for Kepler copying everything from Juno, but disable everything and encourage people to switch on flag and enable aggregation "at the same time" (two, manual steps, unless someone volunteers to automate it). One thing to keep in mind, regardless of this exact solution, is that "name of aggregation file(s)" would be a good piece of metadata to keep in project metadata, like we do "offset" in aggregation build. We sort of have tried to use a "naming convention", but that is kind of unreliable, subject to change, etc. So an explicit listing would help keep track of things (and give at least some hope of automating things better, some day). (In reply to comment #7) +1. Way more projects stay on than fall off. In fact, I'd say the falling off projects are an exception that should be handled specially. What was missed is that a lot of projects don't produce new bits for M1 and often also M2. It overlaps with SR-1 which gets priority. And removing the bits in M1 is the wrong answer. Projects dependent on those bits would rather have old ones than none at all. (like PTP on CDT). As for projects that become inactive. If they don't submit to the release review. They're off. If projects are dependent on those bits, then again, they're probably happy with the old ones which have already been reviewed. I think the need to enable has actually worked well. David stepped in to exclude some blocking dependencies so that we started getting 'green' builds. Perhaps he could have stepped in a day or two earlier. The real problem seems to be the collision of M1 and summer holidays catching too many committers sleeping. Perhaps the solution is two stage: Next year everyone has to enable just as this year, and the response will be better since we will be familiar with the process. But at M1 David can step into enable sleepers with heavy dependencies. These then get disabled again for real at M2. I am with Doug on this. The bulk of projects stay on from year to year once they join. The metadata assumes that projects make this decision every year. We can make project behavior conform to metadata or we can make metadata conform to observed project behavior. > I think some explicit involvement is a good thing. Asking projects to confirm > that they're still in is a very small thing. It is a small thing, except that multitude of small things compound to build into a big thing. Tracking a multitude of small things with their own timeliness requirements isn't trivial either. > The converse (though a corner case) is more challenging. How do we identify that > a project is no longer responsive and needs to be explicitly removed? By what > process would we even detect that a project isn't participating? And then who is > responsible for chasing the project down? If a project goes inactive, either its contribution is still ok or it breaks the aggregation build. Once it breaks the aggregation build, you've detected the problem and the contribution can be disabled if project team doesn't respond in a timely manner on cross-project. No need to track anyone down. If a contribution isn't re-enabled by a certain milestone, the project is removed from aggregation and simrel. If they want to re-join, they have to restart the join process. To make this even simpler, portal can generate project's simrel status automatically based on aggregator metadata/status. I don't know what the right answer is, here. I think we all want to make things easier (the whole reason I opened the bug :) but at the same time make sure all is accurate, and accurate as early as possible. Just to document it, in the past, I had to spend hours creating and reviewing tables such as the one at http://wiki.eclipse.org/Juno/Projects_and_b3aggrconfile so "we" could correlate projects with Sim. Release flag set, with the b3aggrcon files used to create common repo. So a) I don't want to have to spend hours doing that and b) it still required all projects to review and resolve ambiguous cases and make sure my assumptions were accurate. In a perfect world, I think the Portal data and databases could be improved so projects had to list their b3aggrcon files, so a report could be made of "legitimate" files. Others would be removed around M3 or M4. (And, remember, some projects have more that one, for their own convenience? Or historical/reorg reasons?) But, without that automation, what's the alternative plan? Of the counter suggestions made so far, I think they don't address the issue that Wayne was concerned about. First, many project could continue to "build" and go right into the common repo, without ever breaking the build, even though they did not intend to. And, waiting until the release review to find out a project is "out" is too late ... it gives the community the wrong impression if its there for 7 milestones (and and one RC?) and then suddenly removed because they never intended to be in the release. Just trying to clarify, not argue. I sincerely want to make things as easy as they can be. (but also still accurate :) We've moved this out of the portal and into the PMI. WONTFIX. |