Hi All, It's time to change the way OpenCSW packages are released. The current system has many flaws and inconsistencies that cause frustration among maintainers. Changing the process isn't a new idea. Several proposals have hit the maintainers list in the past. What's different this time is that there is something to back the proposal up! Maciej has been busy coding. Other maintainers have been diligently providing feedback and suggestions for improvements. Many of us are currently using the new process.
As I type this, it's possible to use gar/v2/bin/csw-upload-pkg to submit your packages to the unstable catalog in opencsw-future that sees them immediately cataloged and available for download. At this point, the only thing lacking in the new process is the gpg signing of the catalog. Although this will be addressed before any official switch to this tool, we feel that it's time to open the doors to wider testing of the new process. You are encouraged to kick the tires on this new tool and provide feedback that can be incorporated to make it better. Going forward, I formally propose that the current release system be abolished in favour of an automated one. This will entail: 1. All packages are submitted to unstable via csw-upload-pkg. 2. After 2 weeks in unstable with no bugs filed, they are automatically promoted to current. Users are free to pull from unstable directly (just as they can in debian), but most will wait for current. The experimental catalogs on the buildfarm will remain unchanged as they're a good way to deliver quick downloads for personal or bugfix testing. Objections to this type of automation in the past have focused on the benefits of the human inspection that we have currently. Nobody is disputing that having other eyes on a package is a good thing. We hope that people will continue poking at the packages in unstable and filing bug reports. We're attempting to address the following issue with the current process without reducing the ability for human QA: 1. Inconsistent application of policy. Multiple tools that implement different standards or the same standards differently are self defeating. 2. An und(er)ocumented, manual process with no way to know where a package sits or why it sits there. 3. Subject to time availability of a single person. (Redundancy exists on paper but not in practice.) 4. Packages may be stalled for non-policy reasons. The new process will address these areas as follows: A package that fails Maciej's version of checkpkg will be rejected. If checkpkg is ok with it, it will be released into unstable. If problems are discovered by use and/or manual inspection of the packages, a bug can be filed and the issue discussed on the list. At resolution time, checkpkg will be augmented to catch the new problem or the problem will be deemend 'not a bug.' The process will be fully knowable. The tools are open to all. The back end handling for everything will be fully documented[1]. Packages can be released when you're ready, at any time of day. All policy issues will require discussion on the list where all voices are equal. Votes will be held when required to decide issues, but in many cases, we hope they aren't necessary as consensus will be reached quickly. Any and all feedback is welcomed. Update your GAR checkouts and give this a whirl! Watch activity in the new catalog by subscribing to an atom feed for the catalogs[2]. Thanks -Ben [1] http://wiki.opencsw.org/automated-release-process [2] http://buildfarm.opencsw.org/~bwalton -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
