There are currently several larger and smaller repos providing quality rpm packages. Possibly all or most of these repos could benefit from merging into a common packaging project.
The incentive for repo maintainers to join such a project needs to be an improvement from the respective current situation. There are many reasons for consolidation:
- reducing manpower per package due to overlap: Some packages exist in many repos
- OTOH more eyeballs/testers for the same common package now results to higher quality/functionality
- better compatibility of packages
- common infrastructure (build systems, mirrors)
- extending to more platforms
- easier contribution channels
- less confused users
There are also some against:
- no more 100% sovereignty, need to play according to common rules
- conflict situations may arise
- different ideas on per package contents or per repo contents
The aim of the first phase of this project will be to try to collect all goals/requirements of the interested repos. Therefore this manifesto will not contain any requirements/goals.
The proposal is to setup the following phases. The first phases are suggested to be in private communication between the repo maintainers as these are the phases where repos will join or not the project and we'd like to keep a good signal to noise ratio.
- invitation phase (private)
- Existing repo maintainers are contacted
- formulating goals (private)
- The project's parameters are freely discussed. At this point in time everything is under discussion. At the end of this phase a set of goals will come out that hopefully many repo maintainers will agree with and proceed with the common packaging project. It is important to have firm commitment at the end, so the analysis of current goals and practices of different repos and their coexistence in a common repo is very important. Also for the upcoming work items some decision mechanism must be put in place (voting).
- formulating rules and specifications
- After having layed out the basic goals we need to setup specific rules of operation, most notably this contains package contents and (sub)repo contents, as well as conflict resolution and escalation management.
- setting up infrastructure and further implementation parts
- having fun