| Member |
Statement
|
| mmcgrath |
- A. I list this first because not only does it obviously need to get better but it seems obvious it will get better. The QA team has lots of neat things coming down the pipe.
- Better communication around how rawhide works. Both in terms of best practices in making changes to it and in communicating when updates are safe. (probably relates to 1, but can't entirely rely on that)
- Related to 2) I'd like to see a way for our rawhide developers to have their own rawhide branches. Similar to how there are different kernel trees. This isn't so they can have their own distro. But so they can more easily put massive changes in place to be tested for some small period of time before it is merged with "Jesse's tree" :)
- Better messaging systems for contributors and end users. Just in general a better experience in letting our users know what's going on in Fedora (news), what features are coming down the pipe (feature update vs just a normal update), etc.
- Additional ways for people to contribute to via the Fedora Project that are not the distribution itself.
|
| pfrields |
- A coordinated effort between Alpha and Beta (or even post-Beta) to file and fix more bugs as a community effort, perhaps in the form of a focused week of effort across the Fedora community. Community Architecture support for bug parties, say $50-75/group to pay for hacker snacks.
- A central 'www.fedoracommunity.org' website that functions as a directory of other *.fedoracommunity.org domains -- the ones run by our community members that are separate and distinct from the fedoraproject.org domain.
- Improve the wiki documentation for schedule, freezes, critical path, and related info to make it dead simple for any developer (or heck, anyone) to figure out what is permissible at any point in the cycle. This should help eliminate guesswork, late code drops, and misunderstandings that can negatively affect the community. Not only that, but it means that we can more effectively create more robust QA and rel-eng communities because there's a lower barrier to learning what sometimes is institutional knowledge.
|
| jwboyer |
- QA. Fortunately, we have made good progress on the rawhide front already. I'd like to see (and help with) more progress on QA of released versions and updates.
- A higher bar for Features. We have a hugenormous list of Features and it's starting to get a bit fuzzy as to what that means and how a new user could possibly even experience some of those.
- An actual secondary architecture release. We've had 'almost' releases since F8. I don't care which arch it is, but if we don't have a secondary arch that actually does a release I think it's time that we as a project just move on and stop worrying about it. (Or maybe we're already at that point and I'm the only one worrying)
- A clear process around the creation of the distribution. I think rel-eng is making strides towards this already, and trying to improve the experience for contributors with no frozen rawhide and auto-qa. I'd like to see us support that and invest in it because it will have a wide benefit.
- Easy one: auto-sign builds. Represent signed packages exactly as they are today: Fedora built this. That's it. Signing doesn't imply it's been tested or QA'd or that it is somehow a known quantity. It simply means the package as built by Fedora.
|
| notting |
- QA QA QA. AutoQA doing automated tests, AutoQA mailing those test results to developers for review, AutoQA using those tests to block packages where necessary, AutoQA using those tests to promote packages where necessary. A database of past test results so we know what broke, when.
- Defined policy around updating and maintaining released distributions. Not being able to concisely explain what sort of updates you get is a problem.
- Set up a mechanism where large changes can be built in koji, set up as a repo, and tested sanely before being merged, ideally as a self-serve mechanism.
|
| caillon |
- 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.
- 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].
- 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.
- Improve our test suites. Provide $coolstuff incentive for people who contribute (the most?) valid test cases.
- 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
|
| poelstra |
- Completely (as in nothing deferred to Fedora 14) implement the "unfrozen rawhide" proposal
- Update our documented release process and freeze policies so that more people can understand them and find them
- I'm planning to help with this one. Ideas on how to measure the success or failure of this is welcome.
- More communication about upcoming schedule milestones and what the expectations are around those milestones
- I'm planning to help with this one. Ideas on how to measure the success or failure of this is welcome.
- Release Criteria for each release: Alpha, Beta, and Final
- I'm planning to help with this one.
- in order to write good release criteria we need to know what the goals are for what we are creating and releasing
- To to this we also have be able define what success is for our releases.
- I'm suggesting something beyond what we have now and have some drafts in progress
- Clear instructions and a guide so that anyone can write a test for the automated QA testing framework. Established processes for adding newly written tests to the framework and seeing the results.
- The automated testing framework tells us more often than not when rawhide is unusable on a particular day vs. someone discovering it on their own. A place for fedora-test-list posters to check first.
|
