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