/usrmove?

[Harald Hoyer]

Am 10.02.2012 08:36, schrieb Ondrej Vasik:
> On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote:
>> On 02/09/2012 11:06 PM, Jared K. Smith wrote:
>>>> - management, whom seems to be driven by a "must have at any price, no point
>>>> of return ever" policy.
>>>
>>> I'm not sure who you're referring to as "management" here
>> Everybody involved to drawing strategic and tactical decisions related 
>> to the Fedora distribution.
>>
>> My point is, I feel there is a lack of "monitoring", "reporting", and a 
>> sense of "responsibility" of the different bodies involved and of people 
>> who are able to draw "unpleasant decisions".
>>
>> To draw an arbitrary example from recent past: Ask yourself - What was 
>> the shape of systemd in F15/F16? Has the situation been fixed in F17?
>>
>> 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.
> 
> One additional item to this topic.
> I'm the Fedora filesystem package maintainer (and because it has it's
> upstream on the fedorahosted, you can say upstream...) and I was aware
> of the "usrmove" feature only from the discussions and feature pages. 
> For quite a long time I waited for an email from Harald - with some
> "please include the changes into upstream git". The only mail I received
> from him was the mail on 24th of January - saying - do not build the
> package. Nothing more... Strange - when the first thing for Fedora
> maintainers should be "upstream first" and imho violation of Proven

It had to happen all at one time in koji.

> packager rules in some cases . For me it was kind of misusing proven
> packager - as e.g. in coreutils package he did following change:
> 
> +%check
> +# FIXME: check failed!!
> +# make check
> (part of
> http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html ,
> quite easy to miss when reading the commit mail)
> without even informing me about that! I don't see disabling testsuite at
> buildtime as the necessary minimal change. Not saying anything that with
> the /bin/ provides the spec file looks really like a mess now.

The testsuite was failing in rawhide at patch creation time (without any usrmove
patches). Works now again. Just turned it on.

> 
> Given the fact that there is NO ultimate gain from the usrmove feature
> (ok, I understand all the arguments for the usrmove, but I don't see
> them that bright at the moment as Harald and fastboot guys - e.g. the
> compatibility of distro locations is not only in the locations of
> binaries and we have much more differences in Fedora)

That's your personal opinion.. I tend to differ. Please read
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again.

> 
> I really don't know why the REAL ACTIONS on this feature were started
> that late in F17 release cycle - several months after branching.

Because politics took so long.

> Only 3
> weeks after the start of usrmove git commits you now have even F18 git
> branch and F18 would have been MUCH better for it.
> In addition, for mock builds of F17+ packages with usrmove support on
> RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages
> ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ).

and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound,
binding Fedora development to RHEL-6.

> 
> I'm sure that reverting the changes at the moment would mean much more
> confusion and that there is the only option now - finish it.
> But I hope that FESCO will learn from this "feature" and will set the
> "deadlines" for distro-wide features with higher impact sooner - so
> there will be enough time to postpone them to Fedora X+1 in the case of
> immaturity. I think there is a difference between usrmove and e.g.
> GIMP2.8 feature (no offence to Gimp).
> 
> 
> Greetings,
>          Ondrej Vasik
>