(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
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
