Ciaran McCreesh wrote:
> On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato <[EMAIL PROTECTED]>
> wrote:
> | Ciaran McCreesh wrote:
> | > What is the best way to handle packages that require parts of tr1?
> | > The options appear to be:
> | >
> |
> | * have the application bundle a static implementa
On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato <[EMAIL PROTECTED]>
wrote:
| Ciaran McCreesh wrote:
| > What is the best way to handle packages that require parts of tr1?
| > The options appear to be:
| >
|
| * have the application bundle a static implementation and switch to
| system on at confi
Ciaran McCreesh wrote:
> What is the best way to handle packages that require parts of tr1? The
> options appear to be:
>
* have the application bundle a static implementation and switch to
system on at configure time as done for other libs?
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://
[ Background: tr1 is a set of extensions to the C++ Standard Library
giving various useful things like hash tables and smart pointers. There
are partial implementations included in g++-4.1 and boost and full
implementations available from Dinkumware. It is likely that a lot of
C++ apps will start u
On Mon, 2007-29-01 at 14:01 -0600, Grant Goodyear wrote:
> Ned Ludd wrote: [Mon Jan 29 2007, 09:50:28AM CST]
> > > Then it should be offered to the 8th person, at which point either
> > > he/she will then refuse the nomination and it's offered to the 9th.
> > > Rinse and repeat.
> > > If we run out
Ned Ludd wrote: [Mon Jan 29 2007, 09:50:28AM CST]
> > Then it should be offered to the 8th person, at which point either
> > he/she will then refuse the nomination and it's offered to the 9th.
> > Rinse and repeat.
> > If we run out of nominees then we'll need another election.
> >
>
> Agreed. #3
Petteri Räty wrote:
>> Please note, I'm not talking about applications like portage or pkgcore,
>> just the ebuild text files, which I understand have one maintainer?
>
> Many ebuilds are in maintained by a bunch of people via herds.
>
That's not really an issue for a db app.
>> I appreciate that
Marius Mauch wrote:
>> I'm a bit confused about all the portage tree stuff. There's just
>> under 25,000 ebuilds, which are maintained by about 100 devs (not
>> sure of exact number, taken from a forum post.) I guess what I'm
>> asking is why this isn't just a database.
>
> Please define "database
Donnie Berkholz wrote:
> The idea of restricting access to specific parts of gentoo-x86 has come
> up many times. It doesn't fix anything and actually makes some things
> worse. Committers still have access to wherever they can commit, so they
> can work whatever evil they want there without needin
Delayed until we fix some depends on it.
--
gentoo-dev@gentoo.org mailing list
Mike Kelly wrote:
> On Sun, 28 Jan 2007 18:03:49 +0100
> Christian Heim <[EMAIL PROTECTED]> wrote:
>
>> On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote:
>>> Raúl Porcel wrote:
# Raúl Porcel <[EMAIL PROTECTED]> (27 Jan 2007)
# Masked for removal 26 Feb 2007, bug 135257, securit
On Mon, 2007-01-29 at 14:46 +, Roy Marples wrote:
> On Mon, 29 Jan 2007 13:39:05 +0100
> "Rob C" <[EMAIL PROTECTED]> wrote:
>
> > For what its worth, I think option #2 is the best.
> >
> > I think option #1 is out of the question and I think that #3 is flawed
> > because the 8th spot develope
On Sun, 28 Jan 2007 18:03:49 +0100
Christian Heim <[EMAIL PROTECTED]> wrote:
> On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote:
> > Raúl Porcel wrote:
> > > # Raúl Porcel <[EMAIL PROTECTED]> (27 Jan 2007)
> > > # Masked for removal 26 Feb 2007, bug 135257, security issues
> > > # Replac
On Mon, 29 Jan 2007 13:39:05 +0100
"Rob C" <[EMAIL PROTECTED]> wrote:
> For what its worth, I think option #2 is the best.
>
> I think option #1 is out of the question and I think that #3 is flawed
> because the 8th spot developer's situation or commitment to the
> project may have changed since
For what its worth, I think option #2 is the best.
I think option #1 is out of the question and I think that #3 is flawed
because the 8th spot developer's situation or commitment to the project may
have changed since the last vote and in any case that developer would be
free to partake in the run
On Monday 29 of January 2007 12:46:33 Wernfried Haas wrote:
> 4. The position stays empty until the next election (As long the
>number of council members doesn't drop below a certain number,
>let's say 5.
I think we need odd no. of members to have a casting vote.
Btw. I vote for #3.
--
B
Am Montag, 29. Januar 2007 00:26 schrieb Ciaran McCreesh:
> On Sun, 28 Jan 2007 19:17:35 +0100 (MET) Christian Faulhammer
>
> <[EMAIL PROTECTED]> wrote:
> | As we all notice from time to time, amd64 team is lacking behind a
> | bit, due to various reasons. a) manpower, b) a lot of keywording.
> |
On Sun, Jan 28, 2007 at 02:24:49PM -0800, Mike Doty wrote:
> 1. re-elect a whole new council.
Seems to be overkill to me.
> 2. elect a new member at a reduced term to fill the vacancy.
Personally i'd rather go with #3, but the GLEP also states:
> If a council member who has been marked a slac
On Mon, 29 Jan 2007 08:15:18 +0100 (MET)
Christian Faulhammer <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh <[EMAIL PROTECTED]>:
>
> > On Sun, 28 Jan 2007 19:17:35 +0100 (MET) Christian Faulhammer
> > <[EMAIL PROTECTED]> wrote:
> > | As we all notice from time to time, amd64 team is lacking behind
"Dan Meltzer" <[EMAIL PROTECTED]>:
> Isn't this kind of against what glep40 set out to do?
It is. But as we have a outstanding situation for amd64 and
maintainers, we could allow marking ~amd64 for a short (!) time to cut
the backlog a bit. FYI, I am member of x86 arch team, not amd64, and I
j
20 matches
Mail list logo
