Better (release) coordination on the Alpha port
Hi fellow developers,
I think it's time to stir up some discussions on a better release management
for the Alpha port. The way it's organised now leads to double work and a
non-optimal use of human resources.
To minimize double work we need to work on a list of packages that don't
work on Alpha's. This way nobody needs to upload it unless they invest the
time and energy in porting it and releasing the patch.
An other thing is the availability of patches. I, for one, upload the patches
along with a bugreport to the BTS. But seaching every package for patches that
hasn't been merged is not an easy thing to do. So a list of Alpha specific
patches is very helpful. This way it's also easier to identify if a x.1-z
version is a port patch and if it's related to Alpha. Storing the patches on a
separate place on a server in the same structure as the archive can help as
The best way to share information is to condense Alpha specific problems to a
special list. This list can be send by mail or be available on www (or both).
When all uploads are stored in some sort of database it's easy to notify the
uploader of troubles in a package, even when the changes files are erased from
An other point that can increase productivity is to split autobuildable
packages and problem packages. The autobuilder(s) take the packages that can
reliable be build without breaking dependencies (libc6.1-dev on development
packages for one). The problem packages someone needs to do by hand. A list of
good buildable packages need to be compiled. Assigning packages to a specific
porter can also help although. The downside can be a slower response on base,
required and important packages.
There are surely more points to improve the port so please post other (and
better :-) ) solutions to this list. Using some central point of coordination
can help us as well as the release manager!
B. Warmerdam GNU/Debian Linux
email@example.com, firstname.lastname@example.org (Keyid: 10A0FDD1) ----------------