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?
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?
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.
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.)
* 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
