[gentoo-dev] Monthly Gentoo Council Reminder for August

[gentoo-dev] Monthly Gentoo Council Reminder for August

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

[Mike Frysinger]

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

On Wednesday 01 August 2007, 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) !

as discussed on the gentoo-council list, it'll be postponed a week due to LWE 
(the last day of LWE:SF is the same day as the council meeting) ... as a 
reminder, be sure to visit LWE:SF this year to hump your council members as a 
number of us will be there
-mike

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

[gentoo-dev] Monthly Gentoo Council Reminder for August

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

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

[Sebastian Pipping]

Mike Frysinger 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 would love to see the GLEP on CPE names in metadata.xml discussed,
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35155.html

Any guidance on what I need to do to make it happen is very welcome.

Thanks,



Sebastian

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

[Denis Dupeyron]

On Sat, Aug 1, 2009 at 7:10 AM, Sebastian Pipping<webmaster@hartwork.org> wrote:
> I would love to see the GLEP on CPE names in metadata.xml discussed,
> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35155.html
>
> Any guidance on what I need to do to make it happen is very welcome.

Please read GLEP 1 [1], and more specifically the GLEP work flow. Your
GLEP needs to be submitted to and then accepted by the GLEP editors.
Once it is accepted it will be assigned a number and you can discuss
it on gento-dev@gentoo.org (announce it on
gentoo-dev-announce@gentoo.org with reply-to set to
gentoo-dev@gentoo.org). Once that is done and a consensus has been
reached you can submit your GLEP to the council for vote.

In your particular case I'd like to know what are the plans of the
other distributions. I would even think that they should be involved
in the discussion process. And what happens when packages don't
exactly overlap? Binary distros often use many sub-packages to work
around their lack of something like our USE flags, and also to avoid
forcing users to download a whole bunch of non-executable stuff when
the binaries were patched. This thing isn't as easy as your (short)
GLEP draft makes it look like.

Denis.

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

[gentoo-dev] Monthly Gentoo Council Reminder for August

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

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

[Matthew Marlowe]

> iWho knows, maybe its worth finding another bug database
> app, or even be crazy and write our own for a long term solution.
>

If we could get a license donated, my vote would be to switch to Atlassian 
Jira, http://www.atlassian.com/software/jira.   It seems to be gaining 
mindshare rather quickly, and the company I work for just shelled out $2,400 
because they liked it so much more than RT/Bugzilla. I believe it supports 
multiple DB backends, including all the usual suspects.  

MattM
-- 
Matthew Marlowe (mattm@gentoo.org)
 Yahoo IM: deploylinuxconsulting
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Monthly Gentoo Council Reminder for August

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

[Wernfried Haas]

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

Could you (or someone else) send out the agenda and a second reminder
a short while (e.g. 1-2 days) before the actual meeting. I'd very much
appreciate that, and i guess others may too.

cheers,
	Wernfried

PS: I know _i_ could volunteer as i already suggested it, but then we
want someone reliable to do this, don't we? ;-)

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

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

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

[Thierry Carrez]

Wernfried Haas wrote:
> Could you (or someone else) send out the agenda and a second reminder
> a short while (e.g. 1-2 days) before the actual meeting. I'd very much
> appreciate that, and i guess others may too.

The Council will meet on Thursday, August 17, 1900 UTC.
AFAICT agenda is at the moment empty.

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

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

[Stuart Herbert]

On 8/14/06, Thierry Carrez <koon@gentoo.org> wrote:
> The Council will meet on Thursday, August 17, 1900 UTC.
> AFAICT agenda is at the moment empty.

Here's something I'd like to see the council address.  We've just had
baselayout-1.12 go stable.  You might have missed this, because
there's no announcement about the release, and there's currently no
upgrade guide available on www.g.o.

I'm asking the Council to take steps to ensure that we don't stabilise
critical components like this in this manner _ever_ again.  Roy's
worked very hard to ensure that baselayout-1.12 is as good as it can
be at this time, but collectively as a team we should be ensuring that
our users have both advance warning (via GWN, -dev, forums at least)
and supporting documentation on www.g.o to help them migrate.

Many thanks,
Stu
-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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

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

Would like the Council to discuss the current state of Gentoo Bugzilla
[1] and anon CVS/SVN [2].

Thanks.


[1] http://bugs.gentoo.org/show_bug.cgi?id=128588
[2] http://bugs.gentoo.org/show_bug.cgi?id=103664

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

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

[Ned Ludd]

On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote:
> Mike Frysinger wrote:
> > This is your monthly friendly reminder !  Same bat time (typically the
> > 2nd Thursday once a month), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> 
> Would like the Council to discuss the current state of Gentoo Bugzilla
> [1] and anon CVS/SVN [2].

Please elaborate why you need the council to discuss 
ongoing active bugs that are in progress.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Ned Ludd wrote:
> On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote:
>> Mike Frysinger wrote:
>>> This is your monthly friendly reminder !  Same bat time (typically the
>>> 2nd Thursday once a month), same bat channel (#gentoo-council @
>>> irc.freenode.net) !
>> Would like the Council to discuss the current state of Gentoo Bugzilla
>> [1] and anon CVS/SVN [2].
> 
> Please elaborate why you need the council to discuss 
> ongoing active bugs that are in progress.
> 

I would also like to know why the council has to be involved since
you've never sent an email to infra specifically asking the same thing
first. Sure makes sense to me that you should ask the group involved
with the work first instead of going to the top.

But since I'm typing it now, I might as well answer it.

I finally got the hardware this week for bugs, and I've been working on
bringing those boxes online. If I'm lucky, I'll have them at least
booting on their own today.

The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn
guru. We want to ensure that we cover all our grounds in the setup so
that we don't make a system that's easily DoS'able. If anyone wants to
help out with that, please contact KingTaco as he's the contact for that
project right now.

Patience is indeed a virtue.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Ned Ludd]

On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote:
> Ned Ludd wrote:
> > On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote:
> >> Mike Frysinger wrote:
> >>> This is your monthly friendly reminder !  Same bat time (typically the
> >>> 2nd Thursday once a month), same bat channel (#gentoo-council @
> >>> irc.freenode.net) !
> >> Would like the Council to discuss the current state of Gentoo Bugzilla
> >> [1] and anon CVS/SVN [2].
> > 
> > Please elaborate why you need the council to discuss 
> > ongoing active bugs that are in progress.
> > 
> 
> I would also like to know why the council has to be involved since
> you've never sent an email to infra specifically asking the same thing
> first. Sure makes sense to me that you should ask the group involved
> with the work first instead of going to the top.
> 
> But since I'm typing it now, I might as well answer it.
> 
> I finally got the hardware this week for bugs, and I've been working on
> bringing those boxes online. 

