[gentoo-dev] Monthly Gentoo Council Reminder for May

[gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically the
2nd Thursday once a month), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every *re*submission to the council for review must
first be sent to the gentoo-dev mailing list 7 days (minimum) before
being submitted as an agenda item which itself occurs 7 days before the
meeting.  Simply put, the gentoo-dev mailing list must be notified at
least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

On Sunday 07 May 2006 15:31, Mike Frysinger wrote:
> This is your monthly friendly reminder !

sorry for the delay ... the mail server changes broke a bunch of my automated 
scripts :/
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mark Loeser]

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

Mike Frysinger <vapier@gentoo.org> said:
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

I'd like GLEP 48 [1] to be voted on.

Thanks,

[1] http://www.gentoo.org/proj/en/glep/glep-0048.html

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

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

[gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Petteri Räty]

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

Mike Frysinger kirjoitti:
> 
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.
> 

I would like the council to remind everyone that this is not appropriate
for any team:
https://bugs.gentoo.org/show_bug.cgi?id=176256#c4

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Jose Luis Rivero (YosWinK)]

Petteri Räty wrote:
> Mike Frysinger kirjoitti:
>> If you have something you'd wish for us to chat about, maybe even
>> vote on, let us know !  Simply reply to this e-mail for the whole
>> Gentoo dev list to see.
>>
> 
> I would like the council to remind everyone that this is not appropriate
> for any team:
> https://bugs.gentoo.org/show_bug.cgi?id=176256#c4
> 

The alpha arch team is *fully* agree with sparc in this case (as many 
others) and hope the council make a clear statement against this kind of 
keywording, which we think can create many more problems than solutions.

We *really* appreciate the great job doing by our games herd (one of the 
best out there) but, in this case, this is not the way to follow.

Thanks.

-- 
Jose Luis Rivero [yoswink@gentoo.org]
Gentoo/Doc Gentoo/Alpha
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

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

On Tuesday 01 May 2007, Petteri Räty wrote:
> Mike Frysinger kirjoitti:
> > If you have something you'd wish for us to chat about, maybe even
> > vote on, let us know !  Simply reply to this e-mail for the whole
> > Gentoo dev list to see.
>
> I would like the council to remind everyone that this is not appropriate
> for any team

doesnt take much to get people in a hissy over nothing

the issue has been taken care of [to the detriment of users]
-mike

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Ciaran McCreesh]

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

On Wed, 2 May 2007 16:49:32 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 01 May 2007, Petteri Räty wrote:
> > Mike Frysinger kirjoitti:
> > > If you have something you'd wish for us to chat about, maybe even
> > > vote on, let us know !  Simply reply to this e-mail for the whole
> > > Gentoo dev list to see.
> >
> > I would like the council to remind everyone that this is not
> > appropriate for any team
> 
> doesnt take much to get people in a hissy over nothing

What, people deliberately breaking policy that directly leads to
breaking stable and not having any working ebuilds for a package in
the tree, and then refusing to do anything about it is nothing?

> the issue has been taken care of 

You have a conflict of interest in this one. What do other Council
members who aren't games team members think?

> [to the detriment of users]

How is not having broken packages committed straight to stable
detrimental to users?

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

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

On Wednesday 02 May 2007, Ciaran McCreesh wrote:
> > the issue has been taken care of
>
> You have a conflict of interest in this one. What do other Council
> members who aren't games team members think?

perhaps you should try reading the bug
-mike

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Roy Marples]

On Wed, 2 May 2007 22:00:05 +0100
Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> What, people deliberately breaking policy that directly leads to
> breaking stable and not having any working ebuilds for a package in
> the tree, and then refusing to do anything about it is nothing?
> 
> > the issue has been taken care of 
> 
> You have a conflict of interest in this one. What do other Council
> members who aren't games team members think?
> 
> > [to the detriment of users]
> 
> How is not having broken packages committed straight to stable
> detrimental to users?

I maintain and play a game called Eternal Lands. I'm a Council member,
but not part of the games team/herd.

