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

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

[Lisa Seelye]

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

On Mon, 2003-10-06 at 17:47, Ian Leitch wrote:
> Hi everyone,
> 
> I'm sure this HAS to have been discussed before, and if it has, it was
> before my time. I'd like to hear peoples opinions and what the
> conclusion was from earlier discussions. 
> 
> Just to make everything clear, I will outline exactly what I have in
> mind. 
> 
> In my view, the portage tree would benefit from having the following:

How?  Why does this warrant a radical change to the system?

-- 
Regards,
-Lisa
<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Stuart Herbert]

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

tberman was discussing this sort of change some time ago.  Might be helpful if 
he could let us know the status of this ;-)

Stu
--
On Monday 06 October 2003 10:47 pm, Ian Leitch wrote:
> Hi everyone,
>
> I'm sure this HAS to have been discussed before, and if it has, it was
> before my time. I'd like to hear peoples opinions and what the
> conclusion was from earlier discussions.
>
> Just to make everything clear, I will outline exactly what I have in
> mind.
>
> In my view, the portage tree would benefit from having the following:
>
> STABLE arch:
> Obvious realy, stable packages only. Considered a stable ebuild and
> stable software.
>
> PRESTABLE (perhaps called Testing?) ~arch:
> Only software considered stable but whos ebuild is considered unstable
> or just badly written. OpenOffice is a good example: 1.1 is a stable
> release but the ebuild contains warnings about the ebuild itself being
> alpha.
>
> UNSTABLE >arch (or some other symbol):
> Software stability takes precedence over ebuild stability here, eg a
> package whos ebuild was very small and perfectly writen but the software
> itself was considered unstable would be marked unstable and not
> prestable.
>
>
> Regards,
> Ian.
>
>
> --
> gentoo-dev@gentoo.org mailing list

-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Mike Frysinger]

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

On Monday 06 October 2003 17:47, Ian Leitch wrote:
> Hi everyone,
>
> I'm sure this HAS to have been discussed before, and if it has, it was
> before my time. I'd like to hear peoples opinions and what the
> conclusion was from earlier discussions.

http://bugs.gentoo.org/show_bug.cgi?id=30381
-mike

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

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

[Ian Leitch]

Hi everyone,

I'm sure this HAS to have been discussed before, and if it has, it was
before my time. I'd like to hear peoples opinions and what the
conclusion was from earlier discussions. 

Just to make everything clear, I will outline exactly what I have in
mind. 

In my view, the portage tree would benefit from having the following:

STABLE arch:
Obvious realy, stable packages only. Considered a stable ebuild and
stable software.  

PRESTABLE (perhaps called Testing?) ~arch:
Only software considered stable but whos ebuild is considered unstable
or just badly written. OpenOffice is a good example: 1.1 is a stable
release but the ebuild contains warnings about the ebuild itself being
alpha. 

UNSTABLE >arch (or some other symbol):
Software stability takes precedence over ebuild stability here, eg a
package whos ebuild was very small and perfectly writen but the software
itself was considered unstable would be marked unstable and not
prestable. 


Regards,
Ian.  


--
gentoo-dev@gentoo.org mailing list

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

[Sven Blumenstein]

> 
> STABLE arch:
> Obvious realy, stable packages only. Considered a stable ebuild and
> stable software. 

"arch"

> 
> PRESTABLE (perhaps called Testing?) ~arch:
> Only software considered stable but whos ebuild is considered unstable
> or just badly written. OpenOffice is a good example: 1.1 is a stable
> release but the ebuild contains warnings about the ebuild itself being
> alpha. 

"~arch"

> 
> UNSTABLE >arch (or some other symbol):
> Software stability takes precedence over ebuild stability here, eg a
> package whos ebuild was very small and perfectly writen but the software
> itself was considered unstable would be marked unstable and not
> prestable. 

-> package.mask


http://www.gentoo.org/doc/en/policy.xml explains this too:

"Package.mask is used to prevent merging of packages that are broken, 
break something else, or badly need testing before going into ~ARCH 
KEYWORDS in the tree."

"The purpose of ~arch is for testing new packages added to Portage."

"When a package version has proved stable for sufficient time and the 
Gentoo maintainer of the package is confident that the upgrade will not 
break a regular Gentoo user's machine, then it can be moved from ~ARCH 
to ARCH."


Just my $0.02 :-)


