Re: APT 0.6: let's get started
Michael Banck wrote: On Sat, Feb 19, 2005 at 05:50:18PM +0100, martin f krafft wrote: I am not in the position to complain at this stage in the game, but I think it would have been nice for you to quickly announce the location of continuation of this discussion here... It's the APT development list, so it's what everybody would expect as location for this discussion. Everybody? Nope. Counterproof above. Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
On Sun, Feb 20, 2005 at 09:06:36PM +0100, Goswin von Brederlow wrote: Joel Aelwyn [EMAIL PROTECTED] writes: Now, if the reason is because everyone involved in ftp-master has more crucial tasks to do with getting Sarge out the door, that would be one thing; the answer would be Wait if we're expecting that to last a couple of weeks at most, or train an additional person if we expect it to persist (yes, I *know* training someone costs, but it also pays off fairly rapidly, thus the patience-if-it's-short). The NEW queue hasn't been the most expedient for some time now which would indicate this is a long term problem. Unless the reason for the delay is too many people fighting over the decision then more manpower can't hurt, right. With the caveat that it needs to be manpower usefully applied, I would agree. What useful applications are available is one of the questions. Let me repeat two ideas I mentioned before: I also missed these, previously. Which is a pity. They both seem like they could be quite useful, if the problem is the NEW queue is a pain in the arse to deal with and not very rewarding. - uploads to NEW need an advocate in addition to the normal signature The advocates job would be to test the package, check for packaging mistakes, gross bugs, build failures, license, bad name choice when splitting a package. That sort of thing. This would be helpfull in filtering out more bad uploads to NEW. Is that a frequent thing? How much time is wasted on trivial rejections currently? Hmmm. Seems like it could work, but might still have the issue that finding two maintainers who think something is good is not vastly more difficult than finding one; also, many packages are already co-maintained, would you allow co-maints to both sign it? I believe it *is* possible to get multiple signatures with GnuPG (the same way you can encrypt something to multiple keys), but I'd have to go dig through the docs to figure out how to do it. - a NEW team The new team would be an appointed group (not just random DD as for the advocate) of DDs that do all the checking and testing of NEW packages and recommend to ftp-master to accept a package in the end. This would mean the ftp-master would loose some of their duties and only be the implementing tool (with a veto right?). Having a NM team has worked great to NM. Maybe that success could be repeated. This seems like it might be a little easier. Among other things, processing the NEW queue has very different requirements, in many ways, from the rest of the ftpmaster jobs described in the document. 1) Requires a high degree of interaction with other DDs, including things that can frequently go sour, like rejection notices. Often requires patience and tact beyond what may be reasonable to expect of all DDs, or even all ftpmasters. 2) Requires investingating new packages for things like licensing (thus, needing to follow debian-legal to some degree), requires going over the basics of the package structuring (at least, this seems to often be done; I've had first-pass uploads rejected for being split into too many small pieces, even if we don't expect them to catch bugs), etc. Often tedious. 3) Doesn't (as far as I can see offhand) require access to sensitive accounts, key signatures, or software. Thus, someone who processes NEW as a generate recommendations for ftpmaster can do the job without needing much, if any, in the way of privileged access (possibly some issues with crypto, but those should be easily resolveable). I suspect that if this was a good answer, it would require some startup effort (pick one or two folks to learn the basics, get them up to speed, maybe sort out semi-standard forms and checklists of things which need to be answered, and possibly work out some sort of coordination system, though that might be as simply as yell down the hall emails), after which the NEW processors could do most of the training for additional NEW processors. Certainly either of them seems like a worthwhile thing to try, if the problem is need more manpower; the main question is whether an advocate system is really enough to cut down on the difficulty of the task (I have my doubts, but it might cut down on the number of bad/hard-to-check things getting into the queue in the first place... or might not), or whether having more non-privileged manpower to process the queue down to a simpler Looks good, Looks questionable, here's why or Needs to be rejected, here's why (or give them the power to flat-reject something to them, even) is more useful. Not that I expect, given how this and past conversations have gone, that they'd particularly want to deal with me, but if a NEW processing group is considered worthwhile, consider me volunteered to put in the time. Maybe the work is suitable revenge for having to read or delete so many of my emails. -- Joel Aelwyn [EMAIL PROTECTED]
Re: Roles and responsibilities of the FTPmaster team.
On Sun, Feb 20, 2005 at 12:12:13PM +0100, Martin Schulze wrote: Helen Faulkner wrote: Will that document be put on the web anywhere? It would be good to know where to refer people who are asking about this stuff in the future. That was my thought as well. I wonder if it would be useful to add such descriptions (especially if Matthew will continue with these) would be good to be placed on www.debian.org/devel/ somewhere under Teams or something? How about adding a link to it from www.debian.org/intro/organization/ under the FTP Archives text (in this case) as well? Just another logical place where I'd expect to find it. Cheers Floris -- Debian GNU/Linux -- The power of freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the ftpmasters
On Sat, Feb 19, 2005 at 01:20:09PM +, Matthew Garrett wrote: So, how do we rectify this situation? 1. use democractic processes to fix this; 2. make their lives hell until they talk or quit; 3. telepathy. These all suck. Democratic processes don't carry any weight of obligation on volunteers (especially under our constitution). The right answer is Make people stop bitching about other people so much, but that involves that Make word again, so it's not really a practical option. To the extent that this reduces to make people go away if they are unwilling to respect their fellow developers, I believe it *is* an option. Convincing people to stop bitching of their own accord is a *better* option, but I think we as a community need to deal honestly with the possibility that some people do not advance the goals of the project with their involvement. (As distinct from people not advancing the goals of the project through their *lack* of involvement, which as has been pointed out repeatedly is everyone's right.) In the short term, the easiest way to deal with this is probably to have somebody else mediate information flow. The DPL is an obvious choice, but a more realistic choice may be to have people working with individual teams and passing information back and forth. Separating the people doing the job from the people providing updates removes the direct criticism flow. Sure, why not? Let's give it a try. I am not an ftpmaster, but through personal conversations I know that: - most processing of the NEW queue has of late been done by a single ftpmaster, who has not been actively doing NEW processing this year. I don't know the reason, and haven't asked; I assume that he has succumbed to real-world time constraints, and that the other ftpmasters are aware of this. - another ftpmaster has been moving house this month, with much of the usual network-related pain and anguish that goes with it. - the ftpmasters are generally aware that there is a manpower problem here, as some consideration has been given to a candidate for augmenting the existing team. I don't know if there is currently a timeline for confirming him as an ftpmaster, or what steps lie between now and final approval, but the ftpmasters have certainly not been sitting idly by waiting to be flamed before taking action. So, does this quench the flames, or fan them? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bits from the ftpmasters
Le Lun 21 Février 2005 00:16, Matthew Palmer a écrit : NEW would still have to be processed by hand, though -- crypto notifications still need to be sent, and the protection provided by two crap developers working on a package isn't not that much better than one crap developer working on a package. I don't agree at all. multiple signature has to be used if you have really reviewed the package. And as an XP freak, I guess you should know that cross-reading is really good for code quality. I don't understand why it shouldn't be the same for packages. And since we quite all agree that managing multiple gpg signatures is not *that* difficult, it may worth trying it, doesn't it ? -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpivd3dYpC4i.pgp Description: PGP signature
Re: Bits from the ftpmasters
On Mon, Feb 21, 2005 at 08:23:52AM +0100, Pierre Habouzit wrote: Le Lun 21 F?vrier 2005 00:16, Matthew Palmer a ?crit : NEW would still have to be processed by hand, though -- crypto notifications still need to be sent, and the protection provided by two crap developers working on a package isn't not that much better than one crap developer working on a package. I don't agree at all. multiple signature has to be used if you have really reviewed the package. And as an XP freak, I guess you should know that cross-reading is really good for code quality. I don't understand why it shouldn't be the same for packages. Because there's no guarantee (or even real likelihood) that the two developers whose signatures appear on the package have sufficient Clue to be able to produce quality packages. Pair programming only works when both people are switched on and taking note of their surroundings. The ftpmasters are, in general, senior and clueful DDs, with a good knowledge of the likely high and low points of a package. And since we quite all agree that managing multiple gpg signatures is not *that* difficult, it may worth trying it, doesn't it ? Oh, I think it's a great idea, I'm just not convinced that it'll suffice for clearing the NEW processing delay. - Matt signature.asc Description: Digital signature
