[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The nature of testing and where can others help (Was Re: HowTo for Gnome2??)



Chris,

I am interested in learning Debian and contributing to the community. I feel I am somewhat GNU/Linux savy, though I am a neophyte when it comes to Debian. Perhaps my newness can bring out some confusion that people who are more established in the system such as yourself may not notice. I'm sure my newbie questions and attempts to help will be misdirected from time to time. My experiances of the last three months, and more especially the last two weeks, seem to coorispond with your explination of stable, testing, and unstable.

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". 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, but the conclusion is not directly stated or guarenteed anywhere. Perhaps the packages page on the debian web site should be re-worded to reflect your observations on the nature of testing.

The thread seems to be quickly drifing off topic of the origional question of:

Is there any documentation on how, using testing, to get the most
complete (applets, to, please!) Gnome2 installation possible?

The answer seems to be no, there is not one that anyone who has commented so far is aware of, and additionally it would probably be a wasted effort to write one because the state of testing is not fixed. The efforts would probably be best witten as a just a quick guide on someone's website and is possibly already done by someone who's backported Gnome2 to stable.

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.

I am trying to understand the auto-build process that moves packages from unstable to 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. 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."

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. 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.

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. I understand that we don't anticipate everything and mistakes happen. I loved the statement from Michael H. "'Oops.' GNOME in testing seems to be in very poor shape right now." It was a simple statement free of any scalding words or finger pointing, yet acknowleding that yes, that isn't how he would expect it to work. 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. 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.

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?

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. Maybe someday I'll have the knowlege of all debian configurations and policies to move to that level. 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.'"

Chris Metzler wrote:

In general, up until the pre-release package freeze on testing, it's a
bad idea to think of testing as an intact version of Debian.  I tend to
think of testing as kind of like a big cardboard box in which the
different elements of the upcoming release are being placed, continually
being replaced by new versions as they become available (according to
the rules for stuff moving from unstable to testing).  At any given
point, up until the time of release, it's possible for stuff that will
need to be in that box at release-time to not be there yet; and it's
possible for some of the stuff in that box to not get along well with
other stuff in that box.  In general, people try to avoid stuff going
into testing that will cause problems for people who track it closely;
but it still happens sometimes.

A number of GNOME2 packages apparently haven't made it down into
testing yet.  Thus, any GNOME2 installation drawn from testing is bound
to be incomplete, and have problems.  That's the nature of testing;
stuff like that happens.  And when people tracking testing experience
problems with GNOME2 at this point, that's not a problem with GNOME2 or
testing; the problem is with the expectation that GNOME2 in sarge should
necessarily work.  Put another way, it's no more a problem with testing
than the fact that a car halfway down an assembly line doesn't work is
a problem with the car; instead, the problem is with the expectation
that a car at that stage of assembly *should* work.

So what to do?  If all you really want is GNOME2, then your best option
is running woody + a backport of GNOME2 to woody (see www.apt-get.org).
If you need official packages, then your best bet is to bite the bullet
and run sid.  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 (since testing won't see security
updates to packages until the updated versions are put into sid and work
through the process of packages moving from sid to testing).

-c






Reply to: