/usrmove?

[Toshio Kuratomi]

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 at freenet.de> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120210/45ddceac/attachment.sig>