Re: [gentoo-dev] Three teir portage: stable, prestable, unstable?

[foser]

On Tue, 2003-10-07 at 11:46, Paul de Vrieze wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 07 October 2003 00:08, foser wrote:
> > On Tue, 2003-10-07 at 00:08, Ian Leitch wrote:
> > > As I'm sure all devs know, ~arch is used for other things than just
> > > testing ebuilds.
> > >
> > > "The purpose of ~arch is for testing new packages added to Portage. This
> > > is not the equivalent of "testing" of "unstable" in other
> > > distributions." - Development Policy
> >
> > Well then that is a violation of policy. Developers who do this should
> > 'change their ways'.
>
> Or change the policy

Yeah, change the policy whenever it fits and nobody follows it, you can
drop policies altogether if you start reasoning like that.
 
> > I think package.mask is indeed not the best solution for development
> > versions of packages, but neither do i think we should have an official
> > 'unstable branch'. We have trouble enough to keep 'stable' stable and
> > up-to-date as it is, no need to add another official burden to it.
> >
>
> I like the idea of adding this keyword. There are packages whose ebuilds are
> stable, and are reasonably stable, but still release candidates etc.
> Currently the status of such packages is unclear. Sometimes they are put into
> stable, sometimes they stay masked, and sometimes they are marked testing
> (which they should start out with, as then they are new).

No their status is quite clear according to policy. That practice proves
otherwise in some cases is in my opinion a developers mistake.

> Take for example the openoffice-1.1_rc? series. Those from rc3 onwards have
> been almost equal to the final release (what source is concerned, the build
> procedure was fixed). Current policy required them to be masked as they are
> unstable releases, while in fact being quite stable. We had various requests
> to remove them from the package.mask file. That, however, would be a
> violation of policy. An extra keyword could help in that respect.

No, the policy states that in the end it is up to the maintainer to
assess the stability of a package, in case of openoffice which is well
maintained in portage -afaik- i can see a developer deciding to mark it
stable, but this shouldn't become common use. In general packages are
maintained on a more distant basis, where the developer is not too
involved with the package and can't judge it properly, so leaving the
decision to the upstream developers (who to judge better?). Here policy
should be strictly followed. No need for an extra keyword, yet another
USE flag, etc. : just don't add it.

> > The only reason i see for adding an extra layer is for 'big' stuff that
> > needs serious testing : KDE/GNOME development series maybe, arch
> > additions to the tree (amd64 anyone), introduction of new eclasses, etc.
> > Those should be entered to the tree in some special protected
> > environment first, where they get proper testing (maybe by a selected
> > few) and then when reaching stability can be added to the tree with
> > relative ease (not one developer throwing in his local tree one night at
> > once).
> I think that is another discussion although I agree with it.

I don't think so, i think that is exactly what this is about. My point
is really that development releases shouldn't be in portage, but that we
do need a way to test them to some extent to adapt to upcoming stable
releases. As soon as we add them to portage they become a
responsibility. Something we can't have, since the package just isn't
officially stable. I see this in a bit broader perspective here than
just development releases.

Like people asking why the development releases of GNOME enter the tree
so late in the development process. Well, it might be fairly stable and
usable to the general home user, but there are still known bugs and
things to work out. I just can't guarantee a safe,problem free upgrade
for say a small company running GNOME desktops who rely on stability.

You can see the same already with package.mask, which was meant as a way
to mask packages not working/being worked on. Yet users install these
packages at will as if they were normal packages (only slightly annoyed
by the fact that it takes some extra effort). Yes we need the testing,
but no, users shouldn't install those without knowing what they do
(which in my opinion is what happens most of the time). Makes me think
of the libiconv bugs we get every now and then, it shouldn't be used,
but users install it anyway and are left with the pieces. I don't think
most of the users ever read the p.mask comments why something is masked.

- foser


--
gentoo-dev@g.o mailing list