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 us. 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 propose. 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 Schulze[3]. 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 debian-project; 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. Comments? > 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 single-handedly. 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