/usrmove?

[Toshio Kuratomi]

On Wed, Feb 08, 2012 at 11:07:48AM -0800, Adam Williamson wrote:
> On Wed, 2012-02-08 at 11:03 -0800, Toshio Kuratomi wrote:
> 
> > > > If the anaconda support for UsrMove is not merged (and maybe not even
> > > > written?), then why was an untestable and incomplete feature merged?
> > > 
> > > Well, it becomes a semantic argument. You can, after all, install with
> > > the /usr move in place, right now. You can upgrade from F16 with /usr
> > > move in place, if you follow the yum instructions. You can then test the
> > > *feature itself* perfectly well. Arguably, anaconda support for the
> > > feature is not part of the feature. You could go either way on this, but
> > > it's not an obviously wrong statement.
> > >
> > I think I would fall firmly on anaconda support being needed for the
> > feature.  It was one of the things that the FPC was counting on when it
> > approved it, for instance.  If anaconda support doesn't make it in, we
> > won't be able to release with UsrMove activated.
> 
> At this point we're talking about the (first) feature freeze, not the
> final release. The question is whether there's a violation of the
> feature process if anaconda doesn't have support for usrmove *right
> now*, not whether there's a problem if it doesn't have support by
> release time.
>
My argument is that anaconda integration is part of the feature.  It just
wasn't mentioned on the Feature page (I think because the feature page
wasn't fully updated once it became apparent that anaconda integration would
be necessary.)  How do we know that anaconda integration is part of the
feature?  If it wasn't we would be able to ship the final release
without that integration being done because it would be an optional thing.
We wouldn't have an F17 feature, "UsrMove" and an F18 feature "Anaconda that
can work with UsrMove".

The reason the feature process goes through Fesco (as opposed to be purely
about marketing) is because coordination and collaboration is needed to make
sure that all the pieces work together.  You can't have an "SELinux enabled
by default" feature if Xorg doesn't run when it's enabled, for instance.

If you want to look at it as two separate features, you'll find that you're
fighting with the defintion of Feature Freeze[1]_ from the policy rather than
working with it.  For instance, "If a feature page specifies that a feature
will be enabled by default, it must be so at Feature Freeze."  In this case
we have a default method of upgrading (anaconda -- yum upgrading isn't even
a supported method of upgrading) along with a Feature that is supposed to be
enabled on all systems.  If the code that integrates them isn't written,
then they cant both be satisfied by the policy without contorting their
spirit (well, anaconda is only a feature when the anaconda team proposes
changes to it... otherwise, it's just a bug in an existing package that it
doesn't work with the new changes....)

.. [1]_ http://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze

Now it's quite possible that if QA doesn't care whether anaconda upgrades
work until beta that the feature policy could stand to be rewritten here.
Perhaps we could say that Features do not need to be testable in the upgrade
scenario until beta, for instance... I'm not sure that really makes sense,
though.... If we have a failure to communicate between the feature owners
and the anaconda team (as happened with the feature owners and releng this
time) it might be that the anaconda team isn't told that new code needs to
be integrated or even written until Beta which seems like a bad idea....

-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/20120208/2383306a/attachment.sig>