-- 
   .".
   /V\   [web ] http://0x1337.net                 | Behind every great
  // \\  [pgp ] http://0x1337.net/0x1337-pgp.txt  | computer sits a
/(   )\ [geek] http://0x1337.net/0x1337-geek.txt | skinny, little geek.
  ^'~'^



--
gentoo-dev@gentoo.org mailing list

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

[Ian Leitch]

On Mon, 2003-10-06 at 21:51, Lisa Seelye wrote:
> On Mon, 2003-10-06 at 17:47, Ian Leitch wrote:
> > Hi everyone,
> > 
> > I'm sure this HAS to have been discussed before, and if it has, it was
> > before my time. I'd like to hear peoples opinions and what the
> > conclusion was from earlier discussions. 
> > 
> > Just to make everything clear, I will outline exactly what I have in
> > mind. 
> > 
> > In my view, the portage tree would benefit from having the following:
> 
> How?  Why does this warrant a radical change to the system?

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

Making these changes would sort out this little problem/mess whatever
you want to call it. I also think the extra unstable branch would take
some weight off package.mask, which could then be reserved for the need
to mask a package for temporary licensing issues etc.. without removing
it from portage. 

Stable would also gradulay become more stable. We can't match Debian for
stability but we could have the best of both worlds: up-to-date,
reasonably stable software. This must be pretty attractive to those
using Gentoo on the server and more importantly, those thinking about
it. 

Regards,
Ian. 



--
gentoo-dev@gentoo.org mailing list

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

[foser]

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

> Making these changes would sort out this little problem/mess whatever
> you want to call it. I also think the extra unstable branch would take
> some weight off package.mask, which could then be reserved for the need
> to mask a package for temporary licensing issues etc.. without removing
> it from portage. 

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.

> Stable would also gradulay become more stable. We can't match Debian for
> stability but we could have the best of both worlds: up-to-date,
> reasonably stable software. This must be pretty attractive to those
> using Gentoo on the server and more importantly, those thinking about
> it. 

How would stable become more stable ? Stable should be stable as it is,
if it isn't because of development packages, then that is because
developers do not follow policy as it stands (or interpret it the wrong
way). That was put into place to ensure stability.

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

- foser


--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

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

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.
>
> How would stable become more stable ? Stable should be stable as it is,
> if it isn't because of development packages, then that is because
> developers do not follow policy as it stands (or interpret it the wrong
> way). That was put into place to ensure stability.
>
I think he means by not including development packages that come from upstream 
except in exception cases. I do think that even packages that would use the 
new keyword would need to follow the current stability policy. Another option 
could be just to add an extra keyword say "dev" that would be arch 
independent, but would signal the development package status of the upstream 
sources. This would need some portage changes as packages should then only be 
merged if this keyword is not specified unless the user makes changes to 
make.conf


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

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/gotcbKx5DBjWFdsRArtNAJ92M93RKGc/HRGEbZIv1SA/+q18MACdF3eF
5njnf+oL4m6x1TG/Qofo6Xs=
=vwUw
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

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@gentoo.org mailing list

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

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 07 October 2003 14:07, foser wrote:
> >
> > 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.

Certainly not. I don't want to do things lightly. But when a policy is 
violated massively it might be a sign that the policy is wrong. What I wanted 
to say is that I see some use in adding more clear support for developement 
packages. It would make things clear for devs and for users.

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

Unfortunately the mistakes happen. We need to look at reality besides from the 
policies. If we find policies get violated more than we want we need to do 
one of two things: 1) Device a way to make people follow the policy 2) Change 
the policy. In this case Ian proposed option 2. I have as yet not seen any 
suggestion for option 1, or statements that the amount of violations doesn't 
warant action. Further, personally, I think that the policy might be 
improved, and tried to use the openoffice example to support that.

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

Maybe someone should make an assesment how many packages it would concern. 
Given the restriction that those development keywords must not be an excuse 
to provide broken/unstable/alpha stuff. I would figure it would be used for 
prereleases/release candidates etc.

>
> 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.
>
As those releases are prereleases they have to be package masked currently. 
The suggestion is to have a keyword instead of this package.mask so that 
package.mask can be used for things that are actually dangerous to install, 
or just broken.


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

