Sorry for the long delay responding to this - I've been busy breaking things in the critpath. :)
Responses inline: On Wed, 22 Jul 2009, Kevin Kofler wrote:
Hi, I have a few questions for the folks involved with the Critical Path Packages proposal, as I'm still confused about the implementation details: 1. How will the policy be enforced? Will Bodhi withhold submitted updates for packages in the depsolving hull of @critical-path until they get approval from QA and/or rel-eng, like it currently does for security updates until security team approval?
A ticket is in for bodhi to be able to figure out the list of critpath pkgs and not allow them to be sent on w/o approvals.
Assuming the answer to 1. is "Yes":
Since 1. was a "How" question I don't think the answer could ever be 'yes'. :)
2. Will critical-path-gnome also get the same enforcement?
yes.
3. Will critical-path-kde also get the same enforcement?
If the kde-sig desire such.
4. Will critical-path-* for spins.fp.o spins also get the same enforcement?
if those sigs desire such.
If the answer to any of the above (1. to 4.) is "No", what kind of enforcement will there be? When we discussed critical-path-kde today at KDE SIG, we were very much confused about what exactly the practical implications will be. I think it won't be of much use to define critical path packages if that definition doesn't lead to some actual enforcement.
It's up to the sig.
our SIG.) * It doesn't make much sense for us to define critical path packages if it won't have any actual practical implications. (We already know what's critical to what extent, so a purely-informative critical-path-kde won't be of much use to us.)
critpath is really about making sure person X checks in some change and it works on their machine but doesn't work anywhere else and this doesn't result in a bazillion bug reportrs and broken systems and articles on lwn, etc, etc.
We're trying to make things more consistently functional so testing/dev/bug killing can happen.
I don't think of critpath as a special status, it is something which has been defacto in place for certain pkgs(rpm, yum, createrepo, python - essentially if those pkgs didn't work enough to do the compose, then we couldn't go any further) - we're just expanding the set of pkgs, really.
If the kde-sig does not wish to be involved then that's really up to that sig. The rest of the distro is going to moving ahead.
This is only my opinion and my interpretation of things, of course. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
