[gentoo-dev] first council meeting

[gentoo-dev] first council meeting

[Aron Griffis]

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

The first council meeting happened today at 1900UTC.  All council 
members attended.

> 1. Official confirmation that the council is inline with
>    the already-defined roles of devrel and QA and its commitment
>    to make already-approved GLEPs (including GLEP 31) respected
>    (Clarification of position asked by many people including
>    Ciaran McCreesh, Patrick Lauer and Lance Albertson)

Confirmed with the caveat that the council is not taking on 
disciplinary responsibilities.  The QA team should take complaints 
regarding unresolved technical violations to devrel to pursue 
displinary action.

Regarding GLEP 31, the council is in favor of enforcement ASAP, 
provided nano is confirmed to be capable of compliance.  That will set 
the bar to require UTF-8 capable editors for portage work.

(note: agenda reordered per request)

> 3. glep40: Standardizing "arch" keywording across all archs
>    Vote asked by Grant Goodyear

Approved.

> 2. glep33: Eclass Restructure/Redesign
>    Vote asked by Brian Harring

Approved.

> 4. Discussion of the next meeting date(s)

2nd Thursday of each month, 1900UTC.  Rain date of 3rd Thursday.  

> 5. Open Q&A session

Full meeting log available at

    http://gentoo.org/proj/en/council/meeting-logs/20050915.txt

Please post follow-ups to gentoo-council ML (subscription required)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] first council meeting

[Olivier Crete]

On Thu, 2005-15-09 at 16:51 -0400, Aron Griffis wrote:
> > 3. glep40: Standardizing "arch" keywording across all archs
> >    Vote asked by Grant Goodyear
> 
> Approved.

What does that glep mean anyways ? Appart from the creation of the x86
team, is there any action to be taken?
- Is the maint keyword approved? 
- Does it mean that devs who are not part of the x86 team can't move
packages from ~x86 to x86 ?
- Is there something else I failed to read?

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Chris Gianelloni]

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

On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote:
> What does that glep mean anyways ? Appart from the creation of the x86
> team, is there any action to be taken?
> - Is the maint keyword approved?

No.  It was a suggestion, but was never added to the GLEP.

> - Does it mean that devs who are not part of the x86 team can't move
> packages from ~x86 to x86 ?

Correct.  They can, however, make previous arrangements with the x86
arch team to allow them to stabilize their own packages.  What this says
is "I acknowledge that anything that I break or that breaks on x86 with
my package, I get to fix and is not the responsibility of the x86 arch
team."  The x86 team will keep a list of these developers.  This is
similar (or identical) to how other arch teams work.  For example, I'm
not a member of the amd64 arch team, but they know I have an amd64 and
use it as my primary development box, so I have made arrangements with
them so I can ~amd64 -> amd64 my own packages.  If something breaks, I
pick up the pieces, not them.

> - Is there something else I failed to read?

Not that I'm aware of.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Thursday 15 September 2005 05:57 pm, Chris Gianelloni wrote:
> On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote:
> > - Does it mean that devs who are not part of the x86 team can't move
> > packages from ~x86 to x86 ?
>
> Correct.  They can, however, make previous arrangements with the x86
> arch team to allow them to stabilize their own packages.  What this says
> is "I acknowledge that anything that I break or that breaks on x86 with
> my package, I get to fix and is not the responsibility of the x86 arch
> team."  The x86 team will keep a list of these developers.  This is
> similar (or identical) to how other arch teams work.  For example, I'm
> not a member of the amd64 arch team, but they know I have an amd64 and
> use it as my primary development box, so I have made arrangements with
> them so I can ~amd64 -> amd64 my own packages.  If something breaks, I
> pick up the pieces, not them.

actually this is came up in the meeting as something we would like to see 
spelled out explicitly ... either as a GLEP itself or as a policy update to 
current stabilization practices

the GLEP was approved on the grounds that we need an x86 team and that it 
needs to be treated as any other arch ... arch team interaction with 
maintainers should be spelled out clearly rather than part of a single 
sentence '... or make individual arrangements with the x86 arch team.'
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Paul de Vrieze]

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

On Friday 16 September 2005 00:20, Mike Frysinger wrote:
> actually this is came up in the meeting as something we would like to see
> spelled out explicitly ... either as a GLEP itself or as a policy update to
> current stabilization practices
>
> the GLEP was approved on the grounds that we need an x86 team and that it
> needs to be treated as any other arch ... arch team interaction with
> maintainers should be spelled out clearly rather than part of a single
> sentence '... or make individual arrangements with the x86 arch team.'

Ok, I do think that we will need a way for the maintainer to indicate that the 
package is stable. I'd be happy to leave stabilizing out of my hands, but I 
wouldn't want my packages to be stabilized before I deem it stable.

Paul

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

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

Re: [gentoo-dev] first council meeting

[Martin Schlemmer]

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

On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
> On Friday 16 September 2005 00:20, Mike Frysinger wrote:
> > actually this is came up in the meeting as something we would like to see
> > spelled out explicitly ... either as a GLEP itself or as a policy update to
> > current stabilization practices
> >
> > the GLEP was approved on the grounds that we need an x86 team and that it
> > needs to be treated as any other arch ... arch team interaction with
> > maintainers should be spelled out clearly rather than part of a single
> > sentence '... or make individual arrangements with the x86 arch team.'
> 
> Ok, I do think that we will need a way for the maintainer to indicate that the 
> package is stable. I'd be happy to leave stabilizing out of my hands, but I 
> wouldn't want my packages to be stabilized before I deem it stable.
> 

File a bug if the arches (or main ones at least) haven't picked it up
yet?  Will make the problem of missing some or other keyword minimal
(especially for some obscure package not often used).


-- 
Martin Schlemmer


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

Re: [gentoo-dev] first council meeting

[Brian Harring]

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

On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote:
> On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote:
> > On Friday 16 September 2005 00:20, Mike Frysinger wrote:
> > > actually this is came up in the meeting as something we would like to see
> > > spelled out explicitly ... either as a GLEP itself or as a policy update to
> > > current stabilization practices
> > >
> > > the GLEP was approved on the grounds that we need an x86 team and that it
> > > needs to be treated as any other arch ... arch team interaction with
> > > maintainers should be spelled out clearly rather than part of a single
> > > sentence '... or make individual arrangements with the x86 arch team.'
> > 
> > Ok, I do think that we will need a way for the maintainer to indicate that the 
> > package is stable. I'd be happy to leave stabilizing out of my hands, but I 
> > wouldn't want my packages to be stabilized before I deem it stable.
> > 
> 
> File a bug if the arches (or main ones at least) haven't picked it up
> yet?  Will make the problem of missing some or other keyword minimal
> (especially for some obscure package not often used).
I would prefer this route, personally.

Jamming a maint keyword into the ebuild is kind of ugly from where I 
sit :)
~harring

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

Re: [gentoo-dev] first council meeting

[Simon Stelling]

