Re: Kernel 2.2 and Slink
On Fri, Feb 12, 1999 at 04:14:04AM -0700, Ivan E. Moore II wrote:
> On Fri, Feb 12, 1999 at 11:01:03AM +0000, Jules Bean wrote:
> > How about this for potato release goals:
> >
> > Linux 2.2
> > Choose a gtk-version and call it stable (1.1.15, maybe). Recompile all
> > our gtk-apps and gnome with this single version.
> > Do the perl 5.005 transition.
>
>
> How hard would it be to slide XFree86 3.3.3 into that? I notice
> there isn't a debian package for it yet..(well at least
> it hsasn't shown up in my dselect...but that prolly has
> to do with needing to get 3.3.2 stable for slink...I haven't
> been following the thread on all of that as you can tell. :))
>
I think it will be auite easy, i have already made a 3.3.3.1 debian package for
the ppc port (the official one refused to compile for me.) But branden didn't
like it, and was quite busy working on releasing X for slink, and don't wanted
to be disturbed with my work. (Altough i still don't understand what the
problem was, since an upload to potato should not have broken anything in slink
...)
Anyway, i guess if we want ot include that in a fast comming potato, and sinec
X is a monster of a package, i propose that a second team, who could include
people of all architectures who will release for potato), who would work on a X
3.3.3.1 (or anything newer) to include into potato, who will make previous work
on it, and release potato packages of X, and once branden has finished X for
slink (when slink is released i guess) and taken some due rest, he can take
over our work.
In general, if we plan on making fast succesive release (i think i heard
something about 4 releases a year some time ago), it would be better to have
two sets of maintainer, at least for base and other important stuff (X, gcc,
glibc, gtk, gnome, anything else ?) one who will work one frozen, and the other
who will work on unstable. And after the release, either they swap roles (the
one from froaen works on new unstable, while the one from unstable continue
working on their packages now in frozen), or the unstable maintainer could pass
down the job to the frozen maintainer, and continue working on bleeding edge
stuff.
i know it will make for more work, but it will improve the quality, and will be
needed if we want to go for more raproched releases with fewer goals.
Friendly,
Sven LUTHER
Reply to: