The new Update Acceptance Criteria are broken
rc040203 at freenet.de
Wed Nov 24 12:07:18 UTC 2010
On 11/24/2010 12:22 PM, Toshio Kuratomi wrote:
> On Tue, Nov 23, 2010 at 08:31:15AM +0000, "Jóhann B. Guðmundsson" wrote:
>> 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 )
"One size doesn't fit everybody"
This is applicable in some occasions, but is non-applicable in many.
>> 2. Allow all maintainers to touch every component in Fedora note that
>> maintainer that brought the component to Fedora is still responsible for
>> his components.
> I like this idea.
Hmm, we already have the proven-packagers group and we already have the
concept of co-maintainers.
>> 4. Assemble a "bug fixing task force" ( can be per language ) to target
>> component ( including testers if needed ).
> I like this idea as well however...
Again, proven-packagers already can do this.
At least I occasionally applied my proven-packagers' privileges to
troubleshoot critical situations. However, having done so, one lesson
learnt from this, was this kind of help often only to be a short-term
relief, but not to be a long term cure, because packages which are
suffering from issues a "trouble-shooting group" is able to help often
suffer from much deeper issues.
Also, it's this kind of situations, where Fedora's QA's "delays" have
shown to be counter-productive.
More information about the devel