[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some questions for the candidates...


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

> 	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

> 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...

Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com

Attachment: pgplOLnGqunSd.pgp
Description: PGP signature

Reply to: