Ways you can help the XStrikeForce:
- Help close bugs:
- (note: there are MANY bugs and this page takes a long time to load).
UDD powered XSF unstable bugs list
- (note: seams a little shorter to load).
Other tasks are listed on the TODO list.
Notes for developers
- When upgrading to a new upstream version, please check if X.org has added any versioned dependencies (for instance check the REQUIRED_MODULES field in configure.ac), and update the Build-Depends in debian/control accordingly.
Maintainership and the Uploaders Field
The XSF is currently in a transitional phase. Previously, due to the nature of the monolithic tree, while the XSF was a team one person was the primary maintainer for the whole thing and carried a great deal of the weight.
Now, with the move to the modular tree, this model does not appear to be as optimal and we are looking at new ways of managing the very large collection of packages under a single team. Debian has traditionally had a one maintainer per package style of maintainership, where that person was the sole owner and decision maker for the package. This model has the benefit of having a person take responsibility for the package, but the disadvantage of discouraging input and work from other maintainers. Ubuntu has pioneered the model where packages are not owned by anyone and whoever is interested can upload fixes. This has the advantage of making it very easy to get cross-package work done, but the disadvantage of not having anyone be ultimately responsible for a package. Because they derived from Debian though, they were able to leverage Debian's ownership model to fill some of this void.
The move to the modular tree presents a new opportunity for the XSF to discover a more optimal way of working. Drawing from the models above, we are in the process of implementing a middle ground between the two, which is meant to make use of the best aspects of both. Here is how it works:
- The maintainer for the package is the X Strike Force, and all bugs go to the debian-x mailing list for all to see. In addition, all decisions of note are discussed on this list. This way, everyone who is on the team or wants to be on the team will not feel left out of the loop on anything.
- The uploaders field for the package defines the practical maintainer for the package. There can be several people in this field if they choose to co-maintain it. This person does not own the package so much as take responsibility for it. "The buck stops here," as it were. This field must be limited to those who are actively maintaining the package, and must be pruned regularly to avoid having too many people. This is something we are currently failing at.
- Anyone in the XSF can upload any package maintained by the team. There obviously needs to be coordination for important uploads like new versions, and you need to follow certain conventions (like how we use svn/git, etc), but essentially team members are free to upload at their discretion. The experimental distribution is essentially wide open at all times, where uploads to unstable should be done with slightly more care, which is the exact same rule you would follow if you were the maintainer for the package.
- Because the modular packages are relatively easy to handle by themselves, the X packages are generally low threshold NMU's, although the XSF needs to stay on top of the work such that these shouldn't have to happen (we need to improve this currently). This also provides easy opportunities for people outside the XSF to join the team.
The key is that the person in the uploaders field takes responsibility for the package. While people uploading packages that they aren't in the uploaders field for must take responsibility for their actions, the person in the uploaders field gets the final say on where the package goes and how it is managed. However, even though they are responsible for the package, they don't own it, the XSF does. Because the team is the actual maintainer, the team can outrank the uploader. This will likely be most important for matters affecting the whole of the X packages. In practice so far though, the person in the uploaders field is treated as the maintainer, and is given full leeway to do what they want to do.
We don't have a formal procedure set up for voting, but it's something we need to establish so that no one can be a dictator for the whole group.
What we have been endeavoring to do is create a culture where people feel responsible for, and take pride in their packages, as well as the product put out by the whole team. They have their corner of X that they're reponsible for, but because they're part of the team the rest of the packages are partially theirs too, they should want to work on them to fix notable problems. We have managed to create a culture very easily where people will upload whatever fixes they want to upload without too much worry. What we have so far failed to do is take up responsibility for the various pieces, although this is in progress and should be completed within another year.
The XSF was the first real team in Debian to maintain a package collaboratively. This set the model for the large number of teams that have come about since. With any luck, the new model for the XSF will once again set the standard for the way teams will operate in the future for Debian.