Paul de Vrieze wrote:
> Ok, I do think that we will need a way for the maintainer to indicate that the 
> package is stable. I'd be happy to leave stabilizing out of my hands, but I 
> wouldn't want my packages to be stabilized before I deem it stable.

That's exactly what the maint keyword is for.


-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Ok, I do think that we will need a way for the maintainer to indicate
| that the package is stable. I'd be happy to leave stabilizing out of
| my hands, but I wouldn't want my packages to be stabilized before I
| deem it stable.

Take it out of package.mask and leave it for thirty (package-dependent)
days. If there is a pressing (eg security) reason for it to go to
stable sooner than would normally be expected, file a bug and Cc: the
relevant arch teams.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Paul de Vrieze]

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

On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | Ok, I do think that we will need a way for the maintainer to indicate
> | that the package is stable. I'd be happy to leave stabilizing out of
> | my hands, but I wouldn't want my packages to be stabilized before I
> | deem it stable.
>
> Take it out of package.mask and leave it for thirty (package-dependent)
> days. If there is a pressing (eg security) reason for it to go to
> stable sooner than would normally be expected, file a bug and Cc: the
> relevant arch teams.

I was thinking more like signalling that it shouldn't be stable yet, but 
shouldn't be masked either.

Paul

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

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

Re: [gentoo-dev] first council meeting

[Daniel Ostrow]

On Fri, 2005-09-16 at 20:48 +0200, Paul de Vrieze wrote:
> On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> > On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <pauldv@gentoo.org>
> >
> > wrote:
> > | Ok, I do think that we will need a way for the maintainer to indicate
> > | that the package is stable. I'd be happy to leave stabilizing out of
> > | my hands, but I wouldn't want my packages to be stabilized before I
> > | deem it stable.
> >
> > Take it out of package.mask and leave it for thirty (package-dependent)
> > days. If there is a pressing (eg security) reason for it to go to
> > stable sooner than would normally be expected, file a bug and Cc: the
> > relevant arch teams.
> 
> I was thinking more like signalling that it shouldn't be stable yet, but 
> shouldn't be masked either.
> 
> Paul

Here's my 2 cents on this...the general rule of thumb for an arch
stabilizing a package has been 30 days in ~ with no open bugs. As far as
I am concerned this mean that if a package maintainer does not want a
package to follow these rules then indicating such is as easy as opening
a bug against the package assigned to him/herself stating so and mark it
for all arch's. That way when the arch team goes to look for bugs (and
we are all doing this right???) before marking a package stable they
will see the bug and know not to.

Hell the bug can be as simple as "Don't mark this package stable yet for
reasons x, y and z." Doing it this way has the added advantage of
letting arch maintainers know about the reasons why the package
shouldn't be marked stable so they know what they are getting into by
going ahead of the package maintainer.

Personally I like this outlook a lot better then the maint ~maint option
because it provides information and fits into present policy. All in all
it really isn't that hard to open a bug.

If the package is truly not stable then it should really be moved back
into p.mask anyway.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Kevin F. Quinn]

How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for arch, adding a string variable to ebuilds indicating why the
maintainer considers the package unstable, eg:

UNSTABLE="#100435, #100345, unconfirmed break with foo"

The maintainer would simply alter this line as bugs get confirmed or
resolved.  If a package wants to stay ~arch for longer than normal,
even though there are as yet no reports of problems, the maintainer
can just keep it set to something:

UNSTABLE="gaining maturity"

The arch team could consider an ebuild without an UNSTABLE line
as a candidate for stable, and it provides an easy way for maintainers
to communicate what issues are known with a package to the arch team
(and anyone else who is interested).

The 30-day could be calculated from the $Header: of ebuilds that have
no UNSTABLE, or where it's empty.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Brian Harring]

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

On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
> The 30-day could be calculated from the $Header: of ebuilds that have
> no UNSTABLE, or where it's empty.

Doesn't work for N arches keywording, or ebuild dev doing minor 
syntax touch ups.

~harring

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

Re: [gentoo-dev] first council meeting

[Kevin F. Quinn]

On 17/9/2005 11:34:56, Brian Harring (ferringb@gentoo.org) wrote:
> On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
> > The 30-day could be calculated from the $Header: of ebuilds that have
> > no UNSTABLE, or where it's empty.
> 
> Doesn't work for N arches keywording, or ebuild dev doing minor 
> syntax touch ups.

Good point.  The minor touch-up issue could be resolved by setting
the string to the date the last issue was cleared instead of deleting
it:

UNSTABLE="2005/10/04"

but to handle N arches needs a different approach (the 'maint' keyword
idea also falls down here).


My favourite idea so far is mike's '?arch' on the understanding that
we have:

package.mask - 'alpha'
  Not suitable for mainstream testing

?arch - 'beta'
  Works on maintainers systems, worth testing
  Maintainer may not have tried it on arch.

~arch - 'release candidate'
  Maintainer & arch team happy that it's a good candidate for arch
  30-day maturity phase, arch testing in progress

arch - 'released'
  Arch team happy it's stable


In particular it's worth noting that marking ?arch is not restricted
the way marking ~arch is.  Over time I expect the x86 arch team to
impose more rigour on the use of ~x86, so that it behaves similarly
to the other arches.

In general, it would make sense for people to have arch or ~arch in
make.conf, and use package.keywords to grab stuff from ?arch in a
controlled fashion.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
> How about if the maintainer wants wider testing, i.e. wants to move
> it out of package.mask and into ~arch but isn't confident it's ready
> yet for arch, adding a string variable to ebuilds indicating why the
> maintainer considers the package unstable, eg:

i really want to get away from the idea of 'package.mask is for testing 
packages' ... its current dual role as both masking 'testing' packages and 
'broken' packages is wrong imo

we dont want to try reeducating our users to not be afraid of package.mask 
because a lot of things in there they *should* be afraid of
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Alec Warner]

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

Mike Frysinger wrote:
> On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
> 
>>How about if the maintainer wants wider testing, i.e. wants to move
>>it out of package.mask and into ~arch but isn't confident it's ready
>>yet for arch, adding a string variable to ebuilds indicating why the
>>maintainer considers the package unstable, eg:
> 
> 
> i really want to get away from the idea of 'package.mask is for testing 
> packages' ... its current dual role as both masking 'testing' packages and 
> 'broken' packages is wrong imo
> 
> we dont want to try reeducating our users to not be afraid of package.mask 
> because a lot of things in there they *should* be afraid of
> -mike

Why not merely add an overlay to the main tree and put the testing
packages in the overlay.  Then instruct users to add the overlay to
their portage settings.  Testing overlay for testing, p.mask for broken
packages.

   /usr/portage/overlay/cat/pkg/bla.ebuild
or
   /usr/portage/testing/cat/pkg/bla.ebuild
and so on...

- -Alec Warner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQyyRwmzglR5RwbyYAQJzOg/9GtwWPrshqv+24mXpWzjyXJddH/dT2sHF
WLf/BJOLJtsjsPuD/3V/R5RoiMhNAfXbmxsFDmp/Ny2LEJNue534+vMsiPFKRn3q
zLN38ldGkDbRbx3mXkpWlc4SauRasl06Wv2IgoLc0fO37Evv1IzJVG0vMA8o2js7
ZMvGegiW+kfQ8cbQA3LShR92hBK5gZS1pvGUbr6tWv23ebfh7zzwhCVcRGF3Akb6
Kl71I/sDlqPJnTLRwEZZdoSp00JAbGDDEF425O1QRDWZfLT8gZbcBQJ/ouiP2wh2
yy07uMokUHz8dhvcJ44WhQx7QBG0Yjo5OxNnZRasROse9bmEpFp9uNvGgS0nnRgn
PuWTnS2KBWCvfyd8eYY2PJB8rw3qmkgduBVO39XmUhCwD3kwR8wMcS1G2RXNnobc
BU4RCJQmUmzWDN9w/kDY4BL7NZekiZfjb2CjYDM2Acu8BaHKGvWjlygypsyiwzYy
B2pipj9S6Ad+itRFfvXZ+w1kbyp1yJmvXNIwYZC0ylyuYqpboQwKuEFKV/oUpbkX
Z/CK6du7Ke8cD8IYXgkH45MRTl5kvWkd5jhzDGeX+sGnuuXzHAAdQl7+tQbM2Oey
2B0W1ddKNsbnZOhXRGh8sX6+A1j1ao6D33I+M5kj3EyURqCsRhrcqPdxBYKpJyGl
y8wDdEb8Lpc=
=syMf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Saturday 17 September 2005 05:59 pm, Alec Warner wrote:
> Mike Frysinger wrote:
> > On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote:
> >>How about if the maintainer wants wider testing, i.e. wants to move
> >>it out of package.mask and into ~arch but isn't confident it's ready
> >>yet for arch, adding a string variable to ebuilds indicating why the
> >>maintainer considers the package unstable, eg:
> >
> > i really want to get away from the idea of 'package.mask is for testing
> > packages' ... its current dual role as both masking 'testing' packages
> > and 'broken' packages is wrong imo
> >
> > we dont want to try reeducating our users to not be afraid of
> > package.mask because a lot of things in there they *should* be afraid of
> > -mike
>
> Why not merely add an overlay to the main tree and put the testing
> packages in the overlay.  Then instruct users to add the overlay to
> their portage settings.  Testing overlay for testing, p.mask for broken
> packages.

that does sound like a pretty quick and clean solution ... the only problem i 
would have with it is that when we move from testing to normal portage tree, 
we lose cvs history ... and we'd have to merge ChangeLogs ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Wernfried Haas]

On Sat, Sep 17, 2005 at 04:17:10PM -0400, Mike Frysinger wrote:
> i really want to get away from the idea of 'package.mask is for testing 
> packages' ... its current dual role as both masking 'testing' packages and 
> 'broken' packages is wrong imo
> 
> we dont want to try reeducating our users to not be afraid of package.mask 
> because a lot of things in there they *should* be afraid of

Coming from the user side (forums) i fully agree. Common sense among
the users always used to be:
arch: stable
~arch: testing
p.mask: broken

This is also covered in our current documentation, see
http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml
--snip--
The Testing Branch

If you want to use more recent software, you can consider using the
testing branch instead. To have Portage use the testing branch, add a
~ in front of your architecture.

The testing branch is exactly what it says - Testing. If a package is
in testing, it means that the developers feel that it is functional
but has not been thoroughly tested. You could very well be the first
to discover a bug in the package in which case you could file a
bugreport to let the developers know about it.

Beware though, you might notice stability issues, imperfect package
handling (for instance wrong/missing dependencies), too frequent
updates (resulting in lots of building) or broken packages. If you do
not know how Gentoo works and how to solve problems, we recommend that
you stick with the stable and tested branch. 
--snip--

Doesn't exactly sound like packages in ~arch should be ready to enter
arch after 30 days (and or the other QA requirements). If someone
wants to change that, that would be a major change to Gentoo,
especially as it affects _every_ user. So it would at least require a
GLEP to do that.
I'd rather like to finally see proper QA applied and those who don't
beaten with a stick than making fundamental changes to existing common
sense just because it is written down somewhere _that_ way.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Wernfried Haas]

Oh, and for the sake of completeness, also from
http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml
--snip--
1.c. Using Masked Packages

The package.unmask file

The Gentoo developers do not support the use of these files. Please
exercise due caution when doing so. Support requests related to
package.unmask and/or package.mask will not be answered. You have been
warned.

When a package has been masked by the Gentoo developers and you still
want to use it despite the reason mentioned in the package.mask file
(situated in /usr/portage/profiles by default), add the exact same
line in /etc/portage/package.unmask. 
--snip--

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Sun, 18 Sep 2005 08:46:37 +0200 Wernfried Haas <amne@gentoo.org>
wrote:
| Doesn't exactly sound like packages in ~arch should be ready to enter
| arch after 30 days (and or the other QA requirements). If someone
| wants to change that, that would be a major change to Gentoo,
| especially as it affects _every_ user. So it would at least require a
| GLEP to do that.

Uhm. That's current policy and has been current policy for several
years. No GLEP needed.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Wernfried Haas]

On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
> Uhm. That's current policy and has been current policy for several
> years. No GLEP needed.

If that's currenty policy, why does the handbook say something quite
different then? Does it need to be fixed?

If so, i truly don't understand what ~arch should be about in the
first place - what use is a ~arch system for testing if everything in
there just works and stuff to be tested is p.masked?

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Alec Warner]

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

Wernfried Haas wrote:
> On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
> 
>>Uhm. That's current policy and has been current policy for several
>>years. No GLEP needed.
> 
> 
> If that's currenty policy, why does the handbook say something quite
> different then? Does it need to be fixed?
> 
> If so, i truly don't understand what ~arch should be about in the
> first place - what use is a ~arch system for testing if everything in
> there just works and stuff to be tested is p.masked?
> 
> cheers,
> 	Wernfried
> 

The point being that ~arch is generally for EBUILD testing, not package
testing.  This is bad because some PACKAGES need lots of testing but
don't get it because they are in p.mask ( because the PACKAGE is not
stable ).  Some people have begun putting unstable PACKAGES in ~arch,
instead of in p.mask because p.mask does not get enough testing done, so
things rot in p.mask forever.  For larger packages ( apache, mysql,
gnome ) this system works fine because upstream does a lot of testing.

Since users shy away from p.mask ( things in there can have security
issues for example ) a new PACKAGE testing area was proposed.  Packages
in this area would need PACKAGE testing.  Users would know that packages
with security issues would not be in this new testing area.

Personally I like Ciaran's wording of the levels.

~arch - Canidate for Stable on Arch
arch - Stable on Arch

You wouldn't suggest a program you hadn't tested as a Canidate for
Stable.  That would be utterly retarded.  You've tested it
thoroughly(sp?) and it seems to work well for you.  You have had other
developers in your herd test it and they also encounter no problems.
Thus it enters ~arch because you cannot find anything wrong with the
package and you think it's stable.  If the users find a huge bug you can
regress the ~arch back to the testing layer ( be it p.mask or something
new ) and fix the bug.  If no one files a bug for 30 days have an AT
test it and then mark it stable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQy10O2zglR5RwbyYAQLBcQ/9FPBNN6N2GmGvBpT1T2fnSnPTPiyFais5
4nSedhgi2uwROlCIOCdZevVEGLQbomwuOklWjjHhZK5TRYAmiqnqlSEscn881L10
KqRxTj7ctpBC7WExxvjpCOto4WYos+7jIe9n3mCXCeptv4R4/WBGTIXeHFqij8Mq
ii7tL2fxKR1iCzPJ2Hf596Ip6FeMcL5HPpiZ9TEBrx4Bl47OH42USMKVHUODDV4G
dDlGQKPuItubFsv8D4GwEIEFxWCxbIDj5gvTk3Y3g9gVc07sbFNzcO3RJKaN8zff
msDGONSWXZ4dNuYbPwrIs8IC9VWEctVmHxy3iB/HzIlnAoRIq5+an3QDuy93JlCN
TFmyWhf6MGkR4fovjo+zZ4FC4vGy8jYRuptRZpx2VLSX8fH4ishkZ/dJLOyZsRKC
5irvdz7l9y8q5Ge4ZEd/EkdOaYOAK7ZqxsbydKEImoYwY6yLRwnj+LbG3BO9ukUF
5jxyec+X1wWANaxwiWKZ2+WzXpt/QZUQo+r7tLNKUMOs9MZXIX5yTaaEqSNvCGhf
QHTlRjKOX9Z1YxD2u/mhv9UNYmX/gb9LUz/q9rzVUjHXm7CFB4aQiyGhL+HgEqrW
0h/OCHyShYOzG418Dc1lrJff5vVz5O0u5caIhEzn5Z6iHr0EInaqzr0DCtoFUCKa
uzurfVUN5lQ=
=GI+1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Philip Webb]

050918 Alec Warner wrote:
> Personally I like Ciaran's wording of the levels.
>   ~arch - Canidate for Stable on Arch
>   arch - Stable on Arch

</spectate>

As a mere user, that's how I read '~arch',
ie 'not known to be defective, but use at your own risk for now',
while 'arch' means 'the relevant dev(s) are satisfied this is bug-free:
you can feel safe using it in your production system'.

<spectate>

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Sun, 18 Sep 2005 15:01:13 +0200 Wernfried Haas <amne@gentoo.org>
wrote:
| On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote:
| > Uhm. That's current policy and has been current policy for several
| > years. No GLEP needed.
| 
| If that's currenty policy, why does the handbook say something quite
| different then? Does it need to be fixed?

The deal with the handbook wording is... Originally, it was phrased
very much in favour of ~arch, and suggesting that arch was the
equivalent of Debian Stable. Many users who didn't know what they were
doing would use ~arch and then complain when they encountered the
occasional breakage. Certain developers complained, and the wording was
changed.

Here's the important part. What we tell the end user is not the same as
what we tell the developer. Users should not use ~arch unless they're
prepared to accept breakages. Developers should not put things into
~arch if they think there's a significant chance of it breaking things.
That way, breakages will still sometimes occur in ~arch, and when they
do users don't get to complain too much.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Matti Bickel]

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

Wernfried Haas <amne@gentoo.org> wrote:
> Coming from the user side (forums) i fully agree. Common sense among
> the users always used to be:
> arch: stable
> ~arch: testing
> p.mask: broken

And this is what it should be IMHO.
The solutions so far seem to introduce only a new testing layer, already
represented by ~arch and advertised as such:
> http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml
> --snip--
> The Testing Branch
> [...]
> Beware though, you might notice stability issues, imperfect package
> handling (for instance wrong/missing dependencies), too frequent
> updates (resulting in lots of building) or broken packages. If you do
> not know how Gentoo works and how to solve problems, we recommend that
> you stick with the stable and tested branch. 
> --snip--

> Doesn't exactly sound like packages in ~arch should be ready to enter
> arch after 30 days (and or the other QA requirements).

The rules for a package to go to arch were introduced to me as
* >30 days ~arch
* no open bugs
* tested by AT|Dev and deemed stable

And IMHO this is both flexible and quick enough. If anybody has a
problem with the ebuild going stable, file a bug or bug a dev and
explain that you think the ebuild needs more testing.
That's about it.

> I'd rather like to finally see proper QA applied and those who don't
> beaten with a stick than making fundamental changes to existing common
> sense just because it is written down somewhere _that_ way.

Well, i think everybody's wants "proper QA". The problem was just "how
to". And of course i agree with you on that stick part ;-)

Regards,
Matti
-- 

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

Re: [gentoo-dev] first council meeting

[Andrew Muraco]

In response to all replies Thus far,
I as a User,
I expect that arch works (no matter what) - no arguments there
I assume that ~arch will work 95% of the time.
I never ever touch anything in p.mask.

Now, where do we put packages that could work for most users, but they 
might not work for the other 49% of users?
p.mask seems to prevent that 49% of users from trying it, and reporting 
those bugs, but on the other hand ~arch means that 49% of users using 
~arch will have problem x,y, or z.

Now understand, this is the viewpoint of myself, and I have used a full 
~arch system for a while, and i didn't ever run into anything more then 
the occasional package with a new config, or config update that i didnt 
do properly. (lazy-ness)

things to consider
1) would ?arch become the old ~arch, if it was implemented?
2) would people actually try to run a full ?arch system?
3) #2, would it be possible without breakage?

I personally like the idea of the UNSTABLE="" because to me, it changes 
nothing, but allows the AT and PM to communicate, on a per-ebuild basis.

(comments welcome)
just some thoughts,
Andrew


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Monday 26 September 2005 12:01 am, Andrew Muraco wrote:
> 1) would ?arch become the old ~arch, if it was implemented?
> 2) would people actually try to run a full ?arch system?
> 3) #2, would it be possible without breakage?

if we went with a testing mask it'd mean that users would be forced to select 
individual testing packages ... they wouldnt be able to globally accept all 
testing packages

this is another advantage of going with a testing.mask instead of a ?arch 
system
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Marius Mauch]

Mike Frysinger wrote:
> On Monday 26 September 2005 12:01 am, Andrew Muraco wrote:
> 
>>1) would ?arch become the old ~arch, if it was implemented?
>>2) would people actually try to run a full ?arch system?
>>3) #2, would it be possible without breakage?
> 
> 
> if we went with a testing mask it'd mean that users would be forced to select 
> individual testing packages ... they wouldnt be able to globally accept all 
> testing packages

Not completely true (assuming testing.mask would work like 
package.mask), but I'd rather not say how it's possible.

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

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > Take it out of package.mask and leave it for thirty
| > (package-dependent) days. If there is a pressing (eg security)
| > reason for it to go to stable sooner than would normally be
| > expected, file a bug and Cc: the relevant arch teams.
| 
| I was thinking more like signalling that it shouldn't be stable yet,
| but shouldn't be masked either.

Well, if it's in ~arch it's a candidate to go to stable after further
testing. If a package maintainer isn't prepared to have a package moved
to stable, they shouldn't take it out of package.mask.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Simon Stelling]

Ciaran McCreesh wrote:
> Well, if it's in ~arch it's a candidate to go to stable after further
> testing. If a package maintainer isn't prepared to have a package moved
> to stable, they shouldn't take it out of package.mask.

The 30 days are just a rule, there are enough packages which surely need a 
longer testing period, even if they work flawlessly. Or would you mark gcc 4.0 
stable after 30 days? I think that's what Paul wanted to say.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 21:12:56 +0200 Simon Stelling <blubb@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > Well, if it's in ~arch it's a candidate to go to stable after
| > further testing. If a package maintainer isn't prepared to have a
| > package moved to stable, they shouldn't take it out of package.mask.
| 
| The 30 days are just a rule, there are enough packages which surely
| need a longer testing period, even if they work flawlessly. Or would
| you mark gcc 4.0 stable after 30 days? I think that's what Paul
| wanted to say.

For that, I'd point you at the devmanual version of keywording policy,
which is a hell of a lot better written and includes an explicit remark
about core system components needing a lot more than 30 days.

http://dev.gentoo.org/~plasmaroo/devmanual/keywording/

Plus for stuff like gcc, it's very much an arch decision, not a package
maintainer decision.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Simon Stelling]

Ciaran McCreesh wrote:
> Plus for stuff like gcc, it's very much an arch decision, not a package
> maintainer decision.

gcc was just the first example which came to my mind -- you can replace it with 
every other big piece of software that needs more testing than just 30 days. Or 
the other way around: There might be a new, not very popular package, so the 
maintainer didn't get any bug reports (=it works fine), but there might be a too 
little user community that you really could claim it rock-solid stable.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 03:02 pm, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | > Take it out of package.mask and leave it for thirty
> | > (package-dependent) days. If there is a pressing (eg security)
> | > reason for it to go to stable sooner than would normally be
> | > expected, file a bug and Cc: the relevant arch teams.
> |
> | I was thinking more like signalling that it shouldn't be stable yet,
> | but shouldn't be masked either.
>
> Well, if it's in ~arch it's a candidate to go to stable after further
> testing. If a package maintainer isn't prepared to have a package moved
> to stable, they shouldn't take it out of package.mask.

not really ... sometimes you want to keep a package in unstable forever (like 
the cvs snapshots i make of e17), or until you work some quirks/features out 
for a new revbump which you would want stable
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| not really ... sometimes you want to keep a package in unstable
| forever (like the cvs snapshots i make of e17), or until you work
| some quirks/features out for a new revbump which you would want stable

Those should be in package.mask. ~arch is for candidates for arch that
haven't yet proven themselves.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Paul de Vrieze]

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

On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <vapier@gentoo.org>
>
> wrote:
> | not really ... sometimes you want to keep a package in unstable
> | forever (like the cvs snapshots i make of e17), or until you work
> | some quirks/features out for a new revbump which you would want stable
>
> Those should be in package.mask. ~arch is for candidates for arch that
> haven't yet proven themselves.

It's often the case that those ebuilds in principle work, but there are other 
reasons for not marking stable yet. Some packages for example can have 
upgrade problems for stable users while being stable for testing (by benefit 
of allready having passed such upgrade problems). Masking the ebuild is not 
really an option (causing testing users to go through unnecessary hoops 
again), while marking stable is also no option.

Paul

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

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

Re: [gentoo-dev] first council meeting

[Aron Griffis]

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

Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
> > Those should be in package.mask. ~arch is for candidates for arch that
> > haven't yet proven themselves.
> 
> It's often the case that those ebuilds in principle work, but there
> are other reasons for not marking stable yet. Some packages for
> example can have upgrade problems for stable users while being
> stable for testing (by benefit of allready having passed such
> upgrade problems). Masking the ebuild is not really an option
> (causing testing users to go through unnecessary hoops again), while
> marking stable is also no option.

You're saying there's four states:

    package.mask
    ~arch
    ~arch candidate for arch
    arch

Putting packages in package.mask isn't a hardship for testers.  I'm
not sure that's a good reason for the additional state.  It's purely
a matter of

    echo 'dev-util/mercurial' >> /etc/portage/package.unmask

So far I find myself agreeing with Ciaran's idea in this thread.
I don't see the point (yet) in more than three states.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] first council meeting

[Daniel Ostrow]

On Fri, 2005-09-16 at 16:21 -0400, Aron Griffis wrote:
> Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
> > > Those should be in package.mask. ~arch is for candidates for arch that
> > > haven't yet proven themselves.
> > 
> > It's often the case that those ebuilds in principle work, but there
> > are other reasons for not marking stable yet. Some packages for
> > example can have upgrade problems for stable users while being
> > stable for testing (by benefit of allready having passed such
> > upgrade problems). Masking the ebuild is not really an option
> > (causing testing users to go through unnecessary hoops again), while
> > marking stable is also no option.
> 
> You're saying there's four states:
> 
>     package.mask
>     ~arch
>     ~arch candidate for arch
>     arch
> 
> Putting packages in package.mask isn't a hardship for testers.  I'm
> not sure that's a good reason for the additional state.  It's purely
> a matter of
> 
>     echo 'dev-util/mercurial' >> /etc/portage/package.unmask
> 
> So far I find myself agreeing with Ciaran's idea in this thread.
> I don't see the point (yet) in more than three states.

His point (and it's an unfortunately valid one) as I understand it is
that our user base has been (mis)educated to avoid packages in p.mask
for fear of breaking things too badly. As such it gets an inherently far
smaller test base then packages in ~arch do.

Personally I am uncomfortable with people using ~arch as a "We didn't
get enough testing for package X, so we are putting it here for a wider
audience." mentality. That is the whole purpose of p.mask and released
independent overlays (such as fbsd and php use). Either way the use of
~arch for this purpose is really just wrong.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
> His point (and it's an unfortunately valid one) as I understand it is
> that our user base has been (mis)educated to avoid packages in p.mask
> for fear of breaking things too badly. As such it gets an inherently far
> smaller test base then packages in ~arch do.

i [rightly] fear package.mask packages most of the time.  we stick things in 
there that have security issues, or are known to be badly broken in some way, 
or wont work in subprofiles for archs (think glibc-specific packages masked 
in a uclibc profile).  at the sametime, we use package.mask for things that 
*should* work fine, but we dont know yet.  i wouldnt mind a restricted 4th 
level of masking here:

arch stable
~arch unstable
?arch should work fine, but not 100% sure yet
package.mask known to be broken in some way

it's also a pita to maintain package.mask since we're storing information 
about specific ebuilds outside of the ebuild itself, and it tends to suffer 
badly from bitrot
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 04:43 pm, Mike Frysinger wrote:
> On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote:
> > His point (and it's an unfortunately valid one) as I understand it is
> > that our user base has been (mis)educated to avoid packages in p.mask
> > for fear of breaking things too badly. As such it gets an inherently far
> > smaller test base then packages in ~arch do.
>
> arch stable
> ~arch unstable
> ?arch should work fine, but not 100% sure yet
> package.mask known to be broken in some way

actually, going with say 'testing.mask' instead of '?arch' may be better ... 
reinforce the fact that this is a package-level issue rather than 
arch-specific
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Kito]

On Sep 16, 2005, at 4:50 PM, Mike Frysinger wrote:
>
> actually, going with say 'testing.mask' instead of '?arch' may be  
> better ...
> reinforce the fact that this is a package-level issue rather than
> arch-specific

I like that concept. A lot less communication overhead, and addresses  
most of the current problems AFAICT.

--Kito

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Maurice van der Pot]

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

On Fri, Sep 16, 2005 at 05:50:39PM -0400, Mike Frysinger wrote:
> actually, going with say 'testing.mask' instead of '?arch' may be better ... 
> reinforce the fact that this is a package-level issue rather than 
> arch-specific

Let me get things straight. We would want this because it's the least of 
two evils?

On one hand ?arch isn't nice because it's package-level instead of 
arch-specific, so it doesn't belong among keywords. 
On the other hand testing.mask (if it's like package.mask) takes this 
(package-level) stuff and moves it out of the ebuilds it belongs to and 
dumps it all in one file.

So we'd want this because we don't want to introduce something new in
the ebuilds?

Just getting things straight before expressing my opinion explicitly =]

Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


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

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 23:50, Mike Frysinger wrote:
> actually, going with say 'testing.mask' instead of '?arch' may be better
> ... reinforce the fact that this is a package-level issue rather than
> arch-specific
> -mike

That's nearly as bad as having to deal with package.mask all the time. Keeping 
the maintainer's opinion on an ebuild outside of it doesn't make any sense.


Carsten

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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 06:45 pm, Carsten Lohrke wrote:
> On Friday 16 September 2005 23:50, Mike Frysinger wrote:
> > actually, going with say 'testing.mask' instead of '?arch' may be better
> > ... reinforce the fact that this is a package-level issue rather than
> > arch-specific
> > -mike
>
> That's nearly as bad as having to deal with package.mask all the time.
> Keeping the maintainer's opinion on an ebuild outside of it doesn't make
> any sense.

maybe, but considering we're talking about testing on a package level and not 
an arch level, either solution has its failings

i dont really care either way so long as we have a new level of control
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Olivier Crete]

On Fri, 2005-16-09 at 16:21 -0400, Aron Griffis wrote:
> Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
> > > Those should be in package.mask. ~arch is for candidates for arch that
> > > haven't yet proven themselves.
> > 
> > It's often the case that those ebuilds in principle work, but there
> > are other reasons for not marking stable yet. Some packages for
> > example can have upgrade problems for stable users while being
> > stable for testing (by benefit of allready having passed such
> > upgrade problems). Masking the ebuild is not really an option
> > (causing testing users to go through unnecessary hoops again), while
> > marking stable is also no option.
> 
> You're saying there's four states:
> 
>     package.mask
>     ~arch
>     ~arch candidate for arch
>     arch
[...]
> So far I find myself agreeing with Ciaran's idea in this thread.
> I don't see the point (yet) in more than three states.

Well having the "~arch candidate for arch" makes the imlate script much
easier to use.. I would find it a PITA to have to go through the
changelog of every package to see if it has been in testing for 30
days.. Or we need to automate it, something like a
imlate-because-the-package-hasnt-changed-in-30-days.py 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
> Those should be in package.mask. ~arch is for candidates for arch that
> haven't yet proven themselves.

No. Your idea how it should work simply doesn't match reality. When you e.g. 
have upstream devs following the maxim "release early and often", it happens 
that you don't want ebuilds go stable so easily, but still have a wide 
testing audience. Arch teams have to ask package maintainers when they want 
to stabilize an ebuild before it is indicated - be it by a "maint" keyword or 
what else.


Carsten

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

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 22:17:20 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
| > Those should be in package.mask. ~arch is for candidates for arch
| > that haven't yet proven themselves.
| 
| No. Your idea how it should work simply doesn't match reality.

That's not my idea. That's policy. I just happen to a) have actually
read what policy says and b) agree with it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
> That's not my idea. That's policy. I just happen to a) have actually
> read what policy says and b) agree with it.

First: I know you're proposing this regularly, but please show me the policy - 
I'm sure your interpretation doesn't match mine.

Second: a) and b) doesn't match what's going on with large parts of the tree 
and I refuse to constantly add and remove ebuilds from the package.mask file, 
that are not really broken. It's only extra work for me and confusing for 
users.


Carsten

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

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 23:23:35 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
| > That's not my idea. That's policy. I just happen to a) have actually
| > read what policy says and b) agree with it.
| 
| First: I know you're proposing this regularly, but please show me the
| policy - I'm sure your interpretation doesn't match mine.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

> There is a difference between using package.mask and ~arch for
> ebuilds. The use of ~arch denotes an ebuild requires testing. The use
> of package.mask denotes that the application or library itself is
> deemed unstable.

| Second: a) and b) doesn't match what's going on with large parts of
| the tree 

Good time for package maintainers to start following policy properly,
eh?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Patrick Lauer]

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

On Fri, 2005-09-16 at 22:34 +0100, Ciaran McCreesh wrote:
> > There is a difference between using package.mask and ~arch for
> > ebuilds. The use of ~arch denotes an ebuild requires testing. The use
> > of package.mask denotes that the application or library itself is
> > deemed unstable.
> | Second: a) and b) doesn't match what's going on with large parts of
> | the tree 
> 
> Good time for package maintainers to start following policy properly,
> eh?
Good time for policy to be adapted to match reality ;-)

-- 
Stand still, and let the rest of the universe move

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

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 23:41:21 +0200 Patrick Lauer <patrick@gentoo.org>
wrote:
| > Good time for package maintainers to start following policy
| > properly, eh?
| Good time for policy to be adapted to match reality ;-)

Reality is that most people do exactly what policy says. Most bumps
don't warrant a package.mask entry anyway -- most upstreams for
non-trivial apps know about change control.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 23:34, Ciaran McCreesh wrote:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

As I said - your interpretation doesn't match mine - or the policy is not good 
enough.

> Good time for package maintainers to start following policy properly,
> eh?

I'm sorry, not your idea of this policy.


Carsten

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

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Sat, 17 Sep 2005 00:43:02 +0200 Carsten Lohrke <carlo@gentoo.org>
wrote:
| > Good time for package maintainers to start following policy
| > properly, eh?
| 
| I'm sorry, not your idea of this policy.