And it's impressive hardware at a pretty kickass facility :)

> If I'm lucky, I'll have them at least
> booting on their own today.
> 
> The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn
> guru. We want to ensure that we cover all our grounds in the setup so
> that we don't make a system that's easily DoS'able. If anyone wants to
> help out with that, please contact KingTaco as he's the contact for that
> project right now.

It's just about ready afaik. We just want robbat2 to review the CVS 
setup and I probably need to drop a patch in the cvs pkg to disable 
compression. We probably also want Pylon to review the svn setup.

> Patience is indeed a virtue.

Indeed..

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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

Ned Ludd wrote:
> On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote:
>>>> Would like the Council to discuss the current state of Gentoo Bugzilla
>>>> [1] and anon CVS/SVN [2].
>>> Please elaborate why you need the council to discuss 
>>> ongoing active bugs that are in progress.

Progress? Erm... see below.

>> I would also like to know why the council has to be involved since
>> you've never sent an email to infra specifically asking the same thing
>> first. Sure makes sense to me that you should ask the group involved
>> with the work first instead of going to the top.

Because it's been broken for ages? Because I've asked the same on the
bug I've referred to multiple times, as did quite a few other people,
and the thing is still dead ~3 hours a day? (So uhm, the argument that
infra doesn't know about is _really_ moot.) Because users complain over
and over again? Because we are getting tons of duplicate bugs due to
bugzilla being non-responsive? Because it's wasting hours of my time
every day? Because if CVS was in the same state, you'd about have a
revolution by now?

>> The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn
>> guru. We want to ensure that we cover all our grounds in the setup so
>> that we don't make a system that's easily DoS'able. If anyone wants to
>> help out with that, please contact KingTaco as he's the contact for that
>> project right now.
> 
> It's just about ready afaik. We just want robbat2 to review the CVS 
> setup and I probably need to drop a patch in the cvs pkg to disable 
> compression. We probably also want Pylon to review the svn setup.

Good news, would be nice if you actually responded on the bug maybe? Or
send out some status report occasionally, since the bug's been open for
~1 year now?

>> Patience is indeed a virtue.
> 
> Indeed..

Sorry, having a critical facility broken for ~6 months right now =!
patience. It plain sucks.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

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

[Ned Ludd]

On Thu, 2006-08-03 at 16:07 +0200, Jakub Moc wrote:
> Ned Ludd wrote:
> > On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote:
> >>>> Would like the Council to discuss the current state of Gentoo Bugzilla
> >>>> [1] and anon CVS/SVN [2].
> >>> Please elaborate why you need the council to discuss 
> >>> ongoing active bugs that are in progress.
> 
> Progress? Erm... see below.
> 
> >> I would also like to know why the council has to be involved since
> >> you've never sent an email to infra specifically asking the same thing
> >> first. Sure makes sense to me that you should ask the group involved
> >> with the work first instead of going to the top.
> 
> Because it's been broken for ages? Because I've asked the same on the
> bug I've referred to multiple times, as did quite a few other people,
> and the thing is still dead ~3 hours a day? (So uhm, the argument that
> infra doesn't know about is _really_ moot.) Because users complain over
> and over again? Because we are getting tons of duplicate bugs due to
> bugzilla being non-responsive? 

Ok this is basically bitching. Trust me we all know the current state 
of things with bugzilla and it's not fun for anybody. I'm sure 
however if you practice a little patience I'm sure you will be 
quite pleased with the end result.

> Because it's wasting hours of my time
> every day? Because if CVS was in the same state, you'd about have a
> revolution by now?

I think you might be misunderstanding the role that the council plays. 
It's a body for technical matters that effect the mainly "the code". 
Daily matters of infrastructure are handled by our infra team naturally.
Funding for hardware is approved by the foundation.

> >> The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn
> >> guru. We want to ensure that we cover all our grounds in the setup so
> >> that we don't make a system that's easily DoS'able. If anyone wants to
> >> help out with that, please contact KingTaco as he's the contact for that
> >> project right now.
> > 
> > It's just about ready afaik. We just want robbat2 to review the CVS 
> > setup and I probably need to drop a patch in the cvs pkg to disable 
> > compression. We probably also want Pylon to review the svn setup.
> 
> Good news, would be nice if you actually responded on the bug maybe? Or
> send out some status report occasionally, since the bug's been open for
> ~1 year now?
> 
> >> Patience is indeed a virtue.
> > 
> > Indeed..
> 
> Sorry, having a critical facility broken for ~6 months right now =!
> patience. It plain sucks.

You must live in that town where spare hardware and administrators 
grow on the trees.

As it stands I do not see why this needs to be an agenda item for 
council discussions.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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

Ned Ludd wrote:
> On Thu, 2006-08-03 at 16:07 +0200, Jakub Moc wrote:
>> Because it's been broken for ages? Because I've asked the same on the
>> bug I've referred to multiple times, as did quite a few other people,
>> and the thing is still dead ~3 hours a day? (So uhm, the argument that
>> infra doesn't know about is _really_ moot.) Because users complain over
>> and over again? Because we are getting tons of duplicate bugs due to
>> bugzilla being non-responsive? 
> 
> Ok this is basically bitching. Trust me we all know the current state 
> of things with bugzilla and it's not fun for anybody. I'm sure 
> however if you practice a little patience I'm sure you will be 
> quite pleased with the end result.

A little patience? As in half year is not enough?

>> Because it's wasting hours of my time
>> every day? Because if CVS was in the same state, you'd about have a
>> revolution by now?
> 
> I think you might be misunderstanding the role that the council plays. 
> It's a body for technical matters that effect the mainly "the code". 
> Daily matters of infrastructure are handled by our infra team naturally.
> Funding for hardware is approved by the foundation.

Well, I think council should care about things that affect Gentoo as a
whole, and apparently that's not just me:

http://www.gentoo.org/proj/en/council/

<snip>
The elected Gentoo Council decides on global issues and policies that
affect multiple projects in Gentoo.
</snip>

Broken bugzilla affects every ebuild dev, affects GDP, affects bug
wranglers, affects anyone else who's using it to track outstanding
project issues. How is this continuous borkage not a global issue that
council should discuss?

> You must live in that town where spare hardware and administrators 
> grow on the trees.

No, not really. Just that I'd expect kinda more proactive approach than
the one demonstrated fex. in
http://bugs.gentoo.org/show_bug.cgi?id=128588#c29 (and a bit more
flexible approach to other alternatives, such as HW/hosting offers we've
received before) and that have been declined for various strange reasons.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

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

[Alec Warner]

> No, not really. Just that I'd expect kinda more proactive approach than
> the one demonstrated fex. in
> http://bugs.gentoo.org/show_bug.cgi?id=128588#c29 (and a bit more
> flexible approach to other alternatives, such as HW/hosting offers we've
> received before) and that have been declined for various strange reasons.

Linking to a bug where you make crazed comments about how bugs isn't
fixed!!!!1111oneone and that dammit someone should do something
now!!!1111 doesn't really help your case.

I bet if I was infra I'd be wondering what my options were since:

bugs is a pretty critical part of developing; AND
you can't just host it anywhere; AND
the hardware needed for it to perform is expensive; AND
they did not know what the problem was at first

As in, you don't just grab the first dual proc system that was offered
out of some guys basement to host bugs on.  You need a dedicated host
who will stick around and provide good support should something go
wrong.  You need expensive hardware ( I believe we got a blade server
with 3 blades in it, which is fscking expensive if you haven't priced
one out before ).  So once again, chill out.  They are working on it.

And yes bugs is slow and yes it sucks, but bitching about it doesn't
accomplish anything :x

-- 
gentoo-dev@gentoo.org mailing list

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

[Patrick Lauer]

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

On Thu, 2006-08-03 at 13:20 +0000, Alec Warner wrote:
> > No, not really. Just that I'd expect kinda more proactive approach than
> > the one demonstrated fex. in
> > http://bugs.gentoo.org/show_bug.cgi?id=128588#c29 (and a bit more
> > flexible approach to other alternatives, such as HW/hosting offers we've
> > received before) and that have been declined for various strange reasons.
> 
> Linking to a bug where you make crazed comments about how bugs isn't
> fixed!!!!1111oneone and that dammit someone should do something
> now!!!1111 doesn't really help your case.
> 
> I bet if I was infra I'd be wondering what my options were since:
> 
> bugs is a pretty critical part of developing; AND
yes
> you can't just host it anywhere; AND
it's not _that_ much hardware (and bandwidth) needed
> the hardware needed for it to perform is expensive; AND
for a single person yes. For a sponsor (or a group of sponsors) it may
be ok

> they did not know what the problem was at first
And even there it took some heavy prodding to get people to look at the problem.

After about half a year of waiting, with people we would consider
reliable offering pretty much everything from hosting to hardware, it's
hard to listen to the "be patient" mantra without thinking "omgwtfbbq,
it is _still_ not fixed?". Especially since bugs is considered an
important part of our infrastructure.

> As in, you don't just grab the first dual proc system that was offered
> out of some guys basement to host bugs on.
Agreed, but I'd say a webhoster with >1000 machines should know what
they are doing.

>   You need a dedicated host
> who will stick around and provide good support should something go
> wrong.
Only experience can tell you how they will respond, and even reliable
sponsors could get axed if their managment changes. We have almost no
hardware in Europe, that's a huge untapped ressource ...

>   You need expensive hardware ( I believe we got a blade server
> with 3 blades in it, which is fscking expensive if you haven't priced
> one out before ).  So once again, chill out.  They are working on it.
Dude, you don't need blades for it. Any "normal" server will do, two for DB and one for web frontend.
That we got blades is really nice and sweet, but if you check the
traffic and throughput of bugzilla (and then double or triple that for
future growth) you should still be able to do it easily.

(Note to our sponsors: you rock. Keep on rocking.)

Right now bugs is served from a 2,4Ghz P4 - that's roughly a normal
desktop box from last year. 

> And yes bugs is slow and yes it sucks, but bitching about it doesn't
> accomplish anything :x
It may cause discussion that may lead to accelerated problem solving :-)

hth,

Patrick
-- 
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] Monthly Gentoo Council Reminder for August

[Lance Albertson]

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

Patrick Lauer wrote:

> (Note to our sponsors: you rock. Keep on rocking.)
> 
> Right now bugs is served from a 2,4Ghz P4 - that's roughly a normal
> desktop box from last year. 

You have no concept of where the bottle neck is. The webserver hosting
the cgi part isn't being loaded hardly at all. The database server is a
pretty beefy box, and again, its not so much a specific hardware
limitation, just more a limitation on the design of bugzilla and its
ties to mysql. We're having to 'fix' the problem by getting a
master/slave mysql db server setup which the OSL didn't have setup at
the time. This is apparently the 'solution' upstream suggests which I
think is daft, but its what we have to do.

Please stop stating solutions to problems you don't fully understand or
think you understand. I'm getting tired of all this fud being said
around about stuff people don't totally understand. Hardware from
sponsors mean nothing if they aren't utilized in a proper manner with
planning and skills. And its not really a big bottle neck of people. You
try finding people who have a ton of free time, have excellent admin
skills, gives everyone on the team a 'good vibe' and seems trustworthy.
Its not as easy as you think it is. I'm in the process of bringing on a
guy I know personally which will help the load of things a lot. Plus, he
works with me, so I can kick him literally if he slacks :). (now if only
recruiters *cough*swift*cough* could work faster ;-) )

Anyways, I'm not going to rant on about this anymore. We're working on
the problem, and you just have to be patient.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Patrick Lauer]

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

On Thu, 2006-08-03 at 13:48 -0500, Lance Albertson wrote:
> Patrick Lauer wrote:
> 
> > (Note to our sponsors: you rock. Keep on rocking.)
> > 
> > Right now bugs is served from a 2,4Ghz P4 - that's roughly a normal
> > desktop box from last year. 
> 
> You have no concept of where the bottle neck is.
I have followed the discussions quite well. I think I'm quite aware of
the issues.

>  The webserver hosting
> the cgi part isn't being loaded hardly at all.
Yes, only problem is that bugzilla likes to consume larger amounts of
memory, and if I'm not mistaken it's a bad interaction from a OOM killer
(to avoid the webfrontend to die) causing stale locks (which should not
happen) that causes bugzie to fall over, ja?
(I've been told a simple testcase to demonstrate that, haven't tried
myself)

>  The database server is a
> pretty beefy box, and again, its not so much a specific hardware
> limitation, just more a limitation on the design of bugzilla and its
> ties to mysql. We're having to 'fix' the problem by getting a
> master/slave mysql db server setup which the OSL didn't have setup at
> the time. This is apparently the 'solution' upstream suggests which I
> think is daft, but its what we have to do.
... and one of the slowdowns was OSU being unable to get their DB cluster up and running within a reasonable timeframe. Fertilizer happens ...

