Reasons for hall monitoring

[Ralf Corsepius]

On 05/08/2010 01:41 AM, Matěj Cepl wrote:
> Dne 7.5.2010 16:56, Przemek Klosowski napsal(a):

> It seemed like the combination of best of being
> completely independent and maintaining your own repository (what would
> be now called PPA; I haven't heard the term then yet) and having support
> and community of fellow maintainers all in one package. It was
> refreshing to see how problems were just solved on the spot without need
> to apply for permission and a lot of bureaucracy. The result was
> incredibly rapid development (I remember I was using as an advertisement
> slogan “Fedora? Next release of your distribution today!”).
:) Agreed, this aspect to a wide extend has gone lost in Fedora.

> This vision in my opinion requires freedom for packagers of individual
> packages to have quite wide allowance in setting their own policies
> concerning updates and bug fixing. If Kevin prefers to have packages on
> all distros synchronized and (maybe, I don't know, I don't use KDE)
> broken much more often than Gnome-folks, it is in my opinion mostly
> between KDE team and KDE users. Also, if they don't think they can
> manage much more than pushing all non-packaging bugs upstream, I am not
> the one who would preach to them they should do better (especially
> without providing manpower to do so). OTOH, if Ralph doesn't won't to
> push almost any bug upstream and he wants to make sure that all Fedora
> bugs are fixed asap, great for his users, they will certainly love him,
> but I am not sure it should be fixed as a rule for everybody.

Well, my view is a bit different:

I consider it to be a Fedora's package's maintainer's primary task and 
duty to keep his package "working and functional" in *Fedora*.

To be able to achieve this he is required to bring along a certain 
amount of technical skills/qualifications. Wrt. this, I am observing 
deficiencies in Fedora. I feel, there are packagers who consider 
packaging to be a mechanical task, but who don't actually understand 
what they are doing.


Part of this "task and duty" is the Fedora maintainer to go after 
bugs/malfunctions/defects etc." and process them in "adequate time" such 
that these "bugs/malfunctions etc" do not furtheron affect Fedora users.

How and what to do in detail to achieve this can vary in wide ranges in 
individual cases. This can be him to investigate an issue and to provide 
fixes himself, this can be him asking upstream, this can be him 
arranging a contact between reporter and upstream. The only thing that 
matters is to keep the impact of such issues low as possible to the 
Fedora users - In an ideal world, this would be to fix the bug ASAP.

In real world, processing such issues often works entirely different. It 
may easily comprise to release major package upgrades midst of a 
distro's life-cycle, even ABI/APi breaking ones, occasionally to 
backport selected fixes, or ... not to upgrade or in extreme cases, to 
remove or downgrade packages.


In short: Being religous about any of these details doesn't help anyone. 
Neither "let users report bugs upstream" nor "no backports" nor "no 
ABI/API breaking upgrades" nor "strictly follow upstream releases" will 
work everywhere on all occasions.

Or yet differently: The user and his experience with the packages a 
packager maintains should be in the focus of a packager's works.

Ralf