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
Attachment:
pgp0VbGgjEwEm.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
