----- 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
