[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Critical Path Packages - Enforcement?




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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]