/usrmove?

["Jóhann B. Guðmundsson"]

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.

Bugs are being fixed and new features are being introduced as are with 
any project that is actively being worked on.

>
>> 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.

The distribution will never be better then the packages they ship and 
their relevant maintainers so if you want to improve the overall quality 
of the distribution you will have to do so in the roots of the project.

> 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.

For an distribution that should be striving to become self sufficient 
running to or otherwize expecting an sponsor to throw in personal when 
tough gets going is a bit backwards don't you think...

>> 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.

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...

JBG