Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote: > Hi Ben, > > Sorry for not getting back to you about this earlier. > > On 7/7/19 3:43 PM, Ben Hutchings wrote: > > On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: > > [...] > > > No binary maintainer uploads for bullseye > > > = > > > > > > The release of buster also means the bullseye release cycle is about to > > > begin. > > > From now on, we will no longer allow binaries uploaded by maintainers to > > > migrate to testing. This means that you will need to do source-only > > > uploads if > > > you want them to reach bullseye. > > > > I support this move in principle, but: > > > > >Q: I already did a binary upload, do I need to do a new (source-only) > > > upload? > > >A: Yes (preferably with other changes, not just a version bump). > > > > > >Q: I needed to do a binary upload because my upload went to the NEW > > > queue, > > > do I need to do a new (source-only) upload for it to reach bullseye? > > >A: Yes. We also suggest going through NEW in experimental instead of > > > unstable > > > where possible, to avoid disruption in unstable. > > [...] > > > > This is not going to fly for src:linux. We can't stage ABI bumps in > > experimental as we typically have a different upstream versions in > > unstable and experimental. We even need to do ABI bumps in stable from > > time to time. > > We are aware that src:linux is a special case here. I added an exception > for the arch:all binaries from src:linux. When the next ABI bump in > unstable happens, feel free to let me know, so that I can check if it > works as expected. linux version 5.2.17-1 was the first version that included an ABI bump and did not have any regressions that blocked it from testing. It has transitioned to testing including the developer-built arch:all packages, so I believe that this exception works. Thank you! Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)
On Mon, 2019-08-05 at 19:25 +0100, Adam D. Barratt wrote:
> [CC += ftpmaster]
>
> On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> > On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> > [...]
> > > We are aware that src:linux is a special case here. I added an
> > > exception for the arch:all binaries from src:linux. When the next
> > > ABI bump in unstable happens, feel free to let me know, so that I
> > > can check if it works as expected.
> >
> > I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> > the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> > in the NEW queue.
>
> That looks like a problem on the archive side. The dak log suggests an
> issue logging an issue with a .changes file:
>
> 20190805181929|process-upload|dak|exception|Traceback (most recent call last):
> 20190805181929|process-upload|dak|exception| File "/usr/local/bin/dak", line
> 228, in main
> 20190805181929|process-upload|dak|exception|module.main()
> 20190805181929|process-upload|dak|exception| File
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
> 20190805181929|process-upload|dak|exception|process_changes(changes_files)
> 20190805181929|process-upload|dak|exception| File
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in
> process_changes
> 20190805181929|process-upload|dak|exception|Logger.log([filename, "Error
> while loading changes: {0}".format(e)])
> 20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec
> can't encode character u'\ufffd' in position 223: ordinal not in range(128)
Thanks for that. Both my uploads last week seem to have been processed
successfully, but neither of them built on all release architectures so
we haven't yet been able to see whether the special case works.
Ben.
--
Ben Hutchings
Humour is the best antidote to reality.
signature.asc
Description: This is a digitally signed message part
process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)
[CC += ftpmaster]
On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> [...]
> > We are aware that src:linux is a special case here. I added an
> > exception for the arch:all binaries from src:linux. When the next
> > ABI bump in unstable happens, feel free to let me know, so that I
> > can check if it works as expected.
>
> I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> in the NEW queue.
That looks like a problem on the archive side. The dak log suggests an
issue logging an issue with a .changes file:
20190805181929|process-upload|dak|exception|Traceback (most recent call last):
20190805181929|process-upload|dak|exception| File "/usr/local/bin/dak", line
228, in main
20190805181929|process-upload|dak|exception|module.main()
20190805181929|process-upload|dak|exception| File
"/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
20190805181929|process-upload|dak|exception|process_changes(changes_files)
20190805181929|process-upload|dak|exception| File
"/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in
process_changes
20190805181929|process-upload|dak|exception|Logger.log([filename, "Error
while loading changes: {0}".format(e)])
20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec
can't encode character u'\ufffd' in position 223: ordinal not in range(128)
Regards,
Adam
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote: [...] > We are aware that src:linux is a special case here. I added an exception > for the arch:all binaries from src:linux. When the next ABI bump in > unstable happens, feel free to let me know, so that I can check if it > works as expected. I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and the upload was acknowledged (11:40 UTC) but it hasn't yet showed up in the NEW queue. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi Ben, Sorry for not getting back to you about this earlier. On 7/7/19 3:43 PM, Ben Hutchings wrote: On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] No binary maintainer uploads for bullseye = The release of buster also means the bullseye release cycle is about to begin. From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. I support this move in principle, but: Q: I already did a binary upload, do I need to do a new (source-only) upload? A: Yes (preferably with other changes, not just a version bump). Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. We are aware that src:linux is a special case here. I added an exception for the arch:all binaries from src:linux. When the next ABI bump in unstable happens, feel free to let me know, so that I can check if it works as expected. Thanks, Ivo
Re: Bits from the Release Team: ride like the wind, Bullseye!
> "Ben" == Ben Hutchings writes: Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: Ben> [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is >> about to begin. From now on, we will no longer allow binaries >> uploaded by maintainers to migrate to testing. This means that >> you will need to do source-only uploads if you want them to reach >> bullseye. Ben> I support this move in principle, but: Ben> This is not going to fly for src:linux. We can't stage ABI Ben> bumps in experimental as we typically have a different upstream Ben> versions in unstable and experimental. We even need to do ABI Ben> bumps in stable from time to time. Ben> I think that the requirement to upload binary packages for Ben> binary-NEW (but not source-NEW) needs to go. I agree with Ben. There are a lot of good reasons to stage (possibly even most) binary new packages through experimental. Ben has talked about cases where experimental can't work. I'd like to talk about cases where it is the wrong answer. However, we've gotten a lot of feedback from our maintainers over the years that anything that adds an extra round trip to their workflow is significantly demotivating. If I need to wait for something to go through new, and then after it goes through new do an extra thing to accomplish my goal, that increases the cost of what I'm doing significantly. If it's a simple soname bump because of a new symbol, that doesn't always require experimental. Thinking back to my own experience with krb5, I have a good handle on when ABI bumps need to go through experimental and when things are going to be fine through unstable. I haven't made a lot of mistakes in that front--uploading things to unstable that ended up being broken enough we wished they had gone through experimental. I know I'm not alone. I think that for this to fly, binaries for binary new need to go. I understand that balancing the trade offs here requires a bit of a mind meld between the ftp team and the release team, and I understand that cross team decision making is more complex here. I'd be happy to facilitate any discussion around the trade offs if that would be useful. --Sam
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. I support this move in principle, but: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. I think that the requirement to upload binary packages for binary-NEW (but not source-NEW) needs to go. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? or http://members.optusnet.com.au/ckolivas/kernel/ -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sorry for the long mail, but i believe there is something important all the way done, so if you cannot be bothered to read it all; please go down to the point marked *IMPORTANT*. On Tue, Jan 03, 2006 at 10:05:04PM -0800, Steve Langasek wrote: You have been harranguing the ftp team to approve new upstream kernels Wrong, i have asked Gannef to do it quicker NEW handling, and i told him about this as soon as i found out about the 2.6.15 kernel release, since i believe infomring folk early is good courtesy if you want them to do stuff for you, as they can then more easily fit it in their schedule. Notice that NEW handling is also important in this case, since the autobuilders will build out of incoming, but not out of NEW, and since kernels are rather long in building, this is an additional delay. I may have been more insistent, and thus more dissapointed when it failed to happen the same day, for the 2.6.14 release, since this one culminated an intense work session of the whole debian-kernel team to make the 2.6.12-2.6.14 transition with initrd-tools going away and co happen. We are speaking of 2 to 3 weeks of intense work on the -rc serie, which culminated in the release, with the claimed aim to do 0-day uploads which many many believed was not possible, and it didn't happen not for technical reasons, but for bureaucratic details. You would feal the same, but on a larger scale when you where about to announce the release, and you couldn't for some stupid reason fully not under your control and you believe it is an unnecessary issue. Can you honestly say we wouldn't hear you rant about it afterward ? But again, this is the second time this happens, so as soon as i knew, i informed Ganneff, and didn't harrangue or demand or whatever, just informed. I _did_ rant about the not-really-need for NEW in these cases, but that is unrelated. through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even Yes, and we are all volunteers, the preparation of a release like the 2.6.14 one had demanded effort and sacrifice from about a dozen persons, do you not think it burns good will to work on this if you fail to achieve your stated goal for bureaucratic details, i know my motivation fell a bit when we did indeed miss dinstall. if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an How long a time ? A month, two month, four month ? And what is the cost balance between backporting all those fixes from the new version, and simply using the new version. Also, with the new approach of building -rc releases in experimental, we have easily another month or so of time to test the kernels, and the possibility to correct at least part of the issues in upstream before even the release. But sure, there are issues, but i don't believe they are as time consuming as you make them. installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. Bah, ... I can guarantee you users are quick in testing new kernels, part of them are, and we test them ourself also and run them, so major issues are found early. we knew about the powerpc debconf/postinst script fuckage before he package left incoming, altough there was no way to stop it from entering the archive, and the bug reports came in very very shortly after dinstall. The underlying assumption in your plea for a shorter kernel freeze is newer is better. But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an Bah, they run stable with sid/experimental or self built kernels, which is the sanest thing to do, especially given the messy kernel stable security situation, which i warned you about in april. unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. No. the kernel evolves, but more importantly issues get fixed. There are some newer breakage that may slip in, but all in all the fixing amount overweights the breakage introduced, and this breakage can be fixed, so i will have to disagree with this. But i believe the point is elsewhere, with our current plan, we will always have two release candidates in the archive, or a single good quality release candidate. All i ask, and i believe all agree on that, is that the freeze date and the choice of kernel is done solely on the quality and testing of the kernel, and not like it was
Re: bits from the release team
On Wed, Jan 04, 2006 at 08:58:09AM +0100, Andreas Barth wrote: well, the kernel is definitly about the same level as the toolchain and standard/base - changes can have very easily impact on the installer, and it is not an option to remove the package if it is broken. Nope, still it is more in the cqtegory of general base than essential toolchain, but as you said, it is only a week. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? I was speaking about the installer. And usually there are lots of last-minute changes that need to go in - not only new languages, but lots of other small minor, but still important bug fixes. Indeed. I claim that the installer experience gained during the last steps of the sarge release is worthless for the current situation, as the kernel situation is lightyears from what it was back then. Failing on your part to aknowledge this would be a negation or dismissal of the work done by the kernel team during these past 6 month or so, and i would personally feel offended, and i believe others will too, if you do this. It is as if i was takign the boot-floppies experience to take conclusions on the current installer. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. Well, but then an older kernel doesn't hurt you? :P Imagine an installer with a known remote security exploit, which brings up the network early in the install process. This is microsoftian kind of practice, and i want nothing to do with it, nor my name associated with it, and i believe the same for you. Still we did, if i remember well, such a kernel in the sarge installer, solely because the infrastructure didn't allow us to fix it in a timely fashion. This is understandable mere month or weeks before the sarge release, but inexcusable at this point of the release process. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Of course, we have seen that the kernel build process is way more mature now. Nobody doubts that. and that is an euphemism. Still there is doubt about the ability of the kernel team to be able to think how this maturity can be extended beyond the kernel team, and there where harsh words about our ability voiced also, which i think are displaced. so, altough people can't honestly say they doubt it, some still think they know better with regard to kernel matters, and don't hesitate to patronize us on this. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Well, they are definitly the relevant people for the installer. And, frankly speaking, at least I have good experience with both of them. For the installer, sure, but the generation of the d-i kernel .udebs is only marginally of their relevance, and furthermore they don't want the responsability associated with it, and as proof i can show you that joeyh upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the other architectures, defaulting it upto the porters, which are the exact same guys doing the kernel packages. So joeyh and fjp can't have it both way. And furthermore this is to make their live easier, so they have more time to concentrate on more important and core d-i work. d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Hm, which out-of-tree modules do you consider to be release critical, i.e. we cannot release without them? Well, i guess once we kick the non-free firmware modules into the non-free part of linux-2.6, you will reconsider that, or if there are out-of-tree network or disk drivers. I would say that most of the wlan out-of-tree drivers already qualify. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble?
Re: bits from the release team
* Sven Luther | I believe it has also an influence on the place where the source package is | ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said | we should use their system. yeah, git, really strange stuff in the world of Linux kernel development. Available from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git (or http://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:39:09PM +0100, Tollef Fog Heen wrote: * Sven Luther | I believe it has also an influence on the place where the source package is | ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said | we should use their system. yeah, git, really strange stuff in the world of Linux kernel Ah, could, it used to be bazar thingy, or arch previously, which is one of the most non-friendly tools out there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
also sprach Brian Nelson [EMAIL PROTECTED] [2006.01.04.0043 +0100]: Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? I doubt RH has the same concept of stability as we do, and I surely don't want a plethora of potentially untested or buggy hardware support patches in my productive kernels. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! gentoo: for when you finally find out that overclocking can kill your processor. signature.asc Description: Digital signature (GPG/PGP)
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) Different distros have different target audiences so this may not be easy. Often fixing a driver bug for one class of users breaks it for an other class of users so it is quite possible that different distros want different bugs to be fixed/left alone. Also, other distros (e.g. RedHat) already found out the hard way that diverging too much from upstream costs a lot. So unless you find someone to pay the maintainers of such a forked kernel, it will not work out in the long term. If you give it a quick look (and a quick try), we will have more users testing the same kernel, which means more feedback, we will have more developers working to get it stable and working to get it secure. Probably even upstream get benefits from this model and sounds like a very good way to work together, even to try to integrate outside patches and backporting things. =) Dave Jones (Fedora) and Greg KH (Gentoo) already posted a much better idea on l-k: make packages from daily -git snapshots available for distro testers, so bugs like the past udev breakages are found _before_ the next official kernel version is released. Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:51:17PM +0100, Gabor Gombas wrote: snipp Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. the -rc kernels are build in experimental, staging area for unstable and without any potential d-i breakage. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Gabor Gombas wrote: Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. We already had some -rc releases in experimental for 2.6.14 and 2.6.15. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote: the -rc kernels are build in experimental, staging area for unstable and without any potential d-i breakage. Ah, nice, I did not notice it. Perhaps it should get some more publicity to attract more testers :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:11:00PM -0500, Joey Hess wrote: Sven Luther wrote: For the installer, sure, but the generation of the d-i kernel .udebs is only marginally of their relevance, and furthermore they don't want the responsability associated with it, and as proof i can show you that joeyh upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the other architectures, defaulting it upto the porters, which are the exact same guys doing the kernel packages. So joeyh and fjp can't have it both way. Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access to every other architecture out there, and with some of the There is absolutely no need for any architecture access to simply repackage the modules into an .udeb. Absolutely no need. architectures that I do have access to suffering from unaddressed kernel bugs (ie #332962) that make my hardware for them useless for testing new d-i releases, as well as being limited to modem speeds, makes it difficult to maintain anything more. So, what do you think d-i is so special that it deserve special attention, and should not fall in the common case of debian kernel bugs ? Maybe you will in the future start building your own kernels too ? It is just damn repackaging, nobody asks you to test anything at all. If you take a closer look at the commits in question, my changes were limited to kernel-wedge, which means the maintainers for other arches benefit from them. Probably the packages for other architectures can be updated with just a rebuild and simple testing, although it can be very this has not been the case in the past, and you should simply have rebuilt and uploaded them or something. hard to tell, since what hardware is common on which architectures, and thus which udebs it should go into, is not always easy to determine if Indeed, which is why it is not needed to duplicate that process twice, once when the kernel port maintainer choses which config option to include and which not, and twice when you chose to include those modules in the .udebs or not. you're not intamately familiar with the architecture. Which is a good reason to have maintainers who are, instead of me. None, except for modules concerning the powerpc64 hypervisor and virtual scsi stuff, of the upgrades that i did for powerpc since the sarge release needed that kind of intimate knowledge. And all the changes i did, where mirrored on x86 or something, and i lost maybe 2 hours or so each time time which i could have spent doing useful work. Saying that this means I lack responsibility and am only interested in taking the easy way out is, again, insulting. plonk No, but you cannot deny that both you and Franz have been ranting against the porters not taking their duty seriously in the past, and this is one area where you could make their time more worthwhile, but chose not to. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. -- Besos, Marga
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. for etch we will work for our best to be ready. please don't rush out such mails without consensual position. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) Yeah, i was already chidded (?) that my mail was too inflamatory, this was not the intention, altough i wrote it such to get some reaction upto a point :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On :) the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? There is no way of common measure between todays situation and what happened in the pre-sarge timeframe, and we (i, but some of the kernel team at least agreed with that) fully expect to get things working out nicely well before the release date, so that there would be a much reduced impact from the kernel upload on the d-i build schedule. Remember i proposed the common infrastructure already in marsh/april last year, but was voted done for the sarge release on it (with some no-kind words even). The main issue will be one of testing the kernel and d-i built with it, but there should be no technical hurdles which would cause month-long delays. last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. But still, it is an image issue, and i believe the kernel team would be more happy if the obsolet the day it comes out stigma debian has had in the past doesn't touch us. Also, you will pay in maintenance cost for those few month difference during all the etch livetime, guess who will be ending doing this work ? So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
(forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. Producing new udebs for all architectures for d-i can be done quite fast, as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. pgpqdiSs8RCu9.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:32:12PM +0100, Maximilian Attems wrote: On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. the kernel is an essential piece of our release, makes sense to have it in tune with everchanging userspace interfaces (alsa, udev to name a few). Indeed, that is why it is part of base, but putting it in comparison with the toolchain (glibc, gcc, etc) is overkill. N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. we had the chance for sarge, but we weren't ready. Due in big part to the messed up kernel situation we inherited from in sarge, remember i proposed delaying sarge to get the unified kernel infrastructure :) for etch we will work for our best to be ready. indeed. please don't rush out such mails without consensual position. like bow and smile and wait forever ? This is not i believe the debian way of handling things, and i am certainly not the only one taking this kind of approach, and much more involved and whatever DDs than me have done it like that, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, but there is still work to be done on the d-i side of it, and more specifically with the module .udebs, which could be uploaded quickly, but rely on the porters doing very unfriendly drudge work. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) The first kernel after 2.6.8 that was a real improvement was 2.6.12 and that was released definitely too late for Sarge. Agreed, the issue is the common infrastrucure, and the cost the previous situation has, and the repercusion of this cost on stable-security. Already it should be possible, provided the d-i guys get their act together, to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel release, altough the image build may take longer, and we hope to get the external modules and patches streamlined by then. This is an extremely bad way to get friendly cooperation and discussion about changing anything. :) Well, we could have released 2.6.15 with .udeb modules included, which would have been less friendly even. Producing new udebs for all architectures for d-i can be done quite fast, It could, joeyh even told me it could be easily automated, and Kamion mentioned me he is already doing part of what is needed for that automation (namely building module .udebs without installing the kernel images), but upto now it is still a pain, and takes over a week or two to get done, this was the case for both 2.6.12, and 2.6.14, and why is that ? Because the porters are slackers is not really the right reply to this. as evidenced by the recent uploads for 2.6.14, provided the porters taking care of the udebs for their architecture . I expect little problems or delay for 2.6.15. Indeed, and this is the crux of the problem, you put all the responsability on the porters, while there is really no porter work needed at all. it is only the nature of the non-unified package that the mainstream arch gets build quickly, and the non-mainstream arches get bit-rotten until there is an urgency and the porters get kicked. This is the process problem we are facing, and i think we can solve in a way satisfactory to the d-i team. My plan is to come up with something for the 2.6.16 timeframe, which you can then review, and if it works out well, be used shortly afterward. Etch should release with 2.6.18 i believe, with the current timeframe, so we have two versions afterward to sort things out. As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for i386. And exactly this is the bug, and not the feature, it did happen quite fast for i386, but nobody cared about the other arches, like before the i386 kernel came out quite fast, but other arches came out with a more or less longer delay. Compare with same day upload on 9 of the 12 main debian arches ? Yes, we did wait a while before updating to 2.6.14, but that was mainly because d-i itself first had to prepare its userland for the removal of devfs. The 2.6.12 to 2.6.14 upgrade was indeed very very painful because of the devfs removal and thus initrd-tools replacement, i am well placed to know about that. So please, get off your hobbyhorse and stop pissing people off with unfounded statements. He, so, there is no problem, and the situation is perfect, and you prefer to hide and shoot the messenger :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:26:02PM -0300, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Indeed, but that would be something the kernel team is best placed to decide, and if a given unstable kernel is crappy, we won't allow it in testing, its that simple. So, I'd say it's better to give some time to be sure that the kernel that is shipping with Debian's stable distribution is really a stable kernel, and not a crappy one. I don't think you can tell the difference before this version of the kernel reaches a big number of people, and therefore, it does need time (frozen, in testing). Indeed, unstable is such a place, but is 4 month too much of a time to find out, and would a month or two be enough, i do believe this. However, if while preparing the release, the frozen kernel would show up as being a crappy one, the release managers might allow for a new kernel to enter testing. But this is only a hypothetical case, and I expect it would be carefully evaluated before it actually happened. The crappy kernel would never enter testing in the first place, as testing has always been done on unstable. See 2.6.14 is out for over 2 month now, and it didn't reach testing, and never will now that 2.6.15 is out, because the devfs/initrd-tool situation, and this was the right thing to do. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. Rejecting a badly thought out proposal is _not_ the same as saying no outright. I'm not going to repeat the arguments here. They can be found in the archives. Your attitude does nothing to motivate me to work on this. pgp7K3qzGswtd.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:33:44PM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:01, Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) Bullshit. We (d-i team, mainly Joey) gave very good reasons why we thought the proposal was not good and would result in more problems than it solved. You did indeed give good reasons why having the one .udeb per module plan i follhardly proposed would not work. The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. I believe that this is indeed an argument, but which is outweighted by the benefit especially on the port situation, i believe, and the reason i come back with this times after time :) That you choose to structurally ignore the opinions, comments and objections by others who are a lot more knowledgeable about the _other_ area in Debian impacted by the proposal is typical. Yeah, i am an idiot and you know best, especially when you fail to clearly understand what i propose and chose to reject it on the basis of what you think i propose, this is probably due in part to some lacking in my communication skills, but i guess you also don't make things easy. Your half-baked proposals may look good from a kernel maintenance viewpoint, but in our opinion they have a negative impact on the d-i side of the equation. And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Don't look only to save a few hours of work during the moment, in order to lose huge amounts of times (and irremediable lose of face even) later on. Rejecting a badly thought out proposal is _not_ the same as saying no outright. Yeah, but you have kept saying to me : it is a stupid idea, don't even think about it, and then you speak about badly thought out proposal ? I'm not going to repeat the arguments here. They can be found in the archives. Indeed, apart from the fact that they are the arguments against the wrong proposal :) Your attitude does nothing to motivate me to work on this. Yep, but i don't ask you to work on this, while you ask me to not work on it and keep the status quo, which is broken. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. If you would like to blame this pendant, you'll need to be a bit more specific. -- see shy jo signature.asc Description: Digital signature
Re: bits from the release team
On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. pgpCp2aRNAJTL.pgp Description: PGP signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:09:18PM -0500, Joey Hess wrote: Sven Luther wrote: And have you added stable-security into the equation ? Your choices of back in april are in part responsible for the abysmal situation in stable-security with regard to kernels during these past months. Pedantically speaking, fjp made no d-i release decisions last April. Nope, you did, and the Your above was meant to be the d-i team. I also remember you accusing of single-handledly delaying the sarge release by a week, which was not welcome after i invested almost a week fighthing with k-p to get the 2.4 ppc kernels in a decent shape for sarge, especially as i didn't really believe into 2.4 powerpc kernels at that time. Would i have told you at the start of that week what i would have tried to do, can you honestly you would have let me do it ? But anyway, let's agree to disagree or whatever, and stop hurting each other, there will be a proposal made in the 2.6.16 timeframe, and we can then speak again about this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote: On Tuesday 03 January 2006 23:52, Sven Luther wrote: The current proposal is about simply using the same .udeb organisation and move it inside the linux-2.6 common package, which is something that works out just fine for ubuntu even, but which the current linux-2.6 common package infrastructure could also handle. So, when can we expect a coherent, full proposal (with overview of benefits, possible pitfalls, things that need to be worked out further, and so on) on this in a dedicated mail on a new thread to the relevant mailing lists, so we can actually comment on it instead of only seeing a rough outline mentioned every so often as part of a flame? The linux-2.6 package will propose a solution which will produce the *EXACT SAME* set of .udebs as with the current kernel-wedge solution, and will be more easy to maintain in a more automated way, and integrated with the rest of the linux-2.6 kernel, so porters only need to do the work once in a single integrated way. (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? The only reason i saw against this was a mail from joeyh mentioning ease of moving modules around inside .udebs, and that this would be easier under the d-i umbrella than if it is inside the kernel, and naturally the old sarge-time brokeness in the archive infrastructure, which is presumably fixed by now, or should be fixed for etch. You forget the argument that when kernel udebs are maintained within d-i, we will be much more likely to spot changes in them as a possible cause of breakage when installation-reports come in. well, if the only thing you are afraid about is documentation, we shall provide you with this information in a way most suitable. All this can and and will be easily automated and presented upon you on a platter, which is not the case with the current kernel-wedge situation, where the i386 .udebs and kernel-wedge are updated and the rest of the ports left out in the cold without any kind of info about possible breakage already fixed on i386, thanks you very much, so two weights two measures, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:04:39PM -0500, Joey Hess wrote: Sven Luther wrote: Indeed. The d-i team usually says no outright to any kind of proposal of this kind, so it is up to the kernel team to come up with an implementation which convinces them :) The release team deserves to be informed about the possibility though. Cite message-ids or irc logs please. Such hiding in the sand, ... well i don't keep irc logs, and you can go searching for those past email posts as well as i can. Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Understanding how the above paragraph could be perceived as insulting is left as an exersise for the reader. Yeah, and i have mails from you which where degrees of magnitude more insulting than those, and i have still not forgiven you about the way you hurt me in april. So tone done your arrogance a bit, please. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? (Other than telling people just use Ubuntu, which is what I do.) -- ciao, Marco signature.asc Description: Digital signature
Re: bits from the release team
On Tue, 3 Jan 2006, Margarita Manterola wrote: On 1/3/06, Sven Luther [EMAIL PROTECTED] wrote: Why do you put the kernel together with the essential toolchain freeze, it should be together with the rest of base, i believe. [...] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. So, we will be asking the question about the upgradability of the kernel later during this release process, and i believe that it is not something which should be ignored. Already you are considering upgrading the sarge kernel which has some trouble booting on a rather non-negligible quantity of hardware, so having a two version outdated kernel at release time is not nice. I really don't think that having a four months out-dated kernel is that bad. What is really important is to have stable kernels. Past experience with the modified 2.6 release policy has shown that some 2.6 kernels are pretty stable and some others are quite crappy. Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2006 00:24:04 +0100 Sven Luther [EMAIL PROTECTED] wrote: (Without the current method sucks comments please; saying I think the current situation could be improved by... is much more likely to get positive reactions.) This is not my past experience though, and the current method sucks, this is a fact, i as powerpc porter of d-i have to live with, so why should i not be allowed to express my opinion about this ? Because your ignorance of being rude will hurt the conversation - even if your arguments are sane. Go ahead and claim that I have no right to say so due to my having a record of being rude myself. Such reaction would only prove my point here. - Jonas P.S. Please do *not* cc me as I am subscribed to d-kernel! - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuwm8n7DbMsAkQLgRAklqAJ9Tz82+Gw7DjDid2F2cncgsjh2kswCfcZYn J8jSPC7UpM3ut3Oo/5BXkK4= =seHD -END PGP SIGNATURE-
Re: bits from the release team
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 05:28:15PM -0600, Adam Heath wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. Notice that Linus recently expressed on LKML that udev and other userland breakage on kernel upgrade is not to acceptable, so this would be a bug to be fixed. But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote: But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev and it works. AFAIK it should work with the default ruleset. It breaks only with certain custom rules due to a bug in the libsysfs version used by udev. So, if you did not create any udev rules yourself you should be fine. With old udev and new kernel my rules that map my USB disks to persistent names under /dev were definitely broken. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2006 10:13 PM, Sven Luther wrote: On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? Why doesn't debian really collaborate with ubuntu on the kernels, which would be more natural. Debian use mostly the mainline upstream kernels, which is where everything goes back in anyway, so ... Just my two cents... :) Sometime ago, Adrian Bunk [1]raise the question about a kernel stable tree in LKML, after a lot of discussion (and AFAIK no good resolution), a lot of ideas travel on the list (also in the midle of flamewar), ideas like try to not break the entire userland and let the distro take care of having a stable kernel. 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) If you give it a quick look (and a quick try), we will have more users testing the same kernel, which means more feedback, we will have more developers working to get it stable and working to get it secure. Probably even upstream get benefits from this model and sounds like a very good way to work together, even to try to integrate outside patches and backporting things. =) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFDuzGiCjAO0JDlykYRAsYxAKCYl+WPqiEWapKTK3Yee//o6Dn58wCfXPh5 JOZOVATPQIMWPgMnHzDuKrg= =qcxC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, You have been harranguing the ftp team to approve new upstream kernels through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. The underlying assumption in your plea for a shorter kernel freeze is newer is better. But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. There is still room for targetted fixes to the kernel after the freeze date; backports of new drivers, or backports of specific bugfixes, are certainly fair game. Taking a new version of whatever upstream happens to have released would not be. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) I'm all in favor of streamlining the integration of new kernel versions into the installer, but I don't believe that the majority of the work involved falls into the automatable category. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:34:43PM -0800, Steve Langasek wrote: On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. Also, notice that cooperation with the ubuntu kernels was more marked when Fabionne was the ubuntu kernel maintainer, but now that he has passed the relay, i feel that it is less. We have proposed to them to use a common infrastrcuture with enabled/disabled patches for both, but the reply was mostly of the kind, yeah we would like to cooperate, and no actions followed. I believe it has also an influence on the place where the source package is ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said we should use their system. So, altough patches can occasionally be exchanged, i doubt that cooperation will go further for control-and-politics reason, and i believe it is maybe best so for both involved. There can be cooperation without sharing all the infrastructure and packaging. Other less high-profile daughter-distros are probably simply reusing the debian kernel, and this is probably the best way of doing this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Sven Luther ([EMAIL PROTECTED]) [060103 23:02]: On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. i think comparing the kernel with the toolchain is overkill, if nothing else a last minute change in the toolchain will need a kernel recompile anyway maybe. I do confess that i read June 30 at first, and this seemed much less acceptable to me. well, the kernel is definitly about the same level as the toolchain and standard/base - changes can have very easily impact on the installer, and it is not an option to remove the package if it is broken. N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough What experience ? I was speaking about the installer. And usually there are lots of last-minute changes that need to go in - not only new languages, but lots of other small minor, but still important bug fixes. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. Hehe, me runs sid kernels installed almost as is on all my sarge systems indeed, just with rebuild yaird and mininmally backported udev. Well, but then an older kernel doesn't hurt you? :P Indeed, but you have only the sarge experience to go by, and taking the sarge experience on this is hardly fair to the huge amount the kernel team has devoted to streamline the process. Of course, we have seen that the kernel build process is way more mature now. Nobody doubts that. Also, i don't really believe joeyh and fjp are really the relevant maintainers with regard to the debian kernel and its application, since they lack the vision of how things could go better, or more thruthfully, probably lack the time and motivation to think really about the issue, and why should they, it is the kernel team jobs :) Well, they are definitly the relevant people for the installer. And, frankly speaking, at least I have good experience with both of them. d-i is only a part of the problem anyway, and i believe the less problematic. out-of-tree modules and third-party patches are a worse mess. Hm, which out-of-tree modules do you consider to be release critical, i.e. we cannot release without them? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
