Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo

["Jóhann B. Guðmundsson"]

On 05/03/2010 10:30 PM, Jesse Keating wrote:
> The point here is that Kevin isn't perfect.  As such, he can make
> mistakes, just like all of us.  By asking for a couple karma nods from
> different people, we increase the chance of catching some of those
> mistakes.  Since the delay exists anyway, it doesn't seem to be that big
> of a deal to me to make sure a couple people test it and comment as such
> during that delay.
>
>    

Agreed.

For example we had a bug in one of the previous release were a 
relativity harmless "fix" in the maintainers eye  ( which I do believe 
he tested locally before updating the package ) broke all non US 
keyboard layouts ( if I can recall correctly actually reset or set the 
keyboard layout setting to US or deleted the previous stored layout) 
luckily for us he did not act impatiently but pushed it to 
updates-testing were we were able to capture it before it hit 
mainstream. This could have proven disastrous but it did not thanx to 
this process.

Now if maintainers wants to wield the power of pushing straight to 
update without having to have his update lay for few hours/day's in 
update-testing it is my firm opinion that he should be.. a) a upstream 
maintainer b) have flawless bugzilla interaction, c) have very active 
upstream interaction encase a) is false and d) upstream is ACTIVE. 
Encase of a mishap we need to be sure that the maintainer can act 
quickly ( from the first report in after he pushed that update ) if 
needed but before granting that access we seriously need to start 
tracking and visualize ( graph ) component action both in bugzilla and 
in bodhi to identify which maintainers and their components can be 
granted that access.

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 ).

JBG