On Tue, Apr 05, 2005 at 05:04:20PM +0900, Horms wrote: > On Tue, Apr 05, 2005 at 09:03:01AM +0200, Sven Luther wrote: > > On Tue, Apr 05, 2005 at 03:15:00PM +0900, Horms wrote: > > > On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote: > > > > Hello, > > > > > > > > It seems as the 2.4.27 and 2.6.8 kernels which are sarge release > > > > candidates > > > > are now frozen, and will be part of sarge as is, complete with all the > > > > bugs > > > > and problems present in them, and maybe even some security issues which > > > > will > > > > not be fixed in d-i, but only in testing/stable-security-updates, due > > > > to the > > > > longish time needed for d-i to regenerate their kernel. > > > > > > > > I thus announce my intentions to stop any work on those kernels, and > > > > give them > > > > over to the sarge security team and/or any other group of people who > > > > will be > > > > handling stable kernels, and focus my attention on the 2.6.11 and beyond > > > > kernels. > > > > > > > > I will shortly orphan those packages, but will not do an upload setting > > > > their > > > > maintainers to q-a, as they should be maintained by the kernel-team > > > > anyway, > > > > and i will not waste 24+ hours of build and bandwidth for such a small > > > > change. > > > > > > Is there any need to oprphan them, aren't they maintained by the kernel > > > team? > > > Though you are the only person on the team who does ppc stuff IIRC, so > > > maybey it does make sense. > > > > Yep, it is more a flag to invite someone to take over. I believe that there > > is > > not really much need to do any special work, the most difficult thing would > > be > > : > > > > 1) monitor the kernel-source uploads so that you know when to build. > > => this is a generic problem, and we should maybe have some process in > > place > > to streamline this, and some framework to follow this. I believe that > > failure to handle this correctly is the number one reason for the huge d-i > > delays joeyh complained about, but as there doesn't seem to be any will to > > fix the technical problem, i don't want to get involved in this anymore. > > > > 2) notice that a kernel-source upgrade broke a particular arch and provide > > feedback. This is of two kinds, either added config options, and here > > again > > we need a process, or a kernel-source patch which breaks an existing arch > > patch. > > > > The rest is just bumping the changelog entry and doing the build. The only > > part which can't really be automated is the signing of the packages, altough > > ideally the packages should be feed to the autobuilders. The sarge team > > didn't > > want to take the time to streamline this process and make it all easier in > > the > > future, so afeared where they of the delay this will cause, so i wash my > > hands > > of this and let them enjoy the mess they will get, and deservedly. > > Are there debian machines that are suitable for doing such a build > should the need arise? It seems that if it is just a matter of running > a build and watching bugs, then whoever updates kernel-source could do > the ppc build. That is assuming someone like yourself who knows a bit > more about ppc is available for consultation of problems arise.
There should. At least on ppc, i offered a pegasos machine to the debian-admins and it got rejected because there really wasn't need, so ... Many folk have got free pegasos ppc hardware from genesi, including Christoph and Jens, so there should be no lack of such boards. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
