[gentoo-council] January 2010 meeting date

[gentoo-council] January 2010 meeting date

[Denis Dupeyron]

The next meeting will be on 18 January 2010 at 1900UTC. The date was
pushed back 2 weeks for various reasons but the main one is to let our
livers recover. Which prompts me to make the following public
announcement: Happy holidays! :o)

I will be following up discussions on various mailing lists to prepare
the agenda. If you already want to suggest topics feel free to reply
to this thread. You'll get a second chance with the meeting reminder
approximately two weeks before the meeting. I will be sending a
message about the two topics which did not make it last time and
explain why. I should have sent that much earlier but well... you
know...

Denis.

Re: [gentoo-council] January 2010 meeting date

[Ulrich Mueller]

>>>>> On Tue, 15 Dec 2009, Denis Dupeyron wrote:

> I will be following up discussions on various mailing lists to prepare
> the agenda. If you already want to suggest topics feel free to reply
> to this thread.

Please add a topic "EAPI 3 approval". Implementation in Portage is
ready in version 2.1.7.14, according to zmedico. Wordings for PMS have
been proposed in bugs 296716 and 264130.

Ulrich

[gentoo-council] Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1072 bytes --]

On Sunday 20 December 2009 09:49:09 Fabian Groffen wrote:
> On 15-12-2009 09:54:36 -0700, Denis Dupeyron wrote:
> > I will be following up discussions on various mailing lists to prepare
> > the agenda. If you already want to suggest topics feel free to reply
> > to this thread. You'll get a second chance with the meeting reminder
> > approximately two weeks before the meeting. I will be sending a
> > message about the two topics which did not make it last time and
> > explain why. I should have sent that much earlier but well... you
> > know...
> 
> I'd like to council to discuss the current *$^&!! policy of
> -dev-announce and -dev.  I'd propose to at least implement the following
> behaviour such that I:
> - don't have to see some mails 3 (!) times and many 2 times
> - don't get lost where the mail is/was
> - get broken threading because the original mail was sent to another
>   list

get a sane mail client that automatically handles messages with duplicate ids 
and references.  cant say ive ever noticed a problem with kmail.
-mike

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

[gentoo-council] Re: [gentoo-dev-announce] January 2010 meeting date

[Denis Dupeyron]

On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> I will make it short, since i already requested it 3 times, did create a thread at gentoo-dev ML:
>
> agenda topic: Discussion and approval for following item:
>
> Adding real multilib features from current multilib-portage to currently hardmasked and testing
> portage-2.2* for wider testing, more eyes looking at it and hopefully more people helping improving
> it, so we can get a version, which most can accept for PMS and maybe next EAPI.

Sorry, I forgot to send an email explaining what happened on the
council alias as promised. The consensus was that the project wasn't
mature enough to go ahead. Also more generally the council's job isn't
discussing but deciding, approving, etc... Discussing is what should
happen on mailing lists. Before you can bring that to the council we
need to see an as-much-as-possible finalized solution with any of the
following if applicable: portage branch with an implementation that
people can try, documentation, PMS patch, devmanual patches, and a
team. By team I mean: who is going to maintain this in the long run if
necessary? A one man team is a dead team, it's only a matter of time.
If the amd64 team is going to be the one doing this job, and this is
just an example buy the way, then we need them to tell us they're OK
with it.

Now don't get me wrong. I love your project and the last thing I want
is to shoot it down. Look at what happened with prefix. They wanted
the council to approve it immediately or else... We didn't cede to
pressure and worked with them to make it good enough for approval.
Right now I don't hear anybody arguing about prefix going forward. And
that's exactly what I want for your project, i.e. helping you making
it better instead of it fading and failing in the (not so) long run.

I will stop now because I'm at a bus stop near Mount Fuji and I need
to go. I hope the other council members, especially the more
technically competent ones than me, will get back to you on this and
offer help and advice. As soon as I have a better internet connection
I will contact you about this.

Denis.

[gentoo-council] Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

[Doug Goldstein]

On Fri, Dec 25, 2009 at 8:00 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> On 12/25/2009 06:10 AM, Denis Dupeyron wrote:
>> On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>>> I will make it short, since i already requested it 3 times, did create a thread at gentoo-dev ML:
>>>
>>> agenda topic: Discussion and approval for following item:
>>>
>>> Adding real multilib features from current multilib-portage to currently hardmasked and testing
>>> portage-2.2* for wider testing, more eyes looking at it and hopefully more people helping improving
>>> it, so we can get a version, which most can accept for PMS and maybe next EAPI.
>>
>> Sorry, I forgot to send an email explaining what happened on the
>> council alias as promised. The consensus was that the project wasn't
>> mature enough to go ahead. Also more generally the council's job isn't
>> discussing but deciding, approving, etc... Discussing is what should
>> happen on mailing lists.
>
> Since i see noone arguing against adding the multilib features to current testing branch of portage,
> the discussion part already seems to be done. so a simple approval is ok, drop the discussion request.
>
>> Before you can bring that to the council we
>> need to see an as-much-as-possible finalized solution with any of the
>> following if applicable: portage branch with an implementation that
>> people can try, documentation, PMS patch, devmanual patches, and a
>> team.
>
> Did you actually read my lines? I did NOT request an ACK to add it to PMS and next EAPI with a
> complete spec. zmedico also has no problem with having a look and adding it, but since he was once
> forced to remove an added feature, he now wants a council-ok before adding and improving it in
> testing branch of main tree portage.
>
>> By team I mean: who is going to maintain this in the long run if
>> necessary? A one man team is a dead team, it's only a matter of time.
>
> Much code is maintained by a single person, even the package maintainers have one maintainer and
> some contributors. And with integrating it in main tree portage, there will additionally be the
> portage team.
>
>> If the amd64 team is going to be the one doing this job, and this is
>> just an example buy the way, then we need them to tell us they're OK
>> with it.
>
> If any other team raises its voice, no problem with me, but it seems more like noone wants to do the
> work.
>
>> Now don't get me wrong. I love your project and the last thing I want
>> is to shoot it down.
>
> In this case, you will shoot it down. I wont be able to maintain the code alone, do all requested
> code changes, spec writing, PMS patches etc beside my work and other projects i do within Gentoo. So
> if you stop me from getting help by integrating it in *testing* portage (not the 2.1.* versions,
> only the 2.2* versions, which contains more and experimental code), it will probably stay at the
> current level and nothing more will happen.
> I can live myself with a private fork of portage, which contains the features i like, it is easy to
> only do some basic changes and some workarounds to get it personally working without much time.
> But on the other hand, all people, who would like to see emul-linux-* packages dropped, would like
> to actually compile recent versions of 32bit libs and would like to compile additional libs not in
> those emul-linux-* packages in addition to multi-ABI support for other ARCHes and multi-SLOT support
> for the different languages (support parallel install for different SLOTS of e.g. python, perl or
> ruby) would have to do their own local or eclass hacks to get their thing working.
>
>> Look at what happened with prefix. They wanted
>> the council to approve it immediately or else... We didn't cede to
>> pressure and worked with them to make it good enough for approval.
>
> Something like "I/We want <x>,<y>,<z> or you wont get an approval" is no support and no "work with
> them". So if you really would like to see it in, actually help with patches, SPEC writing,
> discussion and code writing. Else i request an approval for getting some additional help instead of
> just shooting it down.
>
>> Right now I don't hear anybody arguing about prefix going forward. And
>> that's exactly what I want for your project, i.e. helping you making
>> it better instead of it fading and failing in the (not so) long run.
>
> prefix is no one-man-team and the actual amount of people, who can and are willing to work on
> portage code is limited, so which other way do you have to improve it as requested?
>
> And yes, it is frustrating to see 3 council sessions and months going by and still no offer to
> support, no discussion, no patches and no decision is made. I can see now, why such project did die
> before and why people dont want to do such things, which can actually improve the experience with
> Gentoo and can give our userbase more options and choice.
>
>>
>> I will stop now because I'm at a bus stop near Mount Fuji and I need
>> to go. I hope the other council members, especially the more
>> technically competent ones than me, will get back to you on this and
>> offer help and advice. As soon as I have a better internet connection
>> I will contact you about this.
>
> Feel free to do so.
>
> P.S.: I dont want to affront you or anyone else personally, but the way, how it currently goes. I
> know from IRC, forums and mails, that there are people around, who would like to see
> multilib-features in portage. But with such frustrating none-actions like this, noone should wonder
> why such things are not implemented, also there are people, who would like to see it and even
> people, who would help doing it and creating code for it. That does not actually speak for Gentoo,
> more against it (and it is not the only point, where Gentoo could improve, but does not, but that
> could be part of another big mail).
>
>
> --
> Thomas Sachau
>
> Gentoo Linux Developer
>
>

People are honestly just waiting for this to hit the tree at this
point. Inaction by the council is a serious failure of the council.
The Portage team doesn't want to start integrating code that the
council will force them to remove in the future. Being a former
council member myself I can easily say, get off your ass and do
something.

-- 
Doug Goldstein

[gentoo-council] Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1479 bytes --]

On Friday 25 December 2009 09:00:36 Thomas Sachau wrote:
> On 12/25/2009 06:10 AM, Denis Dupeyron wrote:
> > On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> >> I will make it short, since i already requested it 3 times, did create a
> >> thread at gentoo-dev ML:
> >>
> >> agenda topic: Discussion and approval for following item:
> >>
> >> Adding real multilib features from current multilib-portage to currently
> >> hardmasked and testing portage-2.2* for wider testing, more eyes looking
> >> at it and hopefully more people helping improving it, so we can get a
> >> version, which most can accept for PMS and maybe next EAPI.
> >
> > Sorry, I forgot to send an email explaining what happened on the
> > council alias as promised. The consensus was that the project wasn't
> > mature enough to go ahead. Also more generally the council's job isn't
> > discussing but deciding, approving, etc... Discussing is what should
> > happen on mailing lists.
> 
> Since i see noone arguing against adding the multilib features to current
>  testing branch of portage, the discussion part already seems to be done.
>  so a simple approval is ok, drop the discussion request.

that's incorrect.  you still havent addressed my outstanding issues.  until 
you do, i dont see how you can push for this being added to portage.  or i 
missed some update along the way, but the last e-mail i see is from me dated 
26.10.2009 ...
-mike

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