Hi Stefano, On Mon, Aug 3, 2009 at 09:21, Stefano Zacchiroli<z...@debian.org> wrote: > On Mon, Aug 03, 2009 at 07:29:20AM +0200, Luk Claes wrote: >> > some questions I still see without a clear answer: > > ACK on most answers from Luk, some more comments on some of them > below. > >> > - what about non-DDs that are currently tracked in MIA database, >> > along with DDs? >> Nothing changes regarding MIA. > > Yes and no. My hope is that the implementation of this proposal would > significantly reduce the workload of MIA, letting that team work only > on non-DD maintainers.
That is the much more time-consuming than checking DDs. for our fellow DDs we have several data sources (mls posts, uploads, key usage) to track them, while we don't have anything similar for non-DDs. So several manual researches are needed (either on lists.d.o, google, etc etc). So, while removing the "easiest" part (checking DDs) we are left with the most difficult and time-consuming part. >> > - what will happen to the packages of DDs deactivated by this >> > proposal? > > I consider this totally orthogonal to the proposal per se and hence I, > on purpose, avoided to raise the issue in the thread. See below. > >> Like with the WAT runs, there will very probably be a feedback to >> the MIA Team. > > Uhm, I would prefer having feedback from that to QA directly. MIA is > needed to discover missing-in-action people. With the implementation > of this proposal we will know, among DD ranks, who is MIA without > needing to chasing it any more. Hence the notification can, for this > specific case, bypass MIA. But sure, downstream the effects should be > the same as for packages of non-DD maintainers discovered to be MIA. > > What to do with such notification is a (not new) topic for -qa, not > -project. Ok, so there should be a communication of removed DDs, at least on -private, so that DDs working on QA at least know it. if you/other feel it unappropriate, please suggest some other form of communication or ways to handle this. either in this proposal or at a later stage. >> > - will the MIA team be dismantled? who's in charge of this? will you >> > take care of removing all the traces of MIA team from Debian >> > documentations (like wiki, devref, etc) or from wherever is >> > referenced? (of course, if we decide to remove it and not "archive") >> > or edit them, where needed? >> >> You are mixing WAT and MIA apparently. The current proposal may replace >> the DAM's WAT runs AFAICS, it does *not* affect MIA except from the >> feedback generated after deactivation of DDs. > > ACK. Again, I don't see MIA "dying" due to this proposal, I only see > it re-focusing his work on non-DD maintainers. see above: this way our work is reduced in number, to focus on the most annoying, difficult, quite frustrating and pointless (non-DDs are not part of the project, in a strict sense (don't get me wrong here, I know they are valuable contributors, but they can't vote, blablabla)). But I also have to be honest and affirm that we receive much less requests for non-DDs than for DDs. >> > - what to do about the current (yet unanswered) queries we've >> > received? should we reply "please wait for <this> to be approved"? >> > should we fulfill? when should we stop operations? (I'm personally not >> > that motivated to work on something that's dying.) >> There is no reason at all to change processing. > > Still, the question of what should be done in the interim for DD > maintainers while the proposal actually gets implemented is a good > one. Here we have a trade-off: on one hand you don't want to invest a > lot of time in accounts that will be spotted more easily at the first > run of this proposal; on the other hand, if the proposal gets time to > get implemented (hey, here we're talking, but the burden of putting it > up to speed has been pushed to somebody else!) you don't want to loose > "MIA-chasing" abilities. > > I don't have _the_ answer for that. What I can do, if you are > interested, is to hand over the list of potentially disabled DDs to > pinpoint your MIA queries at them and avoid/focus MIA activities > elsewhere. Of course it would be welcome: I'll cross check the current "TODO" list marking as 'pending on the proposal to be implemented' accordingly. >> > discuss with) the MIA team about this proposal (since the team main >> > activities are under discussion here), either before or after your >> > made it public. > > /me rolls eyes o_O > > It is true that I did not contact the MIA team in the first place; I > do apologize for that, but at my defense I stress that I did not see, > as I do not see now, this proposal dismantling MIA. Nevertheless, > after my first message to -project some weeks ago you, as the only > active MIA team member AFAIK, Well, I might be the "most" active, not the only one. > contacted me on IRC. At the end of that Yes, I contacted you, and I was quite surprised by this sudden proposal. Probably I should have made clear at that time that a contact would have been welcome. > brief chat, my understanding was that we agreed upon seeing how the > proposal was going to be received on -project. Yes, I wanted to see how's going (in fact I didn't reply to the original thread), but since I think some points where still unanswered, I took this update to ask them. > I still do not see > which "problem" this proposal causes to MIA and MIA team. I think (I hope) I've explained above. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org