We can't target any user without fixing these 5 things

[Christopher Aillon]

(hm, apparently my VPN connection died on the plane when I thought I had 
sent this last Saturday...)

I think perhaps the single largest issue we have is a lack of 
reliability/predictability during a Fedora release stream (e.g. 
post-release updates, rawhide).  It's great that we have predictable 
schedules, and that we have predictable feature sets.  What sucks is 
that nobody knows how well those feature sets will work, and just as 
importantly, nobody knows what types of package updates (wrt ABI compat, 
rebases, etc) to expect in the Fedora update streams.  Things which work 
on release day may break later on due to some packages getting 
de-stabilizing updates, some not.  We ask maintainers to use their 
judgement, and when people complain, we explain that we don't control 
it, and it's up to the maintainer.  This clearly does not work as this 
is a frequent topic of contention on various mailing lists, and is not 
really beneficial to any class of user.

Additionally, nobody knows whether rawhide on any given day will be 
usable, and it still has a negative stigma attached to it: some 
engineers who provide rawhide packages don't even use rawhide, which is 
causing rawhide and thus the upcoming releases to get less testing.  I 
do not think that we can really provide top quality software if we can't 
even use what we build at any given point.  We are more focused with 
getting features in then with getting them in and having them work.  We 
are happy to break things in rawhide and say "well, it's rawhide, i'll 
fix it in a few days".

If we want to target Fedora for any class of user, we need to think and 
act for the user.  Right now, we're clearly not even acting for the 
people that do use our distribution.  I think we should fix that before 
we can even begin to define what our target user should be.  If we can't 
do these five things, then I think any discussion involving target users 
is rather pointless, and quite honestly, we are doomed to fail, IMHO. 
(Note that some of these items may be best specified by e.g. FESCo, but 
I think they reflect a significant enough change in the way we do things 
that the Board should push for and stand behind these).


    1. Define a list of core/critical-path functionality that packagers 
are required to ensure they do not break.  Define a plan of action for 
what happens if such functionality becomes broken.  See example[1]. 
Bonus points: come up with an easy to follow "smoketest" for how to 
determine whether something on the list is broken.

    2. Define update criteria for our release streams: what types of 
updates we expect, and what types of updates we do not want in each 
stream.  Define a plan of action for what happens if an update fails to 
comply.  See example[2].

    3. Set up something similar to Mozilla's "Sheriffs"[3].  The Sheriff 
will be a rotating role and shall be responsible for coordination and 
enforcing of the previous two rules.  If an issue arises, the sheriff 
will attempt to contact the packager responsible, and attempt to get 
them to fix or revert the issue.  If this isn't possible within 15 
minutes, the sheriff will find a provenpackager to do so.

    4. Improve our test suites.  Provide $coolstuff incentive for people 
who contribute (the most?) valid test cases.

    5. Start an initiative to automate as much of the above as possible. 
  Possibly as GSoC projects.  Particularly, I'd like to see a tinderbox 
which creates VMs from a buildroot+ks file, runs automated tests for the 
critical path, and outputs the PASS/FAIL results.  I'd also like to have 
a post-commit hook which reminds people to not break stuff and to be 
available to the sheriff on IRC.


[1] Example: Core/critical-path is a system must boot up, get a display 
manager with XYZ video cards, be able to log in successfully, be able to 
get a working network via ethernet (and if available, via xyz wireless 
cards), have audio work on XYZ audio cards, and be able to successfully 
use yum/rpm/PackageKit.  In the event any package breaks this 
functionality, the package must be fixed immediately (within 15? minutes 
of noticing) or the changed is reverted, package untagged and rebuilt. 
If N violations occur, provenpackager status is revoked.

[2] Example: For rawhide, do not break dependencies without announcing 
in advance about why you are doing so to fedora-devel-list, and not 
receiving objections.  For Fedora releases, updates must not break ABI 
or dependencies without getting an exception granted from FESCo.  In the 
event any package fails to comply, the change is immediately reverted, 
and mail sent to the packager owner.  If N violations occur, 
provenpackager status is revoked.

[3] https://wiki.mozilla.org/Sheriff_Duty