Policy is rather specific about it. It's not a matter of interpretation
at all.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Saturday 17 September 2005 01:00, Ciaran McCreesh wrote:
> Policy is rather specific about it. It's not a matter of interpretation
> at all.

That I disagree should prove that this is not a case. It's one thing to 
consider an application to "just work" for the user and another having e.g. 
the history of bug fix releases for previous versions in mind or knowing 
about minor but annoying bugs, which should be fixed before some version of 
it goes stable.


Carsten

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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 03:34 pm, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <vapier@gentoo.org>
>
> wrote:
> | not really ... sometimes you want to keep a package in unstable
> | forever (like the cvs snapshots i make of e17), or until you work
> | some quirks/features out for a new revbump which you would want stable
>
> Those should be in package.mask. ~arch is for candidates for arch that
> haven't yet proven themselves.

ok, e17 packages dont count here.  however, your hardcore view i still dont 
buy.  how about the baselayout-1.9.x -> baselayout-1.11.x stabilization 
process ?  are you telling me that arch teams should have had the power to 
move those into stable without talking to the maintainer ?  baselayout may be 
a core package, but if you continue with your hard rule here, then it doesnt 
matter.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| ok, e17 packages dont count here.  however, your hardcore view i
| still dont buy.  how about the baselayout-1.9.x -> baselayout-1.11.x
| stabilization process ?  are you telling me that arch teams should
| have had the power to move those into stable without talking to the
| maintainer ?  baselayout may be a core package, but if you continue
| with your hard rule here, then it doesnt matter.

I'm saying that arch teams should be allowed to mark it stable if they
think it's appropriate. Not that it must be moved to stable after $x
days, but that it can be at the arch team's discretion. And any arch
team which is silly enough to mark a broken baselayout stable has far
bigger problems anyway...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@gentoo.org>
>
> wrote:
> | ok, e17 packages dont count here.  however, your hardcore view i
> | still dont buy.  how about the baselayout-1.9.x -> baselayout-1.11.x
> | stabilization process ?  are you telling me that arch teams should
> | have had the power to move those into stable without talking to the
> | maintainer ?  baselayout may be a core package, but if you continue
> | with your hard rule here, then it doesnt matter.
>
> I'm saying that arch teams should be allowed to mark it stable if they
> think it's appropriate. Not that it must be moved to stable after $x
> days, but that it can be at the arch team's discretion. And any arch
> team which is silly enough to mark a broken baselayout stable has far
> bigger problems anyway...

baselayout is an example, any package can be used here (although not many are 
as critical)

i'm saying that the maintainer may have a certain idea of when the package is 
ready for stable (a target feature set, working out certain quirks, etc...).  
your current hard view does not allow for that.  for example, i had an arch 
maintainer one time mark bash-3 stable before base-system was ready for it 
(readline, baselayout, etc... were going to be stabilized together).  i 
smacked them hard for it, but if we went with this hard view, it would have 
been perfectly acceptable behavior.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 16:59:56 -0400 Mike Frysinger <vapier@gentoo.org>
wrote:
| baselayout is an example, any package can be used here (although not
| many are as critical)
| 
| i'm saying that the maintainer may have a certain idea of when the
| package is ready for stable (a target feature set, working out
| certain quirks, etc...). your current hard view does not allow for
| that.  for example, i had an arch maintainer one time mark bash-3
| stable before base-system was ready for it (readline, baselayout,
| etc... were going to be stabilized together).  i smacked them hard
| for it, but if we went with this hard view, it would have been
| perfectly acceptable behavior. -mike

There is nothing in this view that says "consulting the package
maintainer is not part of the stable decision-making process for arch
teams".

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Simon Stelling]

Ciaran McCreesh wrote:
> There is nothing in this view that says "consulting the package
> maintainer is not part of the stable decision-making process for arch
> teams".

So do I have to ask the maintainer first everytime I want mark a package stable? 
Is that what you are currently doing?

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Ciaran McCreesh]

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

On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling <blubb@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > There is nothing in this view that says "consulting the package
| > maintainer is not part of the stable decision-making process for
| > arch teams".
| 
| So do I have to ask the maintainer first everytime I want mark a
| package stable? Is that what you are currently doing?

No. You *can* ask the package maintainer, if you feel that such a move
would be useful and productive.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 05:26 pm, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling <blubb@gentoo.org>
>
> wrote:
> | Ciaran McCreesh wrote:
> | > There is nothing in this view that says "consulting the package
> | > maintainer is not part of the stable decision-making process for
> | > arch teams".
> |
> | So do I have to ask the maintainer first everytime I want mark a
> | package stable? Is that what you are currently doing?
>
> No. You *can* ask the package maintainer, if you feel that such a move
> would be useful and productive.

that's the problem, there's no way to flag which packages should be consulted 
and which ones are a non-issue
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Paul de Vrieze]

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

On Friday 16 September 2005 23:51, Mike Frysinger wrote:
> that's the problem, there's no way to flag which packages should be
> consulted and which ones are a non-issue

This indeed kind of sums up my point.

Paul

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

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

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 23:26, Ciaran McCreesh wrote:
> No. You *can* ask the package maintainer, if you feel that such a move
> would be useful and productive.

No. There're lot of issues an arch maintainer not necessarily knows about. 
Without a way to indicate which ebuild is good, the whole "position" of a 
package maintainer is void.


Carsten

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

Re: [gentoo-dev] first council meeting

[Martin Schlemmer]

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

On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
> On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
> > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@gentoo.org>
> >
> > wrote:
> > | ok, e17 packages dont count here.  however, your hardcore view i
> > | still dont buy.  how about the baselayout-1.9.x -> baselayout-1.11.x
> > | stabilization process ?  are you telling me that arch teams should
> > | have had the power to move those into stable without talking to the
> > | maintainer ?  baselayout may be a core package, but if you continue
> > | with your hard rule here, then it doesnt matter.
> >
> > I'm saying that arch teams should be allowed to mark it stable if they
> > think it's appropriate. Not that it must be moved to stable after $x
> > days, but that it can be at the arch team's discretion. And any arch
> > team which is silly enough to mark a broken baselayout stable has far
> > bigger problems anyway...
> 
> baselayout is an example, any package can be used here (although not many are 
> as critical)
> 
> i'm saying that the maintainer may have a certain idea of when the package is 
> ready for stable (a target feature set, working out certain quirks, etc...).  
> your current hard view does not allow for that.  for example, i had an arch 
> maintainer one time mark bash-3 stable before base-system was ready for it 
> (readline, baselayout, etc... were going to be stabilized together).  i 
> smacked them hard for it, but if we went with this hard view, it would have 
> been perfectly acceptable behavior.

We still have KEYWORDS="-*".  Sure, I know many do not like it, and if
something was decided in regards to it, I missed it, but it is generally
seen as 'less severe' than a package.mask'd mask, and its local to the
package, so should not get stale.



-- 
Martin Schlemmer


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

Re: [gentoo-dev] first council meeting

