On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: > On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > Wrt. F17: usrmove - Independently from the fact that I consider it to be an > > "idotic foolishness", ask yourself if it is a shape to be part of F17? IMO, > > it's foreseeable it will not be ready, because there are too many unknows > > attached to it. I now would expect those people having been involved to > > stand up, show responsibility and revisit their decisions - This obiviously > > doesn't happen. > > At the moment the feature was again brought up to FESCo two weeks ago, > the commits were already in the repository, so reverting the feature > would have had a pretty big cost; as much as I oppose the idea of > UsrMove, I didn't think reverting it was worth it at that time, and I > don't think it is worth it now - the situation is not that hopeless to > call for a comparatively extreme measure. (Also, a large part of FESCo > clearly wants this, and I don't think reverting features just because > elections happened in the mean time is a good idea.) > Just a note -- if this is the case, then the contingency planning portion of the Feature Process is broken. If it is, the changes to fix it could be a big pain... For instance, at X milestone, features that fesco is afraid won't make it are required to run through their contingency plan to make sure that it is doable and extimate cost to revert... falout of this is that with the extra work, some features might miss the deadline because they optimistically felt they wouldn't fall into this category... OTOH, if fit and polish of the GA is the criteria, perhaps this isn't a bad thing.) Note that I didn't get the impression from reading the FESCo logs that they felt the contingency plan was too big to invoke at their last discussion of UsrMove so I'm not certain that this is something that needs attention. > Yes, FESCo > * should have recognized early that the scope of the feature was not > thought through and that more pieces are needed (contrary to claims > back in the end of October that "everything is already implemented and > works") > <nod> So one idea would be that a specific FESCo member needs to step up to be the "collaboration guide" (Must think of a better name for that :-) for a feature. They would be in charge of the feature, watch it as it evolves. Pick apart all the points where it requires coordination with other groups. And make sure that those groups were informed that the feature was in progress. > * probably should have asked for an advance approval from FPC > (although, as a general rule, I think advance approval from FPC > lengthens the feature cycle too much and should be avoided) When I saw the feature, I brought it to FPC for an initial look. We gave it a cursory look in 10 minutes during open floor of one session and gave the recommendation that we would likely find that the /bin/ /sbin/ portion of the feature would not be allowed by us but the / to /usr portion would. Unfortunately, rather than taking that and modifying the Feature before sending it on to FPC, the Feature Owners and FESCo chose to send the feature with the /bin/ /sbin/ merge in it to us. That caused debate, discussion, and examination for at least one whole meeting. This portion could easily have been avoided if people had taken the pre-recommendation from FPC seriously. The implementation changes that occurred after the proposal was officially sent to FPC and lack of a workable method of properly controlling the upgrade experience until FPC made that a requirement also took time. One possible interpretation of that is that the feature owners or fesco should have gotten those figured out before it got to FPC. Another interpretation is that FPC was a second set of eyes that did what they were supposed to by finding the flaws and forcing them to be fixed -- in that case, though, you can hardly say that the lengthening of the time taken to approve the feature was misspent. > * and should have monitored the progress more closely. > <nod> - that would go along with the idea of having a particular FESCo member be in charge of tracking the feature and making sure it was on track. > The feature process is currently being revised, and at least some of > these issues have been brought up at > https://fedoraproject.org/wiki/Fixing_features . What would be > especially useful is to find ways to improve the feature process. > +1. I'm perfectly capable of figuring out bad ways to fix the feature process (See my off the cuff thought on contingency plans, above ;-) If someone has ideas that are less costly, that would help a lot so there is a half-way decent proposed solution for the first strawman proposal. -Toshio
Attachment:
pgpttc6N03Sic.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
