Critical Path Packages - Enforcement?

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

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux