Re: More questions to the candidates
* Konstantinos Margaritis <markos@debian.org> [2004-03-14 22:48]:
> 1. Debian currently supports more than 10 arches (just a quick check
> in /ports. Obviously, trying to keep in sync all of them is too
> much. And I hope I'm not the only one who sees that it's
> increasingly becoming a burden to insist to keep in sync slow arches
> like arm, mips* and m68k. And IMHO, keeping in sync arches that have
> a 20y difference in technology is ridiculous.
> My question: Do you believe that Debian should for ever support all
> arches in parallel? Or establish some kind of "speed lanes" for fast
> arches, slow arches, etc. For example if Debian/m68k is used by
> embedded people, there is little use in building all of KDE/Gnome
> for m68k.
I think there are a lot of advantages to supporting those
architectures, both to our users and the free software community as a
whole. While many commercial Linux distributions drop ports which are
not longer financially interesting, we support them as long as their
is interest. Also, by auto building our whole archive on those
platforms, we help testing GCC and the kernel. This way, Debian has
reported a lot of bugs (especially toolchain bugs), which leads to
better free software.
So far, we have done a pretty good job of supporting all of these
architectures. I'm aware that there are problems from time to time,
usually on a different architecture. In a recent posting, archived at
http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg00463.html
I outlined the status of ARM, mips and mipsel. In short, we have to
set up a good buildd infrastructure with enough systems so they can
keep up. We have had problems due to lack of hardware, but I am
working together with the port maintainers of mk68, ARM, mips and
mipsel to add more redundancy. For example, one new MIPS box has just
been added as a buildd, and another one is being set up.
As to building KDE and GNOME: I agree that there are some packages
which do not necessarily have to be built on all architectures. This
is also technically feasible by removing the packages on that
architecture from the archive and telling buildd not to build it
anymore. The respective porters are responsible to make that
decision.
In summary, I think supporting those architectures is a good things,
as long as it's possible and does not slow down the overall release
cycle. At the moment, our release is not waiting for slow
architectures to catch up, but on totally different things. I'd
therefore suggest to first fix those things (e.g. RC bugs). I'm aware
that there are problems with certain architectures, but it usually
changes which architecture has problems. What we have to do, and I am
working on this together with the port maintainer, is to setup a more
reliable infrastructure so there are no problems if one machine goes
down.
> 2. Two of the candidates (Branden and Martin) have talked about the
> development of processes around Debian, so that things get done
> right and without unnecessary delays. While the theory is perfect
> and I wholeheartidly agree, the implementation is what interests me
> most. How do you plan on implementing processes in Debian and what
> timeschedules you have for that? It's no good saying that you have a
> 10-year plan for developing a perfect process-driven Debian. Instead
> of doing a theoritical analysis on the subject I would appreciate a
> discussion on some specific part of Debian (pick the one you intend
> to deal with first, if you get elected).
You ask how I "plan on implementing processes". This suggests that we
currently don't have any processes. However, this is not the case.
There are lot's of processes in Debian (e.g. doing an NMU, this is a
clearly defined process). I suggest that some of them have to be
better documented so other people understand better what is going on
(e.g. how does NEW processing work).
Basically, I see it as my task that all of the processes in Debian
work smoothly. If there is a problem in a process because of
manpower, I'll try to find more people. If there is a problem in a
process because of communication, I'll look at that issue. etc. In
short, I will look at how the process works, why there are currently
problems with it, and then find solutions for getting the process back
on track. Fortunately, I know already how many of the processes in
Debian work, and know the people involved, which makes understanding
problems and fixing them easier.
In my platform, I mentioned that many core teams have not grown as
much as the rest of Debian. I think this is the area that needs most
attention in the near future. However, different core teams will need
different solutions. In one core team, adding one or two people might
solve the problem, while in another case you actually have to refine
the whole process in order to make it scale.
> 3. What are your plans about Java in Debian? I understand that Java
> license is not Debian's decision, but Debian can push -and I gladly
> witnessed some productive discussion between Martin and Simon Phipps
> (Sun's CTO) in Malaga. From my own discussion with Mr. Phipps, it
> seems that a lot of Java's license problems are because of
> misunderstanding inside Sun wrt to Java turning truly Free. Debian
> should care for its users and many of its users use Java. My
> question: What are your plans to try and establish/strengthen the
> communication link with Sun/whoever to ensure that there is a
> workable Java implementation in Debian? I know about Kaffe, before
> someone corrects me, there is (almost) noone in the commercial world
> that uses it.
As I mentioned in a recent d-d-a posting, I helped out Java
maintainers coordinate a meeting at FOSDEM with developers working on
free Java implementations. The purpose of this meeting was to work
out what needs to be done to move Java packages from contrib to main.
The meeting was quite successful, and a report has been posted at
http://lists.debian.org/debian-project/2004/debian-project-200403/msg00006.html
As you are aware, I also discussed freeing up Sun's Java with Simon
Phipps at the conference in Malaga. I met Simon before at a
conference organized by MIT and Harvard, and I know that he cares
about the free software community. While he would personally like to
make Sun's Java free immediately, there are various issues which have
to be worked out first. One huge step has recently been taken and the
license changed in order to actually allow them to make their Java
implementation free. Since this happened, there is a run between Sun,
IBM and others to make their Java free. Sun knows that they would
lose a lot if e.g. IBM would free their Java implementation before Sun
does. In Malaga, I promised Simon to send him a listing of things
Debian would like to see from Sun. I received some input from Debian
developers on this, and I'll mail Simon tomorrow. I will of course
mention Java again, and offer our help if there's anything we can do.
In summary, I enable interaction between our Java maintainers and
developers on free Java implementations, as well as work with Sun by
giving them reasons why they should make their Java implementation
free.
> 4. Transition from non-free. Please give a specific plan that you
> intend to suggest if removal of non-free is voted. I don't care if
> non-free is removed but to just remove it one instant is
> irresponsible, imho.
I agree that simply removing non-free without having a transition plan
would be very irresponsible (as I mentioned on -vote before). While I
personally would like to see non-free removed (again, as DPL I
represent the whole Debian community and don't just follow my personal
opinion), I think we need a clear transition plan.
In my opinion, the transition should look like this:
- a separate archive (e.g. non-free.org) should be set up, along with
other infrastructure, such as a bug tracking system.
- Packages should be moved there, bug reports migrated, etc
- non-free packages uploaded to Debian would automatically be
uploaded there.
- Users should be asked to update their APT sources line to use
non-free.org
- At the same time, the current APT sources line (i.e. *debian.org
non-free) will still be supported. That is, Debian would mirror
non-free packages for about a year or two in order to give people
a chance to change their APT sources line.
Ideally, we would update all non-free packages before a Debian release
to say "Origin: non-free". This way, bug reports would automatically
be sent to non-free.org.
> 5. Debian has become quite big, much bigger than the previous years.
> In fact, I have come to believe that it's too large a project for one
> person to coordinate. Branded has explicitly talked about delegates
> for tasks.
Please don't get the impression that I am trying to do everything
myself. This would be insane and not work at all. I regularly ask
other people to perform certain tasks.
> My question: Do you think that you can handle all of the tasks a DPL
> is supposed to do?
Yes, and I've shown that I'm capable of doing so in my first year.
> If you have packages to maintain do you plan to keep them as well?
> If at some point you realize that you cannot take it anymore, what
> will be your action?
I have answered this question in
http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00128.html
Please see question C. Feel free to ask additional questions if I
have not asked them there.
> 6. Debian delegate selection
> How would you choose a delegate for a position?
It depends whether there are people working on this area already. If
not, I will:
- clearly identify the roles and responsibility of this position, and
which kind of skills are needed for it (technical, communication,
etc).
- Find someone who:
- has the skills
- is interested
- has enough time
(not necessarily in this order)
If other people are working on this area already, I will also:
- make sure that person can work with the existing team and fits
in nicely.
This is *roughly* what my process would look like - however, I have
never explicitly spelled it out before, so there might be a few things
I have forgotten to mention right now. (This is the problem of tacit
knowledge. For example, try to describe how to use a bike. Most of
us know how to use a bike, but it's incredibly hard to actually
describe in words.)
> PS. Martin, one correction wrt your platform text. I don't work on a
> Debian based distro in Greece, I work -semi-officially- on adding
> Greek support _into_ Debian itself, there is no distro :-)
Yes, I'm aware of this, and as I outlined in "External/internal -
Debian based Distributions" I think this is the way to go. As
reference, I wrote this in my platform:
| Just imagine the great advances we can make if there are a few paid
| people in countries like Brazil, Greece, Norway and Spain (which are
| all working on Debian based distributions).
I apologize that this was not clear. It should say "(which are all
working on Debian based distributions or extending Debian for their
needs)".
--
Martin Michlmayr
tbm@cyrius.com
Reply to: