On Wed, 2009-07-22 at 03:08 +0200, 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? That's the current plan, yes. > > Assuming the answer to 1. is "Yes": > 2. Will critical-path-gnome also get the same enforcement? > 3. Will critical-path-kde also get the same enforcement? > 4. Will critical-path-* for spins.fp.o spins also get the same enforcement? I'm not sure what groups have been created, but it is my understanding that we are considering the gnome desktop and packagekit the critical path for updating. We are not considering alternatives in alternative desktops as part of the critical path. > 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 would be of use to KDE volunteers who wish to be alerted when there is something critical to KDE being proposed for update, so that they can seek it out and test it, even if there is no enforcement at the bodhi level. Tools can be created that will alert when a package as part of the KDE critical path hits bodhi. > What we basically agreed on in KDE SIG (see also our meeting log [1]) was: > * The KDE spin being one of the primary spins, critical-path-kde should get > the same kind of enforcement as critical-path-gnome. (We have no official > opinion about stuff like critical-path-xfce as that's out of the scope of > our SIG.) At this time, KDE is not part of the critical path. As we get to actually deploying code for and using critical path functionality, we can expand what is covered or create other groups to cover other areas. We are starting small to trial before we try and solve everybody's problems. > * 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.) > > But we need the clarification I requested above to make any further > decisions. > > Another open question is who is going to QA critical-path-kde, as we still > don't have a dedicated tester in KDE SIG. Anybody volunteering to be a > tester for KDE SIG is requested to talk to us on the #fedora-kde IRC chan > and/or the fedora-kde mailing list. Being a tester has a much lower barrier > to entry than most other forms of contribution, you just need some HD space > to install test systems to (ideally, you'd have Rawhide, Fn and Fn-1 on at > least one machine each, but even just testing one release is helpful) and > some spare time. No programming, drawing, technical writing etc. skills > required. I will post a call for help to the fedora-test-list as well. (Note > that we do have a KDE SIG member in rel-eng (rdieter), so that part is > covered.) > > Kevin Kofler > > [1] http://urlx.eu/_Mzk4MQ > > -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