Maybe we should remove the package.unmask capabilities and such. Make it hard 
again to unmask packages. But indeed we might need to have a testing tree in 
cvs that is dev only. The problem could indeed be that package.mask currently 
is used for at least three distinct problems. Both for prereleases (etc.), 
for broken/dangerous packages, and for temporary locking of a package until 
it can be "opened" up (like the kde packages). As broken packages can be 
marked with the -x86 keyword they do not need to be in package.mask. I think 
the testing and openup packages can be done in a dev-only tree or set of 
trees making it easier to change packages as one does not need to worry about 
users getting fucked up installations (like with the original db-4 ebuilds 
that should never have been in the tree)

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/grnIbKx5DBjWFdsRAr8RAKC6CCGM+P7DvZwkgJiAoT6CiR4e0gCfd+Bq
SDwsagBiUZq5agV8X+PSFyk=
=VNAI
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

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

[foser]

On Tue, 2003-10-07 at 15:04, Paul de Vrieze wrote:
> > No their status is quite clear according to policy. That practice proves
> > otherwise in some cases is in my opinion a developers mistake.
> 
> Unfortunately the mistakes happen. We need to look at reality besides from the 
> policies. If we find policies get violated more than we want we need to do 
> one of two things: 1) Device a way to make people follow the policy 2) Change 
> the policy. In this case Ian proposed option 2. I have as yet not seen any 
> suggestion for option 1, or statements that the amount of violations doesn't 
> warant action. Further, personally, I think that the policy might be 
> improved, and tried to use the openoffice example to support that.

I think the the problem is uninformedness about the policy, does it even
get properly read by new devs ? They assume they can do it because they
see another dev do it and so it spreads, you don't solve these problems
by accommodating them. 

- foser


--
gentoo-dev@gentoo.org mailing list

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

[brett holcomb]

What's wrong with the alpha beta being part of ~arch?  If 
someone is working with alpha/beta stuff they know what 
they're looking for?  I really don't see a need to have a 
multi-tier mess to keep track of alpha/beta/gamma stuff. 
 If it's arch it is stable and works.  If it's ~arch it 
may be broken and break your system.  When the developer 
deems it's okay it moves to arch.


On Tue, 07 Oct 2003 19:49:56 +0100
  Ian Leitch <port001@gentoo.org> wrote:
>On Tue, 2003-10-07 at 15:30, foser wrote:
>> I think the the problem is uninformedness about the 
>>policy, does it even
>> get properly read by new devs ? They assume they can do 
>>it because they
>> see another dev do it and so it spreads, you don't solve 
>>these problems
>> by accommodating them. 
>
>OK, so say something was done and from now on all devs 
>only submited
>packages to ~arch that they deemed stable but whos ebuild 
>could do with
>some more testing. Where does that leave the beta and 
>alpha software
>that a lot of Gentoo users love so much (myself 
>included)? Places like
>BreakMyGentoo would only become bigger and more breakage 
>would incur
>from the lack of QA. If we had an unstable branch, devs 
>would be able to
>keep up Gentoo's repretation of being a bleeding edge 
>meta-distribution.
>At the same time we could offer alpha gnome releases 
>within our control.
>Ofcourse a plan to combat the extra pointless bug reports 
>would need to
>be thought about, but I see that as a small side effect 
>compared to the
>benefits. 
>
>Regards,
>Ian.  
>
>
>--
>gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Tuesday 07 October 2003 20:10, brett holcomb wrote:
> What's wrong with the alpha beta being part of ~arch?  If
> someone is working with alpha/beta stuff they know what
> they're looking for?  I really don't see a need to have a
> multi-tier mess to keep track of alpha/beta/gamma stuff.
>  If it's arch it is stable and works.  If it's ~arch it
> may be broken and break your system.  When the developer
> deems it's okay it moves to arch.
>

Not really, ~arch means that the package in itself is stable, and the 
developer thinks that the ebuild is also stable. Running ~arch should not 
mean that you get all kinds of beta quality stuff. It means that the 
installing of new packages might in some cases not go without a glitch. Some 
packages might not build without some extra "coersion", but once they are 
installed they should be stable. Unstable packages should be either not 
present or -arch masked or in package.mask. That is the policy as it exists.

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] Three teir portage: stable, prestable, unstable?

[Ian Leitch]

On Tue, 2003-10-07 at 15:30, foser wrote:
> I think the the problem is uninformedness about the policy, does it even
> get properly read by new devs ? They assume they can do it because they
> see another dev do it and so it spreads, you don't solve these problems
> by accommodating them. 

