[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can
From:       someone <someone100 () gmx ! de>
Date:       2006-07-30 16:44:32
Message-ID: 44CCE1F0.6060400 () gmx ! de
[Download RAW message or body]

Enrico Weigelt wrote:
<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.

This my first mail to this list.

Short intro: I was introduced to gentoo by some colleagues roughly 2
years ago. *ALL* of them switched to Ubuntu, because the were annoyed by
the package policy of gentoo with respect to server environments. I am
still into gentoo and this upcoming criticism since Ubuntu motivates me
to support gentoo more actively. Altough I did not finished any ebuild
at this moment, I hope to help with my 'fresh' user view:

I agree on the need to work on the unstable packages (my keyword list is
large and I did not know that it is a bug to say please make it stable)

To differentiate quite stable and proven is a good starting point.

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

The name overlay makes more sense, because a subtree is a sub-directory
in case of a filesystem. The overlay is not a new subdirectory in
portage, it exists of one or more directories outside portage which
'cover' one or more subdirectories of portage.

But I don't know if the overlay is a solution to handle the discussed
problem.


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

Good idea, would be nice for me to find in an *efficient* way starting
points for my helping hand.


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

Overlays may be good for people like me who want to begin developing
gentoo. But it can't help overall.

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

What I understood from sunrise: They try to lower the barrier to get
involved in ebuild development. BTW: Is there anybody who can tell me,
if sunrise is now accepted by the gentoo community, and if not, what is
the criticism? Should I go for sunrise?

But also here I don't thing that sunrise should be a good practice for
the gentoo user to overcome the aging unstable package problem.

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

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


Yeah, that's why I want to raise my voice! Great idea! That would be a
community solution. Since the Ubuntu hype and criticism about unstable
gentoo I was thinking in this direction. May the things and ideas said
above are old (take them as a user vote then), I want try to make it
more explicit and put my own view on it:

1. IMHO the problem is not aging ebuilds at all. It is about information
content in portage and user feedback. More concrete: the problem is that
there is not enough information about ebuilds. What we see on the
surface (either on http://packages.gentoo.org or via emerge) is whether
an ebuild is stable, unstable (keyword masked), hardmasked or not
present at all. Not more. But what is needed is WHY,since WHEN and some
other information:

stable: OK, here everything is fine. The situation everbody likes ;)

unstable: Why? Are there reason in the software package itself that
makes the integration via an ebuild into gentoo non-trivial? Is the
former maintainer Ubuntu addicted, know? Doesn't he find the time? Does
he think, this ebuild is not important, because only two users are using
it?

hardmasked: Why? The same above, or severe security problems that arose?
Since when?

2. To answer these questions, a feedback statistic would help a lot: a
tool like 'emerge-feedback category/package-version' collecting the data
in a single database could do it.

scenario a)  user just says 'emerge-feedback installation-succesfull
category/package-version' and agrees that data like USEFLAGS, CFLAGS etc
 are also submitted. This enables the developers to see how important an
ebuild in the community is and which package works best under which
environment.

scenario b) an emerge was not successful as an immediate reaction the
user says 'emerge-feedback install-failed'. This tool could then collect
all information necessary for a good bug report to bugzilla. If bug
reports could be unified in this way, developer could also get to know
how many user experience this problem under which circumstances. The
difference here: If a bug occurs and a user is willing to submit it. He
checks for an existing bug report. And if it already exist, he normally
does not give any further feedback.

scenario c) A user checks a package like postgis at packages.gentoo.org,
he sees, 5 versions exist but only the oldest ver. 0.75 is marked
stable, and the other 4 up to ver 1.1.2 are not. If he sees next to each
version since when it is in the state and in addition to e.g.  version
1.1.2 that a number of X user already installed it succesfully since
then and Y user report problems he might be more encouraged to test and
report it.


Of course, all this information could be gathered from forums reading,
bugzilla, ChangeLogs etc., but I am enthusiastic about this idea raised
in this thread is: transparency, efficiency of the information and
community feedback.

I would also like to emphasize that it is important to also see why and
since when a package is deleted. Not to say that I am often annoyed by
package deletions, because they often force unwanted upgrades of
depending packages. Also here to have the information, if a package was
deleted because the programmer stopped the support like MySQL will do
for the 3.x and 4.x in the next month. Or if the ebuild maintainer did
not see the use anymore...

I also dream of package branches that are marked as long time
maintained, e.g. apache 1.3 should have a long life in portage.

Ciao,

someone
-- 
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]