On Friday 16 March 2007 18:34, dann frazier wrote: > On Fri, Mar 16, 2007 at 02:19:11AM +0100, Frans Pop wrote: > > In the D-I team we treat the Uploaders field differently. Uploaders > > are people who actually coordinate the package or do frequent uploads > > because of their role in the project (e.g. the release manager). > > Thanks for this description Frans. Is this treatment simply "the way > it has always done it", or are their other justifications/polices > around it? AFAIK (from looking at the uploader fields in D-I packages) it has always done roughly this way: someone will start a component and he/she will initially be the only uploader. People only add themselves if they get involved enough to also take responsibility for managing the component (with consensus from the current uploader), or if they take over as primairy maintainer because the previous person has become inactive. The last happens quite often for architecture specific components; for those you also see people adding themselves for an incidental upload if a bug needs to be closed. AFAIK (but note that my history with D-I goes back less than 3 years) it has never been the practice to just add yourself to Uploaders for any random change in any random component. It would at least be discussed on IRC. The current D-I release manager and core developers (Joey, Colin, me) are uploaders for a lot of packages because we also do "batch" uploads of pending changes and translation updates for components. Even then I normally only add myself as uploader if the changelog contains a bug closure. Us three will always do a mental check of the changes in a component and see if it could affect other components. We will also generally stay alert to installation reports over the next few weeks for indications of regressions. The debian-installer package itself [1] will normally only be uploaded by one person: the current D-I release manager (although Joey could cover for me if that would be needed). The main reason for that is that releasing D-I takes a huge amount of preparation and coordination. I often wish that the kernel team gave more attention to a more open form of release management: coordination with other teams, announcements, planning of stabilization, tracking of major issues. At the moment it is IMHO too much "Are we ready to upload? OK, let's do it. Done. What's the next upstream release?". > For example, if you are not currently in Uploaders and you wish to do > an upload, do you just add yourself to Uploaders and upload? Or, must > you achieve a rough consensus among the other uploaders and/or the > release manager? Or, eg., does the d-i team use this because they > believe it provides information to the outside world such as "these > are the people I need to poke about accepting my patch", etch? Most of this has been covered above. The last point makes sense too, but mostly for the d-i components: it is often useful for users to be able to see who they could poke if a question they deem important enough looks to be forgotten. In general for me the Uploaders field is not a "vanity" field: if you are on the team, you should be in it. It is a primarily a technical field. I know other teams (e.g. Gnome team) treat it differently. If you want to have a list of team members or porters in the package, I would suggest to maintain a file in /usr/share/doc (compare the kernel itself where MAINTAINERS has the subsystem leads; note: also only the leads, not all contributors). Of course the kernel is a lot different from D-I and more like other packages with an external upstream. However, it is similar in the respect that the kernel should not "just be uploaded". The ports need to be checked, other teams (d-i, RMs, ...) need to be informed, maybe a last check of upstream changes, technical checks like ABI changes, ... IMO it makes sense to only list people as uploaders who are trusted by the team to take responsibility for all that. An example of the consequences of limited release management is the long time it took to stabilize 2.6.18 for Etch (although I am aware of the external factors - mainly the memory corruption bug - in that). Cheers, FJP [1] debian-installer currently has only 4 uploaders of which two could and probably should be removed; I am planning a cleanup of uploader fields sometime soon.
Attachment:
pgpQz75PIU5Iz.pgp
Description: PGP signature