On Sat, 09 Apr 2011 13:07:21 +0200 Kevin Kofler <kevin.kofler@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
