Re: upstart and the LSB (was: On cadence and collaboration)
also sprach Steve Langasek vor...@debian.org [2009.08.07.0012 +0200]: Sure, it has compatibility addons, but primarily it conflicts with sysvinit and encourages vendors to provide upstart control files for packages, instead of init.d scripts. Why in the world does it matter whether it's a compat layer, or if it's what the distributor uses for its own work? Do you advocate throwing away Policy and replacing it with the LSB? No, I certainly don't. I also didn't make myself clear in the last message. What I've seen are packages by vendors specifically declared to be for Ubuntu. That used to suggest to me that they're not willing to deal with other users and didn't put me off if I needed them on a Debian system. However, when I tried to install the package on Debian, it wanted to pull in upstart and remove sysvinit. No way, not yet. So I extracted the files to get it working quickly, but had to discover that it only came with an upstart control file and no init.d script. It was at that point that I wondered whether we had just been catapulted back a step. Hope this clears it up. Again, I think upstart is the right step in the right direction. I also didn't want to suggest that this is Scott's or Ubuntu's or Canonical's fault, really. You provided a new tool and the vendor immediately started using it. In ways that's an impressive adoption rate. ;) I suppose there could be stuff in place in upstart to actively discourage this sort of experimental approach for now. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems life is what happens to you while you're busy making other plans. -- john lennon digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
Michael Bienia wrote: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Luk Claes wrote: If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. There is nothing bad with a fixed freeze date. Just with the way it was planned for December. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Fri, Aug 7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote: Michael Bienia wrote: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. You can look at bugs filed by paying customers, and ignore the rest. Cheers, Julien -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) At least on the Ubuntu side, there would be room to agree in advance on items that are as yet unreleased, but which have for various reasons clear advantages and well understood risks. So, for example, if someone on the toolchain team said GCC 4.5 is going to be released in February, and we've run a test rebuild of the archive and there were only 20 FTBFS's then it might well be possible to get consensus around that new version being planned as a consensus base version for releases in 2010. Mark -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Fri, Aug 07, 2009 at 10:55:36AM +0200, Julien Cristau wrote: On Fri, Aug 7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote: How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. You can look at bugs filed by paying customers, and ignore the rest. Really, I don't think discussing Canonical's business model and/or Ubuntu/Canonical's approach to QA/bug triaging/bug fixing has to be discussed here. Michael -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian on Atom 330 Question
Beste, Momenteel heb ik een dedicated server genomen ergens en men zegt er dat ze geen Debian willen instaleren omdat deze niet zou werken omwillen van de processor. Klopt het dat Debian niet werkt onder: Intel Atom Dual core 330 http://processorfinder.intel.com/details.aspx?sSpec=SLG9Y Graag bevestiging of het wel of niet werkt, gezien het bedrijf hiervan bewijs wil. Dank Rein Corselis _ Hebben jij en je vrienden leuke foto's van jullie feestje? Maak een groepsalbum en geniet nog extra na. http://www.microsoft.com/belux/nl/windows/windowslive/products/photos.aspx
Re: On cadence and collaboration
Bernd Zeimetz wrote: Luk Claes wrote: If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. There is nothing bad with a fixed freeze date. Just with the way it was planned for December. s/planned/announced/ It was and still is not meant as a decision, but as a proposal though the announcement said otherwise due to miscommunication from my side which I cannot undo unfortunately. I'm not convinced that we will be able to freeze in December anymore and I still want to talk to teams and people to see how their schedules can fit in with a proposal of a new freeze date. I do consider that we should delay the date significantly as many of the feedback already received indicates that there is more time needed before we freeze. Cheers Luk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Mark Shuttleworth wrote: Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) At least on the Ubuntu side, there would be room to agree in advance on items that are as yet unreleased, but which have for various reasons clear advantages and well understood risks. Just providing a bit of Debian specific context: A freeze in Debian is usually very strict and only allows small diffs that fix release critical bugs, release goal bugs (and sometimes documentation or translation bugs). So, for example, if someone on the toolchain team said GCC 4.5 is going to be released in February, and we've run a test rebuild of the archive and there were only 20 FTBFS's then it might well be possible to get consensus around that new version being planned as a consensus base version for releases in 2010. This is normally out of the question within a Debian freeze, just before the freeze could be an option if there is a clear commitment to fix the remaining bugs though. Cheers Luk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Fri, Aug 7, 2009 at 18:37, Luk Claesl...@debian.org wrote: It was and still is not meant as a decision, but as a proposal though the announcement said otherwise due to miscommunication from my side which I cannot undo unfortunately. I'm not convinced that we will be able to freeze in December anymore and I still want to talk to teams and people to see how their schedules can fit in with a proposal of a new freeze date. I do consider that we should delay the date significantly as many of the feedback already received indicates that there is more time needed before we freeze. I'd like to loudly thank you for admit there was a problem in how this was released to the public and for revisiting your proposed plan after feedbacks received (even if some was rather hard). This is a clear sign of the professionality you're putting in this role (and how hard it is to wear that hat). Thanks, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Fri, Aug 7, 2009 at 00:30, Michael Bieniamich...@bienia.de wrote: On 2009-08-06 16:25:47 +0200, Matthias Andree wrote: [I'm Ubuntu developer (MOTU to be more specific), so I might be biased] I certainly won't excuse some things that are not happening, I know that Ubuntu needs to improve in some aspects. But realising this and get things improved are still not the same. I just want to add some data which hopefully explains why things are happening or not happening. ... I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). ... Unlike Debian, Ubuntu hasn't this one maintainer per package approach (don't know about other distributions). In Ubuntu whole teams are responsible for the components: core-dev for packages in main and MOTU for packages in universe and multiverse. Both approaches have there pro and con. For and a package being in main doesn't necessarily mean that it's better maintained than packages in universe (on a best effort basis). They might only be in main because they are needed by an other package in main (sorry, don't know the reason for bogofilter being in main). While Debian has over 1000 persons with upload rights, Ubuntu counts only 135 persons with upload rights (from those only 56 can upload to main). At the same time there are over 3000 source packages in main and over 12000 source packages in universe. One can easily see that this won't work to get every package the amount of care that it deserves. So in the end many packages are taken unchanged from Debian. Yet bugs don't stop getting filed in Ubuntu and need to be looked at and acted accordingly. This internal view shows how Ubuntu developers are already under-staffed; so where will the resources for collaboration be taken from? If current developers do not even have the time to look at bugs, how can they work on the collaboration tasks and at what price? for both of us: - for Ubuntu, because you have to redirect attention of a developer to another task, while he had already too many to work on; - for Debian, because we *can* (it's a possibility) receive work of low quality; consider the generic Ubuntu developer that must work (because his time was committed to it) to do a collaboration task: what can happen is that he prepare a rough solution, sent to debian in a sense hey, take it, I've done my work, it's an ugly hack but I have no time to prepare an elegant solution; Now I got to go, I have another 1000 things to do. I'm not sure it will happen, but I fear it would. How can this be solved? I used Debian just to keep the example real (and because it's the distro I care about). Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian on Atom 330 Question
Rein Tendonsie tendon...@tendonsie.be writes: Beste, Momenteel heb ik een dedicated server genomen ergens en men zegt er dat ze geen Debian willen instaleren omdat deze niet zou werken omwillen van de processor. Klopt het dat Debian niet werkt onder: Intel Atom Dual core 330 http://processorfinder.intel.com/details.aspx?sSpec=SLG9Y Graag bevestiging of het wel of niet werkt, gezien het bedrijf hiervan bewijs wil. Dank Rein Corselis I don't realy understand much more than the subject but: % cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz stepping: 2 cpu MHz : 1600.234 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm lahf_lm bogomips: 3200.46 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: ^^^ 4 times for 2 cores and 2 hyper threads each. MfG Goswin -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
