Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?

[Enrico Weigelt]

* Chris Gianelloni <wolf31o2@g.o> schrieb:

<snip>

> > 1) thousands of packages will never be marked stable
>
> Honestly, they shouldn't be stable.

hmm, maybe we should have different groups of ports (*1) for 

a) quite stable:  no bugs yet and enough votes)
b) *proven* to be stable: has passed the whole bunch of qm tests.

The quite stable category could be used for "normal" packages which 
are used in production but are not very critical. Maybe games and 
seldomly used stuff can be taken from here.

Critical things (ie. base system, toolchain, critical apps) should 
only be taken from the proven/mature category. Maybe we could maintain
several profiles which does the common masking.

I'm not quite familar w/ overlays yet, but it seems wise to me 
to maintain overlays for several groups of b) ports. Individual
overlays may have their own policies. For example one for critical
server systems would require absolutely reliable, automatic remote
updates, security fixes fast in but enhancements lazy, binary
compatibility, etc.

> In fact, likely, many shouldn't be in the tree.  We have way too many
> packages that are used solely by a small group of people sitting around
> the tree. These would be better served in official overlays, where
> they can be maintained by the interested parties (including users),
> rather than in the tree.

Those overlays seem good, if they represent an entire subtree 
(aka distinct from the main tree). For example there could be an 
KDE/Qt overlay, which contains the whole KDE stuff. People not 
interested in any of KDE (like me) don't need it. This would make
syncing less resource intensive.

But: please let's call them *Subtrees*.

> > 2) Everyone running stable who wants some recent packages ends up with
> > /etc/portage/package.keywords with hundreds of entries
>
> People don't seem to understand that you cannot have your cake and eat
> it, too.  I have no sympathy for these people.
>
> If you want *stable* then you're going to have to wait until the package
> has passed QA and the bugs have been resolved.  If you want *new* then
> you simply have to deal with the bugs.

Well, as I said, there're different views of "stable".
One means "it is working", others mean "it has to be absolutely robust".
Therefore we should differenciate between "stable" and "mature".

For example bugzilla-2.22 (which is still masked ~x86 :():

I needed 2.22 for postgresql. This requires 2.22, which is ~x86, 
so I had to add it to package.keywords. It also requires DBD::Pg,
also masked ~x86, also added to package.keywords. 
Fine so far, as long as I don't have to do it on many packages.


Maybe we could handle the two cases installing vs. updating different.

Again my bugzilla example: I installed bugzilla-2.22 and DBD::Pg, 
(both still masked ~x86). At this point I tried something new. 
Bugzilla + DBD::Pg work for me now, evrything's fine. 

Now it comes to an update. We've got a new Bugzilla version, which 
is considered at the same stability level as my current 2.22. 
I don't see any need for update, since I'm happy w/ current one. 
So emerge should leave it untouched. Some day we'll have an new
version approved to be more stable than current or fixes some bugs.
Now emerge should upgrade, but only to the point where it gets
more stable.

BTW: sometimes it will be good to maintain different branches, 
ie. there could come an quality enhanced 2.22.1 parallel to an
not yet proven 2.23 from upstream. While 2.23 will bring new 
features, but is not yet properly tested, the 2.22.1 will only 
have - very carefully checked - bugfixes. This case should also
be coped here.

<snip>

> People seem to think that there's some magical solution to this.  There
> is no solution other than more people actually *solving* the problems
> that keep packages from making it to stable.  The packages that are
> complained about the most are invariably large sets of packages, like
> GNOME or KDE, that have hundreds of dependencies and take quite some
> time to get into a condition that can be considered "stable" at all.
>
> If you want things to make it to stable faster, then start supplying
> patches.

ACK, of course.
Maybe we need some system to get users and latent contributors more
informed about things to do. I imagine something which directly 
utilizes portage db (installed packages) to query for information.

Ie: 

box:/ # equery-2do world
[www-apps/bugilla-2.22 ~x86] (installed: 2.22 +postgres ...)
   * solve bug 12345
   * test seamless upgrading from 2.20.2
...
[knollo/test-1.23 ~x86] (installed 1.20)
   * solve bug 1222
   * try out new +postgres
...

<snip> 

> > 4) The user experience sucks  - see the forums/wiki... "to install
> > this great sw you need the latest version of x, which depends on y,z,
> > so copy paste this huge block in to /etc/portage/package.keywords."...
> > then 2 weeks later some depend changes, and suddenly emerge -u world
> > no longer works, and user has more problems to solve.
>
> Honestly, the number of people out there giving shit advice is part of
> the problem.  Rather than telling people to do this sort of thing, a
> better solution would be to tell people how they can *help* instead of
> how they can bypass the system, which ends up with clueless users filing
> more bugs, which delays the stabilization longer.