> Please stop stating solutions to problems you don't fully understand or
> think you understand. I'm getting tired of all this fud being said
> around about stuff people don't totally understand.
I'm getting tired of being told "we can manage it", then having to wait
6 months to hear "almost there". We had a few people asking how they
could help, and the answer was roughly "we manage fine on our own, thank
you very much". Personally I don't mind much, but then you shouldn't
complain when people say "we could have done better" ...

>  Hardware from
> sponsors mean nothing if they aren't utilized in a proper manner with
> planning and skills. And its not really a big bottle neck of people. 
That sounds contradictory to me - it's not the people, it's the people?

> You
> try finding people who have a ton of free time, have excellent admin
> skills, gives everyone on the team a 'good vibe' and seems trustworthy.
For me it's easy, being a dev for more than, say, 3 months = trustworthy
Of course if you need to recruit from the outside the situation changes

> Its not as easy as you think it is.
Let me try and fail and I'll believe you ...

>  I'm in the process of bringing on a
> guy I know personally which will help the load of things a lot. Plus, he
> works with me, so I can kick him literally if he slacks :). (now if only
> recruiters *cough*swift*cough* could work faster ;-) )
Cool.

> Anyways, I'm not going to rant on about this anymore. We're working on
> the problem, and you just have to be patient.
Nooooooo :-) You said the bad words again! ;-)

I hope you get everything fixed soonish, let's hope Murphy's law doesn't
try to apply here ...


Patrick
-- 
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] Monthly Gentoo Council Reminder for August

[Jochen Maes]

> On Thu, 2006-08-03 at 13:48 -0500, Lance Albertson wrote:
>> Patrick Lauer wrote:
>>
>> > (Note to our sponsors: you rock. Keep on rocking.)
>> >
>> > Right now bugs is served from a 2,4Ghz P4 - that's roughly a normal
>> > desktop box from last year.
>>
>> You have no concept of where the bottle neck is.
> I have followed the discussions quite well. I think I'm quite aware of
> the issues.
>
>>  The webserver hosting
>> the cgi part isn't being loaded hardly at all.
> Yes, only problem is that bugzilla likes to consume larger amounts of
> memory, and if I'm not mistaken it's a bad interaction from a OOM killer
> (to avoid the webfrontend to die) causing stale locks (which should not
> happen) that causes bugzie to fall over, ja?
> (I've been told a simple testcase to demonstrate that, haven't tried
> myself)
>
>>  The database server is a
>> pretty beefy box, and again, its not so much a specific hardware
>> limitation, just more a limitation on the design of bugzilla and its
>> ties to mysql. We're having to 'fix' the problem by getting a
>> master/slave mysql db server setup which the OSL didn't have setup at
>> the time. This is apparently the 'solution' upstream suggests which I
>> think is daft, but its what we have to do.
> ... and one of the slowdowns was OSU being unable to get their DB cluster
> up and running within a reasonable timeframe. Fertilizer happens ...
>
>> Please stop stating solutions to problems you don't fully understand or
>> think you understand. I'm getting tired of all this fud being said
>> around about stuff people don't totally understand.
> I'm getting tired of being told "we can manage it", then having to wait
> 6 months to hear "almost there". We had a few people asking how they
> could help, and the answer was roughly "we manage fine on our own, thank
> you very much". Personally I don't mind much, but then you shouldn't
> complain when people say "we could have done better" ...
>
>>  Hardware from
>> sponsors mean nothing if they aren't utilized in a proper manner with
>> planning and skills. And its not really a big bottle neck of people.
> That sounds contradictory to me - it's not the people, it's the people?
>
>> You
>> try finding people who have a ton of free time, have excellent admin
>> skills, gives everyone on the team a 'good vibe' and seems trustworthy.
> For me it's easy, being a dev for more than, say, 3 months = trustworthy
> Of course if you need to recruit from the outside the situation changes

hahaha this is funny coming from you...

>
>> Its not as easy as you think it is.
> Let me try and fail and I'll believe you ...
>
>>  I'm in the process of bringing on a
>> guy I know personally which will help the load of things a lot. Plus, he
>> works with me, so I can kick him literally if he slacks :). (now if only
>> recruiters *cough*swift*cough* could work faster ;-) )
> Cool.
>
>> Anyways, I'm not going to rant on about this anymore. We're working on
>> the problem, and you just have to be patient.
> Nooooooo :-) You said the bad words again! ;-)
>
> I hope you get everything fixed soonish, let's hope Murphy's law doesn't
> try to apply here ...
>
>
> Patrick
> --
> Stand still, and let the rest of the universe move
>


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Bainbridge]

Hi,

On 03/08/06, Lance Albertson <ramereth@gentoo.org> wrote:
> You have no concept of where the bottle neck is. The webserver hosting
> the cgi part isn't being loaded hardly at all. The database server is a
> pretty beefy box, and again, its not so much a specific hardware
> limitation, just more a limitation on the design of bugzilla and its
> ties to mysql. We're having to 'fix' the problem by getting a
> master/slave mysql db server setup which the OSL didn't have setup at
> the time. This is apparently the 'solution' upstream suggests which I
> think is daft, but its what we have to do.

I'm curious what the problem is with bugzilla and it's db
interactions? You're suggesting a specific issue rather than general
db performance issues like fs, io scheduling, raid1, hyperthreads,
etc.?
-- 
gentoo-dev@gentoo.org mailing list

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

[kashani]

Chris Bainbridge wrote:
> I'm curious what the problem is with bugzilla and it's db
> interactions? You're suggesting a specific issue rather than general
> db performance issues like fs, io scheduling, raid1, hyperthreads,
> etc.?

	It's most likely related to Bugzilla using MyISAM tables by default 
which is fine in a small environment. However as concurrency grows along 
with table size those full table locks begin to cause issues. 
Additionally most www-apps are not known for their well thought out db 
schema. Performance of the underlying hardware plays a part, but can be 
overshadowed pretty quickly by query and table inefficiencies.

	The usual fix without touching the internals of the software is doing 
master/slave replication and allowing the selects to happen on the slave 
and writes on the master. However you would need to change most of the 
queries to point to the slave server which is usually not trivial. It 
sounds like this is the path the Infra team is pursuing.

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

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

[Lance Albertson]

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

