XFree86-3.3.3 is really not in slink?
Katsura S.Yoshio
Hi,
I would like to have XFree86-3.3.3 in slink. Because, the risk is
rather small, but the advantage is quite big.
Risk ... Security patchs have alreay been applied to 3.3.2.3
... Most newer X server had already tested enough on S.U.S.E
and Redhat.
Advantage ... neoMagic X Server
Virge Chip BUG fix
Regards,
K.Yoshio / Debian JP Project member
mailto:shis...@osk2.3web.ne.jp
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Robert Edmonds
On Mon, 30 Nov 1998, Katsura S.Yoshio wrote:
>
> Hi,
>
> I would like to have XFree86-3.3.3 in slink. Because, the risk is
> rather small, but the advantage is quite big.
>
> Risk ... Security patchs have alreay been applied to 3.3.2.3
> ... Most newer X server had already tested enough on S.U.S.E
> and Redhat.
>
> Advantage ... neoMagic X Server
^^^^^^
A NEW X server?? more bugs!! aieee!!
> Virge Chip BUG fix
^^^^^
I have a S3 Virge DX. I am not aware of any bug in my chip.
>
> Regards,
> K.Yoshio / Debian JP Project member
> mailto:shis...@osk2.3web.ne.jp
No. I think the risk is rather large: many programs (e.g. xterm) have been
changed quite a bit. If we put it in slink we will probably have more
release-critical bugs, take more time to fix them, release slink later and
more obsoleter...
--
Robert S. Edmonds
+-------------------------------------------------------+
| Debian developer | http://www.debian.org |
| Freshmeat staff member | http://freshmeat.net |
| NetWinder developer | http://www.netwinder.org |
| s...@novare.net | http://www.stu.ddns.org |
+-------------------------------------------------------+
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Katsura S.Yoshio
Thanks a lot for your followup.
From: Robert Edmonds <s...@novare.net>
Date: Mon, 30 Nov 1998 07:36:05 -0500 (EST)
Message-ID: <Pine.LNX.3.96.981130073213.31006D-100000@helium>
> > Virge Chip BUG fix
> ^^^^^
> I have a S3 Virge DX. I am not aware of any bug in my chip.
XFree86-3.3.3 relnote says that
o Fix some lockups with ViRGE chips.
A lockup phenomenon is reported onto debian-users (Japan) mailing
list. Yes, it is just a little BUG fix though.
> No. I think the risk is rather large: many programs (e.g. xterm) have been
> changed quite a bit. If we put it in slink we will probably have more
> release-critical bugs, take more time to fix them, release slink later and
> more obsoleter...
Well, I am with you at most part. However, I think we will lose
advantages against another Linux distribution (Suse, Redhat ..) on X.
In particular, A lot newer driver advantages (Mostly tested enough)
would be lost. Yes, It requires another burden on maintainer of X....
Regards,
K.Yoshio / Debian JP Project
mailto:shis...@osk2.3web.ne.jp
Key fingerprint = 3C 3C 1C E6 B1 65 53 58 A3 B3 6A ED BA E4 54 52
David Welton
X? The CD people won't like it, I guess, but it lets us get slink
out, with the possibility of upgrading a subset of the packages a
short time later.
Ciao,
--
David Welton http://www.efn.org/~davidw
Debian GNU/Linux - www.debian.org
Remco Blaakmeer
> Maybe we should do like we did with 1.3.1 and do a 2.1.1 with the new
> X? The CD people won't like it, I guess, but it lets us get slink
> out, with the possibility of upgrading a subset of the packages a
> short time later.
I can very much understand that XFree86 3.3.3 will not be in Debian 2.1,
but equally well do I understand that some people need it[1]. Would it be
OK to test it for a while and then release Debian 2.1.1, including XFree86
3.3.3?
And besides, how much does Debian care about the CD people, anyway? Are
they so important that they could tell Debian not to release 2.1.x
versions and that their orders would simply be followed?
Remco
[1] Count me as one of them, but I have very good Internet connectivity,
so for me it's not really an issue as I could get the X server from either
potato or xfree86.org.
Robert Edmonds
> Well, I am with you at most part. However, I think we will lose
> advantages against another Linux distribution (Suse, Redhat ..) on X.
> In particular, A lot newer driver advantages (Mostly tested enough)
> would be lost. Yes, It requires another burden on maintainer of X....
This new functionality is not "lost". If people need neomagic support they
can just download from slink. We can even put a notice for neomagic users
in the install notes or whatever.
--
Robert S. Edmonds
+-------------------------------------------------------+
| Debian developer | http://www.debian.org |
| Freshmeat staff member | http://freshmeat.net |
| NetWinder developer | http://www.netwinder.org |
| s...@novare.net | http://www.stu.ddns.org |
+-------------------------------------------------------+
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
--
Tyson Dowd
>
> And besides, how much does Debian care about the CD people, anyway? Are
> they so important that they could tell Debian not to release 2.1.x
> versions and that their orders would simply be followed?
More likely they would just stop selling Debian, and encourage their
customers to use RedHat, SUSE, Slackware, Caldera or any other
distribution that isn't a lot of trouble to sell.
I think it's a dumb idea to restrict Debian to those lucky people who
have the sort of net connection that allow you to download it.
I can tell you from experience that sales of Debian 2.0 started
dropping off as soon as Debian 2.1 was announced as frozen on slashdot.
Announcing a product months before it is released tends to do that.
(It also gives Debian a reputation for vapourware).
If everyone knows not to bother with 2.1 because 2.1.1 is just around
the corner, well that will kill sales too.
A *much* better solution is to just allow CD vendors to put 3.3.3 on
their CDs in an updates directory, so those people who need it can
install it (and deal with any bugs that are in it).
That way the CD vendors are happy, the release manager is happy,
and the end users are happy.
--
Because I dislike being quoted I lie almost constantly when talking
about my work.
-- Terry Gilliam
Tyson Dowd <ty...@tyse.net> http://tyse.net/
M.C. Vernon
> I can tell you from experience that sales of Debian 2.0 started
> dropping off as soon as Debian 2.1 was announced as frozen on slashdot.
> Announcing a product months before it is released tends to do that.
> (It also gives Debian a reputation for vapourware).
> If everyone knows not to bother with 2.1 because 2.1.1 is just around
> the corner, well that will kill sales too.
In which case should we announce freezes at all?
Matthew
--
Elen sila lumenn' omentielvo
Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.geocities.com/Area51/Chamber/8841/
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/
Andreas Jellinghaus
> ^^^^^
> I have a S3 Virge DX. I am not aware of any bug in my chip.
star office causes s3v servers to freeze, and other applications could have
that problem too. not the applications fault. and the workarounds are too
bad. if 3.3.3 is not in debian, people will need to get the server from a
different source. will ask my cd burners to add xfree 3.3.3 as tarball to
the contrib cdrom, because i need the new servers.
andreas
Remco Blaakmeer
> On 30-Nov-1998, Remco Blaakmeer <remco-b...@quicknet.nl> wrote:
> >
> > And besides, how much does Debian care about the CD people, anyway? Are
> > they so important that they could tell Debian not to release 2.1.x
> > versions and that their orders would simply be followed?
>
> More likely they would just stop selling Debian, and encourage their
> customers to use RedHat, SUSE, Slackware, Caldera or any other
> distribution that isn't a lot of trouble to sell.
Come to think of it, yes that would be a problem.
> I think it's a dumb idea to restrict Debian to those lucky people who
> have the sort of net connection that allow you to download it.
>
> I can tell you from experience that sales of Debian 2.0 started
> dropping off as soon as Debian 2.1 was announced as frozen on slashdot.
> Announcing a product months before it is released tends to do that.
> (It also gives Debian a reputation for vapourware).
> If everyone knows not to bother with 2.1 because 2.1.1 is just around
> the corner, well that will kill sales too.
Yes, I can see this as a problem for CD vendors. But what would you do
about it? Code freezes are announced to the general public (why? I don't
know, but also I don't know why not). At the time of the code freeze a
fixed release date can't and shouldn't be set, because any number of
serious problems with the software could lead to the release being
postponed to some later date. And not releasing on a previously fixed date
will lead to this reputation of vapourware even sooner, IMHO.
What should be done about this, if anything? Shorter freeze periods would
be difficult. Not announcing code freezes to the general public would
also not be a very good solution. What else is possible?
> A *much* better solution is to just allow CD vendors to put 3.3.3 on
> their CDs in an updates directory, so those people who need it can
> install it (and deal with any bugs that are in it).
> That way the CD vendors are happy, the release manager is happy,
> and the end users are happy.
Yes, this is a good idea. I think there would be enough space for this on
the contrib CD. There could be a stable-updates directory on the ftp
servers and this directory could be put onto the contrib CD, which would
make many people happy.
Remco
Katsura S.Yoshio
From: Remco Blaakmeer <remco-b...@quicknet.nl>
Date: Wed, 2 Dec 1998 01:46:50 +0100 (CET)
Message-ID: <Pine.LNX.3.96.98120...@rd31-144.quicknet.nl>
> > A *much* better solution is to just allow CD vendors to put 3.3.3 on
> > their CDs in an updates directory, so those people who need it can
> > install it (and deal with any bugs that are in it).
> > That way the CD vendors are happy, the release manager is happy,
> > and the end users are happy.
>
> Yes, this is a good idea. I think there would be enough space for this on
> the contrib CD. There could be a stable-updates directory on the ftp
> servers and this directory could be put onto the contrib CD, which would
> make many people happy.
I think I would be happy, too.
By the way, We Debian JP Project already have XFree86-3.3.3 with XTT
rendering engine on potato-jp maintained by Mutsumi-san. Please take
a look at it.
ftp://ftp.debian.or.jp/pub/Linux/debian-jp/dists/potato-jp/main/binary-i386/x11/
Regards,
K.Yoshio from Debian JP Project
mailto:shis...@osk2.3web.ne.jp
Sven LUTHER
>
> From: Remco Blaakmeer <remco-b...@quicknet.nl>
> Date: Wed, 2 Dec 1998 01:46:50 +0100 (CET)
> Message-ID: <Pine.LNX.3.96.98120...@rd31-144.quicknet.nl>
>
> > > A *much* better solution is to just allow CD vendors to put 3.3.3 on
> > > their CDs in an updates directory, so those people who need it can
> > > install it (and deal with any bugs that are in it).
> > > That way the CD vendors are happy, the release manager is happy,
> > > and the end users are happy.
> >
> > Yes, this is a good idea. I think there would be enough space for this on
> > the contrib CD. There could be a stable-updates directory on the ftp
> > servers and this directory could be put onto the contrib CD, which would
> > make many people happy.
>
> I think I would be happy, too.
but what about X 3.3.3 in potato ? there don't seem to be yet debian sources
for it ...
what is the reason for the xfree86-corel packages ? would it not be nicer if we
could present them in the form of patches against the normal xfree, instead of
having two xfree source that are both more than 40MB big, this is hard on
people mirroring the source tree. Also i noticed same problems with
base/fileutils-hurd and base/fileutils, both package seem to be exactly the
same size, so they are chances that they are there two times. Is this really
necessary ?
Should the correct thing to do not be one .tar.gz file, and a n extra set of
diff/dsc files ?
i guess there are more files in this case ...
Friendly,
Sven LUTHER
Katsura S.Yoshio
From: Sven LUTHER <lut...@maxime.u-strasbg.fr>
Date: Fri, 4 Dec 1998 15:46:04 +0100
Message-ID: <1998120415...@maxime.u-strasbg.fr>
> having two xfree source that are both more than 40MB big, this is hard on
> people mirroring the source tree. Also i noticed same problems with
Right, and I'm afraid the duplication work of the maintainer.
Having two X sources semms to be tough for X maintainer, isn't it?
Regards,
K.Yoshio from Debian JP Project
mailto:shis...@osk2.3web.ne.jp
Key fingerprint = 3C 3C 1C E6 B1 65 53 58 A3 B3 6A ED BA E4 54 52
Jiri Baum
> Code freezes are announced to the general public (why? I don't know, but
> also I don't know why not).
Well, it'd be kinda hard for a freeze to go ahead without *some* mention of it
slipping into debian-devel... which is a publicly list. It's obvious on the
ftp server. Any number of places.
> What should be done about this, if anything? Shorter freeze periods would be
> difficult. Not announcing code freezes to the general public would also not
> be a very good solution.
How would you keep it a secret?
Jiri <ji...@baum.com.au>
Jim Pick
Sven LUTHER <lut...@maxime.u-strasbg.fr> writes:
> what is the reason for the xfree86-corel packages ? would it not be
> nicer if we could present them in the form of patches against the
> normal xfree, instead of having two xfree source that are both more
> than 40MB big, this is hard on people mirroring the source
> tree. Also i noticed same problems with base/fileutils-hurd and
> base/fileutils, both package seem to be exactly the same size, so
> they are chances that they are there two times. Is this really
> necessary ?
I created the xfree86-corel package because Corel had some big patches
that weren't merged in.
I agree it isn't ideal. Hopefully, it'll be replaced soon with a
patch against the standard xfree86 package.
> Should the correct thing to do not be one .tar.gz file, and a n extra set of
> diff/dsc files ?
>
> i guess there are more files in this case ...
I like how the glibc package contains a debian/patches directory for
additional patches which are patched in at build time.
Cheers,
- Jim
James Taylor
> > also I don't know why not).
>
> Well, it'd be kinda hard for a freeze to go ahead without *some* mention of it
> slipping into debian-devel... which is a publicly list. It's obvious on the
> ftp server. Any number of places.
Yes, but announcing it on debian-devel is a lot different from advertising
it on the web site, having an IRC party, submitting it to Slashdot, et
cetera.
l;jt
Scott Ellis
> > > Code freezes are announced to the general public (why? I don't know, but
> > > also I don't know why not).
> >
> > Well, it'd be kinda hard for a freeze to go ahead without *some* mention of it
> > slipping into debian-devel... which is a publicly list. It's obvious on the
> > ftp server. Any number of places.
>
> Yes, but announcing it on debian-devel is a lot different from advertising
> it on the web site, having an IRC party, submitting it to Slashdot, et
> cetera.
Of course, I'd really like to know how you can announce anything
significant on debian-devel without it almost immediatly being forwarded
bt 20 people to slashdot and freshmeat these days. :)
--
Scott K. Ellis <st...@gate.net> http://www.gate.net/~storm/
Marcelo E. Magallon
> Yes, but announcing it on debian-devel is a lot different from advertising
> it on the web site, having an IRC party, submitting it to Slashdot, et
> cetera.
If we don't publicize the freeze, where are we going to get the people that
test the distribution from? Or do you have any other reason for the number
of critical and important bugs to rise by a significant ammount on every
freeze?
Marcelo.
James Taylor
> > it on the web site, having an IRC party, submitting it to Slashdot, et
> > cetera.
>
> If we don't publicize the freeze, where are we going to get the people that
> test the distribution from? Or do you have any other reason for the number
> of critical and important bugs to rise by a significant ammount on every
> freeze?
>
> Marcelo.
I quite agree with you. But I think that the way this freeze was handeled
was very poor. It makes sense to set a freeze date goal. If this is missed
(as happened with slink) it is not a problem, a new goal is set.
Eventually once a freeze is attained, we THEN advertise the freeze, and
make it very clear that it is to be used for testing only.
But the way the freeze is advertised is very important. People need to
understand that the release is not stable and not for general use. I don't
feel that is the case with slink.
---------------------------------------------------james.taylor---
this IS the state of nature.
---http://fsck.org/~valis-----------------------------------------
Jim Pick
James Taylor <jta...@emba.uvm.edu> writes:
> I quite agree with you. But I think that the way this freeze was handeled
> was very poor.
I don't know. I can't remember a freeze that we've done really well.
We're probably doing just as well on this one as on previous ones, if
not better. The job has gotten harder, but now most people know
more-or-less what to expect.
Cheers,
- Jim
Sven LUTHER
>
> Sven LUTHER <lut...@maxime.u-strasbg.fr> writes:
>
> > what is the reason for the xfree86-corel packages ? would it not be
> > nicer if we could present them in the form of patches against the
> > normal xfree, instead of having two xfree source that are both more
> > than 40MB big, this is hard on people mirroring the source
> > tree. Also i noticed same problems with base/fileutils-hurd and
> > base/fileutils, both package seem to be exactly the same size, so
> > they are chances that they are there two times. Is this really
> > necessary ?
>
> I created the xfree86-corel package because Corel had some big patches
> that weren't merged in.
>
> I agree it isn't ideal. Hopefully, it'll be replaced soon with a
> patch against the standard xfree86 package.
>
> > Should the correct thing to do not be one .tar.gz file, and a n extra set of
> > diff/dsc files ?
> >
> > i guess there are more files in this case ...
>
> I like how the glibc package contains a debian/patches directory for
> additional patches which are patched in at build time.
but ther is a glibc-hurd tarball in addition of the normal glibc one, both ~7MB
big.
Friendly,
Sven LUTHER