One of the problems games have with stable/unstable/testing/whatever
keywords is that upstream changes things that in any other application
just would not change. For example, the network protocol when talking
to servers. EL is very version specific and when a new client is
launched, around once every 6 months they change over right away. That
means our users need the game right away.

I used to commit EL straight to stable for this very reason, but now
after a few Gentoo QA people bitched EL will never ever have a stable
keyword. So instead I periodically have to let our users know how to
unmask EL just so they can play their game.

So no, in many cases NOT committing straight to stable CAN be
detrimental to our users if all they want is a games machine. You could
argue that they shouldn't be using Gentoo, but I would argue why should
we discriminate?

Thanks

Roy

DISCLAIMER: I've not read the bug mentioned as I've lost the email
with it's number so I may just be talking out of my ass.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

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

On Thursday 03 May 2007, Roy Marples wrote:
> DISCLAIMER: I've not read the bug mentioned as I've lost the email
> with it's number so I may just be talking out of my ass.

there's nothing of value in said bug so having not read it is OK
-mike

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

["José Luis Rivero (yoswink)"]

Roy Marples wrote:
> 
> I maintain and play a game called Eternal Lands. I'm a Council member,
> but not part of the games team/herd.
> 
> One of the problems games have with stable/unstable/testing/whatever
> keywords is that upstream changes things that in any other application
> just would not change. For example, the network protocol when talking
> to servers. EL is very version specific and when a new client is
> launched, around once every 6 months they change over right away. That
> means our users need the game right away.

Thanks for the example, trust me if I tell you that we can understand 
the situation pretty well.

> 
> I used to commit EL straight to stable for this very reason, but now
> after a few Gentoo QA people bitched EL will never ever have a stable
> keyword. 

I'm nearly sure that you always (at least) compile and run the new 
version in your box before you sent it to stable, didn't you? So, at 
least, you are able to say that it works in your case.

> So instead I periodically have to let our users know how to
> unmask EL just so they can play their game.

There are always ways to educate users about how to use portage properly.

> So no, in many cases NOT committing straight to stable CAN be
> detrimental to our users if all they want is a games machine. You could
> argue that they shouldn't be using Gentoo, but I would argue why should
> we discriminate?
> 

Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or 
beryl users discriminated or they should be using something different to 
Gentoo? They only thing people have to do is use some ~arch branch 
packages, which isn't too difficult (in Gentoo).

This is how I see it:

Problem with keywording straight to stable is that arch teams are very 
zealous about our stable branch. We put a lot of time trying things to 
not fail in stable, and if an app is broken, we prefer to not force the 
users to compile and install another broken (or unknown to be broken) 
version and work to fix the current stable (patches or bumping) together 
with the maintainer.

But if you send things, that you can't try, to stable, the qa baby jesus 
will cry if it fails, because nobody has taken care of even compile it 
in the arch  :)

Games are not part of core system, so IMHO, use the ~arch branch to have 
the latest cool version to enjoy, could be a good way to go for those 
el1te gam3rs.

Thanks.

-- 
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Doc Gentoo/Alpha
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Roy Marples]

On Thu, 03 May 2007 12:15:45 +0200
"José Luis Rivero (yoswink)" <yoswink@gentoo.org> wrote:
> Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or 
> beryl users discriminated or they should be using something different
> to Gentoo? They only thing people have to do is use some ~arch branch 
> packages, which isn't too difficult (in Gentoo).

No no no.
In my example we can only use one version of the game with the upstream
servers. There is only 1 upstream server, we have to use it.

So if it supports 6 archs and some of the arch teams take a few months
to mark it stable then the chances are it will be out of date anyway
and the "slacker arches" will never have a stable keyword.

So remove the onus on slacker arches making games stable I just don't
bother with the stable keyword for network games ever.

Gnome-2.18 on the other hand is a desktop product with zero upstream
interaction except with programs that have clearly defined protocols
and are normally backwards compatible. Like say HTTP

