old_testing_critpath notifications

[François Cami]

On Thu, Dec 2, 2010 at 6:31 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2010-12-02 at 18:20 +0100, François Cami wrote:
>> On Thu, Dec 2, 2010 at 6:03 PM, Adam Williamson <awilliam at redhat.com> wrote:
>> > On Thu, 2010-12-02 at 13:20 +0100, François Cami wrote:
>> >
>> >> Of course, we could look at things differently: for a package to be
>> >> marked critpath, it should have users or be a dependency of some other
>> >> package with users.
>> >
>> > This is pretty inevitably implicit in the current definition of critpath
>> > - packages that are necessary to boot the system and use it. :) Okay,
>> > there's slightly unexpected cases like openldap, which isn't necessary
>> > for most people to login and use their systems but gets brought in
>> > because it's a dependency of various auth mechanisms which *optionally
>> > support* LDAP, but even that is obviously used by >0 people.
>>
>> jlaska just gave me the list of packages marked critpath in rawhide:
>> http://kojipkgs.fedoraproject.org/mash/rawhide-20101202/logs/critpath.txt
>> 389-ds, cobbler, httpd, libvirt, mysql, postgresql, puppet, vsftpd are
>> not in the list. My guess is therefore that most server packages are
>> completely ignored by the critpath definition. And we have server
>> users.
>
> Ah. I misread you: I thought you meant to add that to the current
> definition of critpath packages, not to replace the current critpath
> definition with simply "anything with users".

Make that "anything with enough users for us to care", especially if
said users participate in the process, and that's about it.

>> >> And packages with enough known users should always land in critpath,
>> >> otherwise we might break systems users depend on.
>> >
>> > That doesn't fit in with the current function-based definition, so your
>> > proposal is to change that?
>>
>> Yes. Note that the current function-based definition is contained in
>> the "have users"-based one, as long as Fedora is used on the desktop,
>> that is.
>
> Right, but it massively increases the range of critpath packages (which
> would only exacerbate the problem under discussion unless we made
> critpath testing less rigorous), and loses the initial purpose of the
> critpath policy. I think really what you want is the three-tier system
> so that 'not important' packages can be allowed to go through without
> testing, right?

That, and catch regressions in updates to well-used packages before
they're pushed. And that includes server packages.

>> > but we don't really have any very reliable methods for
>> > determining use of packages yet.
>>
>> We could extend smolt to do so.
>
> smolt's still opt-in and always will be, AFAIK, because there'd be way
> too much of a Slashdot drama if it weren't.

Yes it is and rightly so. However, it contains data about 200K active
systems at the moment:
http://smolts.org/static/stats/stats.html
Data about CPU, RAM, Language, etc... But no data about packages yet.

François