[gentoo-dev] Re: Please do not stabilize packages for arches you cannot test for

[gentoo-dev] Re: Please do not stabilize packages for arches you cannot test for

[Tom Payne]

A pertinent discussion. I inadvertently broke the sparc tree by marking what
I thought was a architecture-independent script (net-www/raggle) as being
stable. The problem was that one of it's dependencies (dev-lang/ruby-1.8.0)
was still unstable on sparc. I thought repoman would find problems like this
but the version I have doesn't. Oops. Damage now undone and lesson learned.

But it seems to me that there is a simple fix that would easy the burden on
arch teams to test every single package for their arch. I advocate this only
for ebuilds unlikely to cause problems, e.g. scripts and documentation.


I propose:

An ebuild that is unlikely to cause problems can be MARKED stable on
relevant arches, even if the dev is unable to actually test it.

An ebuild is only CONSIDERED stable on an arch if it, and all its
dependencies, are marked stable on that arch.


Problems solved:

Arch leads no longer have to test every single ebuild that comes there way
-- non x86 arches get package updates quicker with reduced workload for arch
leads.

No need to write unit tests for packages to help arch leads (lots of work
and hard to do in some cases (e.g. interactive progs)).

Marking packages stable can no longer break dependencies.


New problems:

Might result in broken software being installed.


Feedback please. I advocate this approach for 'minor' packages, i.e. nothing
fundamental to the working of the system. It's more suitable for scripting
language libraries and minor applications (e.g. obscure window managers).

Regards,

Tom

P.S. I'm off skiing for a couple of weeks and so will only be able to lurk
on this discussion via gmane.org.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Please do not stabilize packages for arches you cannot test for

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1361 bytes --]

On Monday 29 December 2003 05:00, Tom Payne wrote:
> I propose:
>
> An ebuild that is unlikely to cause problems can be MARKED stable on
> relevant arches, even if the dev is unable to actually test it.
>
> An ebuild is only CONSIDERED stable on an arch if it, and all its
> dependencies, are marked stable on that arch.
>
> New problems:
>
> Might result in broken software being installed.
>

As you might know we are trying to improve the quality of the tree. A policy 
like this one is not beneficiarry to that. Further I have the strong feeling 
that this is the kind of policy that will get blurry boundaries. In other 
words I think it will not work.

> Feedback please. I advocate this approach for 'minor' packages, i.e.
> nothing fundamental to the working of the system. It's more suitable for
> scripting language libraries and minor applications (e.g. obscure window
> managers).

A more appropriate option would be to allow users to test packages that have 
not been marked as broken on their arg and then have a policy that if at 
least two users have reported a package as stable, and an arch dev can 
compile it it will be marked testing, and stable if it has no problems within 
a reasonable time period.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Please do not stabilize packages for arches you cannot test for

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Mon, 29 Dec 2003 15:23:33 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > Feedback please. I advocate this approach for 'minor' packages, i.e.
| > nothing fundamental to the working of the system. It's more suitable
| > for scripting language libraries and minor applications (e.g.
| > obscure window managers).
| 
| A more appropriate option would be to allow users to test packages
| that have not been marked as broken on their arg and then have a
| policy that if at least two users have reported a package as stable,
| and an arch dev can compile it it will be marked testing, and stable
| if it has no problems within a reasonable time period.

This is basically how we do things for sparc already. For non-core
packages with sane dependencies, if it is reported as working by a user
(bugzilla or over irc) and it compiles then we'll usually keyword it up
pretty quickly. This is how we handle a lot of the more obscure
packages. "It works" reports are always welcomed :)

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Please do not stabilize packages for arches you cannot test for

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

On Mon, 29 Dec 2003 04:00:40 +0000
Tom Payne <twp@gentoo.org> wrote:

> Problems solved:
> 
> Arch leads no longer have to test every single ebuild that comes there
> way-- non x86 arches get package updates quicker with reduced workload
> for arch leads.

If we can do this without a loss of the Q in QA, then I'm all for it :)

One alternative that is becoming available to developers are the
development/release engineering boxes that are cropping up.

For a lot of programs out there, it's not hard to test their functionality
remotely (though GUI applications can be a bit harder).  I imagine having
one or two people per herd with accounts on these various boxes would help
improve QA substantially.

Granted at the current time, not all arches have a publically
available test machine or two, but it definitely decreases the
amount of work on the arch devs and the "no news is good news"
stablization of ebuilds that happens now.
 
> No need to write unit tests for packages to help arch leads (lots of
> work and hard to do in some cases (e.g. interactive progs)).

Test cases don't necessarily need to be automated.  A simple list of
instructions to verify functionality that a dev could run wound be
acceptable (to me).  

For example

1) Do operation a
2) Do operation b
3) Expect result c

> New problems:
>
> Might result in broken software being installed.

I'd like to avoid this if at all possible.  All software in the tree,
even if it's marked ~arch, is supposed to work.  The fact that ~arch
things are broken is bad, but if a package gets to arch broken or still
broken is even worse, and reflects poorly on Gentoo as a whole.

> Feedback please. I advocate this approach for 'minor' packages, i.e.
> nothing fundamental to the working of the system. It's more suitable for
> scripting language libraries and minor applications (e.g. obscure window
> managers).

While most of the time, packages aren't problematic on non-x86 arches,
there do crop up those that have abnormal behavior.  Whether it's unable
to compile or has undesired/broken functionality once compiled/installed. 

I'm a bit more open to packages that are scripts, but I have yet to meet a
language that is truly as cross-platform compatible as they all claim to
be (not that I'm any kind of official reviewer or have run into every
language out there).

However, if something like this is implemented, I would ask that programs
that need to be compiled not be put into this list.  If a problem is going
to crop up, it'll be here, and often times Makefiles don't fail correctly
if something cannot build (for instance try over-optimizing
net-firewall/fwbuilder and then find the fwbuilder executable after it has
installed).


My (non-refundable) $0.02,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]