Re: sarge kernel frozen (2.4.27 and 2.6.8), and plans for post-sarge powerpc kernels.
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.