Re: Emphasize teams, not packages
(M-F-T set.) [Frans Jessop] When somebody wants to become a DD he is told ?Go find a package to maintain, one that you can be the maintainer for.? I see serious problems with this approach as Debian increases in DD's. I will how this is in a second. What I think should be emphasized is ?Go find a package team and join it and contribute and show your stuff.? The point of maintaining a package is to prove that you *can* maintain a package. Being on a team proves nothing. Being on a team and doing most of the work proves something, if this can be measured, but that's difficult. As it happens, I'm on at least one team where I do a majority of the work, and at least one team in name only (haven't yet done *any* work). I don't particularly expect to be judged favorably for the one or unfavorably for the other, because it's just too hard to get the data. I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Besides, there are lots of things we need to emphasise in Debian. We've had those conversations, too. Future A: There are now 10,000 DD's and over 100,000 packages, most nobody uses, they are just there because they were needed by people who wanted to become DD's. Obvious solution: Change the requirement from maintain a package to maintain a package that a significant number of people care about. Since AMs / DAMs are people rather than machines, we don't need an accurate automated metric for this - something as vague as popcon should be quite sufficient to reveal the difference between useful packages and pet packages only ever installed by people who said to themselves hmmm I wonder what this does and then never bothered to uninstall them. signature.asc Description: Digital signature
Re: Emphasize teams, not packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006 04:55:57 -0600 Peter Samuelson [EMAIL PROTECTED] wrote: [Frans Jessop] When somebody wants to become a DD he is told ?Go find a package to maintain, one that you can be the maintainer for.? I see serious problems with this approach as Debian increases in DD's. I will how this is in a second. What I think should be emphasized is ?Go find a package team and join it and contribute and show your stuff.? The point of maintaining a package is to prove that you *can* maintain a package. Being on a team proves nothing. Being on a team and doing most of the work proves something, if this can be measured, but that's difficult. As it happens, I'm on at least one team where I do a majority of the work, and at least one team in name only (haven't yet done *any* work). I don't particularly expect to be judged favorably for the one or unfavorably for the other, because it's just too hard to get the data. It is too hard to read the changelogs where it is (or at least should be) clearly documented who from a team did what parts of the packaging. I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Please provide a reference to that discussion. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDy4QCn7DbMsAkQLgRApjHAJwIXDOSpDIdbCbKIM9NdyX1Ll409ACgoXTU So7uXuAyCmdJgap/jUy7DuA= =x8EH -END PGP SIGNATURE-
Re: Emphasize teams, not packages
[Jonas Smedegaard] It is too hard to read the changelogs where it is (or at least should be) clearly documented who from a team did what parts of the packaging. I agree that it's too hard, but I don't agree with the rest of that. The debian changelog doesn't typically say much about who's doing the testing, who's reproducing the bugs, who's forwarding bugs upstream and working with upstream to resolve them, and several other tasks the debian maintainer is expected to do. Nor does the debian changelog typically give an accurate picture of how easy or hard each line item was to achieve. Nor does it explain anything about whether the person who added the line items got them right or wrong, whether anyone else is covering for his mistakes before a package is finally uploaded. Much fuller pictures emerge from the combined logs of the version control system and the BTS, but estimating who is doing most of the work on a package based on *those* logs is a tedious and subjective process. This tedious and subjective process isn't something I'd expect an AM or DAM to want to undertake. Particularly when an example of solo maintenance is available to analyse instead. The most credit I'd expect any NM candidate to get from a team-maintained package is a few words of endorsement from co-maintainers. I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Please provide a reference to that discussion. google://site:lists.debian.org+team+maintenance The first hit is a great example, http://lists.debian.org/debian-devel/2005/08/msg00712.html and a rather long thread following. The fat subthread starting at http://lists.debian.org/debian-devel/2005/12/msg01055.html is another. It surprises me that you missed both of those threads. If you are interested in promoting team maintenance, I suggest you read them in the archives, to avoid repetition. Team maintenance, and the advantages and disadvantages thereof, is a very old and tired subject. signature.asc Description: Digital signature
Re: Emphasize teams, not packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jan 2006 07:46:50 -0600 Peter Samuelson [EMAIL PROTECTED] wrote: [Jonas Smedegaard] It is too hard to read the changelogs where it is (or at least should be) clearly documented who from a team did what parts of the packaging. I agree that it's too hard, but I don't agree with the rest of that. Ahem - serious typo: I meant to question, not state, the above. The debian changelog doesn't typically say much about who's doing the testing, who's reproducing the bugs, who's forwarding bugs upstream and working with upstream to resolve them, and several other tasks the debian maintainer is expected to do. Nor does the debian changelog typically give an accurate picture of how easy or hard each line item was to achieve. Nor does it explain anything about whether the person who added the line items got them right or wrong, whether anyone else is covering for his mistakes before a package is finally uploaded. This is true wether or not the package is team-maintained: You cannot easily see from the final package if it was dead easy or hard to do. If mistakes was done that was later corrected (by yourself or by others sitting next to you, upstream getting annoyed with your bad promotion of their work, or something else). But you can get a glimpse. And with team-maintained packages you can even ask the others from the team straight out: How much of this or that was actually done by our NM? I think Debian needs to emphasize teams packaging, not just individuals for many reasons. We've had this conversation already. So I'll skip it. Please provide a reference to that discussion. google://site:lists.debian.org+team+maintenance The first hit is a great example, http://lists.debian.org/debian-devel/2005/08/msg00712.html and a rather long thread following. The fat subthread starting at http://lists.debian.org/debian-devel/2005/12/msg01055.html is another. It surprises me that you missed both of those threads. If you are interested in promoting team maintenance, I suggest you read them in the archives, to avoid repetition. Team maintenance, and the advantages and disadvantages thereof, is a very old and tired subject. Thanks. I'll shut up now and go read... :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDy7W+n7DbMsAkQLgRAsLfAJ0VRXvraZTDVkN2f4J4Qp4vPZbouQCeMzj4 Fm1PcaJ5KDSaYC47s5KzZf4= =FBE4 -END PGP SIGNATURE-
Re: Emphasize teams, not packages
Peter Samuelson wrote: The point of maintaining a package is to prove that you *can* maintain a package. Being on a team proves nothing. Being on a team and doing most of the work proves something, if this can be measured, but that's difficult. As it happens, I'm on at least one team where I do a majority of the work, and at least one team in name only (haven't yet done *any* work). I don't particularly expect to be judged favorably for the one or unfavorably for the other, because it's just too hard to get the data. My experience with participating in teams in Debian suggests that the NM people give a lot of weight to recommendations about team members, and that working with someone in a team gives a much better feel for their skill set and overall suitability than installing some package they put together, and leads to more detailed and strong recommendations to NM. -- see shy jo signature.asc Description: Digital signature