> 
> This is how I see it:
> 
> Problem with keywording straight to stable is that arch teams are
> very zealous about our stable branch. We put a lot of time trying
> things to not fail in stable, and if an app is broken, we prefer to
> not force the users to compile and install another broken (or unknown
> to be broken) version and work to fix the current stable (patches or
> bumping) together with the maintainer.

Right, but if stable client version != stable usptream server version
it cannot be used anyway, making the stable keyword here a bit of a
joke.

> But if you send things, that you can't try, to stable, the qa baby
> jesus will cry if it fails, because nobody has taken care of even
> compile it in the arch  :)

Well, that's up to the arch teams I guess. Lots of things fail randomly
on g/fbsd because of a patch added to fix a linux bug. Maybe when we
g/fbsd gets a stable branch then we'll come down on the linux
developers like a ton of bricks :)

Thanks

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

["José Luis Rivero (yoswink)"]

Roy Marples escribió:
> On Thu, 03 May 2007 12:15:45 +0200
> "José Luis Rivero (yoswink)" <yoswink@gentoo.org> wrote:
>> Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or 
>> beryl users discriminated or they should be using something different
>> to Gentoo? They only thing people have to do is use some ~arch branch 
>> packages, which isn't too difficult (in Gentoo).
> 
> No no no.
> In my example we can only use one version of the game with the upstream
> servers. There is only 1 upstream server, we have to use it.
> 

Excuse me, Roy. I didn't get the point.

Only one upstream server seems to make things much stricter and sounds 
quite reasonable to me the both ways you have used to handle it.

IMHO, this is a good case where I'm sure arch teams could be happy to 
make an exception to the general rule.

BTW, I think this is completely different to the situation being discussed.

Thanks.

-- 
Jose Luis Rivero <yoswink@gentoo.org>
Gentoo/Doc Gentoo/Alpha
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Matthias Langer]

On Thu, 2007-05-03 at 08:11 +0100, Roy Marples wrote:
> On Wed, 2 May 2007 22:00:05 +0100
> Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> > What, people deliberately breaking policy that directly leads to
> > breaking stable and not having any working ebuilds for a package in
> > the tree, and then refusing to do anything about it is nothing?
> > 
> > > the issue has been taken care of 
> > 
> > You have a conflict of interest in this one. What do other Council
> > members who aren't games team members think?
> > 
> > > [to the detriment of users]
> > 
> > How is not having broken packages committed straight to stable
> > detrimental to users?
> 
> I maintain and play a game called Eternal Lands. I'm a Council member,
> but not part of the games team/herd.
> 
> One of the problems games have with stable/unstable/testing/whatever
> keywords is that upstream changes things that in any other application
> just would not change. For example, the network protocol when talking
> to servers. EL is very version specific and when a new client is
> launched, around once every 6 months they change over right away. That
> means our users need the game right away.

ok, agreed, this is a valid point. so i would suggest, that maintainers
of games where this argument applies, come to special agreements with
the arch teams - or just file bugreports like this:

"
although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like
to have it stable real soon, as upstream has changed the network
protocol. i have x86 and amd64 hardware available, and can confirm, that
the game works nice there; so, if no one objects, i'm gonna mark
lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like
to have a shiny sparc keyword, but have no hardware to test. so it would
be highly appreciated if someone from the sparc team can give the game a
try.
"

but committing straight to stable on arches where the package wasn't
even tested is an absolute no-do for me.  

> DISCLAIMER: I've not read the bug mentioned as I've lost the email
> with it's number so I may just be talking out of my ass.

no, in fact you are the first one that comes up with a valid argument,
why games sometimes should go to stable almost immediately. sad, but
true...

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Ferris McCormick]

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

On Thu, 2007-05-03 at 13:11 +0200, Matthias Langer wrote:

> 
> ok, agreed, this is a valid point. so i would suggest, that maintainers
> of games where this argument applies, come to special agreements with
> the arch teams - or just file bugreports like this:
> 
> "
> although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like
> to have it stable real soon, as upstream has changed the network
> protocol. i have x86 and amd64 hardware available, and can confirm, that
> the game works nice there; so, if no one objects, i'm gonna mark
> lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like
> to have a shiny sparc keyword, but have no hardware to test. so it would
> be highly appreciated if someone from the sparc team can give the game a
> try.
> "
> 

I can't speak for all of sparc, of course, but generally we try to
accommodate requests when the package developers explain the situation.
In a case like Eternal Lands, it might turn out that the best solution
would be always to keep it as ~sparc, but that would have the same
effect in practice as a stable keyword, because anyone playing the game
on sparc would know what was going on (I would think).  The key here is
the bug report, and at that point the friendly sparc developers would
work with you. :)
  
> but committing straight to stable on arches where the package wasn't
> even tested is an absolute no-do for me.  
> 
> > DISCLAIMER: I've not read the bug mentioned as I've lost the email
> > with it's number so I may just be talking out of my ass.
> 
> no, in fact you are the first one that comes up with a valid argument,
> why games sometimes should go to stable almost immediately. sad, but
> true...
> 

Regards,
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Jorge Manuel B. S. Vicetto]

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

Hi.

José Luis Rivero (yoswink) wrote:
> Roy Marples wrote:
>>
>> I maintain and play a game called Eternal Lands. I'm a Council member,
>> but not part of the games team/herd.
>>
>> One of the problems games have with stable/unstable/testing/whatever
>> keywords is that upstream changes things that in any other application
>> just would not change. For example, the network protocol when talking
>> to servers. EL is very version specific and when a new client is
>> launched, around once every 6 months they change over right away. That
>> means our users need the game right away.
> 
> Thanks for the example, trust me if I tell you that we can understand
> the situation pretty well.
> 
>>
>> I used to commit EL straight to stable for this very reason, but now
>> after a few Gentoo QA people bitched EL will never ever have a stable
>> keyword. 
> 
> I'm nearly sure that you always (at least) compile and run the new
> version in your box before you sent it to stable, didn't you? So, at
> least, you are able to say that it works in your case.
> 
>> So instead I periodically have to let our users know how to
>> unmask EL just so they can play their game.
> 
> There are always ways to educate users about how to use portage properly.
> 
>> So no, in many cases NOT committing straight to stable CAN be
>> detrimental to our users if all they want is a games machine. You could
>> argue that they shouldn't be using Gentoo, but I would argue why should
>> we discriminate?
>>
> 
> Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or
> beryl users discriminated or they should be using something different to
> Gentoo? They only thing people have to do is use some ~arch branch
> packages, which isn't too difficult (in Gentoo).
> 

Agreed.
All Gentoo beryl users need to use ~arch. I don't think games are so
special that we must provide them on stable arch. Afertall, if games are
keyworded testing, users can add them to /etc/portage/packaage.keywords
if they run a stable system.

> This is how I see it:
> 
> Problem with keywording straight to stable is that arch teams are very
> zealous about our stable branch. We put a lot of time trying things to
> not fail in stable, and if an app is broken, we prefer to not force the
> users to compile and install another broken (or unknown to be broken)
> version and work to fix the current stable (patches or bumping) together
> with the maintainer.
> 
> But if you send things, that you can't try, to stable, the qa baby jesus
> will cry if it fails, because nobody has taken care of even compile it
> in the arch  :)
> 
> Games are not part of core system, so IMHO, use the ~arch branch to have
> the latest cool version to enjoy, could be a good way to go for those
> el1te gam3rs.
> 
> Thanks.
> 

I also don't agree with having an exception for the games herd. As
others have questioned, how are games more important than security
bumps? If we were considering exceptions, I would argue that allowing
the security team to mark packages as stable would make a lot more
sense, imho.

Anyway, the important point here for the council meeting is whether our
keywording policy is to be enforced or not, regardless of herd, or if /
how we want to have exceptions.


DISCLAIMER: I have no problems with games. I do like to play some, but I
see no problem with using package.keywords.