kashani wrote:
> Chris Bainbridge wrote:
>> I'm curious what the problem is with bugzilla and it's db
>> interactions? You're suggesting a specific issue rather than general
>> db performance issues like fs, io scheduling, raid1, hyperthreads,
>> etc.?
> 
>     It's most likely related to Bugzilla using MyISAM tables by default
> which is fine in a small environment. However as concurrency grows along
> with table size those full table locks begin to cause issues.
> Additionally most www-apps are not known for their well thought out db
> schema. Performance of the underlying hardware plays a part, but can be
> overshadowed pretty quickly by query and table inefficiencies.
> 
>     The usual fix without touching the internals of the software is
> doing master/slave replication and allowing the selects to happen on the
> slave and writes on the master. However you would need to change most of
> the queries to point to the slave server which is usually not trivial.
> It sounds like this is the path the Infra team is pursuing.

1++

You got it right :-)

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Simon Stelling]

Lance Albertson wrote:
> kashani wrote:
>> Chris Bainbridge wrote:
>>> I'm curious what the problem is with bugzilla and it's db
>>> interactions? You're suggesting a specific issue rather than general
>>> db performance issues like fs, io scheduling, raid1, hyperthreads,
>>> etc.?
>>     It's most likely related to Bugzilla using MyISAM tables by default
>> which is fine in a small environment. However as concurrency grows along
>> with table size those full table locks begin to cause issues.
>> Additionally most www-apps are not known for their well thought out db
>> schema. Performance of the underlying hardware plays a part, but can be
>> overshadowed pretty quickly by query and table inefficiencies.
>>
>>     The usual fix without touching the internals of the software is
>> doing master/slave replication and allowing the selects to happen on the
>> slave and writes on the master. However you would need to change most of
>> the queries to point to the slave server which is usually not trivial.
>> It sounds like this is the path the Infra team is pursuing.

Thanks a lot for this explanation.

> 1++
> 
> You got it right :-)

I'm not out to blame anybody, but if infra had communicated what the problem 
exactly is once they found it out, you wouldn't have ended up with all those 
"I'm sick and tired of your "we're working on it"". Asking people for patience 
is easy, but it's hard to swallow when you don't understand what the problem is 
at all.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Simon Stelling wrote:

> 
> I'm not out to blame anybody, but if infra had communicated what the
> problem exactly is once they found it out, you wouldn't have ended up
> with all those "I'm sick and tired of your "we're working on it"".
> Asking people for patience is easy, but it's hard to swallow when you
> don't understand what the problem is at all.
> 

I'm pretty sure this has been explained in the bug, IRC conversation,
emails, countless times. It may not have been as summarized as he put
it, but I know we mentioned the table locking issues at some point
somewhere. I haven't looked at the bug, so you can prove me wrong. I
thought we had explained those issues somewhere (maybe -core?).

But yeah, I totally agree.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Lance Albertson]

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

Chris Bainbridge wrote:
> Hi,
> 
> On 03/08/06, Lance Albertson <ramereth@gentoo.org> wrote:
>> You have no concept of where the bottle neck is. The webserver hosting
>> the cgi part isn't being loaded hardly at all. The database server is a
>> pretty beefy box, and again, its not so much a specific hardware
>> limitation, just more a limitation on the design of bugzilla and its
>> ties to mysql. We're having to 'fix' the problem by getting a
>> master/slave mysql db server setup which the OSL didn't have setup at
>> the time. This is apparently the 'solution' upstream suggests which I
>> think is daft, but its what we have to do.
> 
> I'm curious what the problem is with bugzilla and it's db
> interactions? You're suggesting a specific issue rather than general
> db performance issues like fs, io scheduling, raid1, hyperthreads,
> etc.?

Mostly dealing with table locking and how bugzilla handles most of its
queries. If you want more details, look for r2d2, Kingtaco, or jforman
(in that order). Another issue was backups were locking up all the
tables, so for a matter of an hour or more every day, bugs was just
useless because of that. Upstream's 'solution' was to use a db cluster
and make the backup on the read-only side. Anyways, I personally don't
know a lot of the details, but feel free to ask those people mentioned
above.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Jochen Maes]

> On Thu, 2006-08-03 at 13:20 +0000, Alec Warner wrote:
>> > No, not really. Just that I'd expect kinda more proactive approach
>> than
>> > the one demonstrated fex. in
>> > http://bugs.gentoo.org/show_bug.cgi?id=128588#c29 (and a bit more
>> > flexible approach to other alternatives, such as HW/hosting offers
>> we've
>> > received before) and that have been declined for various strange
>> reasons.
>>
>> Linking to a bug where you make crazed comments about how bugs isn't
>> fixed!!!!1111oneone and that dammit someone should do something
>> now!!!1111 doesn't really help your case.
>>
>> I bet if I was infra I'd be wondering what my options were since:
>>
>> bugs is a pretty critical part of developing; AND
> yes
>> you can't just host it anywhere; AND
> it's not _that_ much hardware (and bandwidth) needed
>> the hardware needed for it to perform is expensive; AND
> for a single person yes. For a sponsor (or a group of sponsors) it may
> be ok
>
>> they did not know what the problem was at first
> And even there it took some heavy prodding to get people to look at the
> problem.
>
> After about half a year of waiting, with people we would consider
> reliable offering pretty much everything from hosting to hardware, it's
> hard to listen to the "be patient" mantra without thinking "omgwtfbbq,
> it is _still_ not fixed?". Especially since bugs is considered an
> important part of our infrastructure.
>
>> As in, you don't just grab the first dual proc system that was offered
>> out of some guys basement to host bugs on.
> Agreed, but I'd say a webhoster with >1000 machines should know what
> they are doing.
>
>>   You need a dedicated host
>> who will stick around and provide good support should something go
>> wrong.
> Only experience can tell you how they will respond, and even reliable
> sponsors could get axed if their managment changes. We have almost no
> hardware in Europe, that's a huge untapped ressource ...
>
>>   You need expensive hardware ( I believe we got a blade server
>> with 3 blades in it, which is fscking expensive if you haven't priced
>> one out before ).  So once again, chill out.  They are working on it.
> Dude, you don't need blades for it. Any "normal" server will do, two for
> DB and one for web frontend.
I hope you know what you are talking about and if you use 2 db's with one
database (i think you mean a sort of loadbalancing/clustering) you
practicly need double mem +10% of the size of you database...

> That we got blades is really nice and sweet, but if you check the
> traffic and throughput of bugzilla (and then double or triple that for
> future growth) you should still be able to do it easily.
>
> (Note to our sponsors: you rock. Keep on rocking.)
>
> Right now bugs is served from a 2,4Ghz P4 - that's roughly a normal
> desktop box from last year.
>
>> And yes bugs is slow and yes it sucks, but bitching about it doesn't
>> accomplish anything :x
> It may cause discussion that may lead to accelerated problem solving :-)
>
> hth,
>
> Patrick
> --
> Stand still, and let the rest of the universe move
>


-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Alec Warner wrote:

> I bet if I was infra I'd be wondering what my options were since:
> 
> bugs is a pretty critical part of developing; AND
> you can't just host it anywhere; AND
> the hardware needed for it to perform is expensive; AND
> they did not know what the problem was at first

Yes, its been hard to find a place that I feel totally comfortable with
moving such a service. The service at the OSL is hard to beat, but
they're loaded enough with other projects as it is. I'm hoping that
moving this will help their load as well.

> And yes bugs is slow and yes it sucks, but bitching about it doesn't
> accomplish anything :x

Exactly :-) How would you feel if I nagged you every other day about why
cvs hasn't been migrated, and that I'm bringing the council into it
because you're not fast enough and being ignorant for help? I think you
know how I'm feeling now then. I fail to see how the constant nagging
helps the situation. The logic escapes me. There are more constructive
ways of finding out the status of a problem/solution.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Ciaran McCreesh]

On Thu, 03 Aug 2006 13:51:55 -0500 Lance Albertson
<ramereth@gentoo.org> wrote:
| There are more constructive ways of finding out the status of a
| problem/solution.

Actually, with that in mind I think the council could be of help here...
The bugs slowdown *is* a serious problem, and Jakub's failing miserably
at getting it addressed properly. Perhaps the council could suggest a
more reasonable way of handling things -- for example, how about
requesting that certain projects (ones that are important but not
providing what developers or users would like) deliver status reports
to each meeting? That would satisfy the requests for information, and
it would spare infra from the constant puerile whining they're
receiving...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

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

[Lance Albertson]

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

Ciaran McCreesh wrote:
> On Thu, 03 Aug 2006 13:51:55 -0500 Lance Albertson
> <ramereth@gentoo.org> wrote:
> | There are more constructive ways of finding out the status of a
> | problem/solution.
> 
> Actually, with that in mind I think the council could be of help here...
> The bugs slowdown *is* a serious problem, and Jakub's failing miserably
> at getting it addressed properly. Perhaps the council could suggest a
> more reasonable way of handling things -- for example, how about
> requesting that certain projects (ones that are important but not
> providing what developers or users would like) deliver status reports
> to each meeting? That would satisfy the requests for information, and
> it would spare infra from the constant puerile whining they're
> receiving...
> 

I don't see a problem with doing something like that if its within
reason. I know this has made infra look terrible with how long its been
drawn out. Its been a failure on many different levels in the chain. I
admit that I'm not happy about it either and feel rather embarrassed
about it.

I was planning on eventually sending an email asking the devs what they
want so we (infra) have a better idea. Sometimes its hard to get a feel
for what developers need without them directly contacting us. Anyways,
thats for another time (hopefully soon).

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Jochen Maes]

> On Thu, 03 Aug 2006 13:51:55 -0500 Lance Albertson
> <ramereth@gentoo.org> wrote:
> | There are more constructive ways of finding out the status of a
> | problem/solution.
>
> Actually, with that in mind I think the council could be of help here...
> The bugs slowdown *is* a serious problem, and Jakub's failing miserably
> at getting it addressed properly. Perhaps the council could suggest a
> more reasonable way of handling things -- for example, how about
> requesting that certain projects (ones that are important but not
> providing what developers or users would like) deliver status reports
> to each meeting? That would satisfy the requests for information, and
> it would spare infra from the constant puerile whining they're
> receiving...
this is a very good idea. It happens in most companies like that to :-)
>
> --
> Ciaran McCreesh
> Mail            : ciaran dot mccreesh at blueyonder.co.uk
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


-- 
gentoo-dev@gentoo.org mailing list

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

[Simon Stelling]

Jakub Moc wrote:
> Broken bugzilla affects every ebuild dev, affects GDP, affects bug
> wranglers, affects anyone else who's using it to track outstanding
> project issues. How is this continuous borkage not a global issue that
> council should discuss?

What is there to discuss? Do you expect them to say 'bugzilla shall be fix0rd!'? 
What would that change in reality? I, (and I guess so does solar) fail to see 
what the council could effectively do in regard to this matter. You should 
probably elaborate on that.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

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

[Patrick Lauer]

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

On Thu, 2006-08-03 at 19:03 +0200, Simon Stelling wrote:
> Jakub Moc wrote:
> > Broken bugzilla affects every ebuild dev, affects GDP, affects bug
> > wranglers, affects anyone else who's using it to track outstanding
> > project issues. How is this continuous borkage not a global issue that
> > council should discuss?
> 
> What is there to discuss? Do you expect them to say 'bugzilla shall be fix0rd!'? 
They could (in theory) demand that infra changes policies, i.e. active
recruiting to reduce bottlenecks or open demands for hardware. I think
it wouldn't help much though ...

> What would that change in reality? I, (and I guess so does solar) fail to see 
> what the council could effectively do in regard to this matter. You should 
> probably elaborate on that.
I guess the question is "What can we do when a project misbehaves and
our efforts to help are being denied?" (Please excuse the offensive
formulation, but that is afaict roughly what jakub and others
communicate when they wish to summon the council).

Any ideas how to improve communication appreciated :-)

hth,
Patrick 
-- 
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] Monthly Gentoo Council Reminder for August

[Lance Albertson]

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

Jakub Moc wrote:

