|This is an old document. The proposal has been implemented. Please see Automated Release Process.|
The group of maintainers listed at the bottom of this proposal is formally endorsing a change to the release process. The new system will be driven by automated tools and processes. The new system will be driving by automated and transparent tools and processes. It will change the point at which QA it is applied and how detected issues are handled.
We believe that the current process is flawed in ways that lead to maintainer frustration (references, which may require reading a bit of context from the thread: 1 2 3 4 5) and an unclear path to resolution of disputes. This maintainer frustration leads to a reduction in output and by extension leads to our inability to produce a stable release for our users. Specifically, a few items that cause the most problems are:
- Inconsistent application of policy. Not all packages are subjected to the same (or any) checks at release.
- Packages are subject to stalls or rejections for non-policy reasons.
- It is subject to the availability of a single person. Technically two people can release packages, but practice has shown that this doesn't happen.
- It is under-documented and overly manual.
Application of policy at the release step is handled by the legacy checkpkg but not all packages are run through it. This tool isn't as comprehensive as the modern checkpkg and it also lacks easy extensibility.
In addition to policy issues, the release process routinely stalls packages for reasons beyond the scope of QA. These stalls may be presented as QA, but they typically reflect only the views of the release manager. More often than not, these views are in contrast with the majority of the active/vocal maintainers.
As has been seen in some cases, urgent package updates are delayed by the process as we have only a single person that releases packages. While a backup exists the option is exercised so rarely, if at all, that it may as well not exist.
The replacement system that we are proposing will be an automated system that treats all packages equally. Policy will be applied consistently to all packages with tools that are developed based on maintainer agreement (eg: no policy checks introduced without approval via list discussion or votes when required).
It will allow any maintainer to push a package to the newly created 'unstable' repository when they feel it is release ready. At this point, it will be available for download and inspection by anyone that wishes to use it. Before it is accepted into 'unstable' it must pass all current policy checks enforced by checkpkg.
At this time traditional QA may be applied by someone other than the maintainer. Any suspected or actual defects will be noted by filing a bug in our bug tracker. A package may not progress from unstable to current with open bugs.
These issues/bugs may be discussed on the maintainers mailing list or resolved privately between filer and maintainer as the case requires.
Non-policy items may still be used as QA items, but they will be treated the same as any other bug filed against a package. This means that the person noting the issue will have equal voice with the maintainer on the resolution of the issue. We expect that in some cases the maintainer will amend the package and in others he/she will choose to leave the package as is.
Any bug filed has the potential to trigger the creation of new policy. This would require list discussion and in some cases a vote if there is no clear consensus from that discussion. New policy will be implemented as a check within checkpkg.
As part of this effort a group of volunteer subject matter experts will be established to support and maintain the release system. Membership in the group is open and the purpose is to establish a broad list of individuals who are best capable of supporting and improving the release system. This group will be subordinate to the board and responsible for seeing that packaging policy is properly enforced by the release system. In the event an unforeseen issue disrupts the release process they are empowered to manually augment the system to enable timely release of packages. Such intervention will be logged with the understanding that repeated manual intervention will require enhancements to the release system to accommodate routine exceptions.
All items that fail checks in checkpkg may be overridden to allow package-local exceptions to policy when/where required. These overrides are visible in the package delivered to the system and the code repository. Additionally, they can be queried for in the package database.
By opening up the QA process such that multiple people can easily participate and have equal standing on the matters at hand, we feel that overall package quality will improve; maintainers that would once walk away from publishing a package will fight harder for things they believe in and disputes will have a clear path to resolution.
The new system will also standardize the flow of packages from the maintainer to the mirrors. This is an improvement on the current system which promotes but doesn't enforce package submission through the pkgsubmissions@ mailing list. There will be no steps in which the state of the package is unknown. It is either accepted and will be batched for the next mirror push or rejected. In all cases, the maintainer immediately knows what is happening.
Furthering the automation theme, catalog signatures will also be generated automatically by a daemon/service and mirror pushes will happen automatically at defined intervals.
Overall, we feel that the key benefits of the new system are:
- Anyone can participate.
- All participants will have equal standing.
- Clearly defined and predictable processes.
- All code, tools and documentation will available for all to see and improve.
Maintainers supporting this proposal: