"Staying close to upstream"

[Kevin Kofler]

Al Dunsmuir wrote:
> The  FireFox  maintainer  might  well  be  viewed as best qualified to
> determine  which  (if  any) distribution-specific patches they want to
> support  over  the life of the package.   If you say no, then put that
> maintainer in a "FireFox SIG" and repeat the question.

1. It doesn't make sense to have a SIG for a single package, a SIG needs to 
be for a set of packages. For example, the Perl SIG is not for just the perl 
package, but for most perl-* (and IMHO should be responsible for ALL perl-* 
packages).
2. Even packages primarily maintained by one SIG can be subject to decisions 
by other SIGs. E.g. I fully accept that the Games SIG should have its say 
over kdegames as long as they don't step into KDE territory (e.g. requiring 
us to change the BR kdelibs4-devel to a BR kdelibs-devel >= 6:4.0 would be 
unacceptable), that the SIGs for interpreted languages should have some 
control over their respective subpackages of kdebindings (and in fact we 
already try hard to follow their language-specific packaging guidelines 
there; if we don't, it's a bug) etc. My position is not "the KDE SIG should 
rule everything", it's "SIGs must be given authority over their subject 
matter, even if it means overruling individual maintainers or even, in the 
worst case, other SIGs, in order to allow for a consistent experience across 
the distribution".

> FESCo  might  well  be viewed as best to deal with policies related to
> updates  across  _all_ Fedora SIGs and releases, since that one of the
> tasks they were _ELECTED_ to perform.

FESCo is a too central body and the election process is broken in many ways 
(very low turnaround, too few and not sufficiently diverse candidates etc.).

> Seems  you think best is one way in one case, and the other way in the
> other  case.   It is this inconsistency that folks are trying to bring
> to your attention.

This perceived "inconsistency" just comes out of misunderstandings.

There is a middle ground between an authoritarian central authority and 
anarchic "I refuse to apply the patches you need because of XYZ" attitudes. 
SIGs are the right granularity for management.

Usually, and by default, the maintainer should be trusted. Where integration 
across packages is relevant (and that's exactly the case for those KDE 
_integration_ patches!), that's a matter for the SIGs (who should be allowed 
to overrule individual maintainers). Our central governing bodies are just 
bureaucratic overhead.

        Kevin Kofler