>>> I would also like to know why the council has to be involved since
>>> you've never sent an email to infra specifically asking the same thing
>>> first. Sure makes sense to me that you should ask the group involved
>>> with the work first instead of going to the top.
> 
> Because it's been broken for ages? Because I've asked the same on the
> bug I've referred to multiple times, as did quite a few other people,
> and the thing is still dead ~3 hours a day? (So uhm, the argument that
> infra doesn't know about is _really_ moot.) Because users complain over
> and over again? Because we are getting tons of duplicate bugs due to
> bugzilla being non-responsive? Because it's wasting hours of my time
> every day? Because if CVS was in the same state, you'd about have a
> revolution by now?

There's a difference between "do you know its broke?" and "how is the
progress going?". I understood your email as "how is the progress
going?" as such, I did not see any recent comment made on the bug, nor
an email sent to us asking how the progress was going. I know you view
this as "I don't see it fixed, so that's not progress", but if you don't
think the hard work of the GNi folks of setting up some nice hardware
for this as part of the progress, then I'm sorry.

Anyways, if you would like, I can send you an update to the bug every
week until it gets completed. My guess (sparing any huge hurdles), is
that we can have the new bugs up by the end of this month. That's
including setting up the software, and testing it to make sure that the
issues that's been occurring have been addressed.

Cheers-

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


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

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

[Jakub Moc]

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

Lance Albertson wrote:
> Anyways, if you would like, I can send you an update to the bug every
> week until it gets completed. 

I'd just love to see this fixed and working, first of all... ;)

> My guess (sparing any huge hurdles), is
> that we can have the new bugs up by the end of this month. That's
> including setting up the software, and testing it to make sure that the
> issues that's been occurring have been addressed.

Wonderful.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

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

[Curtis Napier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Ned Ludd wrote:
> On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote:
>> Ned Ludd wrote:
>>> On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote:
>>>> Mike Frysinger wrote:
>>>>> This is your monthly friendly reminder !  Same bat time (typically the
>>>>> 2nd Thursday once a month), same bat channel (#gentoo-council @
>>>>> irc.freenode.net) !
>>>> Would like the Council to discuss the current state of Gentoo Bugzilla
>>>> [1] and anon CVS/SVN [2].
>>> Please elaborate why you need the council to discuss 
>>> ongoing active bugs that are in progress.
>>>
>> I would also like to know why the council has to be involved since
>> you've never sent an email to infra specifically asking the same thing
>> first. Sure makes sense to me that you should ask the group involved
>> with the work first instead of going to the top.
>>
>> But since I'm typing it now, I might as well answer it.
>>
>> I finally got the hardware this week for bugs, and I've been working on
>> bringing those boxes online. 
> 
> And it's impressive hardware at a pretty kickass facility :)
> 

Yes indeed it is impressive hardware at a pretty kickass facility :)

I got to chat with the CEO of the company that donated that equipment
and the wait was *more* than worth it. Once it's up and running our
bugzilla will be rock solid and fast fast fast fast fast for years to come.

Web front end:

1 x IBM HS20's
Dual 3.2GHz XEON 2MB Cache
2048 DDR2 ECC RAM
Dual 73GB SCSI 320 HDD

Database:

2 x IBM HS20's
Dual 3.2GHz XEON 2MB Cache
4096 DDR2 ECC RAM
Dual 73GB SCSI 320 HDD
Qlogic 4Gb/s Fiber controller
10GB SAN LUN


They donate a lot of other equipment to us as well. Thanks goes to
http://365main.com


>> If I'm lucky, I'll have them at least
>> booting on their own today.
>>
>> The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn
>> guru. We want to ensure that we cover all our grounds in the setup so
>> that we don't make a system that's easily DoS'able. If anyone wants to
>> help out with that, please contact KingTaco as he's the contact for that
>> project right now.
> 
> It's just about ready afaik. We just want robbat2 to review the CVS 
> setup and I probably need to drop a patch in the cvs pkg to disable 
> compression. We probably also want Pylon to review the svn setup.
> 

Very cool. Nice work, thanks.


>> Patience is indeed a virtue.
> 
> Indeed..
> 

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

iQEVAwUBRNML6Eb8Q0uRCeTQAQFnFgf/Rhtr5ttGP9x0BvZVTGHCAMrcWYveC4qK
h2TsARRcAMhSqfQi3VOkLSeTN0suFuJxFu0ha8NfxvTYY3g0R5+/2Rin9UHE1jm6
y1EJr/TB1v47YAVidG32Ktac9zLafDCX6mudX3OxPR2JRhjC3PeXLm3NWtyA26FD
tOEPyF98SPSawlqEAlbiJMA4GS9uaxKqy9eGtfR61gyEXRarn2RqbOv+Ceb1Sh/t
1tjzRv5lOx/Pr46WKvqGR4RzjmvY7drWdZMzanPcIZKUsdxPnjIdF+2hMfFGd/qf
dXaH/UoHjM0XTTVULF4vmxB10SQ9yEA0NVlvpK1wUmjCNy2ZA4huYw==
=s4RE
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Curtis Napier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Curtis Napier wrote:
> 
> Yes indeed it is impressive hardware at a pretty kickass facility :)
> 
> I got to chat with the CEO of the company that donated that equipment
> and the wait was *more* than worth it. Once it's up and running our
> bugzilla will be rock solid and fast fast fast fast fast for years to come.
> 
> Web front end:
> 
> 1 x IBM HS20's
> Dual 3.2GHz XEON 2MB Cache
> 2048 DDR2 ECC RAM
> Dual 73GB SCSI 320 HDD
> 
> Database:
> 
> 2 x IBM HS20's
> Dual 3.2GHz XEON 2MB Cache
> 4096 DDR2 ECC RAM
> Dual 73GB SCSI 320 HDD
> Qlogic 4Gb/s Fiber controller
> 10GB SAN LUN
> 
> 
> They donate a lot of other equipment to us as well. Thanks goes to
> http://365main.com
> 

Correction.

http://www.gni.com is the company doing the donating. 365main is the
building where the boxes are located.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBRNMOVUb8Q0uRCeTQAQH5FAgAvQjW9qzwk0tukJNSGZz/ZEKORZgmCSPN
CdUtHmkdgagRCNyMOOQHtoW2jnqT7qqmlOKownuqA9JOnYt9Ks59g5Amu1mqfdp6
KaG5Gk2L7OCcJMBOR9Qb78O9WRWFjnD2c/JRHeT3OC3DAJ/C+M0cO3b1cQHLcVWK
DbiocdmU0Mine7fA6RcNseKxr0686yVRsiOKrZhB1Fc4Da2gUvwMBGX85bKlfybk
2XXzjvK5nroj2LOi1OPeEXiS/F5gEx0E6YCrlIAiHg/Zlw5E6Lj2iivv11AjNs2k
j8AcBRvE9NXwA2Ougvle8AeYdySytmDnT0IljKUlHw32wkd6xk8XPQ==
=kJ5x
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Joshua Jackson]

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

Lance Albertson wrote:
> Curtis Napier wrote:
>
>> I got to chat with the CEO of the company that donated that equipment
>> and the wait was *more* than worth it. Once it's up and running our
>> bugzilla will be rock solid and fast fast fast fast fast for years to
come.
>
> Well, as I stated before. Having nice hardware will help a lot, but if
> we could get upstream bugzilla folks to fix some of these issues instead
> of us having to resort to a clustered database structure would be the
> better solution in the long run. A fast db cluster/web server means
> nothing if the database structure behind the app isn't done properly. It
> might be worth it for someone to maybe look at the problem in the code
> and see if we can patch it from our end and then submit those patches
> upstream. That approach generally works better. But I fear that the
> change needed to be done on it might involve so much change/work, it may
> not be worth it. Who knows, maybe its worth finding another bug database
> app, or even be crazy and write our own for a long term solution.
>
> Cheers-
>
Here's the question, gnome's bugzilla has over twice as many bugs as
we have, is quite speedy and doesn't seem to suffer from the OOM
killers that our bugzilla has. So what's the difference? Did gnome
just toss hardware at the problem to make it go away or have they done
something to make bugzilla work for them?

