Hi Peter,

Peter wrote:
Sometimes I really hate this portage developers pressure not to mark
ebuilds as stable for a long time. Does developers look at packages
ChangeLog's?

Ok, I'm sure you mean (most of) Gentoo developers, not portage devs. The portage devs aren't responsible for that.
Sometimes we have a look at changelogs, sometimes not. I am really not interested in app-foo/bar.

I can understand that when the package is rather new it needs more
testing. But there some examples when I'm sure this ~x86 flag is

Sure, that's why we put it into ~arch first. ~arch actually means testing.

unnecessary. More it even leave buggy applications as stable for gentoo
while fixed applications are marked ~.

These are two absolutely different problems. The main reason for leaving a package in ~arch is that it has not been tested enough (at least 30 days for every new version) or that it's known to not work completely.

One example is stardict. Now it's not in a very fast developing. Look at
ChangeLog. There are ONLY cosmetical Changes (e.g. new translation added)
and one bug (possible loop) avoided. So if we have 2.4.3 stable Why not to
put 2.4.4 into stable???

Look at the ChangeLog: It was bumped on 13 Jan 2005, today is 19 Jan 2005, so it was only 6 days in portage.

Short answer: Policy says a package has to be 30 days in ~ before becoming stable, excluding security fixes.

Long answer: arch (e.g. x86) was made for people that want to have a stable, secure system. To ensure a package/version works fine, it has to be tested, not just on a single box. That's why there is a ~arch/~x86 flag. It's for people that want to help Gentoo finding bugs and have an even more recent system. Again, to ensure that a piece of software works fine, we have to test it on multiple machines, which takes about 30 days on average.

Another example is glade. The stable version in portage is very old, about
two years old. So it's necessary to move version up. There was a big
changes in glade with the 2.6.x release. There were some problems. But now
most of bugs are fixed. So one day 2.6.x version come into stable. And
again. Does developers forced to mark 2.6.7 as stable when 2.6.8 is only
bugfix release. Why not to mark 2.6.8 as a stable?

Same thing, to ensure it's stable. A little story: We had a very small patch to fix a security hole in samba. We tested it and thought it was working. Then, someone pointed out that samba crashes with the new patch when you try to use a cups printer. Notice that it was a security fix and only a small, 'cosmetical' change.

To avoid statments like: Do it yourself. I want to ask: How can I help?

1. Do it yourself. If you run a stable box and aren't patient, you can use package.keywords (see man portage).
2. Test it, report that it works on bugs.g.o.
3. Become a dev and do it yourself.

*SCNR*

ebuild is working and also report about this. But, my hands down, when I
can see no reaction for a very long time... So this questions, this
statements.

We have a huge amount of bugs/mails we have to care about, some are more important than others. If you can't see any reaction and feel lonely, bug us again. Ask why nothing happens (in the specific bug).

Greetings,

blubb

Attachment: signature.asc
Description: OpenPGP digital signature



Reply via email to