Re: The nature of testing and where can others help (Was Re: HowTo for Gnome2??)
On Fri, 2003-07-04 at 16:06, Jacob Anawalt wrote:
> 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.
This is just the impression I get as a bystander, but I'm sure 101 list
regulars will tear it apart if I'm too inaccurate ..
The release process goes something like
upstream
| into unstable as soon as the maintainers can
unstable
| into testing after 10 days with no outstanding bugs, conflicts, etc
testing
| becomes stable after a considerable freeze + bug hunt
stable
The task of the security team is to backport critical fixes from
upstream (and possibly some of their devising - I'm not sure, but I
don't want to underestimate the job they do), into Stable's packages.
So the way I see it, Unstable, and to an extent, Testing, don't have the
same dire need of the security team, as fixes from upstream arrive there
as part of the normal release process. They don't arrive into Stable
without the security team's intervention.
> 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."
Another "as a bystander" observation, this is the "into testing after 10
days with no outstanding bugs, conflicts, etc" mentioned above. A
package won't (/shouldn't?) get into Testing until all it's dependencies
are available in Testing (else it wouldn't be installable).
> 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
Yes 'Gnome Desktop' is designed to be more than the sum of it's parts -
just a Debian GNU/Linux is more than just the programs it contains.
> 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.
I'm not sure these are particularly comparable. I can use Gnome1 apps
within Gnome2 - I can't use apache 1.x modules within apache 2.
> 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?
The theory is that when Testing works properly, it gets released. So
logic dictates that if it hasn't been released, then atleast some of it
doesn't work.
I believe good bug reports are always valuable, but I'm not sure if
there's much priority between Testing and Unstable. I'd _guess_ it's
more valuable in Unstable until Testing freezes, to aid smooth
transitions into Testing. Once Testing is frozen, it'd be the prefered
target for bug-hunting, to aid a quality release.
> 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.'"
I updated from Potato (2.2 - oldstable) to Woody (3.0 - stable) several
times, very smoothly. This is the end product of such a rigorous release
process. Unstable is the raw input - Testing has passed a few sanity
checks to make sure it doesn't tear itself apart too bad - then the
freeze gives them a chance to beat these raw materials into a great
distribution and a smooth upgrade path. So Testing pre-freeze is still
a melting pot, _not_ what you'll expect to see when it's released.
As far as running Gnome 2.x on Debian goes right now, I see 4 options
Gnome2.x on Stable
I installed a Woody system on Friday, and added:
deb
http://ftp.acc.umu.se/mirror/mirrors.evilgeniuses.org.uk/debian/backports/woody gnome2.2/
to my sources.list (mine the line wrap). That site now provides very
workable backports of Gnome 2.2 and Xfree86 4.2.x (I believe X4.2 is
required by Gnome2). The downside is that most your system is still
running Stable, so I ended up trying to backport evolution 1.4 myself.
Gnome2.x on Testing
As you've already discovered, isn't in great shape right now. I guess
"wait it out, the packages are coming" counts as an option tho.
Gnome2.x on Unstable
YMMV - "Works For Me" at this very moment, but that doesn't mean it'll
stay that way. I don't recall having any problem that required more than
a downgrade of the offending package tho, but that's no assurance it'll
still work tomorrow.
Gnome2.x build-scripts
a very "un-debian" solution is one of several build-scripts to compile
gnome into a system-independant location (ie, /opt, or $HOME).
Pros? This gives you exactly what you compiled, and a chance to tarball
it before you build the next release .. and in theory, shouldn't be
affected too much by changes to the rest of the system
Cons .. very time consuming, unsupported, and doesn't aid Debian's
bug-hunting.
- jhbuild (in gnome CVS) builds from CVS branches
- Garnome ( www.gnome.org/~jdub/garnome )builds releases from tarballs
(currently 2.3.x))
Regards,
Shaun.
Reply to: