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

Re: More questions to the candidates

On Sun, Mar 14, 2004 at 10:48:48PM +0200, Konstantinos Margaritis wrote:
> 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.

Supporting architectures in parallel makes one thing harder: actually
releasing.  It makes a lot of other things much easier, and I suspect
the costs and inefficiencies that would be introduced by skewing the
release cycle on a per-architecture basis would hurt us more than help

I do not intend at present to make a proclamation as DPL on this point.
The status quo seems superior to the "speed lanes" alternative you

I think the best fix for buildds slowing down migrations of packages
from sid to sarge is to improve the buildd infrastructure (be it in
terms of actual machines, personnel, communication, or what-have-you).

If an arch proves to be unsustainable, I think we should probably
officially discontinue it rather than move it into some sort of "slow
lane".  If there aren't enough people dedicated enough to keep the port
alive in Debian, I suspect there won't be enough people to keep it alive
*outside* Debian, either.

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

There is no specific infrastructural team or person that I'm going to
"pick on".  I outlined my plans for wrestling with this issue in my
platform[1], a reply to Pascal Hakim[2], and a reply to Martin

My first monthly report to the developers[4] will, I expect, have
information about the delegates as the lead (or possibly even only,
depending on how much labor is involved) item.

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

I think the best thing to do about this is to appoint a delegate, or
possibly a small team of delegates, to Sun Microsystems, as described
for other organizations in my platform[5].

In this particular case I think we need a person who is very strong both
in their understanding of the Java development environment, and strong
on legal issues.  This could easily be two people if one person is not
willing to hold him- or herself forth as comfortable wrangling both
aspects of this problem.

> 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. And non-free is an important subject and if a 
> candidate wants to be voted he has to provide a clear position on 
> this. (Note: I know that the candidates are against non-free, I want 
> to hear a strategy on non-free removal).

I think I would probably offer to delegate this position to a volunteer,
as it could be quite time consuming.  Here's one possible approach:

1) Post a call for volunteers to manage the migration from non-free to
2) Ask Andrew Suffield and Anthony Towns -- the proposers of the two
   ballot options being voted on -- to each nominate an "elector".
3) The two "electors" would then vote on the list of volunteers, naming
   a winner whom I would then appoint as a delegate.

This type of arrangement, where disputing parties each name a person
they can trust, who together choose an arbitrator, is common in
dispute-resolution systems.

Why do I think this is a good approach?

A) The migration of non-free from Debian to (possibly) non-free.org
   could be time-consuming and labor-intensive, at least at certain
   points -- and the DPL needs to be free to work on multiple tasks;
B) As a sponsor of Andrew Suffield's proposal, I'd rather not tempt
   anyone to question the objectivity of the process by being closely
   and personally involved (the external non-free project needs to be
   permitted to succeed or fail on its own merits);
C) As the drivers behind this vote, I think Andrew and Anthony should be
   invited to help see the process through;
D) By having them appoint "electors" who then choose the delegate, we
   avoid compelling them to agree on a person who does the job.

Given the very high passions that surround this issue, I don't think
this approach is overdesigned.


> 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. My stance is that at some point in the future there will 
> have to be some form of senate :-)
> My question: Do you think that you can handle all of the tasks a DPL 
> is supposed to do?

As I understand them, yes.  I do not think the DPL's job is to put on a
blue suit and red cape and solve all of Debian's problems

I think the DPL's job to see to it that the Debian Project better
understands its challenges, effectuates solutions, and exemplifies not
just our technology, but our organization.

> If you have packages to maintain do you plan to keep them as well?

My current list of personally-maintained packages[6] is pretty small now
that I have passed XFree86 over to team maintainership.

I do continue to play a very prominent role in XFree86 package
maintenance, and I will continue to do so if time permits.  The
reorientation of the entire Linux community, plus at least 2 of the 3
major BSDs, towards the X implementations of X.Org and FreeDesktop.org
(who are working in close collaboration with each other), is bringing a
lot of enthusiastic people to into X development.  I'm not too worried
for the future of X in Debian (or anyplace else), and I suspect I'd be
pretty happy settling into a kind of mentor status.

But first, there's a sarge release to babysit, of course.

> If at some point you realize that you cannot take it anymore, what
> will be your action?
> a) Drop everything and go to Hawaii
> b) Work until you die
> c) Resign
> d) Other

Heh.  1) delegate what I can; 2) work hard on that which I can't
delegate but cannot accomplish; 3) inform the developers of what I can
neither delegate nor accomplish; 4) go on vacation when my term is over.

(..and probably spend it hacking on tractable problems like bugs in
packages, to the annoyance of my wife...)

> 6. Debian delegate selection
> How would you choose a delegate for a position? 

By asking for volunteers!  I believe I covered existing personnel whom
I'd formalize above, as I did the tricky case of non-free transition.

In any situation where a delegate cannot be found, I will be sure to let
the developers know it.  In fact, it occurs to me that having a
"positions available" section at the end of every DPL report might not
be a bad idea...

[1] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p2
[2] http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00050.html
[3] http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00137.html
[4] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p3
[5] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p6
[6] http://qa.debian.org/developer.php?login=branden@debian.org

G. Branden Robinson                |     Communism is just one step on the
Debian GNU/Linux                   |     long road from capitalism to
branden@debian.org                 |     capitalism.
http://people.debian.org/~branden/ |     -- Russian saying

Attachment: signature.asc
Description: Digital signature

Reply to: