Hi, Le Wed, Mar 06, 2002 at 07:45:02PM +1000, Anthony Towns écrivait: > Some questions for the DPL candidates... Dozens of questions ! ;-) > Such motivation is arguably my responsibility, so it's arguable that > these delays (in getting people to start working on boot-floppies > and fixing RC bugs in base) were mostly due to me focussing on the > pools/testing roll-out early in the piece. The candidates might have > some views on things that can be done about that, but at the very least Well, yes I believe that base should be always mostly ready. How to achieve that ? I guess that we need more maintainers for each base package. So that's one of the goals of the "Promote the PTS" project. > it seems unlikely there'll be any transitions on quite the same scale > for a while. OTOH, if Raphael's plan gets implemented, it might be a > problem again, and perhaps he'll want to comment on that aspect. I don't think that my plan would cause so many headaches. Because : - I don't change anything, the pool is kept like it is - I just add two new distributions. The "working" one would be created by copying the last stable release. The "releasable" one would be generated by a copy of the testing script adjusted with s/unstable/working/g and s/testing/releasable/g. (actually it's certainly not true since we probably would like some special rules but it's just to show that it isn't too much to do) Basically we extend what we have, we don't change everything. I believe that you could manage that in a few months (let's say 4). And of course, the usual work would continue in unstable/testing during the change. > platform does on working out solutions to improving the release process > at the moment. I think that's much better left 'til *after* the release > is over. I agree, it's just to show that I have ideas about the release and that we'll make some changes if I am elected. But everything is open to discussion, my project is just a base for the discussion, it's not yet something ready to be implemented. > Once these things are done, we'll be releasing. Once that's done, we'll > have a nice relaxing flamewar about what happened and what we'll do > next time. That's my plan too. :) > What do you consider the DPL's field? > - as an intelligent rubber stamp as per the constitution? (ie, > spending money, giving people who're already doing a job an > official "delegation", etc) Yes, giving credits to those who work hard is part of DPL's job. It's important since we all know that pride is one of the motivation behind lany developers. > - poltical issues? Yes, at least for Debian political issues. More general issues (free software in general, crypto regulation laws, ...) may be better treated by other associations, however I wish we could support them by acknowledging some of their actions that we do believe as good for the free software in general. > - technical leadership? Not really, we are quite good a taking technical decisions (the leader can participate of course but he's not more influencial than any other developer). And we already have the technical committee to resolve the controversial issues. > - design or implementation of technical changes? It depends on what kind of technical changes you think about. Technical changes that affect Debian's way of working (ie Debian's infrastructure), yes. Otherwise not really, it's more debian-policy which defines the changes in our packaging rules. > As DPL, how will you ensure the technical goals in your platform are > achieved? I'll pester the volunteers who will do the work. :-) I'm quite familiar on how to get things done, I'll give all the necessary advice to help the motivated volunteers. I'll also work on some of the projects. > talked about? Raphael, how will you ensure that the "second > security team" becomes more of a reality if you're elected, than > the similar thing Ben talked about last year [1] did? Branden, Several of the projects have been suggested to me by other Debian developers who are motivated to work on those. I'll give them access to what they need to get the work done. :-D I'll also work on promoting the various projects so that they find all the volunteers required to make it happen. BTW, my projects is not the same than BenC's one of least year. He wanted to audit the source code of software, I just want to improve our way of getting fixes into testing/unstable (and working/releasable :)). > If you aren't elected DPL, what does that mean for the items in your > platform? Will you spend time over the next twelve months helping > motivate the project, or recruiting people to adopt packages, or trying > to ensure the developer base is active, or any of the other things in > your platforms anyway? Yes, I'll do, but I certainly can't manage everything alone and I'd like that whoever is elected could pick some of my ideas so that I can get help for doing them. > 1. Releasing woody [BenC, Branden, Bdale] > 3. Getting a handle on our bugs [BenC] Both of these are more or less related for me. Having packages better maintained would help the release process. I don't think there is any miraculous solution that BenC could have done himself. I believe that the only solution is more manpower for each package and I hope to achieve that gradually with the PTS and the other projects (cvs for packages, ...). I think that it's a long term solution, and that there's no solution with immediate visible results. > 2. Getting control over our new maintainer process [BenC] I'm quite happy with the current situation, the only thing that worries me is the DAM whose way of working is not always self-evident. He's doing quite a good job since new maintainers are added regularly but there's no clear evidence of the status of the applicant once he's at "DAM approval stage". Some are processed within a few days, while other wait for weeks (and the order of submission is not always respected), I'd like him to give answers so that the applicant knows his status (let's say for applicants who are at "DAM approval" for more than 3 weeks for example). Sometimes I find very skilled applicants who are waiting at DAM approval for several weeks without news and I'm tempted to contact the DAM to tell him that this applicant merits to be a DD but I wonder if that is beneficial or not for him... :) > How well or poorly do you think we've gone at _avoiding_ problems due > to each of the following? Same qualifications. > > 1. Accumulation of inactive maintainers [Branden] > 2. Accumulation of unmaintained packages [Branden] Serious efforts have been made under the impulsion of Martin Michlmayr and we probably avoided many problems due to that. But we can avoid even more ... by documenting how to deal with MIA developer and by tracking the state of developer/packages automatically. > 3. Inconsistent timliness of security advisories [Branden] The work of the security team is pretty good. We just need to keep up and to extend it to testing/unstable. > Just for kicks, what did you think were the three big achievements > we actually had in the last year, and the three biggest problems we > actually faced? (If you haven't already been horribly biassed by the > list of problems at the start of this message, anyway) I'm not good at categorizing the progress and the problems we faced. They are all related. Sometimes simple things make big changes, I'm thinking for example about the new DELAYED incoming stuff. The implementation was quite easy but it's still something very useful as you you can make your NMU and don't need to worry for uploading 5 days later if the maintainer hasn't responded. We also progressed in the bug tracking area, the tags (I don't know how old they are) are very useful once integrated within the RCB list for example, it's great to be able to see if a patch is available with a simple look. I could continue with many other things (new maintainer team, new incoming, pts, ...), they are all positive in the long run. Our biggest problems are related to our human nature, we aren't always motivated and as such we don't always do our maintainer job, we disappear, we come back, we forget answering mails, ... it's not something that can be easily corrected. Backup maintainers are the only solution that I know of at this time. But this is a change that needs time to get into our habits. (It's like the "fear of doing NMU", you know it's hard to make it change ...). > Top three things you hope Debian will achieve during the next twelve > months? Top three problems you think Debian will face during the same > period? Are there any longer term goals or concerns we should be worrying > about, and, if so, what needs to be done about them in the next twelve > months? I guess my platform answers all of that. > Do you think there's anything that can or ought to be done about changing > the trend of the graph at http://bugs.debian.org/~ajt/graph.png ? Yes, recruit more people for each package. It's quite incredible, but the more we are the more we need to be. > and debian-installer, eg. What, if anything, can or should be done to > ensure these things actually get finished and released? It's not DPL's reponsibility, since I said he's not a technical leader. But if the teams who started the projects have difficulties, they may want to contact the leader to ask him help into getting more help (ie the leader may try to promote the subproject). > Do you think Debian should continue to support the LSB? If so, what do you > plan on doing to ensure issues like the bin uid and filetype detection are > resolved satisfactorily? If not, what, if anything, should we do instead? Yeah, we should continue with the LSB, much like we're already doing even we face problems with them. Maybe have one or more official representatives of Debian (ie have them recognized as such on w.d.o/intro/organization). > Should Debian (or SPI) be involved in distributing data (as opposed to > programs) that can be distributed, and might be useful for Debian users, > eg the RFCs, the Bible, books from Project Gutenburg, desktop theme > packages, or game data files? I don't know, really. It's a difficult subject ... i'd like something like that but I don't think I'd want it to be done under the umbrella of Debian or SPI. > Is there anything that Debian (or SPI) can or should be doing (either in > the next twelve months or longer term) to promote more open media formats? Nothing that I can think of, but I'm always open to new initiatives. > Is there anything that Debian can or should be doing (either in the next > twelve months or longer term) to make SPI more useful? I'd happily delegate that part to Overfiend who is interested by the Debian-SPI cooperation. I have to admit that I don't know much of SPI internal working apart from the news I have on -private from time to time. > What's more important: being as open as possible about things, > getting them done in a timely manner, or avoiding making a decision on > controversial topics? There must be a median point ... somewhere between the two first items. > Will you be at the next linux.conf.au in Perth, January 2003? I don't know yet. > Do you think any of these questions were biassed or prejudicial? If > so, don't you think you're being a bit overly sensitive for a pompous > blowhard? Well, your questions were interesting, I took much time to answer and there are some questions that I didn't investigate fully... As for the "overly sensitive", I think it's one point where I'm quite good. I have been flamed several times (including by Overfiend :)) but I don't get upset about it, I don't leave when I get bashed. That doesn't mean that I appreciate flames ... :-) I'd like that more developers could resist to flames because loosing man power due to flames is a bit disgusting. I wish we could be more prone to educate people instead of flaming them. Some flamers tend to consider that people are dumb when they only lacking a bit of experience... Cheers, -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Formation Linux et logiciel libre : http://www.logidee.com
Attachment:
pgplOLnGqunSd.pgp
Description: PGP signature