OK, so say something was done and from now on all devs only submited
packages to ~arch that they deemed stable but whos ebuild could do with
some more testing. Where does that leave the beta and alpha software
that a lot of Gentoo users love so much (myself included)? Places like
BreakMyGentoo would only become bigger and more breakage would incur
from the lack of QA. If we had an unstable branch, devs would be able to
keep up Gentoo's repretation of being a bleeding edge meta-distribution.
At the same time we could offer alpha gnome releases within our control.
Ofcourse a plan to combat the extra pointless bug reports would need to
be thought about, but I see that as a small side effect compared to the
benefits. 

Regards,
Ian.  


--
gentoo-dev@gentoo.org mailing list

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

[foser]

On Tue, 2003-10-07 at 20:49, Ian Leitch wrote:
> OK, so say something was done and from now on all devs only submited
> packages to ~arch that they deemed stable but whos ebuild could do with
> some more testing. Where does that leave the beta and alpha software
> that a lot of Gentoo users love so much (myself included)? Places like
> BreakMyGentoo would only become bigger and more breakage would incur
> from the lack of QA. 

No breakage occurs because they use alpha/beta quality software (ok and
their ebuilds are of mediocre quality in my opionon), you can't AQ
(assure quality) of something in heavy development.

Unlike some popular believe I'm not all against repositories like BMG
where stuff i can't possibly put in the tree is supplied to users
wanting to try some beta quality app, as long as it doesn't end in
excesses where it is cool to build a whole system from cvs HEAD. And i
strongly suggest against using lower libs/core apps not from the Gentoo
tree as they can easily affect the stability/integrity of a complete
install that results in hard to track bugs for us in some cases.

> If we had an unstable branch, devs would be able to
> keep up Gentoo's repretation of being a bleeding edge meta-distribution.

Bleeding stable edge, I think this was more aimed at the likes of Debian
where stable is stable as can be, but terribly outdated. We're still a
meta-distro, nothing to do with stableness. We're trying to be a serious
distro here, that is not supplying known broken stuff to the masses.

And as far as Gentoo's current reputation goes with various upstream
devs : we still have a lot to work on and i don't think supplying
alpha/beta/cvs in our mainline is gonna help.

> At the same time we could offer alpha gnome releases within our control.
> Ofcourse a plan to combat the extra pointless bug reports would need to
> be thought about, but I see that as a small side effect compared to the
> benefits. 

What benefits exactly ? Do we have to act according to a label that got
wrongly put on Gentoo as a distro?

I expect much more bugreports to be generated when providing alpha/beta
stuff, that would probably double the amount of bug reports (rough
estimate). Those are all bugs we can do little about only move them
upstream creating a huge amount of insolvable bugs for us. Our herd
teams are too small to handle that, we're not like Debian where every
single package has dedicated maintainers and even there unstable stuff
doesn't enter stable ever.

- foser


--
gentoo-dev@gentoo.org mailing list

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

[Jason Stubbs]

On Wednesday 08 October 2003 03:27, Paul de Vrieze wrote:
> On Tuesday 07 October 2003 20:10, brett holcomb wrote:
> > What's wrong with the alpha beta being part of ~arch?  If
> > someone is working with alpha/beta stuff they know what
> > they're looking for?  I really don't see a need to have a
> > multi-tier mess to keep track of alpha/beta/gamma stuff.
> >  If it's arch it is stable and works.  If it's ~arch it
> > may be broken and break your system.  When the developer
> > deems it's okay it moves to arch.
>
> Not really, ~arch means that the package in itself is stable, and the
> developer thinks that the ebuild is also stable. Running ~arch should not
> mean that you get all kinds of beta quality stuff. It means that the
> installing of new packages might in some cases not go without a glitch.
> Some packages might not build without some extra "coersion", but once they
> are installed they should be stable. Unstable packages should be either not
> present or -arch masked or in package.mask. That is the policy as it
> exists.

I've been reading the discussion with keen interest as I'm a user that runs 
~x86. However, my belief when I chose to do so was not along policy lines. 
I've never read the policy and have only read the following excerpt from 
make.conf.

# Gentoo is using a new masking system to allow for easier stability testing
# on packages. KEYWORDS are used in ebuilds to mask and unmask packages based
# on the platform they are set for. A special form has been added that
# indicates packages and revisions that are expected to work, but have not yet
# been approved for the stable set. '~arch' is a superset of 'arch' which
# includes the unstable, in testing, packages.

Perhaps this text needs to be revised so users know exactly what they're 
getting into.

Regards,
Jason

--
gentoo-dev@gentoo.org mailing list