Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
rc040203 at freenet.de
Tue May 4 16:25:16 UTC 2010
On 05/04/2010 05:55 PM, "Jóhann B. Guðmundsson" wrote:
> On 05/04/2010 01:50 PM, Kevin Kofler wrote:
>> "Jóhann B. Guðmundsson" wrote:
>>> You must all realize that the ratio of bureaucracy/process burden and
>>> quality of maintainers/packagers go hand in hand. The better the
>>> maintainers/packagers/components are less bureaucracy/process burden is
>>> needed. The worse it gets more bureaucracy/process burden is needed. If
>>> ye all feel that the bureaucracy/process burden is increasing that only
>>> means that the quality of maintainers and their components is going
>>> down.. ( we might be getting more components inn in less quality ).
>> If our maintainers suck, bureaucracy is not a good solution to fix that
>> But we already have a group of trusted maintainers, it's called
>> "provenpackager". We could give provenpackagers the power to push
>> to stable without any karma requirements.
> Given the requirements FESCo + if they checks on the bugzilla activity
> of the individual that wants to become a provenpackager and take that
> into consideration when approving the request I dont see why not.
> So basically it would be like this..
> If you are a provenpackager you have the power to push directly to
> stable without any karma requirements however if you are not a
> provenpackager you will have to follow what ever procedure FESCo RELeng
> and QA come up with at any given time until you have been accepted as a
> provenpackager by FESCo.
> Sounds like a draft to a solution everyone can agree with?
a) This would cause the "provenpackager" group to gradually start
suffering from the same issues as the current "packager" group has
("lack of qualification"). It would degrade the "provenpackager" group.
b) Members of the current "packager" group should be qualified enough to
judge if their update/upgrade needs an "immediate push".
It they aren't able to do so, they should reconsider if they are
qualified to be a packager at all.
More information about the devel