Re: Changes to Debian Installer release process
On 07/28/2011 01:18 PM, Otavio Salvador wrote: I used some of Debcamp and Debconf time this year to discuss the Debian Installer release process with some people and after talking with many people it seems we agreed on the following changes on Debian Installer release process and it would be interesting to receive feedback on those to see if anyone see a problem we didn't notice yet. Great, lets make d-i as easy to handle as general packages (or at least almost ;-))! * Official uploads to be built against unstable Sounds good. * Linux kernel udebs to be built from linux source package Also looks good. * Debian Installer daily builds to be done from source uploads The daily builds will use the archive source for building so every time we do a change in unstable in a module that is included in initrd it will trigger a binNMU in all architectures replicating what we have in daily builds. When source changes in debian-installer source package are done, a new source upload will be required. Do the daily builds only uncover issues from building the initrd? A.k.a. will changes in packages other than the one in the initrd only have an effect on the install via genuine downloading from the archive at the time of the install? * Debian Installer experimental builds With Linux kernel udebs built from linux source we have the possibility to get the installer built against the development kernel that will be available on experimental and this is quite important to us to be able to test all this before it is available in unstable to avoid bad surprises for us and users. This will also be a handy tool for us to play with not well tested or finished stuff without breaking installer to end users. Sounds good! * Use of britney to handle package and installer migration This is the end of the process and some details are yet unknown how this is going to happen however but our goal is to make it happen since it will alleviate a lot the amount of work to make Debian Installer release to happen. Super! It is important to notice that it is not a single-man effort but a coordinate and shared effort of Debian Kernel, Debian Release and Debian Installer teams to get all this done. Those changes are not going to happen at once but in a progressive process and at the end this is going to make the installer release process easier to understand and handle. Right, lets go for it! Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e341d9a.1040...@debian.org
Re: Changes to Debian Installer release process
On Sat, Jul 30, 2011 at 17:04, Luk Claes l...@debian.org wrote: ... * Debian Installer daily builds to be done from source uploads The daily builds will use the archive source for building so every time we do a change in unstable in a module that is included in initrd it will trigger a binNMU in all architectures replicating what we have in daily builds. When source changes in debian-installer source package are done, a new source upload will be required. Do the daily builds only uncover issues from building the initrd? A.k.a. will changes in packages other than the one in the initrd only have an effect on the install via genuine downloading from the archive at the time of the install? Mostly; the only addition situation we'll need to rebuild the installer is when the amount of translation changes for a specific language so we get the 'translation-status' file updated into the initrd. Cheers, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odkpinxtg0z7neo1mye-jgrx_lh1tmry0_q3nm1g8z9e...@mail.gmail.com
Re: Changes to Debian Installer release process
Quoting Otavio Salvador (ota...@ossystems.com.br): Mostly; the only addition situation we'll need to rebuild the installer is when the amount of translation changes for a specific language so we get the 'translation-status' file updated into the initrd. We might need to find a way to avoid rebuilding just because *one* language changed. Mostly because this happens really often..we don't really have control about the translator's schedule and they happen to commit things more or less randomly (with peaks when something is changed in a string, or when strings are added: some like to be 100% all time long..:-)). As I'm watching all this very regularly, we could maybe imagine something where the i18n coordinator can trigger an l10n-rebuild because (s)he notices that a given language changed significantly enough to be worth itor because it has been too much time since the last rebuild and many very small changes piled up. signature.asc Description: Digital signature
Re: Changes to Debian Installer release process
On Sat, Jul 30, 2011 at 22:12, Christian PERRIER bubu...@debian.org wrote: Quoting Otavio Salvador (ota...@ossystems.com.br): Mostly; the only addition situation we'll need to rebuild the installer is when the amount of translation changes for a specific language so we get the 'translation-status' file updated into the initrd. We might need to find a way to avoid rebuilding just because *one* language changed. Mostly because this happens really often..we don't really have control about the translator's schedule and they happen to commit things more or less randomly (with peaks when something is changed in a string, or when strings are added: some like to be 100% all time long..:-)). But this will change only when we upload the package to the archive so we can try to upload a set of packages with translation updates to avoid this. Basically the binNMU would be triggered when the translation status change for a language and since we work with percentage this will not change on every translation update. As I'm watching all this very regularly, we could maybe imagine something where the i18n coordinator can trigger an l10n-rebuild because (s)he notices that a given language changed significantly enough to be worth itor because it has been too much time since the last rebuild and many very small changes piled up. Or maybe if there's no initrd changes queue it to the end of week if nothing else changes? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odko0ent87kdj_cevexzwi+g+iedn8r9__kqgluzn7_u...@mail.gmail.com
Changes to Debian Installer release process
I used some of Debcamp and Debconf time this year to discuss the Debian Installer release process with some people and after talking with many people it seems we agreed on the following changes on Debian Installer release process and it would be interesting to receive feedback on those to see if anyone see a problem we didn't notice yet. * Official uploads to be built against unstable Currently when we do a source upload of debian-installer it gather all build-depends on /unstable/ but the udebs from /testing/. We want to get it change and all udebs be fetched from unstable so we will migrate it all to testing when ready and not before building as done currently. This is going to make easier to Debian Installer and Debian Release teams to coordinate the migration of packages to testing. Philipp will send a mail regarding this with more details later. * Linux kernel udebs to be built from linux source package We won't get rid of kernel-wedge instead linux source package will use it during the build process to produce all the kernel udebs from it. Ben will send a mail about this later with a more detailed description. * Debian Installer daily builds to be done from source uploads The daily builds will use the archive source for building so every time we do a change in unstable in a module that is included in initrd it will trigger a binNMU in all architectures replicating what we have in daily builds. When source changes in debian-installer source package are done, a new source upload will be required. * Debian Installer experimental builds With Linux kernel udebs built from linux source we have the possibility to get the installer built against the development kernel that will be available on experimental and this is quite important to us to be able to test all this before it is available in unstable to avoid bad surprises for us and users. This will also be a handy tool for us to play with not well tested or finished stuff without breaking installer to end users. For now, I think we will need to use an infra-structure similar of what we have today for daily builds for those. * Use of britney to handle package and installer migration This is the end of the process and some details are yet unknown how this is going to happen however but our goal is to make it happen since it will alleviate a lot the amount of work to make Debian Installer release to happen. It is important to notice that it is not a single-man effort but a coordinate and shared effort of Debian Kernel, Debian Release and Debian Installer teams to get all this done. Those changes are not going to happen at once but in a progressive process and at the end this is going to make the installer release process easier to understand and handle. Please share your ideas regarding those proposed changes so we can start looking on the required changes to accomplish all this. Thanks in advance, Regards, -- Otavio Salvador ota...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odko9_21zxolagenchnte8+xc1p4xr6vxnavugqcwekb...@mail.gmail.com
