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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
