/usrmove?

[Ralf Corsepius]

On 02/10/2012 01:34 PM, "Jóhann B. Guðmundsson" wrote:
> On 02/10/2012 10:49 AM, Ralf Corsepius wrote:
>> On 02/10/2012 10:06 AM, "Jóhann B. Guðmundsson" wrote:
>>> On 02/10/2012 04:45 AM, Ralf Corsepius wrote:
>>
>>>> In this spirit, I eg. would propose to table usrmove for F17 and to
>>>> concentrate on systemd integration and anaconda/grub2 improvements,
>>>> both topics, I perceived as the "hall of shame of F16".
>>>
>>> Better systemd integration of services is not going to happen I can 
>>> just
>>> tell you that here and now
>> Why not? Users are supposed to struggle with the swamp/mess the 
>> systemd integration currently is in? Could it be systemd reached its 
>> design limitations (== is a failure)?
>>
>
> In a perfect world users should not have to struggle with anykind of 
> mess systemd integration currently is or any other project for that 
> matter but then again arguably we would not make any progress et all...
>
> Systemd does not suffer from any kind of design limitation that I'm 
> aware of so you need to be a bit more specific than this and point 
> them out to me what you think they are?
>
> However the systemd migration process has shown that the project 
> suffers from limitations in so many ways.
>
>> Don't get me wrong, I am honestly asking, because I don't know and 
>> because it's in general not uncommmon to see "promissing 
>> developments" to reach 90% of its goals in 10% of the projected time, 
>> but to never cover the remaining 10% - Often because for limitations 
>> of the design.
>
> Again limitation in design is not a factor here and the people behind 
> this particular project are flexible enough to extent that scope 
> should it ever become necessary.
>
> Systemd itself is as complete as any other development project for 
> it's age.
>
ATM, systemd integration is a semi-cooked, hardly usable mess, which 
still has to prove its sustainability. Not more and not less.

>
>>
>>> unless fesco brings fourth the big hammer or
>>> packagers get their act together.
>> That's what I meant my "responsibility". I am asking the people in 
>> charge to "draw consequences".
>>
>
> If anyone is to blame for the current state it's the package maintainers.
It's naive to expect all packager to modify their packages to adopt 
something they do not understand or consider "to be crack". IMO, systemd 
integration would have been an example where a "tag team" would have 
been appropriate. This did not happen, a fact I consider to be project 
management mistake.

>>
> This could be to "bring out the hammer", it could be to "revert", it 
> could be Red Hat to delegate personnel, it could be volunteers to jump 
> in, to bring "this unpleasant topic to a proper end".
>
> Bringing out the big hammer which would be in this case to *force* 
> migration or the package will be removed from the distribution is a 
> last resource solution which is why FESCO.
>
> Reverting is not an option at this stage and even considering is 
> nonsense.
Well, history is full of initd systems, which been replaced before they 
had been "fully up". I would not want to bet if systemd isn't amonst these.

>>> The said state of systemd migration only reflects the said state of
>>> package maintainership in the distribution...
>> Well, I do not share this view. IMO, it reflects the attitude of the 
>> people behind this development.
>
> No the current state of systemd migration has everything to do with 
> relevant package maintainers in the distribution not systemd not fesco 
> not fpc not someone else and refusing to accept that fact wont make 
> that problem go away.
cf. above.
>
> I've been responsible for overseeing this migration in the project or 
> feature if your will and I dont need to be told what and where the 
> problems are I already know...
Ok, then my advice to you is: Stop shifiting around responsibilities and 
start to work. Team up with others and start working on migrating the 
remaining not-converted services.

Ralf