I think throwing hardware at the problem is the wrong approach in this
case, as its just delaying the problem that has made the new hardware
seem like the solution...which will no doubt creep up again.

Don't get me wrong, the donation of hardware from gni is greatly
appreciated. I'd just to see that we try and see why we have the
problem in the first place as well. As I'm sure that this problem will
creep up again
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE021uSENan+PfizARAifIAKCQ1g0sVRxvAbpm1khTCLfw9KxOTgCcD1lo
6Arc6MGKDoqRTfZWgvWR1fQ=
=5gzO
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

> 
> Here's the question, gnome's bugzilla has over twice as many bugs as
> we have, is quite speedy and doesn't seem to suffer from the OOM
> killers that our bugzilla has. So what's the difference? Did gnome
> just toss hardware at the problem to make it go away or have they done
> something to make bugzilla work for them?
> 
> I think throwing hardware at the problem is the wrong approach in this
> case, as its just delaying the problem that has made the new hardware
> seem like the solution...which will no doubt creep up again.
> 

Because it's not just "more hardware" it's "search queries execute on 
read-only slaves and write queries execute on the master" which is a 
design change from how things are done now.  If you give bugs a massive 
search query it can lock a bunch of tables in the current system, which 
means all those people who are trying to commit stuff to bugs will 
probably sit waiting for the massive search query to finish ;)  Now 
multiply by a few times since tons of people use our bugzilla and you 
can imagine this happening quite often.

In the new system the massive search query will run on the slave system, 
and it won't affect people making changes; hoewever there may be soem 
delay between data replication from the master to the slave(s), but that 
would be implementation dependent (depends on what you use to replicate).
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Doty]

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

Alec Warner wrote:
> In the new system the massive search query will run on the slave system,
> and it won't affect people making changes; hoewever there may be soem
> delay between data replication from the master to the slave(s), but that
> would be implementation dependent (depends on what you use to replicate).
We're using whatever mysql feature is default.  From everything I've
read the replication is well under a minute at worst.

- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRNOeoYBrouQZ9K4FAQLfzAP+IsgLEraKrzb0lEwVcBEaM/jTOJYsmsRF
tlNGSzUXN1LxwNpYr8Q1qrWcb9rIT8+CzMp+upc9xtXy3a7v28a2jGkq6dznx+Bu
QvHI7hRF3vM/47fZIlkMuIDoYmJgPKWCzYvwLL/BZeKOGHrnYZGYtFFk62SCesfm
dt52GndtEio=
=rxS8
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[kashani]

Joshua Jackson wrote:
> Here's the question, gnome's bugzilla has over twice as many bugs as
> we have, is quite speedy and doesn't seem to suffer from the OOM
> killers that our bugzilla has. So what's the difference? Did gnome
> just toss hardware at the problem to make it go away or have they done
> something to make bugzilla work for them?
> 
> I think throwing hardware at the problem is the wrong approach in this
> case, as its just delaying the problem that has made the new hardware
> seem like the solution...which will no doubt creep up again.
> 
> Don't get me wrong, the donation of hardware from gni is greatly
> appreciated. I'd just to see that we try and see why we have the
> problem in the first place as well. As I'm sure that this problem will
> creep up again

	Another technique is to change high transaction tables to Innodb table 
format. Innodb is going to be roughly 30% slower than MyISAM for selects 
and take up much more space on disk approx 3-5x larger. However it has 
row locking which solves the contention issue. A good example of mixed 
table types is actually Mediawiki which uses Memory for hitcounters, 
Innodb for pages and revisions, and MyISAM for everything else.

	Bugzilla has 50 tables in its schema, but converting bugs and 
bugs_activity to Innodb might cause more problems than it solves. 
Normally a decision to change tables format is accompanied by some 
normalization of your tables and changing queries to get the best 
performance out of each table type. It's possible that changing a few 
tables would work and have no downside, but if that were the case I'd 
expect upstream to have suggested it.

Here's a paper on general Mysql scaling that's pretty interesting and 
easy to read if you don't have much db background.
http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf

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

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

[Robin H. Johnson]

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

On Fri, Aug 04, 2006 at 11:07:44AM -0700, kashani wrote:
> 	Another technique is to change high transaction tables to Innodb 
> 	table format. Innodb is going to be roughly 30% slower than MyISAM for 
> selects and take up much more space on disk approx 3-5x larger. However it 
> has row locking which solves the contention issue. A good example of mixed 
> table types is actually Mediawiki which uses Memory for hitcounters, 
> Innodb for pages and revisions, and MyISAM for everything else.
From professional deployments, InnoDB is only slower when your hardware
isn't up to the task of keeping the entire DB in the kernel disk cache
(needs 8Gb+ of RAM for some databases). BUT...

This path WAS explored, and a major stumbling block is that Bugzilla
makes very large use of FULLTEXT indices, which InnoDB does not support.
There is an open bug in Bugzilla's bugzilla requesting people to work on
it, but it would entail huge changes to the bugzilla DB structure,
moving away from proper normalization and adding a split to allow
keeping either duplicate MyISAM for indices, or splitting existing
tables simply based on the indices needed.

We are in good hands (I'm involved as well, I started the mysql team,
and I'm one of the upstream developers of phpMyAdmin) and slowly getting
there, the powerful hardware is actually really needed.

> Here's a paper on general Mysql scaling that's pretty interesting and 
> easy to read if you don't have much db background.
> http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf
I am fully aware of the DB systems layout of LiveJournal, and believe
me, we are taking large parts of it into consideration, where
applicable (Bugzilla SQL queries are a LOT more complicated than those
of LiveJournal). 

Using the 2 DB boxes, there will be 2 slave instances that get reads
balanced between them, and a migratable master instance (in case one DB
box has to go down, the actual master DB content is on the SAN, and the
other box can take over the master instance). There's some glue work
needed to make all of this transparent to Bugzilla as well, due to it's
existing limitations (the glue is faster to develop, more stable, and
much easier to debug than hacking on the Bugzilla codebase).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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