[Mike Frysinger]

On Friday 16 September 2005 05:57 pm, Martin Schlemmer wrote:
> On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote:
> > On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote:
> > > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@gentoo.org>
> > >
> > > wrote:
> > > | ok, e17 packages dont count here.  however, your hardcore view i
> > > | still dont buy.  how about the baselayout-1.9.x -> baselayout-1.11.x
> > > | stabilization process ?  are you telling me that arch teams should
> > > | have had the power to move those into stable without talking to the
> > > | maintainer ?  baselayout may be a core package, but if you continue
> > > | with your hard rule here, then it doesnt matter.
> > >
> > > I'm saying that arch teams should be allowed to mark it stable if they
> > > think it's appropriate. Not that it must be moved to stable after $x
> > > days, but that it can be at the arch team's discretion. And any arch
> > > team which is silly enough to mark a broken baselayout stable has far
> > > bigger problems anyway...
> >
> > baselayout is an example, any package can be used here (although not many
> > are as critical)
> >
> > i'm saying that the maintainer may have a certain idea of when the
> > package is ready for stable (a target feature set, working out certain
> > quirks, etc...). your current hard view does not allow for that.  for
> > example, i had an arch maintainer one time mark bash-3 stable before
> > base-system was ready for it (readline, baselayout, etc... were going to
> > be stabilized together).  i smacked them hard for it, but if we went with
> > this hard view, it would have been perfectly acceptable behavior.
>
> We still have KEYWORDS="-*".  Sure, I know many do not like it, and if
> something was decided in regards to it, I missed it, but it is generally
> seen as 'less severe' than a package.mask'd mask, and its local to the
> package, so should not get stale.

that would address the 'arch teams marking ahead of maintainer' issue, but in 
general, i think we need a testing mask of some sort separate from 
package.mask where we can put things like modular X, new KDE betas, new GNOME 
betas, e17 packages, etc...
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: first council meeting

[Duncan]

Mike Frysinger posted <200509161817.01181.vapier@gentoo.org>, excerpted
below,  on Fri, 16 Sep 2005 18:17:01 -0400:

>> We still have KEYWORDS="-*".  Sure, I know many do not like it, and if
>> something was decided in regards to it, I missed it, but it is generally
>> seen as 'less severe' than a package.mask'd mask, and its local to the
>> package, so should not get stale.
> 
> that would address the 'arch teams marking ahead of maintainer' issue, but in 
> general, i think we need a testing mask of some sort separate from 
> package.mask where we can put things like modular X, new KDE betas, new GNOME 
> betas, e17 packages, etc...

Exactly.  I'm a full ~arch user, and regularly load packages such as gcc4
(including snapshots once in awhile, plus the accompanying glibc and
binutils) and kde and xorg snapshots, as well as pre versions of
baselayout and portage, at times.

I'd DEFINITELY be more convenient if I could easily separate the security
and confirmed system munching stuff in package.mask out from these testing
packages.  ? arch would be great, here, as it would mean I could simply
package.keyword as necessary, rather than (1) package.unmask, then
sometimes  (2) copying to overlay, and (3) adding ~arch and redigesting so
portage will work with it.  However, a testing.mask and parallel
testing.unmask in /etc/portage, would work fine as well, provided when
they were used, ~archs were carried over, to prevent having to overlay the
package simply to add the appropriate keyword.  (Being amd64 and having
some packages do amd64 conditionals, I don't like adding ~x86 or -* to
package.keywords, so overlay it has to be.)

The point has been made that snapshots/pres/rcs and the like should never
make it to ~arch, because they are never reasonable candidates for
arch-stable.  Point taken.  However, that's certainly far easier for
testers such as myself, than having to move a hundred kde-split-pkgs to
overlay and keyword them, to be able to test the latest kde snapshot, then
do the exact /same/ thing a week or two later for the /next/ one.  For
devs and users alike, an upstream package testing area (to parallel ~arch
which is effectively ebuild testing and stable candidate area) that was
separate and distinct from known actively harmful package.mask, would be
/very/ useful, giving both advanced users and devs a way to know with no
doubt what was considered ready for testing of the upstream-package, as
deployed on Gentoo.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] first council meeting

[Carsten Lohrke]

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

On Friday 16 September 2005 23:57, Martin Schlemmer wrote:
> We still have KEYWORDS="-*".

I'd appreciate, if we disallow that and all use package.mask.


Carsten

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

Re: [gentoo-dev] first council meeting

[Aron Griffis]

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

Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT]
> not really ... sometimes you want to keep a package in unstable
> forever (like the cvs snapshots i make of e17), or until you work
> some quirks/features out for a new revbump which you would want
> stable

Why wouldn't you put these in package.mask?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] first council meeting

[Elfyn McBratney]

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

On Fri, Sep 16, 2005 at 04:16:22PM -0400, Aron Griffis wrote:
> Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT]
> > not really ... sometimes you want to keep a package in unstable
> > forever (like the cvs snapshots i make of e17), or until you work
> > some quirks/features out for a new revbump which you would want
> > stable
> 
> Why wouldn't you put these in package.mask?

Why would you ? ;)  If package foo isn't known to be broken, or known to
break other packages, and generally just works(tm), why make it just that
little bit harder for other people to test it ?

Forgetting that it's just one extra step to take before emerging (adding
an atom for package to /etc/portage/p.unmask), in addition to adding an
atom for it to /etc/portage/p.keywords also, there's also the fact that
package.mask is a dumping ground for packages that fit one (or more) of
the following:

	* is vulnerable to exploitation and the like, or;
	* is broken on some level (crashes, munched goldfish, ..); or
	* requires extensive testing with the rest of the system i.e.,
	  could _completely_ break ones install.

In other words, it's unstable, and many users (including myself) stay
away from packages therein.

So, the question is: when did ~arch and packake.mask become synonymous ?

Best,
Elfyn

-- 
Elfyn McBratney
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

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

Re: [gentoo-dev] first council meeting

[Jason Stubbs]

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

On Friday 16 September 2005 05:51, Aron Griffis wrote:
> Regarding GLEP 31, the council is in favor of enforcement ASAP,
> provided nano is confirmed to be capable of compliance.  That will set
> the bar to require UTF-8 capable editors for portage work.

Confirmed.

-- 
Jason Stubbs

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

[gentoo-dev] Re: first council meeting

[Duncan]

Jason Stubbs posted <200509160847.11783.jstubbs@gentoo.org>, excerpted
below,  on Fri, 16 Sep 2005 08:47:09 +0900:

> On Friday 16 September 2005 05:51, Aron Griffis wrote:
>> Regarding GLEP 31, the council is in favor of enforcement ASAP,
>> provided nano is confirmed to be capable of compliance.  That will set
>> the bar to require UTF-8 capable editors for portage work.
> 
> Confirmed.

Hmm... I've never seen this one mentioned, and use it a lot...

Does mcedit properly handle UTF-8?  I /do/ see 8-bit is an option.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list