The new Update Acceptance Criteria are broken
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Tue Nov 23 08:31:15 UTC 2010
On 11/23/2010 06:51 AM, Ralf Corsepius wrote:
> IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs",
> it's bugs not getting fixed in Fedora, for a variety of reasons.
> Therefore, I consider trying to apply any such simple "policy" to be
> impossible and naive.
Agreeable logical conclusion.
The underlying problem needs to get address and fixed first.
I proposed this as a possible long term solution in one rough possible
way a bit back on a different list to try to address the underlying
issue but I did not receive any feedback on that proposal.
1. Improve the general standard of packagers ( need to at least have
upstream bugzilla account and are part of or in good communication with
the upstream community )
2 Allow for a adjusting period when it's over revoke the rights from
those that already have but do not full fill this requirements. Package
goes up for grabs or gets dropped.
2. Allow all maintainers to touch every component in Fedora note that
maintainer that brought the component to Fedora is still responsible for
3. Gather what information from all those maintainers we have in the
community what their code skill are and in which language and what skill
level their expertise is.
4. Assemble a "bug fixing task force" ( can be per language ) to target
component ( including testers if needed ).
5. Assign a component to the "bug fixing task force" and assign a time
period they should spend looking at the bugs on that component and
fixing them could be a day a week a month starting from critical path
6. Assign interns ( students home hackers and what not ) to tag along
the bug fixing task force and learn a few things..
Note that there could be several bug fixing task force working at the
same time but in different programming language and based on what skill
level they have as newbies could take the first rounds tackle the easy
fixers push what they cant fix to the medium team which then goes
through it if they cant handle it they push it on to the heavy hitters
who will strike upon it with furious vengeance and squash that bug to a
If and when something like above is ready then we can start small with
procedure we know.
create "proven $language coders" groups which maintainers sign up for
Reverse the roles of testers and maintainers and host a "bug squash day!"
QA decide which components needs addressing and contacts the relevant
"proven $language coders".
Triagers run through the bugs list on the component the day(s) before
and create a tracker bug with all the valid reports
"proven $language coders" run through tracker bug list
Testers stand ready on the sidelines during the code fiesta.
Hopefully bunch of bugs get squashed and users live happily ever after
or we find out this idea was great on paper but crap on field and we
return back to the drawing board..
More information about the devel