The aim of the
vcs-pkg project is to investigate the use of version control for distro package maintenance. We bring together people interested in taking the next step in distro package maintenance: the proper integration of version control into the package maintenance workflow.
This effort originated in the bowels of the Debian project, but it’s not specific to Debian. The cross-distro aspect of
vcs-pkg is its most powerful aspect.
Maintainers of a specific package in all distros basically have the same task. We could benefit from each other if we joined forces: less workload, improved access to patches in use by other distros, more structured communication, a wider spread of innovation, etc..
A lot of Debian is already using version control for the task, but everyone cooked up something of their own, more or less. We think the situation is similar in the other distros: the current approach to package maintenance doesn’t scale too well, given today’s needs (teams, offline work, increasing number of users and increased use of the bug trackers), and discussions of how to improve things are on the way, but have not yet carried fruit.
Our goal is to integrate version control with distro package maintenance. We want to recognise all involved in the process, from upstream, the package maintainers of the various distributions, their security and release teams, and power users, who aren’t afraid to fix their own bugs, and give maximum flexibility to them.
vcs-pkg is (D)VCS-agnostic, and it’d be ideal if it stayed that way. However, part of what we do is comparing version control systems and assessing their merits, and one tool may outperform the others. We want to avoid the religious wars of version control and instead argue technically and sensibly about their individual advantages and shortcomings in the context of distro package maintenance. A desired output could be a VCS-agnostic wrapper of the concepts involved in maintaining and developing a distro package of an existing software.
bzr-plugin to work with multiple patches/branches at once (HOWTO, discussion).
Links are arranged in chronological order for the most part, so often the ones further down are more “contemporary” and might be closer to the current best-practice, as far as there is one.