- --
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo-forums / Userrel / Proctors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOxXWcAWygvVEyAIRAgv5AJ9k5N/7Uri+rFCxOZllSp2NwmB67gCfepe3
A1Yj3pwuAI3oo/TODP7N79E=
=UYbe
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Alan McKinnon]

On Friday 04 May 2007, Jorge Manuel B. S. Vicetto wrote:
> I also don't agree with having an exception for the games herd. As
> others have questioned, how are games more important than security
> bumps? If we were considering exceptions, I would argue that allowing
> the security team to mark packages as stable would make a lot more
> sense, imho.

A quick 2c here from the peanut gallery:

Just leave the affected games always keyworded ~arch. The users of games 
are generally pretty savvy and they know how portage works. You might 
even find the majority of games players run ~arch boxes anyway so they 
will never notice that the game ebuild is not in stable

alan


-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Alec Warner]

Alan McKinnon wrote:
> On Friday 04 May 2007, Jorge Manuel B. S. Vicetto wrote:
>> I also don't agree with having an exception for the games herd. As
>> others have questioned, how are games more important than security
>> bumps? If we were considering exceptions, I would argue that allowing
>> the security team to mark packages as stable would make a lot more
>> sense, imho.

There has never been an exception for games.  There is however, no one
willing to beat games herd (and others) with a stick sufficiently often
that they stop.

I don't even see how this is a policy discussion at all as the policy is
more or less clear to me; is it unclear for others?  This is an
enforcement problem, no?

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Chris Gianelloni]

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

On Thu, 2007-05-03 at 12:15 +0200, "José Luis Rivero (yoswink)" wrote:
> Games are not part of core system, so IMHO, use the ~arch branch to have 
> the latest cool version to enjoy, could be a good way to go for those 
> el1te gam3rs.

We actively discourage users from using ~arch for stable, since it is,
well, more stable.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Chris Gianelloni]

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

On Fri, 2007-05-04 at 08:53 -0700, Alec Warner wrote:
> I don't even see how this is a policy discussion at all as the policy is
> more or less clear to me; is it unclear for others?  This is an
> enforcement problem, no?

No.  It *was* an enforcement problem.  The problem has been resolved
already.  There's really no need for the Council to speak on this.
Keyword policy applies to everyone.  In the cases of certain games, such
as Eternal Lands (thanks Roy!), we can make exceptions simply because of
the necessity.  That being said, there's nothing stopping games (or any
maintainer) from filing a stabilization bug *immediately* after putting
a package in the tree.  I've done it on games a few times and I've seen
it done on things like portage when a necessary fix needed to go out as
quickly as possible.

The point of policy is *not* to impede progress.  It is supposed to be
to provide our users the best quality distribution.  If policy gets in
the way of progress without gain for our users, then the policy needs to
be revisited.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

RE: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Karl Haines]

Lol, its funny that we must concern ourselves with the needs of ""el1te
gam3rs"", but I suppose its necessary.

Karl Haines

-----Original Message-----
From: Chris Gianelloni [mailto:wolf31o2@gentoo.org] 
Sent: Friday, May 04, 2007 2:13 PM
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

On Thu, 2007-05-03 at 12:15 +0200, "José Luis Rivero (yoswink)" wrote:
> Games are not part of core system, so IMHO, use the ~arch branch to have 
> the latest cool version to enjoy, could be a good way to go for those 
> el1te gam3rs.

We actively discourage users from using ~arch for stable, since it is,
well, more stable.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Ciaran McCreesh]

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

On Fri, 04 May 2007 15:36:51 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> The point of policy is *not* to impede progress.  It is supposed to be
> to provide our users the best quality distribution.  If policy gets in
> the way of progress without gain for our users, then the policy needs
> to be revisited.

And the point of enforcing policy and escalating problems is to prevent
rogue developers from breaking stable, screwing over users' systems and
then repeatedly refusing to show any sign that they've learned from
that and lots of other mistakes.

-- 
Ciaran McCreesh


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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Chris Gianelloni]

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

