Re: Q for all candidates: (Old) Architecture Support
* Margarita Manterola (margamanter...@gmail.com) [100318 21:03]: > I would like to support as many architectures as possible. We cannot > deny the passage of time, however, and so we must accept that some > architectures are bound to stop being supported. This even happened > some years ago with 386. We still call the "common" architecture > i386, but a real 386 computer wouldn't be able to run the current > systems, since the kernel requires at least 486. And that happened before we removed m68k. (Technically it's not the kernel, but the way we set atomic locks within glibc - there used to be an patch lingering around for the kernel to emulate that behaviour, but using the patch opens an trivial root exploit, that's why we refused to use the patch.) Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324092434.gt19...@mails.so.argh.org
Re: Q for all candidates: (Old) Architecture Support
* Yavor Doganov (ya...@gnu.org) [100317 14:55]: > - mips/mipsel are probably the most hated archs by DDs in the past few > months :-), and there's no ironclad way to secure their future too. First of all, the needs-build queue is almost empty on mipsel (and was on mips till we lost the hard disk on mayr). Also, we have new and faster machines. As of writing this I'm compiling a kernel which will hopefully help us with seeing why we get our new mips machines dead with 8 hours of compiling packages. For the mipsel machines, there is a new kernel with http://www.linux-mips.org/archives/linux-mips/2010-03/txt23iVvbmCyX.txt since yesterday night. I hope to have time this week to try if I can still break the hardware. If we resolve mips or mipsel, we will have enough ressources to fix both architectures (because our current machines could run either flavour). I have the hope that we're not too far away from that. Of course, if we notice that we won't get new hardware anymore, and architecture is starting to die. But that's not true for mips and mipsel as of now. Andi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324092018.gs19...@mails.so.argh.org
Re: Q for all candidates: (Old) Architecture Support
On Wed, Mar 17, 2010 at 10:49 AM, Yavor Doganov wrote: > Debian has been known through the years for its excellent support for > many architectures. In theory, a released arch should be as stable as > the common/popular archs. (In practice, it is/was pretty close, which > is good enough.) Yes, this has always been something that makes me be proud of about Debian, and I'd definitely like for it to continue that way. (... skipping the bulk of the analysis ...) > What do you think the project should do (with or without or regardless > of your help as potential DPL) to preserve this goodness (maximum > supported architectures) for as long as possible? Do you think it is > "goodness" or you're in the "good riddance" camp? I would like to support as many architectures as possible. We cannot deny the passage of time, however, and so we must accept that some architectures are bound to stop being supported. This even happened some years ago with 386. We still call the "common" architecture i386, but a real 386 computer wouldn't be able to run the current systems, since the kernel requires at least 486. The only way for an architecture to be supported is to have enough people interested in it, enough porters working on the toolchain, the kernel, and helping the maintainers with the arch specific bugs. If there's enough interest in the arch, then it's probably going to survive, if too many people lose interest, then it becomes impossible to maintain the port. The root of the problem then comes back to lack of enough contributors, which is one of the problems I plan to tackle if I'm elected. I'm not really sure on how to attract more people to contribute as porters, since that usually requires having access and interest in a particular platform, but with the use of porting tools, like using QEMU to emulate a particular architecture where a bug needs debugging, we could try to encourage more external contributors to help fix porting bugs, and thus help keeping the overall health of the port. Also, we could try to improve motivation on bug fixing, by reminding developers that each time they fix an arch specific bug they are improving the overall quality of the software and that we really appreciate having high quality software. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8bbf0361003181302q3af153d2k73484b6b7eede...@mail.gmail.com
Re: Q for all candidates: (Old) Architecture Support
В Thu, 18 Mar 2010 00:02:56 +0900, Charles Plessy написа: > Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : >> * There should be an entitiy within the project to decide which arch >> gets released and which not > I do not completely agree with this: > > I think that the porters should have much more latitude on how to what > their port contain. If they can assemble a reasonable subset of Debian's > packages into a working system that matches the expectations of the > users and that Debian can be proud of. Interesting. Are you suggesting that bugs (mostly of the FTBFS type) should be ignored at the discretion of the porters and other important teams on a per-package basis (e.g. "Nobody in their right mind would install `foo' here, so it's OK to ignore the bug")? I think that this is a dangerous path to follow. IMHO it is the fastest way to *prematurely* kill an arch. Problems will start to accumulate, and issues with non-trivial inter-dependencies (e.g. resolving one major bug depends on the fix for another, sometimes in a different package) will pile up on the TODO stack, which at some point would inevitably lead to "enough, this arch is problematic, so we have no choice but to exclude it from the release". Ideally, all architectures should be equal (in practice they are not, but theoretically the criteria are the same). If the project allows the lapses you seem to suggest, that would be the end of all but mainstream archs. IMVHO. > Architectures that lose their mainstream position and therfore > upstream support in popular heavy-weight applications could survive > much longer. I seriously doubt that if your view/plan is in force. IIRC, this plan was discussed on -m68k (at least) several times in the past, and this is a plan to hide bugs, to sweep them under the carpet. YMMV, of course. (Just as a side note, you would be surprised how much "impossible to use" complex/heavyweight packages people install and run (even for testing purposes) on slow architectures. It is hard to predict the limit of users' patience, therefore I conclude that it is not possible to state with certainty "package foo is not suitable for arch bar because of performance reasons". And yes, I say this from the standpoint of experience -- my home machine park is "Jurassic", and still I manage to do what I intend to do with the tiny computer power available.) > if nobody wants to fix the bug, it is a good indicator that > everybody has more important, more rewarding, and in the end more > fun things to do, and that we should trust their judgement by > changing our release strategy instead of maintaining an institution > that opposes people. I disagree with this sentiment, but who am I to disagree... If nobody wants to fix the bug, this probably means that the majority of users are not affected by this bug. However, it has always been my understanding that a Debian package maintainer should look a little bit more forward than her own packages, and should do her best to ensure that everything she maintains is at least buildable on all Debian architectures, including unofficial ones (whether former stable ones or new, struggling to become official). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hntf4s$k...@dough.gmane.org
Re: Q for all candidates: (Old) Architecture Support
Hi Yavor!
On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote:
> This asset is not something to be proud of because of shallow
> marketing reasons -- it benefits the whole Free World as many bugs are
> uncovered, reported, and fixed, quite often by Debian people. It
> would not be incorrect to say that, having in mind how many packages
> are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports,
> Debian is the most comprehensive testground of the GNU system.
Absolutely, it is one of our distinguishing values that we should
cherish more than we currently do. FWIW, there is nothing wrong in
using it _also_ for marketing reasons. In general, the kind of marketing
based on our distinguishing features (and this is one of those) is our
best chance to attract new contributors.
> - m68k was the first "kicked out" arch. AFAICT, it is essentially
> dead now and not even a miracle can save it.
That is was kicked out by the current rules is true (actually, that is
what it seemed to me as a DD non-porter, people like Wouter surely knows
more than me about extra details, if any). What I don't share of this
sentence is the feeling of causality it gives between being kicked out
and then dying.
I sure do not want to deny that a non-release arch is looked at by less
eyes, and that the project in general cares less about it (e.g. as the
bugs are not RC, they are less likely to be NMU-ed). But an architecture
which is suffering anyhow---for instance no maintenance of the toolchain
or no buildd admins for it---would not necessarily be any better
supported for end users. Also, the process of arch qualification goes
both ways, and the entrance of GNU/kFreeBSD as a new release arch is IMO
evidence of that. In fact, if the above impression of causality were
true, we would risk to be stuck to not having new archs in the future,
which luckily is not true.
Ultimately, I believe that when an "average" package (i.e. not a monster
package) is properly maintained, the maintainer will be happy to apply
patches that add support for an arch, even if it is not (yet) a release
arch. You might argue that there are several average packages which are
not properly maintained, but that's a whole different problem ...
> * Support for old (and not only old) architectures cannot be infinite;
> and there's a line to draw somewhere when it comes to a release.
> * There should be an entitiy within the project to decide which arch
> gets released and which not, which one is blocking the whole release
> * There's not much a DPL could do except some publicity and
> RFH-oriented efforts which are known not to work well...
AOL
I was thinking along the same lines while reading your post thus far,
thanks for sparing me to write these :)
> Porters are an extremely valuable resource, and the survival of an
> Therefore, it is essential to preserve, and even grow, such
> resources by doing all possible to attract people with sufficient
> knowledge and also pass that knowledge through.
Agreed.
> What do you think the project should do (with or without or regardless
> of your help as potential DPL) to preserve this goodness (maximum
> supported architectures) for as long as possible? Do you think it is
> "goodness" or you're in the "good riddance" camp?
I'm surely on the goodness side. More generally, I'm for defending and
advertising more all of Debian distinguishing features, and our range of
supported archs is surely one of them.
On the side of developers, ideally we should not accept maintenance
behaviors in which patches that add support for non-release archs are
regularly ignored, but that can hardly be imposed to people. Let's just
aim for packages which are in a good maintenance status (more QA, as
usual) and I believe that more reactivity to porters patches will come
for free.
On the side of porters, we cannot create them magically. All we can do
is (1) do our best to attract them (because we know such rare entities
do exist :-)) and then (2) put them in the best possible condition to do
what they like. To improve their work condition I fear the DPL can do
little more than ensuring our arch-specific machine park is up to par.
To attract them, advertising arch support as I said above would be a
wonderful start.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Q for all candidates: (Old) Architecture Support
On Thu, Mar 18, 2010 at 12:02:56AM +0900, Charles Plessy wrote: > By the way, I would like to react to one of Wouter's comment, that package > maintainers should fix the porting bugs themselves. I didn't mean to imply that, and if it came across as such, I would like to apologise. What I meant to say is that if there is an architecture-specific problem in one of your packages, you should actively work towards its resolution. Sometimes this may mean debugging and fixing it yourself; sometimes this may mean asking a porter to help you with it. But it should not mean (and that was my main point) ignoring the bug "because it's not a release architecture, anyway". That happened rather often to the m68k port in its final days on the Debian archives, and it was not helpful. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Q for all candidates: (Old) Architecture Support
Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : > > * There should be an entitiy within the project to decide which arch > gets released and which not, which one is blocking the whole release > process and ought to be ignored for testing propagation, etc. > Naturally, such entity is the Release Team, and their criteria don't > seem bad. Hello Yavor, I do not completely agree with this: I think that the porters should have much more latitude on how to what their port contain. If they can assemble a reasonable subset of Debian's packages into a working system that matches the expectations of the users and that Debian can be proud of. Other teams (security, toolchain maintainers, …) are qualified to tell if releasing a port with that given subset would perturbate their work and therfore the other ports, and the release team would then be the one to take the final decision. I think that a simple reorganisation of our archive's sections and priorities would open the way to such lighter releases. Efforts of developers would be rewarded earlier. Architectures that lose their mainstream position and therfore upstream support in popular heavy-weight applications could survive much longer. As Wouter noted, it is probably when the core toolchain is not maintained anymore that the port is severly compromised. By the way, I would like to react to one of Wouter's comment, that package maintainers should fix the porting bugs themselves. I really disagree. As a pakcage maintainer, I found myself a couple of times in this kind of situation, where nobody wants to do the work. This is a totally fun-killing situation. The port threaten's my package's seat in the release, and my package threatens the port's existence. Yet nobody ever complained that the package is not available for that port… What I mean by my not-so original ‘more fun, more trust’ credo in my platform, is exemplified in this situation by the fact that if nobody wants to fix the bug, it is a good indicator that everybody has more important, more rewarding, and in the end more fun things to do, and that we should trust their judgement by changing our release strategy instead of maintaining an institution that opposes people. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100317150256.gb23...@kunpuu.plessy.org
Re: Q for all candidates: (Old) Architecture Support
On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote: > Debian has been known through the years for its excellent support for > many architectures. In theory, a released arch should be as stable as > the common/popular archs. (In practice, it is/was pretty close, which > is good enough.) > > This asset is not something to be proud of because of shallow > marketing reasons -- it benefits the whole Free World as many bugs are > uncovered, reported, and fixed, quite often by Debian people. It > would not be incorrect to say that, having in mind how many packages > are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, > Debian is the most comprehensive testground of the GNU system. > > There is a disturbing and unpleasant tendency (which > probably has its roots in the Dark Times, i.e. the Vancouver Proposal) > to drop support for some problematic archs as years go by. That's > entirely understandable, but: > > - m68k was the first "kicked out" arch. AFAICT, it is essentially > dead now and not even a miracle can save it. I agree on the stance that it's essentially dead now, yeah. The latter part is not precisely true. If someone were to fix the technical issues with the port that exist today--which would qualify as a 'miracle'--there's a fairly good chance that the port might be resurrected; the m68k porters were always rather enthousiastic about their port. [...list of problematic architectures snipped...] > So, having in mind the obvious conclusions a sensible person could do, > namely > > * Support for old (and not only old) architectures cannot be infinite; > and there's a line to draw somewhere when it comes to a release. > * There should be an entitiy within the project to decide which arch > gets released and which not, which one is blocking the whole release > process and ought to be ignored for testing propagation, etc. > Naturally, such entity is the Release Team, and their criteria don't > seem bad. > * There's not much a DPL could do except some publicity and > RFH-oriented efforts which are known not to work well... Agreed on those points. > the apparent solution to the problem is: > > Porters are an extremely valuable resource, and the survival of an > architecture in the distribution is impossible without skilled > people who can fix the hardest problems, assist upstream > (especially toolchain packages) and Debian maintainers in fixing > the issues that prevent a specific arch to meet the release > criteria. > Therefore, it is essential to preserve, and even grow, such > resources by doing all possible to attract people with sufficient > knowledge and also pass that knowledge through. I agree. > (I hope that most of you remember how much insightful Thiemo's > analysis about mipsen problems were.) > > > If you managed to keep up reading until this point, my question to the > candidates is: > > What do you think the project should do (with or without or regardless > of your help as potential DPL) to preserve this goodness (maximum > supported architectures) for as long as possible? When package maintainers are informed of architecture-specific bugs in their package, they should listen to porters, and actively work on the bug, rather than expect that a porter will fix it (which happens rather often for architectures that are in a problematic state, because "it's not a release architecture anyway", thereby only enlarging that architecture's problems). Porters can't fix every architecture-specific bug; and reading unfamiliar code to hunt down why a bug fails on one particular architecture isn't always the easiest thing to do. Of course porters are available to help, since they're supposed to know the architecture, but that's a different matter. > Do you think it is "goodness" or you're in the "good riddance" camp? I'm clearly in the former camp. > Extra question to Wouter as a (former?) porter and buildd admin I'm still a porter; while the m68k port is mostly dead, there are still buildd hosts running that occasionally manage to successfully build something; and that is still uploaded. But these are far and few between. Also, I am an admin for one powerpc host. > (feel free not to reply at all; and for other candidates -- feel free > to reply if you want to): > > IMVHO the m68k team was one of the most energetic, enthusiastic and > tireless porter teams. It included many knowledgable people who > contributed upstream as well (Linux, GCC, glibc, binutils, etc.) Not entirely. There were people who contributed to the upstream kernel, yes. There were no people active in the Debian m68k port on the toolchain. That was one of the reasons of our decline; we had no in-house knowledge to fix our toolchain, and had to rely on outside contributors. I did manage to hunt down a few problems by myself, but it wasn't enough to turn the tide. > The release team made it clear that m68k can ret
Q for all candidates: (Old) Architecture Support
Debian has been known through the years for its excellent support for many architectures. In theory, a released arch should be as stable as the common/popular archs. (In practice, it is/was pretty close, which is good enough.) This asset is not something to be proud of because of shallow marketing reasons -- it benefits the whole Free World as many bugs are uncovered, reported, and fixed, quite often by Debian people. It would not be incorrect to say that, having in mind how many packages are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports, Debian is the most comprehensive testground of the GNU system. There is a disturbing and unpleasant tendency (which probably has its roots in the Dark Times, i.e. the Vancouver Proposal) to drop support for some problematic archs as years go by. That's entirely understandable, but: - m68k was the first "kicked out" arch. AFAICT, it is essentially dead now and not even a miracle can save it. - alpha will not be released with squeeze; I dare to speculate that it will be in the position of m68k within a release or two. - Debian is the last GNU distro with a sparc port (Gentoo has sparc too, but it's actually sparc64); squeeze+1 will probably drop sparc. (Again speculation/clairvoyance: sparc will follow m68k's footsteps pretty soon too, especially having in mind that there's no or little upstream support.) - hppa was (and always is, it seems) at great risk, although thanks to the Herculean efforts of the porters it is in a good shape (as far as I can judge) now. - mips/mipsel are probably the most hated archs by DDs in the past few months :-), and there's no ironclad way to secure their future too. So, having in mind the obvious conclusions a sensible person could do, namely * Support for old (and not only old) architectures cannot be infinite; and there's a line to draw somewhere when it comes to a release. * There should be an entitiy within the project to decide which arch gets released and which not, which one is blocking the whole release process and ought to be ignored for testing propagation, etc. Naturally, such entity is the Release Team, and their criteria don't seem bad. * There's not much a DPL could do except some publicity and RFH-oriented efforts which are known not to work well... the apparent solution to the problem is: Porters are an extremely valuable resource, and the survival of an architecture in the distribution is impossible without skilled people who can fix the hardest problems, assist upstream (especially toolchain packages) and Debian maintainers in fixing the issues that prevent a specific arch to meet the release criteria. Therefore, it is essential to preserve, and even grow, such resources by doing all possible to attract people with sufficient knowledge and also pass that knowledge through. (I hope that most of you remember how much insightful Thiemo's analysis about mipsen problems were.) If you managed to keep up reading until this point, my question to the candidates is: What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is "goodness" or you're in the "good riddance" camp? Extra question to Wouter as a (former?) porter and buildd admin (feel free not to reply at all; and for other candidates -- feel free to reply if you want to): IMVHO the m68k team was one of the most energetic, enthusiastic and tireless porter teams. It included many knowledgable people who contributed upstream as well (Linux, GCC, glibc, binutils, etc.) The release team made it clear that m68k can return as a release arch at any time, so the kick-out for Etch was (supposed to be) temporary. Why do you think the m68k port is not doing very well (to put it mildly; [*])? [*] It's like the old joke when a person sends a supposed-to-be "delicate" telegram to a relative: "John not feeling well. Funeral tomorrow noon." -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq8vys6b.gnus_not_unix!%ya...@gnu.org
