Re: The nature of testing and where can others help (Was Re: HowTo for Gnome2??)
Hi. Your post was very very long; so I hope you won't mind that I've
only got time to reply to parts of it, sorry.
On Fri, 04 Jul 2003 14:06:37 -0600
Jacob Anawalt <jacob@cachevalley.com> wrote:
>
[ snip ]
>
> Unfortunatly for a Debian neophyte like myself your descriptions seem to
> be contrary on some points to the statements describing the packages
> found here: http://www.debian.org/distrib/packages. I may be
> misunderstanding the last paragraph of your post, but the phrase
> "choosing one of these options also brings you the bonus that you'll get
> security updates more quickly as testing is the last place for security
> updates to appear" seems quite opposite of the statement from the
> packages web page "'unstable' is also not supported by the security
> team".
No, it's not really the *opposite* of saying that. The security team is
responsible for making sure that software changes that were necessitated
by discovered security vulnerabilities get backported to stable (and some
older versions as well). The security team doesn't support unstable; but
they don't really need to, because the versions in unstable are coming
straight from the upstream developers and Debian package maintainers.
In other words, people continually working on updating the packages in
unstable, and that provides a route for security updates to get in. But
in general, nobody is working on updating the packages in stable anymore
-- it's released -- so there's a need for an entity like the security team
to make sure that security updates get into the stable packages.
So if you're running unstable, you usually get security updates fairly
promptly, because the upstream developers and/or Debian package maintainers
typically get the security updates in promptly. If you're running stable,
then the security team is working to update packages in stable. But if
you're running testing, you're entirely dependent on how quickly the updated
package in unstable can make it into testing, which may not be so fast.
> The packages page does say that testing does not get timely
> security updates, it does not say it is the last place for security
> updates after unstable and unofficial packages. You may be speaking from
> experiance, implying that the unofficial packages found through
> apt-get.org or the unstable packages are more likely to have security
> patches applied than testing because developers would be activly
> updating these packages whereas packages in testing have to pass the
> automated processes criteria,
Exactly.
> but the conclusion is not directly stated
> or guarenteed anywhere. Perhaps the packages page on the debian web site
No, I don't know that it is stated anywhere; but it's an obvious
conclusion of the way in which testing is built. See
http://www.debian.org/devel/testing
It's an automated distribution: it can't have anything that didn't
filter down to it from unstable, so logically it gets changes (such
as security updates) more slowly than stable does.
> Perhaps the packages page on the debian web site
> should be re-worded to reflect your observations on the nature of
> testing.
Maybe. It was certainly a while that I'd been running testing (then,
woody) before I realized that the notion I'd had -- that testing was
some sort of intermediate place between stable and unstable, more
robust than unstable but more current (in terms of software) than
stable -- was wrong, or at least oversimplified.
[ snip ]
>
> Since we have already drifted OT a bit towards what testing is or should
> be, it seems to me that the state of gnome2 can be a learning experiance
> if we let it. It can help us determine what packages should be grouped
> together as gnome2 so that when it hits stable if a security update
> changes some core gnome2 components to the level that they no longer
> play well without upgrading other gnome2 tools, the depenancies can be
> fixed now (while in testing and unstable) so they are already in place
> (in the future stable) to not allow an update to one portion without
> updating all interrelated systems.
My understanding is that this is normally done, through the appropriate
setting of dependencies, and through the use of metapackages. Those
metapackages for GNOME2 aren't yet present in testing, because not all
the GNOME2 infrastructure has made it down yet. When it does, I'm
sure that stuff will appear. So I think that what you're suggesting
is the way that it already works.
> I am trying to understand the auto-build process that moves packages
> from unstable to testing.
http://www.debian.org/devel/testing
> It seems that if the packages were defined so
> that gnome2 desktop depended on nautilus2, gnome-control-center2 and
> gnome-terminal (this list is not complete), then people couldn't
> dist-upgrade to testing to try gnome2 out untill it was ready to go into
> testing.
Right, and that's a reason why a GNOME2 metapackage (like "gnome2-desktop")
hasn't yetappeared in testing -- because the components aren't all there
yet.
It's true that if one was running stable with GNOME1 and casually
dist-upgraded to testing at this point, one might get components
replaced, ending up with a partial GNOME2 install, and then run into
problems; but what that says is that it's not smart to casually
dist-upgrade to testing. It's not a problem with testing, or with
the (partial) gnome2 implementation in testing.
> If the rules for testing is that it's ok to stick the engine in
> without a carburetor or exhaust system because they will go in sometime
> down the line before it is sold to people, then I guess these
> dependancies don't matter in testing, and maybe testing should have a
> disclaimer "It's probably broken, but we don't want to hear about it
> because it wasn't for sale yet anyway."
Well, you'd have to craft such a disclaimer very carefully, because
some problems the developers *do* want to hear about -- namely, problems
which are actual bugs with individual software packages, or components
which *are* expected to integrate well with other components but aren't,
or whatever. Telling whether something is a bug, or is just a
consequence of running testing, could conceivably be a challenge
sometimes; but that's one of the hassles that comes with running testing.
> When I try to learn about gnome2, it is presented by gnome.org as "Gnome
> Desktop 2.0" http://www.gnome.org/learn/users-guide/2.0/. It talks about
> window managers, nautilus file manager, and the panel as one system, not
> as several seperate systems you might want to use individually.
Sure; and that's (hopefully!) the experience that one will have in sarge
when it's released. While it's still being assembled, though, all bets
are off.
> I
> wouldn't expect to find apache2 executable and apache1.3 modules in
> testing with apache2 giving me errors because it can't link to the 1.3
> modules, unless I also had apache1.3 executable and the two packages
> co-existed and functioned independantly of eachother. While gnome and
> gnome2 seem to co-exist to some degree, I do get errors when using the
> system because all the components are not gnome2.
Yeah, and to a certain extent, an effort is made to minimize this stuff
by the setting of appropriate dependencies. But strictly speaking, while
a decent GNOME2 desktop might depend on both gnome-control-center and
gnome-panel, the two *don't* depend on each other. Stuff like this is
going to happen sometimes in testing. That's life in testing. Right
now, if you upgrade your perl installation to the perl that's currently
in testing, you'll lose apt-file, because a version of libapt-pkg-perl
that works well with the new version of perl isn't down in testing
yet, and apt-file depends on that. So on my testing box, I've been
sitting on the old version of perl for a couple of months, and
dist-upgrade has not been an option. That's a mild annoyance; but that's
life running testing.
> Back to my interest in helping out. I don't have any intention to be a
> whiner or burden on people such as yourself who are graciously investing
> time and effort into bringing software such as gnome2 into the Debian
> system.
Oh, I'm not a developer, just a user.
[ snip ]
> I would like to help by
> noticing bugs that others may not be aware of yet, so that things can
> get fixed and we have a good solid Sarge release to stable.
Yay, that's good. And you *can* do that by running testing; it just takes
a bit of extra work to determine whether the problem you've encountered
really is a bug, or rather is just a consequence of some transient state
that testing is passing through.
> When I ask a
> quesiton to a few different communication forums and no-one seems to
> know what I'm talking about (or they do and don't want to comment) then
> it seems I've found a bug others may not be aware of. Sometimes the
> solution to a bug is just to post a 'known bugs' statement somewhere
> with some tips on working around it, and I would be happy to try and
> help out that way.
If you've found a bug, then by all means, post a bug report to the
BTS. The developers want good bug reports. And to me, posting bug
reports is part of the deal: I get free software, and in return I
contribute in one of the few ways I can, which is by pointing out
where things have gone wrong. But there's no harm in asking people,
here or elsewhere, "is this a bug?" before posting the bug; and it
helps to avoid spurious bug reports.
> After reading your comments in this post, I am re-evaluating my actions
> and asking for feedback from the debian-users list community. Should
> people be looking for bugs in testing, or in unstable because testing
> isn't suppose to work anyway untill the pre-release freeze?
Yes, people should be looking for bugs in testing, and *definitely* in
unstable. But sometimes there's a bit of work required to make sure
that what's not working properly is not working properly because of a
bug.
> I chose testing for two main reasons. The debian packages web page
> states of unstable "Packages in unstable are the least tested and may
> contain problems severe enough to affect the stability of your system."
> I don't want to deal with an unstable system. Although I am interested
> in helping out, I would like to notice the bugs as part of normal usage
> and not as part of a daily debugging unstable ritual.
Unstable really isn't that bad, in general. Stuff that's *that badly*
messed up isn't generally made available by the upstream developers in
the first place. But sometimes there are exceptions.
> The page states of testing "This area contains packages that
> are intended to become part of the next stable distribution." I am
> interested in what packages are part of the next stable release. This is
> what I will be showing friends and family when I talk about Debian and
> GNU/Linux with them. These packages are what I want them to use when the
> next stable release is made. I do not want to have them asking me "How
> come after the security update you did, nothing 'works right.'"
And while that should never, ever happen with stable, it *is* possible
with testing. If that's something that you just absolutely cannot
tolerate, then perhaps running testing isn't the best option for you.
-c
--
Chris Metzler cmetzler@speakeasy.snip-me.net
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
Reply to: