critpath approval process seems rather broken

[Kevin Fenzi]

On Sat, 09 Apr 2011 13:07:21 +0200
Kevin Kofler <kevin.kofler at chello.at> wrote:

> While I welcome those changes, I don't understand why we need to make
> the update rules to be enforced by Bodhi more and more complicated
> (and in fact, too complicated for Bodhi to implement correctly, there
> are already several corner cases in which the implementation in Bodhi
> differs from what FESCo requested) when we could just ask maintainers
> for a bit of common sense and do without any software enforcement.
> 
> As you're seeing from all those proposals being floated for various
> special cases, there are many factors to consider in the tradeoff
> between getting important fixes out quickly and getting changes
> tested. I think there's a lot to gain from being flexible. No
> hardcoded policy will do the right thing in all cases. This thread is
> just one of the many cases where it goes wrong.
> 
> Homo sapiens sapiens has an organ called the "brain", which is very 
> effective at making decisions. We have many of those available, one
> per maintainer. Why not use this processing power for decision making?

To some extent I agree with you. ;) 

We went though several models over the years... 

- Anything goes, up to the maintainer. 

This gave us major updates in stable releases, things that weren't
tested very well or widely, lots of smaller updates for minor things
leading to churn, etc. 

- Anything goes, up to the maintainer, but verify/put some framework on
  it. 

Sadly, there's no way to verify/sanity check all updates from a rel-eng
point of view. The flow is far too vast, so the only way we can really
test/check things is... 

- Some rules/structure, enforced by the tool and verified/checked by
  anyone out there who cares to do so. 

I agree that the complexity is anoying and hard to get right, but not
sure we could go to less rules without hitting cases we really would
like to check for. 

Things like bodhi 2.0 and autoqa will help too... when they finally
arrive. ;) 

The current situation is not ideal, but we are trying... 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110411/e4f9807b/attachment.bin