Ciaran McCreesh wrote:
| voting previleges
Again, why? They have not yet demonstrated their understanding of
complex technical issues. Voting should be restricted to people who
know what they're doing. Arch testers have not yet proven themselves.
Does that mean that all the Gentoo people who
Homer Parker wrote:
On Tue, 2005-09-13 at 04:14 +0100, Ciaran McCreesh wrote:
| voting previleges
Again, why? They have not yet demonstrated their understanding of
complex technical issues. Voting should be restricted to people who
know what they're doing. Arch testers have not yet proven
On Tue, 2005-09-13 at 01:13 +0100, Ciaran McCreesh wrote:
This list is automagically generated. It will be sent to the gentoo-dev
mailing list at irregular intervals until someone asks me to stop.
I know that this is automatically generated, but can we either change
the bug subjects or figure
13.9.2005, 13:39:10, Chris Gianelloni wrote:
I know that this is automatically generated, but can we either change
the bug subjects or figure out some way to add proposed categories to
these? I think changing the summary should suffice. For the ones with
categories, I can pretty much
Thierry Carrez wrote:
Nathan L. Adams wrote:
Mike Frysinger wrote:
right ... once a GLEP has been hammered out and approved, there isnt really
anything left for managers/council to do ... it's then up to whoever to get
it done ;)
They *could* do some 'creative re-org' a.k.a. remove some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Luca Barbato wrote:
| Simon Stelling wrote:
|
| Ciaran McCreesh wrote:
|
| On Mon, 12 Sep 2005 22:51:38 -0500 Brian Harring [EMAIL PROTECTED]
| wrote:
| | define exactly how one proves themself, and in what context.
|
| Repeated good contributions.
|
Hello,
this bug is from 2005-02-05. It was reported again (in this thread)
2005-02-10. I hit the same behavior 2005-09-08.
internal compiler error: segmentation fault during emerge Xorg
The bug is simply reproducible (emerge Xorg) at the same line of code.
The bug is still marked as NEW.
On Tue, Sep 13, 2005 at 03:24:38PM +0200, Frank Schafer wrote:
Hello,
this bug is from 2005-02-05. It was reported again (in this thread)
2005-02-10. I hit the same behavior 2005-09-08.
internal compiler error: segmentation fault during emerge Xorg
The bug is simply reproducible (emerge
Frank Schafer wrote:
Does someone know if it's worth a try with the vanilla and if vanilla
here means a really vanilla from kernel.org or if it's sufficient to get
the (too patched and thus not so vanilla) vanilla-sources.
vanilla-sources is not patched.
Please be kind with me regarding to
On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
are running vesafb-tng and have =1GB RAM then try
turning off vesafb-tng
Why ?
--
Cheers,
Ivan Yosifov.
--
gentoo-dev@gentoo.org mailing list
Ivan Yosifov wrote:
On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
are running vesafb-tng and have =1GB RAM then try
turning off vesafb-tng
Why ?
Actually, this shouldn't matter, as this only occurs with 64gb highmem. I only
mentioned it as this is the only random crasher
On Tue, 2005-09-13 at 17:01 +0300, Ivan Yosifov wrote:
On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
are running vesafb-tng and have =1GB RAM then try
turning off vesafb-tng
Why ?
Because of known bugs I'd guess?
--
Stand still, and let the rest of the universe move
On Tue, 2005-09-13 at 15:14 +0100, Daniel Drake wrote:
Ivan Yosifov wrote:
On Tue, 2005-09-13 at 14:52 +0100, Daniel Drake wrote:
are running vesafb-tng and have =1GB RAM then try
turning off vesafb-tng
Why ?
Actually, this shouldn't matter, as this only occurs with 64gb
On Tue, 2005-09-13 at 14:08 +0200, Jakub Moc wrote:
13.9.2005, 13:39:10, Chris Gianelloni wrote:
I know that this is automatically generated, but can we either change
the bug subjects or figure out some way to add proposed categories to
these? I think changing the summary should
On Tue, 13 Sep 2005 13:21:22 +0200 Simon Stelling [EMAIL PROTECTED]
wrote:
| Uhm... Different people have different skill levels. Some of this is
| down to natural ability, some of it is down to experience. Arch
| testers have not yet proven themselves. Full developers have (at
| least in
On Tue, 13 Sep 2005 00:39:31 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Each has a role, don't blur the AT definition into ebuild devs unless
| you've after eliminating AT positions (something I doubt going by
| your previous QA threads); if you're after that, state so please.
Not at all.
On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
The actual powers/role of devrel has always been a grey area.
No it hasn't, unless by 'gray area' you mean 'a few people who don't
like devrel claim it shouldn't be able to do anything because drobbins
set it up'
Recruitment,
Jon Portnoy wrote:
On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
The actual powers/role of devrel has always been a grey area.
No it hasn't, unless by 'gray area' you mean 'a few people who don't
like devrel claim it shouldn't be able to do anything because drobbins
Jon Portnoy wrote: [Tue Sep 13 2005, 11:22:32AM CDT]
The actual powers/role of devrel has always been a grey area.
No it hasn't, unless by 'gray area' you mean 'a few people who don't
like devrel claim it shouldn't be able to do anything because drobbins
set it up'
Recruitment,
On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy [EMAIL PROTECTED] wrote:
| On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
|
| The actual powers/role of devrel has always been a grey area.
|
| No it hasn't, unless by 'gray area' you mean 'a few people who don't
| like devrel
Lance Albertson wrote:
Ah, I see. To the best of my knowledge that just needs to be worked out
w/ the GLEP 15 people and infra. I dropped into -infra and they said
that there's space for it, but that bug # 98282 lists a couple of
contentious points. (Also, the gentooexperimental scripts
On Tuesday 13 September 2005 01:09 pm, Ciaran McCreesh wrote:
On Tue, 13 Sep 2005 12:22:32 -0400 Jon Portnoy [EMAIL PROTECTED] wrote:
| On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
| The actual powers/role of devrel has always been a grey area.
|
| No it hasn't, unless by
On Tue, 13 Sep 2005 07:39:10 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| I know that this is automatically generated, but can we either change
| the bug subjects or figure out some way to add proposed categories to
| these? I think changing the summary should suffice. For the ones
| with
13.9.2005, 20:31:30, Ciaran McCreesh wrote:
On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| Uhm, if the ebuild submitter does not choose a category, then we'd
| have to change the subject ourselves (and sometimes I'm not even
| remotely sure into which
On Tue, 13 Sep 2005 20:57:24 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
| Sure, I've already managed to delete all the bugspam this caused...
| *g*
Yeah, maintainer-wanted bug emails are a pain in the ass. How about we
turn off email sending for:
* I'm added to or removed from this capacity
*
13.9.2005, 21:08:43, Ciaran McCreesh wrote:
On Tue, 13 Sep 2005 20:57:24 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
| Sure, I've already managed to delete all the bugspam this caused...
| *g*
Yeah, maintainer-wanted bug emails are a pain in the ass. How about we
turn off email sending for:
On Tue, 2005-09-13 at 19:31 +0100, Ciaran McCreesh wrote:
On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| Uhm, if the ebuild submitter does not choose a category, then we'd
| have to change the subject ourselves (and sometimes I'm not even
| remotely sure
On Tue, 2005-09-13 at 19:53 +0100, Ciaran McCreesh wrote:
Okay, I've gone through and added in approximate categories to the
subjects where possible. A few I'm really not sure about, if anyone
wants to tinker feel free.
Excellent!
This is definitely appreciated. Thanks.
--
Chris Gianelloni
On Tue, 2005-09-13 at 20:08 +0100, Ciaran McCreesh wrote:
* Keywords field changes
Wouldn't you *want* to see these?
--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
On Tue, 13 Sep 2005 15:50:50 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Tue, 2005-09-13 at 20:08 +0100, Ciaran McCreesh wrote:
| * Keywords field changes
|
| Wouldn't you *want* to see these?
Mmm, I suppose maybe someone might try to sneak a REVIEWED add past us.
I've switched the
On Tuesday 13 September 2005 02:04 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
- in the case of developers who do not wish to follow accepted
policies/guidelines/etc even after being enlightened, devrel is notified
and takes appropriate corrective action
- in the case of a need to
Mike Frysinger wrote:
this side note is unrelated to the point being made and really belongs in the
previous discussions on the devrel list
besides, is this a bad thing ? i'd prefer to have devs settle crap themselves
than ever contacting devrel :P
It's very relevant, because it supports
On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
this side note is unrelated to the point being made and really belongs in
the previous discussions on the devrel list
besides, is this a bad thing ? i'd prefer to have devs settle crap
themselves than
On Tue, Sep 13, 2005 at 05:02:45PM -0400, Mike Frysinger wrote:
On Tuesday 13 September 2005 04:43 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
this side note is unrelated to the point being made and really belongs in
the previous discussions on the devrel list
besides, is this
Mike Frysinger wrote:
QA team identifies a misbehaving dev who refuses to change and then hands off
the name/relevant data to devrel ... QA team then is pretty much done with
the issue and the rest is up to devrel to resolve
I disagree that devrel should be involved. I think QA should hand
On Tuesday 13 September 2005 06:43 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
QA team identifies a misbehaving dev who refuses to change and then hands
off the name/relevant data to devrel ... QA team then is pretty much done
with the issue and the rest is up to devrel to resolve
I
On Tuesday 13 September 2005 12:22 pm, Jon Portnoy wrote:
On Tue, Sep 13, 2005 at 07:33:59AM -0500, Lance Albertson wrote:
The actual powers/role of devrel has always been a grey area.
No it hasn't, unless by 'gray area' you mean 'a few people who don't
like devrel claim it shouldn't be able
On Tuesday 13 September 2005 07:31 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
at any rate, you're proposing giving the control to the QA team which has
no guidelines or processes outlined, let alone the manpower. devrel has
all of these.
And devrel is the wrong group to handle it,
On Tuesday 13 September 2005 07:46 pm, Lance Albertson wrote:
Donnie Berkholz wrote:
Not really, because my opinion that devrel shouldn't be involved is not
automatically turned into reality (much to my regret). I'm trying to
supply evidence why this should stay between QA and infra.
at
Mike Frysinger wrote:
as avenj pointed out, current 'mission statement' of devrel says that they
handle the issue of actually revoking a dev's access
I thought this was written somewhere too, but I can't seem to find it
anywhere. Do you know where it says this?
It certainly says they're
On Tuesday 13 September 2005 07:59 pm, Donnie Berkholz wrote:
Mike Frysinger wrote:
as avenj pointed out, current 'mission statement' of devrel says that
they handle the issue of actually revoking a dev's access
I thought this was written somewhere too, but I can't seem to find it
Mike Frysinger wrote:
It certainly says they're responsible for adding and removing
developers, but I don't see anything about them being solely responsible
for revoking access.
no, nowhere does it say 'devrel is the only team which may revoke access',
but
it is the only team which says
On Tuesday 13 September 2005 08:22 pm, Lance Albertson wrote:
Mike Frysinger wrote:
It certainly says they're responsible for adding and removing
developers, but I don't see anything about them being solely responsible
for revoking access.
no, nowhere does it say 'devrel is the only team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
if you read this whole thread you'll find that it is a grey area with
different devrel people saying/thinking different things in terms of what
devrel's responsibilities are
It sounds like somebody needs to take a look at
On Tuesday 13 September 2005 10:21 pm, Nathan L. Adams wrote:
Mike Frysinger wrote:
if you read this whole thread you'll find that it is a grey area with
different devrel people saying/thinking different things in terms of what
devrel's responsibilities are
It sounds like somebody needs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
GLEP's are developed after the details are ironed out in public developer
forums ... their purpose isnt to fast track changes through the Gentoo
council to kill long threads
not saying that is what you meant, just making
On Tue, Sep 13, 2005 at 10:21:42PM -0400, Nathan L. Adams wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Frysinger wrote:
if you read this whole thread you'll find that it is a grey area with
different devrel people saying/thinking different things in terms of what
devrel's
Frank Schafer wrote:
I'm still on the kernel from the life-cd. The self compiled kernel has
the highmem option set to off (I have only 1GB). I'm on x86 Intel
Celeron M and have CHOST set to i686-pc-linux-gnu and CFLAGS=-O2
-march=pentium2
Um, why pentium2? The Celeron-M is the same core
Hello all,
The GNOME herd is now ready for 2.12.0 to be tested.
The gnome-2.12.0.ebuild should hit the mirrors shortly. ( just committed)
Please see this document for information on how to test:
http://dev.gentoo.org/~allanonjl/gnome/2.12.0/testing.instructions.txt
Thanks, and happy bug
On Tuesday 13 September 2005 5:22 pm, Lance Albertson wrote:
I would like there to be a clause that infra has the ability to at least
temporarily revoke access to have the ability to protect our servers if
something came up quickly. I've always made sure any permanent removals
go through
On Tuesday 13 September 2005 11:10 pm, Jon Portnoy wrote:
As far as devrel goes, call me a traditionalist but I think while infra
should be able to do emergency deactivations (and afaik nobody's ever
said they shouldn't) devrel should continue to be responsible for
disciplinary issues
Lance Albertson wrote:
snip
...
I tend to agree with Donnie on this partially. Devrel's main focus isn't
the QA of the tree, its dealing with developers. QA should have the
authority to limit access to the tree if someone isn't following the
guidelines properly. They are the ones with the
On Wed, Sep 14, 2005 at 12:06:13AM -0400, Curtis Napier wrote:
I'm not an ebuild dev so I may not know enough about this situation to
competantly comment on it but it seems to me that QA should have some
sort of limited ability to temporarily take away write access to the
tree until devrel
53 matches
Mail list logo