ACK. It's quite the same problem as many many packages (upstream) in 
the OSS world have - they try to work around bugs in imported packages,
sometimes even ship their own branch of them (ie. apache -> expat)
instead of simply fixing the problem on the source. And this then
ends up in thinkgs like the whole autotools hell.
That's why I started my OSS-QM project, I had announced some weeks ago.

<snip>
> Every user that someone knowledgeable gets to use something they don't
> understand, is a potential bug report slowing stabilization even more.

At least these bug reports should contain the user's keywording info.
Ie. if the bug applies to an masked version, there should be an tag,
so the devs can easily filter on that. Maybe one's only fixing bugs 
in unmasked packages and keeps things stable, another one then works
on stabelizing an still masked package.

BTW: is there any console tool for reporting bugs w/ all necessary
information quickly ?

Ie. if I found an bug in my current bugzilla, I simply wan to call
it with the package name - the tool gathers all necessary information
(ie. looks for the installed version, including masks, useflags, etc)
and asks a few questions.

> > The testing is supposed to be for the ebuild, not the package itself,
> > so there's not much point in holding back packages with simple ebuilds
> > from being stabilised. And the testing process isn't that extensive
> > anyway - all it ensures is that the package builds and can be run on
> > one particular arch testers system. No disrespect to the testers, but
> > they can't be experts in every particular piece of software. How much
> > code coverage does a typical ebuild really get when being tested?
>
> First off, we have a level of expectation of stability to maintain.  If
> all packages were done "right" then 90% of the ~arch packages in the
> tree would be under package.mask, rather than ~arch.  Only packages in
> ~arch would be ones with no bugs open, to test the ebuild, so that they
> can become stable.  As we all know, this isn't the case.  Developers all
> over the place, including myself, have put in tons of packages that
> aren't necessarily perfectly stable themselves.  We do this because our
> users demand it.  We have reached a critical mass of users, where no
> matter what we do, somebody is going to bitch and piss and moan because
> we don't do things the way they would like.  There's nothing that we can
> do about this except decide collectively what the best course of action
> for our users would be and try to make things as high-quality as
> possible.

hmm, social pressure is a big problem here. The mass of people who
maybe are happy with semi-stable packages hurt those few who need 
critical stability. 

I tend to like the idea of mission-critical overlays more and more.

> Automatic stabilization is one of those things that would cause our
> quality to go to hell.  Another thing is this.  If you don't like it,
> fork.  You've got the code.  You're *more than welcome* to go around
> making your own overlay/tree and marking whatever rubbish you feel like
> as stable.  There's *nobody* stopping you from doing so.  However, many

I just read over the discussion very quickly, but isn't this exactly
what Sunrise should be for ?

<snip>

> Another problem is that we don't *know* what is being run by our users.

hmm, why not creating an database for this ?
Users are then encouraged to run an tool which regularily posts the
interesting parts of the emerge database (package+version+useflags+
keywords) and some system information (CFLAGS, hardware data, ...) 
into the database. Once we've reached an critical mass, we've got 
some usable statistic information. So we could also see, what should
not be kicked off the tree (ie. someone's still using old packages, etc).
We simply should tell people to use this tool if they like to get their 
systems supported.

<snip>
> out into overlays.  I wouldn't mind seeing the tree completely split
> into the "ricer" and "stable" camps.  Let's call them "Gentoo
> Enterprise" and "Gentoo X-Treme UberEdition" just to keep them
> separate...

So like other distros like debian do with there "testing" vs. 
"stable" branches ? 
hmm, would be easier to maintain, but mixing would be hard for users.

<snip>

> Seriously, folks.  If you think that packages should be available
> faster, run ~arch.  Test the packages.  Report successes/failures to the
> maintainers.  File stabilization bugs if your favorite package hasn't
> had another bug in 30 days and you've been using it.  Basically, help

maybe this could be done (partial) automatically:

+ an tool checks the emerge db for masked packages which are older
  than 30 days and asks the user if he likes to give comments and
  if he likes to see it stabelized.
  

BTW: is there an quick way for checking if some package in an specific 
version has some bugs ? Is there a fixed syntax for such bug reports
where we could let the machine filter on ?



cu

*1: port := package+version

-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@g.o mailing list