On Fri, 2007-05-04 at 20:43 +0100, Ciaran McCreesh wrote:
> On Fri, 04 May 2007 15:36:51 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > The point of policy is *not* to impede progress.  It is supposed to be
> > to provide our users the best quality distribution.  If policy gets in
> > the way of progress without gain for our users, then the policy needs
> > to be revisited.
> 
> And the point of enforcing policy and escalating problems is to prevent
> rogue developers from breaking stable, screwing over users' systems and
> then repeatedly refusing to show any sign that they've learned from
> that and lots of other mistakes.

What does enforcement have to do with the Council?  The Council
approves/enacts policy.  We don't do enforcement.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Roy Marples]

On Fri, 4 May 2007 14:37:21 -0500
"Karl Haines" <karl@franklincomputer.net> wrote:

> Lol, its funny that we must concern ourselves with the needs of
> ""el1te gam3rs"", but I suppose its necessary.

We concern ourselves with the needs of everyone, from our elite users,
to our crapola devs. There are, or should, be no favourites.

Hi Mom :D

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

[gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Ferris McCormick]

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

(I'll Try again, from correct email address)

On Thu, 2008-05-01 at 05:30 +0000, Mike Frysinger wrote:
> This is your monthly friendly reminder !  Same bat time (typically
> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
> (#gentoo-council @ irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.
> 
Just to summarize, for purposes of informing everyone of something I've
already requested.

Recently we retired 3 developers, the devrel project was not involved as
a group except for the lead, and apparently the developers did not know
anyone was looking at complaints filed against them.  I'd like Council
(1) to explain its role in this, if any, (2) explain why it permits such
actions in apparent violation of Gentoo's policy of openness, (3) and
since there seems to be some confusion (on my part at least) how to
interpret Council's role in any appeal IF (I don't really know) Council
played a part in the disciplinary action, please amend Council's
enabling document GLEP 39 to explain how Council handles appeals and
whether or not Council can take or direct disciplinary action in light
of this absolute requirement.

Since this is a general mailing list and some of you might not know what
I'm talking about, this is GLEP 39 and as such it helps define Gentoo
policy and procedure.
http://www.gentoo.org/proj/en/glep/glep-0039.html

 

> Keep in mind that every GLEP *re*submission to the council for review
> must first be sent to the gentoo-dev mailing list 7 days (minimum)
> before being submitted as an agenda item which itself occurs 7 days
> before the meeting.  Simply put, the gentoo-dev mailing list must be
> notified at least 14 days before the meeting itself.
> 
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Mart Raudsepp]

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

On N, 2008-05-01 at 05:30 +0000, Mike Frysinger wrote:
> This is your monthly friendly reminder !  Same bat time (typically
> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
> (#gentoo-council @ irc.freenode.net) !
> 
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

I would like to see the council to chat about two points, which are the
following:


1) ChangeLog entries and when one is a must-have. This especially in
relation to arch stabilizations.

2) The situation of keywording, stabilization or other bugs being
completely ignored by the arm, sh and s390 teams. Can something be done
to help in resolving this? Stabilizations do happen, but ignoring the
bugs, and whenever they are felt to be done, and no un-CC-ing happens -
usually with a 1 to 5 months of delay.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

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

Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

[Ciaran McCreesh]

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

On 01 May 2008 05:30:01
Mike Frysinger <vapier@gentoo.org> wrote:
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

I'd like a decision on the eight digits thing in PMS:

> No integer part of a version specification may contain more than eight
> digits.

It's been discussed on this list previously:

http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml

and on bugzilla:

https://bugs.gentoo.org/show_bug.cgi?id=188449

and I get the impression that there aren't any particularly strong
feelings either way. So can we get a Council ruling to either kill the
limit and strongly encourage people to fix their code, or keep the
limit and start enforcing it and fixing it in the tree via repoman etc?

-- 
Ciaran McCreesh

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

[gentoo-dev] Monthly Gentoo Council Reminder for May

[Mike Frysinger]

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council @ irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/