* Konstantinos Margaritis <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
