Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
"Jóhann B. Guðmundsson"
johannbg at hi.is
Tue May 4 00:09:32 UTC 2010
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.
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
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 ).
More information about the devel