----- Mail original -----
De: "Tomasz Kłoczko" ?
What I'm trying to say is that IMO I probably know why up to now
it was not
possible to introduce common indentation in RH and Fedora as well.
(bad news)
I know probably as well why now it will be even harder.
.. because (as result)
[…]
In other words on this area way bigger some "human/ego" obstacles than all
those technical ones. Am I close?
Look, there's no need to assume nefarious intent. Once a spec works, packagers will
find something else to fill their life with (something else may be another form of Fedora
activity), and only return to it when an update is needed (usually, with the minimal
amount of spec changes), or if there is a huge problem in the issue tracker. Need for
updates can be predicted quite a long time in advance if they know their upstream and big
problems are rare because anyone sensible won't choose to package a software that
fails more often than he can cope with.
And, mostly, because Fedora packagers are nice people, they still feel responsible. That
means they do not like someone else touching their specs, because, at minima, that forces
them to drop their other activities, to check the changes are ok (because they feel
responsible), and potentially deal with the fallout (if the changes have side effects).
Worse, if you change too many of their specs at once, they may find out they are
over-committed, and need to allocate yet more time to find someone to hand over some or
all the changed specs. Lastly, if they are currently working on a change, it may require
them to rebase their work.
Add to this they do not trust you, because they do not know you, and will suspect if they
see you change too many specs at once it's just fire and forget scripting with no
proper testing and no QA on the result, leaving *them* to deal with the problems when they
asked nothing and their spec worked in the first place.
So if you want to setup a Fedora spec cleanup office, that's great but it takes more
than deep rpm knowledge of one person:
— you need to recruit enough technical people the cleanup office can still function when
you are unavailable (bus factor)
– you need to setup procedures with QA to properly check the effects of each mass spec
change, with enough technical guys your side to fix the fallout QA finds, all that fast
enough there is no long broken period during which original packagers are yelled at and
distro development crawls to a stop
– you need to setup communication to announce your changes, explain them, and give an
account of the result
— you need to make sure Fedora documentation is in sync with the changes you're
making
— you need to plan, for the right least invasive time in the Fedora release cycle, to do
those changes
And, mostly, you need to build trust. Trust is achieved by being publicly successful
several times. Trust is destroyed by doing changes without assuming their effects, or by
doing changes blind, because surely someone will complain if you make a mistake (yes they
will complain. They will also not trust you afterwards).
The bar you need to pass is *way* higher than any other distro-wide change because other
distro-wide changes usually bring functional improvements (that people understand, and
want), other distro-wide changes are usually driven by a particular package (so it's a
matter of packagers helping one of their own), other distro-wide changes rarely require
touching hundreds of specs, while cleanups are highly invasive with no immediate
functional benefit to anyone. While the problems they can trigger are very immediate.
Regards,
--
Nicolas Mailhot