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

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

[Duncan]

Patrick Lauer posted <1136238763.23404.171.camel@localhost>, excerpted
below,  on Mon, 02 Jan 2006 22:52:43 +0100:

Lance Albertson wrote:
>>  When I say "we have a niche we're perfect at",
>> I'm mainly referring to the source-based nature of our OS. There isn't
>> another distro out there that does it as well as us and we should
>> improve on that fact. Let the other distros get better at being
>> binary-based.

> Why would one prevent the other from happening? 
> Maybe someone finds an elegant way for "Binary Gentoo" ... should we
> stop that person because it conflicts with a weird mission statement?

I believe that's where the differing opinions begin to come in.  Here's
mine.  I don't believe that Gentoo, /as/ /Gentoo/, will ever be very
successful as an Enterprise distribution, and I don't think that it can
every be very successful as a binary distribution, either.  The things
that make us, that is Gentoo, unique, and the best in our area, by
definition are the /same/ sort of things that make a relatively poor
enterprise or binary distribution.

I'm all for a /separate/ enterprise effort based on Gentoo, and likewise,
all for a /separate/ binary targeted distribution based on Gentoo. 
However, the goals are sufficiently different that I don't believe either
one will work well /as/ Gentoo, or, in the event that it /does/ work well,
it will change Gentoo into that image, and Gentoo won't continue to fit
the current niche, a relatively fresh "source based" distribution for
those who aren't afraid to take responsibility for managing their systems,
as well as it does.

What I expect will happen if we try, is that we won't be the sort of best
of genre solution in those other areas, that makes Gentoo what it is today
within its own "admin's source based distribution".  At the same time,
splitting our efforts in that direction will end up weakening the Gentoo
we all know and love.

Rather, I'd prefer an independent distribution, Gentoo based is great,
some devs doing both is great, to do the enterprise stuff.  Same with the
binary.  There are of course already several smaller Gentoo based
mini-distributions, and I think that's the way to go.  Doing it that way
will prevent fuzzing up our image and our drive, allowing us to continue
to be the best at what we are good at, while others get to focus on the
stuff they can be good at.  Some devs will naturally be attracted to one
or the other -- not a problem.  Others will find they can spend time on
both (or all three) projects and drive up personal productivity, much as
Greg KH seems to thrive on all his projects, managing to be more
productive on all of them than many devoting all their time to the
project.  Again, that shouldn't be a problem, for those that can
effectively handle it, and for those that can't, well, it's a volunteer
situation, and as such, a natural solution tends to appear.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote:
> Patrick Lauer posted <1136238763.23404.171.camel@localhost>, excerpted
> below,  on Mon, 02 Jan 2006 22:52:43 +0100:
> 
> Lance Albertson wrote:
> >>  When I say "we have a niche we're perfect at",
> >> I'm mainly referring to the source-based nature of our OS. There isn't
> >> another distro out there that does it as well as us and we should
> >> improve on that fact. Let the other distros get better at being
> >> binary-based.
> 
> > Why would one prevent the other from happening? 
> > Maybe someone finds an elegant way for "Binary Gentoo" ... should we
> > stop that person because it conflicts with a weird mission statement?
> 
> I believe that's where the differing opinions begin to come in.  Here's
> mine.  I don't believe that Gentoo, /as/ /Gentoo/, will ever be very
> successful as an Enterprise distribution, and I don't think that it can
> every be very successful as a binary distribution, either.  The things
> that make us, that is Gentoo, unique, and the best in our area, by
> definition are the /same/ sort of things that make a relatively poor
> enterprise or binary distribution.

I completely agree with you here.  What Gentoo does is make a
meta-distribution, that one can utilize to build their own distribution
easily.  This isn't limited to Linux, either, thanks to Gentoo/Alt.

I think that any single direction that we shoot towards will cause
friction internally and will reduce productivity, along with leaving
certain projects out.  We're simply moving in too many directions to
have a single direction.

The biggest concern that I see here is a lack of communications, really.
We don't need direction.  We just need some way for people to know who's
going where.  I think Koon's "MetaBug" project would be an excellent
idea to assist in this.  We need a body with some teeth to get things
done in a timely manner.  We also need enforcement of some sort to
ensure projects are active and reporting information on their status.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

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

[Mark Loeser]

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

Chris Gianelloni <wolf31o2@gentoo.org> said:
> On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote:
> > I believe that's where the differing opinions begin to come in.  Here's
> > mine.  I don't believe that Gentoo, /as/ /Gentoo/, will ever be very
> > successful as an Enterprise distribution, and I don't think that it can
> > every be very successful as a binary distribution, either.  The things
> > that make us, that is Gentoo, unique, and the best in our area, by
> > definition are the /same/ sort of things that make a relatively poor
> > enterprise or binary distribution.
> 
> I completely agree with you here.  What Gentoo does is make a
> meta-distribution, that one can utilize to build their own distribution
> easily.  This isn't limited to Linux, either, thanks to Gentoo/Alt.
> 
> I think that any single direction that we shoot towards will cause
> friction internally and will reduce productivity, along with leaving
> certain projects out.  We're simply moving in too many directions to
> have a single direction.

+1

Each project has a direction they want to go in, and by setting some sort of
"global vision" we are only going to restrict this.

> The biggest concern that I see here is a lack of communications, really.
> We don't need direction.  We just need some way for people to know who's
> going where.  I think Koon's "MetaBug" project would be an excellent
> idea to assist in this.  We need a body with some teeth to get things
> done in a timely manner.  We also need enforcement of some sort to
> ensure projects are active and reporting information on their status.

Sounds good as well.  I'd like to see all of the projects/teams saying what
their goals are, or what they have done to move towards their goals.


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

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

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

[Lance Albertson]

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

Mark Loeser wrote:
> Chris Gianelloni <wolf31o2@gentoo.org> said:
> 
>>On Tue, 2006-01-03 at 04:08 -0700, Duncan wrote:
>>
>>>I believe that's where the differing opinions begin to come in.  Here's
>>>mine.  I don't believe that Gentoo, /as/ /Gentoo/, will ever be very
>>>successful as an Enterprise distribution, and I don't think that it can
>>>every be very successful as a binary distribution, either.  The things
>>>that make us, that is Gentoo, unique, and the best in our area, by
>>>definition are the /same/ sort of things that make a relatively poor
>>>enterprise or binary distribution.
>>
>>I completely agree with you here.  What Gentoo does is make a
>>meta-distribution, that one can utilize to build their own distribution
>>easily.  This isn't limited to Linux, either, thanks to Gentoo/Alt.
>>
>>I think that any single direction that we shoot towards will cause
>>friction internally and will reduce productivity, along with leaving
>>certain projects out.  We're simply moving in too many directions to
>>have a single direction.
> 
> 
> +1
> 
> Each project has a direction they want to go in, and by setting some sort of
> "global vision" we are only going to restrict this.

I never meant that each subproject can't have their own goals. They need
to have those of course! I was more directed that there isn't a person
in charge of all the subprojects just to keep track of them (Not
governing them). i.e. if subproject foo is working on adding feature X
to portage, then this person could make sure the portage people know
that these folks are wanting to add that feature instead of blind siding
them. Of course, if we lived in a perfect world, they would go ahead and
work together like that. I'm not stating that we'd want to restrict
everyone from doing what they want, just that there's some kind of
direction/guidance/overall project manager that keeps track of all these
projects. They would keep track of all this and report back to the
council/devs/etc.

We've gotten to the size that trying to get everyone communicating with
everyone is getting difficult. Having someone overseeing these things
might help development and make sure everyone is on the same page.

-- 
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] Re: Monthly Gentoo Council Reminder for January

[Mark Loeser]

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

Lance Albertson <ramereth@gentoo.org> said:
> Mark Loeser wrote:
> > Chris Gianelloni <wolf31o2@gentoo.org> said:
> >>I completely agree with you here.  What Gentoo does is make a
> >>meta-distribution, that one can utilize to build their own distribution
> >>easily.  This isn't limited to Linux, either, thanks to Gentoo/Alt.
> >>
> >>I think that any single direction that we shoot towards will cause
> >>friction internally and will reduce productivity, along with leaving
> >>certain projects out.  We're simply moving in too many directions to
> >>have a single direction.
> > 
> > 
> > +1
> > 
> > Each project has a direction they want to go in, and by setting some sort of
> > "global vision" we are only going to restrict this.
> 
> I never meant that each subproject can't have their own goals. They need
> to have those of course! I was more directed that there isn't a person
> in charge of all the subprojects just to keep track of them (Not
> governing them). i.e. if subproject foo is working on adding feature X
> to portage, then this person could make sure the portage people know
> that these folks are wanting to add that feature instead of blind siding
> them. Of course, if we lived in a perfect world, they would go ahead and
> work together like that. I'm not stating that we'd want to restrict
> everyone from doing what they want, just that there's some kind of
> direction/guidance/overall project manager that keeps track of all these
> projects. They would keep track of all this and report back to the
> council/devs/etc.

So, is this something like Koon's "MetaBug" thing?  (I have no idea what that
is besides what Chris just said about it).  I just don't want to see someone
else telling the subprojects how to run their team, or what goals they should
have.


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

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

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

[Duncan]

Brian Harring posted <20060105064956.GC14338@nightcrawler.e-centre.net>,
excerpted below,  on Wed, 04 Jan 2006 22:49:56 -0800:

> Note I said 'intentional'; seems like people have been pushing for 
> gentoo as a whole to slow down (note the enterprise 
> concerns/complaints that hit the ml every 6 months for example).
> 
> Dunno.  Maybe it's all a ramble, maybe you think I'm a loon, but final 
> point I'm going to make is that pushing for a global solution (whether 
> a BDFL or board or committee) totally is missing the actual issue- 
> that individuals get things done, the larger the # of folks involved 
> in progressing towards something the slower they're going to move.

This man speaks my mind.  That's one of the things I'm worried about with
the Enterprise Gentoo thing, and why I think it will make a better
separate project than part of Gentoo itself.  

Anyone who thinks Gentoo isn't progressing simply isn't seeing the forest
for all the trees, as they say.  Another way of putting it is that Gentoo
seems to be in that critical period after the honeymoon, it has hit its
middle-aged crisis.  Reality has set in -- we're not going to magically
move mountains, as yes, a mountain /can/ be moved, see the  history of the
Panama canal for instance, but it takes a *LOT* of work, a LOT of
investment, and sometimes even some deaths along the way.  During that
time, progress may seem painfully slow, yet it never-the-less occurs. 
What's the alternative, dumping the project and leaving it for dead?  Then
all that work and investment, and all those deaths, /will/ be in vain.

OTOH, after a certain point, which Gentoo seems to have reached, throwing
more bureaucracy at a project, as seems to be part of the proposal here,
does  more harm than good.  I'm with Brian, here.  If we want progress, we
gotta slack off on the regulation a bit and give the folks actually down
there getting their hands dirty some room to work, at least if we aren't
willing (or able) to get in there with them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 05 Jan 2006 03:26:03 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| Anyone who thinks Gentoo isn't progressing simply isn't seeing the
| forest for all the trees, as they say.  Another way of putting it is
| that Gentoo seems to be in that critical period after the honeymoon,
| it has hit its middle-aged crisis.  Reality has set in -- we're not
| going to magically move mountains, as yes, a mountain /can/ be moved,
| see the  history of the Panama canal for instance, but it takes a
| *LOT* of work, a LOT of investment, and sometimes even some deaths
| along the way.  During that time, progress may seem painfully slow,
| yet it never-the-less occurs. What's the alternative, dumping the
| project and leaving it for dead?  Then all that work and investment,
| and all those deaths, /will/ be in vain.

What makes you think we're not moving mountains? Getting 1.4 out of the
door was considered an amazing feat. Now we're doing the same thing
every six months, and it's largely going unnoticed. Is something only
an impressive accomplishment if it goes wrong and generates lots of
mess first?

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

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

[Carsten Lohrke]

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

On Thursday 05 January 2006 11:26, Duncan wrote:
> This man speaks my mind.  That's one of the things I'm worried about with
> the Enterprise Gentoo thing, and why I think it will make a better
> separate project than part of Gentoo itself.

I agree mostly, too. Just that QA has more aspects than "cool nifty package x 
that has bleeding edge dep y, with dep y sitting due to QA concerns", to 
quote Brian. A QA team can work concurrently to other subprojects of Gentoo, 
spot testing ebuild quality, checking e.g. for correct dependencies and 
licenses (I stumpled about four false ones the last few months) and a lot of 
other things without slowing development down. It's a pity, that we don't 
have an proactive QA team.

The complaints about Gentoo having no direction, sound (at least in my ears) 
more like "Gentoo is not heading in the direction I want to have it." - so, 
attract developers who work with you on your goals (We don't have enough devs 
anyways, ~10% unmaintained packages in the tree speak for themselves) within 
Gentoo. I for one can't say we haven't seen a lot of improvements in 
different subprojects, just that it takes time.


> see the  history of the Panama canal for instance, but it takes a *LOT* of 
work

Odd comparison, having in mind how much lives it did cost.


Carsten

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

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

[Duncan]

Carsten Lohrke posted <200601052030.36308.carlo@gentoo.org>, excerpted
below,  on Thu, 05 Jan 2006 20:30:27 +0100:

> On Thursday 05 January 2006 16:46, Diego 'Flameeyes' Pettenò wrote:
>> Yeah ok, let me end up these holidays, and I'll prepare a written request
>> to change the Linux part in something else
> 
> You should also contact the folks working on the gentoo.org redesign. While 
> there was a bit of fuss about the infinity symbol, I always wondered why no 
> one lost a word against the "Linux" below, given that we claim to provide a 
> meta-distribution.

Well, for that matter, "distribution" is considered at least by my *BSD
friends, to be a peculiarly Linux term.  From their perspective, Linux has
1001 "distributions", but they only have the one *BSD they choose to use. 
They don't consider BSD fragmented, even with multiple "distributions" as
it were, because each BSD is its own thing, yet at the same time, no Linux
is its own thing, it's fragmented into 1001 "distributions".

So, while Gentoo is certainly more than Linux, even maintaining the
"metadistribution" term in the definition, will be the same thing as
keeping the "Linux", from the viewpoint of the many tending toward the BSD
side of the FLOSS community.

What word to use in place of "distribution", when one wants to include the
BSDs and other "non-distributions" as well, other than
Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

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

[Jon Portnoy]

On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote:
> 
> What word to use in place of "distribution", when one wants to include the
> BSDs and other "non-distributions" as well, other than
> Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?
> 

Well we could say "meta operating system" if we wanted to be really 
stupid, or we could just admit that we don't have to make a bunch of 
anal terminology nerds happy and continue on using sane naming

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

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

On Friday 06 January 2006 09:37, Duncan wrote:
> Well, for that matter, "distribution" is considered at least by my *BSD
> friends, to be a peculiarly Linux term.  From their perspective, Linux has
> 1001 "distributions", but they only have the one *BSD they choose to use.
That's what we started changing. Gentoo/FreeBSD is by all means a FreeBSD 
distribution (actually, PC-BSD started this a bit before of us).
We didn't fork it to change the base system, we use FreeBSD basesystem and 
portage, so it's not like others BSD.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

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

[Marius Mauch]

Lance Albertson wrote:
> I never meant that each subproject can't have their own goals. They need
> to have those of course! I was more directed that there isn't a person
> in charge of all the subprojects just to keep track of them (Not
> governing them). i.e. if subproject foo is working on adding feature X
> to portage, then this person could make sure the portage people know
> that these folks are wanting to add that feature instead of blind siding
> them. Of course, if we lived in a perfect world, they would go ahead and
> work together like that.

Can you give examples where this has actually been a problem?

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

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

[Donnie Berkholz]

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

Jon Portnoy wrote:
| On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote:
|
|>What word to use in place of "distribution", when one wants to include the
|>BSDs and other "non-distributions" as well, other than
|>Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term?
|>
|
|
| Well we could say "meta operating system" if we wanted to be really
| stupid, or we could just admit that we don't have to make a bunch of
| anal terminology nerds happy and continue on using sane naming

Hey, we could be like Yoper and call ourselves GentooOS!

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvrsKXVaO67S1rtsRAgWlAJ0aZu8IlPoNANBi6VeKOfr0EBHEzgCgwEuT
LYABrSmTYV3EEq6QdYJvOTo=
=FRpL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Monthly Gentoo Council Reminder for January

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

[Piotr Jaroszyński]

On Tuesday 01 of January 2008 06:30:01 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 like council to discuss GLEP 54 and 55.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

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

[Caleb Tennis]

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

I would like to request the council discuss, though not necessarily take action or
vote on, the idea of "slacker arches" and what ebuild maintainers are allowed/can do
to a package versions that are languishing due to not getting stable keywords on
those arches.

I'm not trying to pick on any specific case, but I am hoping to find out if there's
an allowable/acceptable period of time to which if an arch team is unable to
stabilize a package to a newer version, for non-technical reasons, that it's okay to
drop older unstable ebuilds.

I realize this is open to lots of debate and dicussion, and I'm just trying to have
a dialogue as to what is acceptable and hopefully get concensus as to some kind of
guidance that could be added to the devmanual.

Thanks,
Caleb

-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Caleb Tennis 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 like to request the council discuss, though not necessarily take action or
> vote on, the idea of "slacker arches" and what ebuild maintainers are allowed/can do
> to a package versions that are languishing due to not getting stable keywords on
> those arches.
>

I'd suggest something like "if nobody could test your update in a timely
way you should ask and possibly get an account on an arch box in order
to test it and bump if the minimal test pass"

sounds fair?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Fri, 04 Jan 2008 00:54:50 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> I'd suggest something like "if nobody could test your update in a
> timely way you should ask and possibly get an account on an arch box
> in order to test it and bump if the minimal test pass"
> 
> sounds fair?

Sounds like a great way to get more broken packages, which means more
work for arch teams fixing them, which means less time available for
fixing important bugs.

-- 
Ciaran McCreesh

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

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

[Ryan Hill]

Ciaran McCreesh wrote:
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> I'd suggest something like "if nobody could test your update in a
>> timely way you should ask and possibly get an account on an arch box
>> in order to test it and bump if the minimal test pass"
>>
>> sounds fair?
> 
> Sounds like a great way to get more broken packages, which means more
> work for arch teams fixing them, which means less time available for
> fixing important bugs.

I find it more often we're waiting for the arch team to do something
so we can remove the broken package from the tree.  I have four versions 
of freetype sitting around that I'd really like to get rid of but can't 
until mips stabilizes a newer version.  Granted, I may only think it 
happens more often because I only see it from the dev side.

I don't mean to rag on the mips team because I understand how difficult 
it can be to build and test packages on that type of hardware (see [i] 
for a good explanation).  I've personally been looking into getting an 
Indigo2 or O2 box to help out.  I'd like to know, though, if they have 
any plans to deal with the current situation. And if there is no real 
solution in sight, what can we do about it?  Is dropping the
MIPS stable tree an option?

(btw this is a discussion that should take place on the -project ML)


[i] http://permalink.gmane.org/gmane.linux.gentoo.devel/46072

-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 03 Jan 2008 18:40:43 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> I have four versions of freetype sitting around that I'd really like
> to get rid of

And what is the cost of you not getting rid of them? Is there any
particular reason it matters when it's done?

-- 
Ciaran McCreesh

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

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

[Ryan Hill]

Ciaran McCreesh wrote:
> On Thu, 03 Jan 2008 18:40:43 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>> I have four versions of freetype sitting around that I'd really like
>> to get rid of
> 
> And what is the cost of you not getting rid of them? Is there any
> particular reason it matters when it's done?

The general maintenance cost of any ebuild in the tree.  If we want to 
make an external or global change in how the package is built or used, 
we have to make sure those changes work with all versions in the tree.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 03 Jan 2008 19:21:39 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 03 Jan 2008 18:40:43 -0600
> > Ryan Hill <dirtyepic@gentoo.org> wrote:
> >> I have four versions of freetype sitting around that I'd really
> >> like to get rid of
> > 
> > And what is the cost of you not getting rid of them? Is there any
> > particular reason it matters when it's done?
> 
> The general maintenance cost of any ebuild in the tree.  If we want
> to make an external or global change in how the package is built or
> used, we have to make sure those changes work with all versions in
> the tree.

And do you actually want to make such a change? If you do, give an
explanation, and demonstrate why it can't be solved simply by
dependencies.

Most of the time, when people are moaning about 'slacker' archs, they
don't have any kind of decent technical reason for doing so... In cases
where such a reason exists, the arch teams are usually quite happy to
prioritise if asked.

-- 
Ciaran McCreesh

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

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

[Caleb Tennis]

> Most of the time, when people are moaning about 'slacker' archs, they
> don't have any kind of decent technical reason for doing so... In cases
> where such a reason exists, the arch teams are usually quite happy to
> prioritise if asked.

And the point of me asking for the council to talk about this is to set some kind of
guidelines for what happens after you've asked X number of times and let Y number of
days go by, where X and Y are amounts open for discussion.

Caleb


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Fri, 4 Jan 2008 06:23:11 -0500 (EST)
"Caleb Tennis" <caleb@gentoo.org> wrote:
 > > Most of the time, when people are moaning about 'slacker' archs,
> > they don't have any kind of decent technical reason for doing so...
> > In cases where such a reason exists, the arch teams are usually
> > quite happy to prioritise if asked.
> 
> And the point of me asking for the council to talk about this is to
> set some kind of guidelines for what happens after you've asked X
> number of times and let Y number of days go by, where X and Y are
> amounts open for discussion.

X and Y are pretty much irrelevant. The important factor is Z, the
impact of leaving things the way they are.

-- 
Ciaran McCreesh

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

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

[Caleb Tennis]

> X and Y are pretty much irrelevant. The important factor is Z, the
> impact of leaving things the way they are.

Well, I'm asking the council to discuss when "pretty much" irrelevant no longer
applies.

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Fri, 4 Jan 2008 17:26:39 -0500 (EST)
"Caleb Tennis" <caleb@gentoo.org> wrote:
> > X and Y are pretty much irrelevant. The important factor is Z, the
> > impact of leaving things the way they are.
> 
> Well, I'm asking the council to discuss when "pretty much" irrelevant
> no longer applies.

Compared to the cost of causing yet more arch breakage, which takes
huge amounts of time to fix and leads to far more problems, I'd say X
and Y should be something like one billion and three billion
respectively, except in those rare cases where Z is genuinely
significant.

Really, I'd like to see some genuine examples of cases where people
think they have a legitimate value of Z...

-- 
Ciaran McCreesh

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

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

[Chris Gianelloni]

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

On Fri, 2008-01-04 at 21:02 +0000, Ciaran McCreesh wrote:
> X and Y are pretty much irrelevant. The important factor is Z, the
> impact of leaving things the way they are.

...and the idea is to let the Council decide what level of Z is
acceptable.  Currently, it appears as if the "issue" is maintainers
being forced to keep abhorrently old versions of packages, including
security-vulnerable packages, simply because a security-unsupported
architecture hasn't had time to test/update/whatever.

This has been an issue for quite some time.  Of course, the impact is
debatable, but it seems that we cannot agree ourselves on what is
agreeable, so I see this as a point to bring to the Council simply so it
can be resolved "once and for all" and things can resume normal
operation.  I know that I, as an ebuild developer, would be much more
comfortable/accepting of having to keep around old versions of packages,
if the Council had deemed it to be something "important" enough.  No
offence to any alternative architectures or their hard-working team
members, but there are some times when we have to look at the common
good, and forcing maintainers to spend time keeping older ebuilds that
are possibly using older ebuild code and other idiosyncrasies versus the
current versions for the more mainstream architectures simply might not
be worth it for architectures with a very minimal number of users.

I've heard some suggestions for removing stable KEYWORDS on arches that
aren't security supported.  I see this as a possible solution to such
issues, since ~arch packages aren't "security-supported" in the sense of
GLSA and such, so why not keep arches which aren't security-supported
from having stable KEYWORDS?  Of course, this is a "global" change which
affects multiple architectures, so it should be deferred to the Council.
I don't really think it requires a large amount of discussion simply
because it is simple to see how it would come to a swift stand-still.
The arch teams affected will want nothing to change, the package
maintainers will want to make things easier on themselves.  This is to
be expected.  We elect the Council for a reason.  Making decisions like
this is one of them.  Let's let them do their job and follow their
leadership.

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

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

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

[Chris Gianelloni]

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

On Fri, 2008-01-04 at 22:37 +0000, Ciaran McCreesh wrote:
> Really, I'd like to see some genuine examples of cases where people
> think they have a legitimate value of Z...

How about we base X Y and Z on the number of verifiable users of said
arch?  That's just as arbitrary and fits with the normal "pink ponies"
philosophy of pulling complete bullshit out of the air and using it as a
justification or argument.  Maybe we'll base it on how many months
they've been security-supported?

No offense to anyone, but holding back hundreds of developers and
thousands of users for a handful of developers, who could do their jobs
just as well without stable KEYWORDS, and an nearly as small number of
users, just isn't worth it to us all.  How many users do you really
think breaking some of these arches affects?  If the architecture (or
its team) is incapable of maintaining stable KEYWORDS in a timely
manner, why should we care about them, again?

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

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

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

[Ciaran McCreesh]

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

On Fri, 04 Jan 2008 20:20:18 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> No offense to anyone, but holding back hundreds of developers and
> thousands of users for a handful of developers

...and how exactly are hundreds of developers and thousands of users
being held back? So far as I can see, in cases where anyone really is
being held back, the arch teams are quite happy to prioritise -- the
people who go around moaning about 'slacker archs' rarely if ever
actually have anything holding them back.

If anyone has any examples of where they really are being held back and
where they really have given the arch teams plenty of time to do
something, I'd like to see them... Somehow I doubt it happens very
often, if at all.

-- 
Ciaran McCreesh

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

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

[Samuli Suominen]

On Sat, 5 Jan 2008 04:32:33 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Fri, 04 Jan 2008 20:20:18 -0800
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > No offense to anyone, but holding back hundreds of developers and
> > thousands of users for a handful of developers
> 
> ...and how exactly are hundreds of developers and thousands of users
> being held back? So far as I can see, in cases where anyone really is
> being held back, the arch teams are quite happy to prioritise -- the
> people who go around moaning about 'slacker archs' rarely if ever
> actually have anything holding them back.
> 
> If anyone has any examples of where they really are being held back
> and where they really have given the arch teams plenty of time to do
> something, I'd like to see them... Somehow I doubt it happens very
> often, if at all.
> 

No need to talk about 'slacker archs' since we are REALLY talking about
a 'slacker arch' called mips. I've given up hope long time ago, leaving
ebuilds behind with KEYWORDS="mips" since opening bugs seems useless and
maintaining them is too much work (the target of stabilization or
keywording changes many times before the bug is finally touched)

Mainly, talking about categories (yes, categories, no need to mention
single ebuilds at this point) xfce-* and media-* here.

IIRC, paludis has the "imlate" script you can use.

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

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

[Caleb Tennis]

> If anyone has any examples of where they really are being held back and
> where they really have given the arch teams plenty of time to do
> something, I'd like to see them... Somehow I doubt it happens very
> often, if at all.

Why?  You aren't the person I or anyone else has to make a case to.  In fact, I
never would have mailed the list about this to prevent this very type of
potentially-out-of-control discussion from occurring, except that the e-mail from
Mike said that discussion topics needed to be sent to the list.

We currently get rid of packages that are unmaintained or are old enough that they
pose technical problems for developers with today's tools.  I see no difference in
establishing some similar kinds criteria for arch team keywords (which I'm not even
asking for.  I'm simply asking for dialogue to determine what kinds of criteria
would be appropriate, if any).

Similarly, what would the Gentoo policy be if at some time in the future an arch
team had no members?  What if it had two members, but they were unable to keep up
with stabilization requests and were running 6-12 months behind?  "Sorry, there
isn't anybody who can mark that stable, but we're hoping to get someone on the team
this year" isn't a valid answer in my book.

I have no idea what the process is to add an "officially" support arch to the tree,
but certainly it's more than just one guy making a few commits.  There's some
process that has to be gone through, right?  Well, there also needs to be an exit
strategy for when lack of interest in maintenance no longer means that arch should
be supported.  But right now, all I'm asking for it when it's appropriate for an
ebuild maintainer to not have to spend any more time waiting for the arch team to
respond to requests.  If you believe that number is 1 billion days, fine.  Those of
us who have faced the issue and disagree can also make our opinions heard to the
council, and let them decide what should be done, again, if anything.

-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Chris Gianelloni wrote:
> This has been an issue for quite some time.  Of course, the impact is
> debatable, but it seems that we cannot agree ourselves on what is
> agreeable, so I see this as a point to bring to the Council simply so it
> can be resolved "once and for all" and things can resume normal
> operation.

This thread so far spawned lots of reply from an external contributor
making the point of keeping stale ebuilds around and 4 developers
against the idea proposing different solutions ranging from force update
pending some remote testing to remove the stable keyword for such arches.

Anything other suggestions?

lu

PS: has anybody checked how viable is now qemu-system ?

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Wulf C. Krueger]

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

On Saturday, 05. January 2008 18:19:10 Luca Barbato wrote:
> This thread so far spawned lots of reply from an external contributor
> making the point of keeping stale ebuilds around and 4 developers
> against the idea 

Make that 5.

> Anything other suggestions?

Let the maintainer of said package decide on the keywording (and therefore 
how to handle slacker arches). 

An example: An arch cares more about e. g. games (and proudly blogs about 
it) than KDE. In such a case in the future I'm going to try to work it 
out with the respective arch and if they don't react in a timely manner, 
I'll simply remove the stale ebuilds (or whatever action is appropriate).

And, if that has happened often enough, I will take appropriate steps to 
make sure such stuff doesn't happen again, e. g. by making sure the 
ebuilds I maintain are not keyworded by the respective arch again until 
their problems have been resolved. As will be the case for KDE4. It won't 
get any mips keyword.

As for Ciaran's remarks - yes, theoretically, he is right but I don't see 
him arch testing for mips so his remarks are pretty meaningless to me.

-- 
Best regards, Wulf

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

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

[Carsten Lohrke]

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

On Samstag, 5. Januar 2008, Wulf C. Krueger wrote:
> > Anything other suggestions?
>
> Let the maintainer of said package decide on the keywording (and therefore
> how to handle slacker arches).

That's not a good idea. What Gentoo needs is users (and this includes 
co-develoepers) having a reliable maintenance experience across the 
repository and developers not following our maintenance policies to be 
booted. In fact the MIPS team should have been given a last chance to reduce 
the number of keyworded packages to a number the team can handle and 
otherwise we should have said "Sorry, but goodbye MIPS." long long ago.

That said, the only reason the old KDE ebuilds are still in the tree is that I 
didn't kick my ass to do it, yet.


Carsten

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

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

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> 
> If anyone has any examples of where they really are being held back and
> where they really have given the arch teams plenty of time to do
> something, I'd like to see them... Somehow I doubt it happens very
> often, if at all.
> 

Maintainers want that the versions they provide to users work. I don't 
want to make that guarantee for old versions because I don't have the 
time to test wrt updates to the dependency tree etc. Maintainers could 
keep the old versions for some time but in my experience the mips team 
is completely unresponsive (http://bugs.gentoo.org/show_bug.cgi?id=160056).

Regards,
Petteri


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

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

[Peter Volkov]

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

В Сбт, 05/01/2008 в 18:19 +0100, Luca Barbato пишет:
> Anything other suggestions?

I think, arch which does not manage to cope with stabilize bugs force
users to use unstable branch so it's good both for developers and users
to force such arch to concentrate on fixing real bugs and maintain only
unstable branch. Decision to drop stable branch for certain arch should
be done by council after request and discussion on -dev having
arch@gentoo.org in CC.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ryan Hill]

Luca Barbato wrote:
> Chris Gianelloni wrote:
>> This has been an issue for quite some time.  Of course, the impact is
>> debatable, but it seems that we cannot agree ourselves on what is
>> agreeable, so I see this as a point to bring to the Council simply so it
>> can be resolved "once and for all" and things can resume normal
>> operation.
> 
> This thread so far spawned lots of reply from an external contributor
> making the point of keeping stale ebuilds around and 4 developers
> against the idea proposing different solutions ranging from force update
> pending some remote testing to remove the stable keyword for such arches.
> 
> Anything other suggestions?

I don't know, I can kinda see both sides.  Alt arches tend to be finicky 
so it's important that updates are well tested on them.  Also they're 
more prone to break during upgrades, not only because they're more 
fragile but because upstream is far less likely to have tested on them, 
so I can see why having a stable tree is important.

On the other hand, that stable tree is crufting up badly and also prone 
to breakage just due to being unmaintained.  mips have 225 open bugs, 87 
of which they are the assignee.  i don't really care about open bugs, 
but some do, and it's making them crabby.

I don't think any of the current suggestions are very good, but I don't 
have anything better, other than we get more mips/alt-arch ppl or access 
to hardware.  Like I said, I'm willing to buy hardware if I can find any 
(must ship to Nowhere, Canada).

Does anyone from the (current) mips team have anything to suggest?

> PS: has anybody checked how viable is now qemu-system ?

Does it build with GCC 4 yet?


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 5 Jan 2008 12:47:51 +0200
Samuli Suominen <drac@gentoo.org> wrote:
> Mainly, talking about categories (yes, categories, no need to mention
> single ebuilds at this point) xfce-* and media-* here.

So nothing that's a priority for the users of those archs then. Now
please provide specific examples of how anyone is being held up.

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Sat, 5 Jan 2008 09:03:43 -0500 (EST)
"Caleb Tennis" <caleb@gentoo.org> wrote:
> > If anyone has any examples of where they really are being held back
> > and where they really have given the arch teams plenty of time to do
> > something, I'd like to see them... Somehow I doubt it happens very
> > often, if at all.
> 
> Why?  You aren't the person I or anyone else has to make a case to.
> In fact, I never would have mailed the list about this to prevent
> this very type of potentially-out-of-control discussion from
> occurring, except that the e-mail from Mike said that discussion
> topics needed to be sent to the list.

Ah, so you'd like the Council to jump to some arbitrary decision,
rather than hearing specific examples and evidence from all involved?

How will providing specific examples of how people are being held up
not be beneficial to the decision-making process?

-- 
Ciaran McCreesh

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

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

[Ryan Hill]

Ryan Hill wrote:
> I don't think any of the current suggestions are very good, but I don't 
> have anything better, other than we get more mips/alt-arch ppl or access 
> to hardware.  Like I said, I'm willing to buy hardware if I can find any 
> (must ship to Nowhere, Canada).

Alright, I put my money where my mouth is and found an R5K O2 for sale 
in Texas.  Hopefully shipping won't be too much.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@gentoo.org mailing list

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

[Michael Sterrett -Mr. Bones.-]

On Sun, 6 Jan 2008, Ciaran McCreesh wrote:

> So nothing that's a priority for the users of those archs then. Now
> please provide specific examples of how anyone is being held up.

http://bugs.gentoo.org/show_bug.cgi?id=202726

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 5 Jan 2008 20:33:15 -0500 (EST)
"Michael Sterrett -Mr. Bones.-" <msterret@coat.com> wrote:
> On Sun, 6 Jan 2008, Ciaran McCreesh wrote:
> > So nothing that's a priority for the users of those archs then. Now
> > please provide specific examples of how anyone is being held up.
> 
> http://bugs.gentoo.org/show_bug.cgi?id=202726

And what is the impact of that holdup? Have you explained why you
consider that to be a priority to the arch teams in question?

-- 
Ciaran McCreesh

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

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

[Martin Jackson]

> And what is the impact of that holdup? Have you explained why you
> consider that to be a priority to the arch teams in question?
> 

We had a sec bug on net-snmp that was held up due to 
dev-python/setuptools not being ~mips.  The net-snmp folks added a 
python module to their distribution, and I added support to the ebuild 
for it, so now the latest stable net-snmp for mips has a DoS against it.

See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2 months 
for mips to keyword it.

Security bugs are normally supposed to have enhanced priority for 
keywording, etc.

Thanks,
Marty
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 05 Jan 2008 20:18:09 -0600
Martin Jackson <mjolnir@gentoo.org> wrote:
> See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2
> months for mips to keyword it.
> 
> Security bugs are normally supposed to have enhanced priority for 
> keywording, etc.

Perhaps you should have explicitly stated in the bug that it was for
security reasons and thus a priority. Make things easy for the arch
teams -- if you have useful information like that, provide it in an
easy to see place. Looking at that bug, I don't see anything indicating
that there's any reason it should have been considered over more widely
used packages.

-- 
Ciaran McCreesh

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

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

[Martin Jackson]

Ciaran McCreesh wrote:
> On Sat, 05 Jan 2008 20:18:09 -0600
> Martin Jackson <mjolnir@gentoo.org> wrote:
>> See http://bugs.gentoo.org/show_bug.cgi?id=191550 - it took > 2
>> months for mips to keyword it.
>>
>> Security bugs are normally supposed to have enhanced priority for 
>> keywording, etc.
> 
> Perhaps you should have explicitly stated in the bug that it was for
> security reasons and thus a priority. Make things easy for the arch
> teams -- if you have useful information like that, provide it in an
> easy to see place. Looking at that bug, I don't see anything indicating
> that there's any reason it should have been considered over more widely
> used packages.
> 

Because setuptools is not widely used?

The sec bug was (and remains) linked as a blocker.  Is that not explicit 
or easy enough?

Thanks,
Marty
-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Ryan Hill wrote:
>> PS: has anybody checked how viable is now qemu-system ?
> 
> Does it build with GCC 4 yet?

not yet...

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 05 Jan 2008 20:32:09 -0600
Martin Jackson <mjolnir@gentoo.org> wrote:
> > Perhaps you should have explicitly stated in the bug that it was for
> > security reasons and thus a priority. Make things easy for the arch
> > teams -- if you have useful information like that, provide it in an
> > easy to see place. Looking at that bug, I don't see anything
> > indicating that there's any reason it should have been considered
> > over more widely used packages.
> 
> Because setuptools is not widely used?
> 
> The sec bug was (and remains) linked as a blocker.  Is that not
> explicit or easy enough?

When arch people get dozens to hundreds of bug emails per day, no, it's
not. A simple "this is now a security issue, see bug blah" makes it an
awful lot easier for arch people to prioritise -- emails that merely
show blockers added or removed tend to get ignored because a) they're
almost always meaningless changes from the arch team's perspective, and
b) the bug email doesn't convey any useful information on its own
anyway.

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Sat, 05 Jan 2008 18:19:10 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> PS: has anybody checked how viable is now qemu-system ?

Testing on qemu isn't anything like testing on real hardware. It's not
a reliable or useful way of doing arch work.

-- 
Ciaran McCreesh

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

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

[Martin Jackson]

> When arch people get dozens to hundreds of bug emails per day, no, it's
> not. A simple "this is now a security issue, see bug blah" makes it an
> awful lot easier for arch people to prioritise -- emails that merely
> show blockers added or removed tend to get ignored because a) they're
> almost always meaningless changes from the arch team's perspective, and
> b) the bug email doesn't convey any useful information on its own
> anyway.
> 

That's making the assumption that anyone looked at it, of course. Please 
note comment #9 on http://bugs.gentoo.org/show_bug.cgi?id=198346.  It 
was still ~8 days from then that the setuptools keyword was added.

So, we have examples of impact due to delay in keywords/etc.  Shall we 
proceed with the discussion of what to do about it?

Thanks,
Marty

-- 
gentoo-dev@gentoo.org mailing list

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

[Martin Jackson]

Ciaran McCreesh wrote:
> On Sat, 05 Jan 2008 20:32:09 -0600
> Martin Jackson <mjolnir@gentoo.org> wrote:
>>> Perhaps you should have explicitly stated in the bug that it was for
>>> security reasons and thus a priority. Make things easy for the arch
>>> teams -- if you have useful information like that, provide it in an
>>> easy to see place. Looking at that bug, I don't see anything
>>> indicating that there's any reason it should have been considered
>>> over more widely used packages.
>> Because setuptools is not widely used?
>>
>> The sec bug was (and remains) linked as a blocker.  Is that not
>> explicit or easy enough?
> 
> When arch people get dozens to hundreds of bug emails per day, no, it's
> not. A simple "this is now a security issue, see bug blah" makes it an
> awful lot easier for arch people to prioritise -- emails that merely
> show blockers added or removed tend to get ignored because a) they're
> almost always meaningless changes from the arch team's perspective, and
> b) the bug email doesn't convey any useful information on its own
> anyway.
> 

To be clear, the security issue didn't arise until November 7, 2007. 
The request to keyword setuptools was *not* a security issue until then.

Thanks,
Marty
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 05 Jan 2008 20:52:49 -0600
Martin Jackson <mjolnir@gentoo.org> wrote:
> That's making the assumption that anyone looked at it, of course.
> Please note comment #9 on
> http://bugs.gentoo.org/show_bug.cgi?id=198346.  It was still ~8 days
> from then that the setuptools keyword was added.
> 
> So, we have examples of impact due to delay in keywords/etc.  Shall
> we proceed with the discussion of what to do about it?

http://www.gentoo.org/security/en/vulnerability-policy.xml

The target for that GLSA was 20 days. 8 days is well within target.
What are you moaning about?

-- 
Ciaran McCreesh

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

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

[Martin Jackson]

Ciaran McCreesh wrote:
> On Sat, 05 Jan 2008 20:52:49 -0600
> Martin Jackson <mjolnir@gentoo.org> wrote:
>> That's making the assumption that anyone looked at it, of course.
>> Please note comment #9 on
>> http://bugs.gentoo.org/show_bug.cgi?id=198346.  It was still ~8 days
>> from then that the setuptools keyword was added.
>>
>> So, we have examples of impact due to delay in keywords/etc.  Shall
>> we proceed with the discussion of what to do about it?
> 
> http://www.gentoo.org/security/en/vulnerability-policy.xml
> 
> The target for that GLSA was 20 days. 8 days is well within target.
> What are you moaning about?
> 

The original topic of this conversation was about what to do about an 
arch that is obviously not as responsive as other arches.  This is a 
concrete example of that fact, which you requested.  This seems to be a 
topic frequently discussed here.

Who knows how long that request would have languished if not for the 
security bug?  As you said, when there are so many requests and so few 
people to service them, they all have the same priority, unless there's 
something to elevate their priority.

Ciaran, I think you've made my point far more eloquently than I could 
have myself.  Thanks for your time and attention to this matter.

Marty
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Matthias Langer]

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


On Sun, 2008-01-06 at 02:06 +0300, Peter Volkov wrote:
> В Сбт, 05/01/2008 в 18:19 +0100, Luca Barbato пишет:
> > Anything other suggestions?
> 
> I think, arch which does not manage to cope with stabilize bugs force
> users to use unstable branch so it's good both for developers and users
> to force such arch to concentrate on fixing real bugs and maintain only
> unstable branch. Decision to drop stable branch for certain arch should
> be done by council after request and discussion on -dev having
> arch@gentoo.org in CC.
> 

Well, if running mips actually causes more breakage than running ~mips
and if it is unlikely that this will change soon, then the stable
keyword is not just useless, but misleading. In this case, just dropping
it seems the most sensible solution.

Thus it all comes down to a question for mips users/developers: Is mips
any longer more stable than ~mips? Any opinions?
 



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

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

[Ciaran McCreesh]

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

On Sat, 05 Jan 2008 21:35:52 -0600
Martin Jackson <mjolnir@gentoo.org> wrote:
> The original topic of this conversation was about what to do about an 
> arch that is obviously not as responsive as other arches.  This is a 
> concrete example of that fact, which you requested.  This seems to be
> a topic frequently discussed here.

Really, I wanted concrete examples of where there was an actual
problem. Preferably lots of concrete examples, to demonstrate that this
is a systemic thing rather an odd one off issue.

> Who knows how long that request would have languished if not for the 
> security bug?

Who knows indeed... Wouldn't the Council be better served with examples
where we do know? If there's a real problem here, surely it wouldn't be
that hard to produce an extensive list of examples? Ideally each
example would state how often the arch team has been asked, how long
they've had to respond, how clear it has been made to the arch team
that the issue is considered a priority and what the impact of the arch
team not taking action is.

-- 
Ciaran McCreesh

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

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

[Denis Dupeyron]

On Jan 6, 2008 1:33 AM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Sat, 5 Jan 2008 09:03:43 -0500 (EST)
> "Caleb Tennis" <caleb@gentoo.org> wrote:
> > > If anyone has any examples of where they really are being held back
> > > and where they really have given the arch teams plenty of time to do
> > > something, I'd like to see them... Somehow I doubt it happens very
> > > often, if at all.
> >
> > Why?  You aren't the person I or anyone else has to make a case to.
> > In fact, I never would have mailed the list about this to prevent
> > this very type of potentially-out-of-control discussion from
> > occurring, except that the e-mail from Mike said that discussion
> > topics needed to be sent to the list.
>
> Ah, so you'd like the Council to jump to some arbitrary decision,
> rather than hearing specific examples and evidence from all involved?

No. What he meant and doesn't dare to say is you didn't ask, but
demanded, in your usual dry and pesky "I'm a spoiled 6-year old" tone.
And this as usual results in people ignoring you. People aren't as
stupid as you think they are, and they don't want to play this game
with you anymore. So don't build a case on the fact that you're not
getting answers.

Someday you'll understand this.

Oh, and council members too aren't as stupid as you think they are. If
they decide to discuss this, one of their first steps will surely be
to try and evaluate what the current situation is. If I were a council
member I'd probably feel offended by such condescension from your
part.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sun, 6 Jan 2008 10:08:47 +0100
"Denis Dupeyron" <calchan@gentoo.org> wrote:
> No. What he meant and doesn't dare to say is you didn't ask, but
> demanded, in your usual dry and pesky "I'm a spoiled 6-year old" tone.
> And this as usual results in people ignoring you. People aren't as
> stupid as you think they are, and they don't want to play this game
> with you anymore. So don't build a case on the fact that you're not
> getting answers.
> 
> Someday you'll understand this.
> 
> Oh, and council members too aren't as stupid as you think they are. If
> they decide to discuss this, one of their first steps will surely be
> to try and evaluate what the current situation is. If I were a council
> member I'd probably feel offended by such condescension from your
> part.

Ah, so this is what you consider to be solid technical reasoning, is
it? You certainly present a compelling case, but probably not for
the position you were trying to...

-- 
Ciaran McCreesh

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

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

[Peter Volkov]

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

В Сбт, 05/01/2008 в 18:17 -0600, Ryan Hill пишет:
> I don't know, I can kinda see both sides.  Alt arches tend to be finicky 
> so it's important that updates are well tested on them.  Also they're 
> more prone to break during upgrades, not only because they're more 
> fragile but because upstream is far less likely to have tested on them, 
> so I can see why having a stable tree is important.

If this is an issue arch developers should tell us that.

Problems with having slacker archs are: open bugs in bugzilla and old
ebuilds which are unsupported by maintainer[1]. Open bug just takes my
time and attention to open it and to find out that we already fixed that
bug and wait for arch to take their action. Old ebuilds they leave me
without satisfaction and lie to our users - I know that they are broken,
but they are still in the tree and are marked as stable.

Open bugs problem can't be solved until we fix problem with old ebuilds
because ordinary for broken/old ebuilds I keep herd/myself in CC of bug
until it's closed to drop old ebuild from the tree.

And for me the problem with old ebuilds could be solved if I could drop
keywords from old ebuilds. Then I could remove herd/myself from CC to
bug. Also if council decide this way I'd like to see recommendation for
slacker arch to drop old ebuild (with none keywords except ~arch) from
the tree by themselves as soon as they stabilize new version.

[1] And security problem could be solved by labeling arch as security
unsupported.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 05 Jan 2008 18:19:10 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> PS: has anybody checked how viable is now qemu-system ?
> 
> Testing on qemu isn't anything like testing on real hardware. It's not
> a reliable or useful way of doing arch work.
> 
We ALL know that the right way is to build on the target hw, test on the
hw and do that in a TIMELY manner.

Now, since seems that certain arches do not have enough hw or people
which are the workaround to have stuff tested to a minimum in time?

- emulate such hardware if you don't own it
- use cross-distcc if you have the hardware but takes ages to build or
just requires too much power.
- use qemu-system or qemu-softmmu if you don't have access to the hw.


lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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

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

[Matthias Langer]

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


On Sun, 2008-01-06 at 09:12 +0000, Ciaran McCreesh wrote:
> On Sun, 6 Jan 2008 10:08:47 +0100
> "Denis Dupeyron" <calchan@gentoo.org> wrote:
> > No. What he meant and doesn't dare to say is you didn't ask, but
> > demanded, in your usual dry and pesky "I'm a spoiled 6-year old" tone.
> > And this as usual results in people ignoring you. People aren't as
> > stupid as you think they are, and they don't want to play this game
> > with you anymore. So don't build a case on the fact that you're not
> > getting answers.
> > 
> > Someday you'll understand this.
> > 
> > Oh, and council members too aren't as stupid as you think they are. If
> > they decide to discuss this, one of their first steps will surely be
> > to try and evaluate what the current situation is. If I were a council
> > member I'd probably feel offended by such condescension from your
> > part.
> 
> Ah, so this is what you consider to be solid technical reasoning, is
> it? You certainly present a compelling case, but probably not for
> the position you were trying to...
> 

This kind of conversation is not technical at all... Ciaranm, are you a
MIPS user? If so, do you think that running KEYWORDS="mips" is less
likely to result in breakage than running KEYWORDS="~mips"?

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

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

[Piotr Jaroszyński]

On Sunday 06 of January 2008 13:04:13 Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > On Sat, 05 Jan 2008 18:19:10 +0100
> >
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> PS: has anybody checked how viable is now qemu-system ?
> >
> > Testing on qemu isn't anything like testing on real hardware. It's not
> > a reliable or useful way of doing arch work.
>
> We ALL know that the right way is to build on the target hw, test on the
> hw and do that in a TIMELY manner.
>
> Now, since seems that certain arches do not have enough hw or people
> which are the workaround to have stuff tested to a minimum in time?
>
> - emulate such hardware if you don't own it
> - use cross-distcc if you have the hardware but takes ages to build or
> just requires too much power.
> - use qemu-system or qemu-softmmu if you don't have access to the hw.

Might as well toss a coin or check the phase of the moon...

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@lists.gentoo.org mailing list

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

[Luca Barbato]

Piotr Jaroszyński wrote:
> Might as well toss a coin or check the phase of the moon...

Forgot those and dropping mips from the main repo as whole, yes.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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

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

[Ryan Hill]

Ciaran McCreesh wrote:
> "Caleb Tennis" <caleb@gentoo.org> wrote:
>>> If anyone has any examples of where they really are being held back
>>> and where they really have given the arch teams plenty of time to do
>>> something, I'd like to see them... Somehow I doubt it happens very
>>> often, if at all.
>> Why?  You aren't the person I or anyone else has to make a case to.
>> In fact, I never would have mailed the list about this to prevent
>> this very type of potentially-out-of-control discussion from
>> occurring, except that the e-mail from Mike said that discussion
>> topics needed to be sent to the list.
> 
> Ah, so you'd like the Council to jump to some arbitrary decision,
> rather than hearing specific examples and evidence from all involved?
> 
> How will providing specific examples of how people are being held up
> not be beneficial to the decision-making process?

First you have to acknowledge that old perpetually open bugs and old 
unmaintained ebuilds are a maintenance burden.  There seems to be a 
consensus among maintainers that they are, but when given the examples 
of xfce and media-* you responded that those are not a priority for the 
archs in question.  Well, that's nice, but they are for the maintainers 
of those herds and that's what we're talking about.  We're not actively 
looking for ways to dump more work on the arch teams, but we're also 
tired of having more work dumped on us.  We're looking for a solution 
that has both sides happy here, but that won't happen if you don't admit 
there's a problem.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

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

[Ciaran McCreesh]

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

On Sun, 06 Jan 2008 11:36:06 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> > How will providing specific examples of how people are being held up
> > not be beneficial to the decision-making process?
> 
> First you have to acknowledge that old perpetually open bugs and old 
> unmaintained ebuilds are a maintenance burden.  There seems to be a 
> consensus among maintainers that they are, but when given the
> examples of xfce and media-* you responded that those are not a
> priority for the archs in question.  Well, that's nice, but they are
> for the maintainers of those herds and that's what we're talking
> about.  We're not actively looking for ways to dump more work on the
> arch teams, but we're also tired of having more work dumped on us.
> We're looking for a solution that has both sides happy here, but that
> won't happen if you don't admit there's a problem.

Ok, so explain:

* How perpetually open bugs are a maintenance burden. They don't
generate emails and they don't require any work on the maintainer's
part. Is the mere fact that they show up in queries all you're
concerned about, and if so, have you considered either adapting your
queries or requesting a special keyword to make such bugs easier to
filter?

* How unmaintained ebuilds are a maintenance burden. Doesn't that
contradict itself?

-- 
Ciaran McCreesh

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

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

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>:
> > Who knows how long that request would have languished if not for
> > the security bug?
> Who knows indeed... Wouldn't the Council be better served with
> examples where we do know? 

<URL:http://tinyurl.com/ypoxyg> is a list of closed security bugs where
mips is still cced.  163 is the total number, where surely some
duplicates can be found (PHP, Mozilla products), but we can assume that
quite an extensive number of packages which are vulnerable stay still
in the tree.
 Normal policy is to remove all vulnerable ebuilds which is not
possible if a vulnerable version is the only one keyworded mips.  This
would break an even bigger rule.
 We are not here to accuse anyone but to find a solution to this
problem...and no, I am not in the (financial) position to buy MIPS
hardware nor am I really interested in having it.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

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

[Ciaran McCreesh]

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

On Sun, 06 Jan 2008 14:09:24 +0100
Matthias Langer <mlangc@gmx.at> wrote:
> This kind of conversation is not technical at all... Ciaranm, are you
> a MIPS user? If so, do you think that running KEYWORDS="mips" is less
> likely to result in breakage than running KEYWORDS="~mips"?

I think you'd need a much larger sample than one to get any meaningful
answer there (and it might be worth doing it across all other archs
too, to find out whether mips is in any way anomalous).

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Mon, 7 Jan 2008 00:35:41 +0100
Christian Faulhammer <opfer@gentoo.org> wrote:
> <URL:http://tinyurl.com/ypoxyg> is a list of closed security bugs
> where mips is still cced.  163 is the total number, where surely some
> duplicates can be found (PHP, Mozilla products), but we can assume
> that quite an extensive number of packages which are vulnerable stay
> still in the tree.

And how many of those have been fixed on mips without the Cc: being
removed? How many more of those would have been fixed had the bug not
been closed off?

-- 
Ciaran McCreesh

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

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

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>:

> On Mon, 7 Jan 2008 00:35:41 +0100
> Christian Faulhammer <opfer@gentoo.org> wrote:
> > <URL:http://tinyurl.com/ypoxyg> is a list of closed security bugs
> > where mips is still cced.  163 is the total number, where surely
> > some duplicates can be found (PHP, Mozilla products), but we can
> > assume that quite an extensive number of packages which are
> > vulnerable stay still in the tree.
> And how many of those have been fixed on mips without the Cc: being
> removed? How many more of those would have been fixed had the bug not
> been closed off?

 As you are so interested in those numbers, I humbly leave it to you
to investigate in depth because I have to run a business.  
 A quick check on the 15 newest bugs showed exactly 1 package where
mips was not lagging behind, where out of these only 2 are X
applications.  The bugs reach back until mid-November 2007 (CC date for
arches).
 For the sake of fairness I took 15 bugs in a row from 170000 and
greater.  Where mips lagging behind in 4 packages (from April 2007,
1 X application), 2 packages where mips has been dropped completely
(MySQL 5 e.g.).

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

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

[Petteri Räty]

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

Christian Faulhammer kirjoitti:
> Hi,
> 
> Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>:
> 
>> On Mon, 7 Jan 2008 00:35:41 +0100
>> Christian Faulhammer <opfer@gentoo.org> wrote:
>>> <URL:http://tinyurl.com/ypoxyg> is a list of closed security bugs
>>> where mips is still cced.  163 is the total number, where surely
>>> some duplicates can be found (PHP, Mozilla products), but we can
>>> assume that quite an extensive number of packages which are
>>> vulnerable stay still in the tree.
>> And how many of those have been fixed on mips without the Cc: being
>> removed? How many more of those would have been fixed had the bug not
>> been closed off?
> 
>  As you are so interested in those numbers, I humbly leave it to you
> to investigate in depth because I have to run a business.  
>  A quick check on the 15 newest bugs showed exactly 1 package where
> mips was not lagging behind, where out of these only 2 are X
> applications.  The bugs reach back until mid-November 2007 (CC date for
> arches).
>  For the sake of fairness I took 15 bugs in a row from 170000 and
> greater.  Where mips lagging behind in 4 packages (from April 2007,
> 1 X application), 2 packages where mips has been dropped completely
> (MySQL 5 e.g.).
> 
> V-Li
> 

Also let's see the CIA activity of the MIPS team for last month:
kumba: 3 commits
cristel: 0 commits
iluxa: 0 commits
peitolm: 1 commit
psi29: 0 commits
rbrown: 26 commits (None of the commits listed on the page reference mips)
redhatter: 6 commits (Finally some commits mentioning mips)
spb: 1 commit

 From this I would say the mips team is pretty much inactive.

Regards,
Petteri



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

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

[Matthias Langer]

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


On Sun, 2008-01-06 at 23:35 +0000, Ciaran McCreesh wrote:
> On Sun, 06 Jan 2008 14:09:24 +0100
> Matthias Langer <mlangc@gmx.at> wrote:
> > This kind of conversation is not technical at all... Ciaranm, are you
> > a MIPS user? If so, do you think that running KEYWORDS="mips" is less
> > likely to result in breakage than running KEYWORDS="~mips"?
> 
> I think you'd need a much larger sample than one to get any meaningful
> answer there (and it might be worth doing it across all other archs
> too, to find out whether mips is in any way anomalous).

Right, but if everyone I ask gives me an answer like this, it will take
quite a while before we have even two opinions...

As you are engaged in this discussion very heavily, I thought that maybe
you are a occasional MIPS user, that could point out, that for example
removing stable keywords for all MIPS packages, would have a quite
negative impact for most MIPS boxes.

The thing that really bothers me about this discussion is, that there
seems to be almost no input from the people actually affected (users and
developers), which makes the whole thing a bit pointless, unless it
turns out that exactly this is the problem, in which case MIPS support
may be removed entirely without doing any harm.



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

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

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Sat, 05 Jan 2008 20:52:49 -0600
> Martin Jackson <mjolnir@gentoo.org> wrote:
>> That's making the assumption that anyone looked at it, of course.
>> Please note comment #9 on
>> http://bugs.gentoo.org/show_bug.cgi?id=198346.  It was still ~8 days
>> from then that the setuptools keyword was added.
>>
>> So, we have examples of impact due to delay in keywords/etc.  Shall
>> we proceed with the discussion of what to do about it?
> 
> http://www.gentoo.org/security/en/vulnerability-policy.xml
> 
> The target for that GLSA was 20 days. 8 days is well within target.
> What are you moaning about?
> 

Well sqlite has been security vulrenable for two months now 
http://bugs.gentoo.org/show_bug.cgi?id=194812

Here is the comment from security for remaining arch teams to speed 
things up:

http://bugs.gentoo.org/show_bug.cgi?id=194812#c8

Regards,
Petteri


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

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

[Chris Gianelloni]

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

On Sat, 2008-01-05 at 04:32 +0000, Ciaran McCreesh wrote:
> On Fri, 04 Jan 2008 20:20:18 -0800
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > No offense to anyone, but holding back hundreds of developers and
> > thousands of users for a handful of developers
> 
> ...and how exactly are hundreds of developers and thousands of users
> being held back? So far as I can see, in cases where anyone really is
> being held back, the arch teams are quite happy to prioritise -- the
> people who go around moaning about 'slacker archs' rarely if ever
> actually have anything holding them back.
> 
> If anyone has any examples of where they really are being held back and
> where they really have given the arch teams plenty of time to do
> something, I'd like to see them... Somehow I doubt it happens very
> often, if at all.

It happened several times during the 2007.1 release cycle.  Of course, I
don't feel like wasting my time searching bugs to justify myself to you,
so if you're interested, feel free to search on your own.  Pretending it
doesn't happen doesn't make it go away.

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

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

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

[Chris Gianelloni]

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

On Sun, 2008-01-06 at 11:36 -0600, Ryan Hill wrote:
> that has both sides happy here, but that won't happen if you don't admit 
> there's a problem.

He doesn't have to admit anything.  He is neither an ebuild maintainer
nor an arch team developer.  Basically, his opinion is useless in this
case, as *his* work flow is not affected.  As such, I think we can
simply just ignore him.

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

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

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

[Chris Gianelloni]

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

On Sun, 2008-01-06 at 23:34 +0000, Ciaran McCreesh wrote:
> Ok, so explain:
> 
> * How perpetually open bugs are a maintenance burden. They don't
> generate emails and they don't require any work on the maintainer's
> part. Is the mere fact that they show up in queries all you're
> concerned about, and if so, have you considered either adapting your
> queries or requesting a special keyword to make such bugs easier to
> filter?

I have foo 1.0, which is mips.  There is foo 2.0, which is stable
everywhere else.  The foo 1.0 ebuild does not conform to current ebuild
standards.  I want to commit changes to foo 2.0, and repoman won't allow
me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo
1.0, because it's been EOL for 2 years and I've had an open bug for mips
to test the newer version for 2 years.  I've asked several mips team
developers, who all give me the same "we don't have enough
manpower/horsepower to test that right now" excuse.

> * How unmaintained ebuilds are a maintenance burden. Doesn't that
> contradict itself?

When repoman keeps me from being able to commit due to an ebuild that
remains in the tree only for an architecture hardly anyone uses or cares
about, that affects me.

Now, I know that you're just being your usual self-absorbed
argumentative self and I likely shouldn't feed you, but I thought that
answering this might clear it up for the people who don't understand
this as well as you do.

This is especially true since you've been pretty much the main proponent
for keeping things as they are with these slack arches.  I mean, if
vapier can maintain arm/sh/s390, by himself, to a better degree than the
mips *TEAM* can do, that should be an indication of a problem.

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

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

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

[Chris Gianelloni]

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

On Sun, 2008-01-06 at 23:35 +0000, Ciaran McCreesh wrote:
> On Sun, 06 Jan 2008 14:09:24 +0100
> Matthias Langer <mlangc@gmx.at> wrote:
> > This kind of conversation is not technical at all... Ciaranm, are you
> > a MIPS user? If so, do you think that running KEYWORDS="mips" is less
> > likely to result in breakage than running KEYWORDS="~mips"?
> 
> I think you'd need a much larger sample than one to get any meaningful
> answer there (and it might be worth doing it across all other archs
> too, to find out whether mips is in any way anomalous).

Are there even enough users to get a larger sample?  Other than the like
3 devs still working on mips, I thought you were the only actual user.
I mean, I've watched things in "system" get broken on mips and nobody
even notices for several weeks.  There simply can't be that many people
who actually care if nobody even notices when *system* breaks.

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

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

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

[Ciaran McCreesh]

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

On Tue, 08 Jan 2008 14:04:49 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I have foo 1.0, which is mips.  There is foo 2.0, which is stable
> everywhere else.  The foo 1.0 ebuild does not conform to current
> ebuild standards.  I want to commit changes to foo 2.0, and repoman
> won't allow me due to problems in foo 1.0, but I don't want to WASTE
> MY TIME on foo 1.0, because it's been EOL for 2 years and I've had an
> open bug for mips to test the newer version for 2 years.  I've asked
> several mips team developers, who all give me the same "we don't have
> enough manpower/horsepower to test that right now" excuse.

You know what by far the largest cause of repoman not allowing you to
commit because of older versions is? Developers screwing up keywords
because they don't care about certain archs. Things don't mysteriously
break on their own...

> > * How unmaintained ebuilds are a maintenance burden. Doesn't that
> > contradict itself?
> 
> When repoman keeps me from being able to commit due to an ebuild that
> remains in the tree only for an architecture hardly anyone uses or
> cares about, that affects me.

And why does repoman do that?

Oh. Yeah. Because people with an attitude like yours think that the
correct way to fix a repoman message is to start nuking arch keywords,
ignoring what it does to the rest of the tree.

> This is especially true since you've been pretty much the main
> proponent for keeping things as they are with these slack arches.

Perhaps because the people maintaining those archs have better things
to do that deal with the same silly ill-thought-out arguments every
three months.

> I mean, if vapier can maintain arm/sh/s390, by himself, to a better
> degree than the mips *TEAM* can do, that should be an indication of a
> problem.

That's an interesting assertion. Can you back it up?

-- 
Ciaran McCreesh

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 02:17 +0000, Ciaran McCreesh wrote:
> Oh. Yeah. Because people with an attitude like yours think that the
> correct way to fix a repoman message is to start nuking arch keywords,
> ignoring what it does to the rest of the tree.

...for the architecture in question which is proving incapable of
keeping up with the state of the tree as it is...

Sorry, you fail.

> 
> > This is especially true since you've been pretty much the main
> > proponent for keeping things as they are with these slack arches.
> 
> Perhaps because the people maintaining those archs have better things
> to do that deal with the same silly ill-thought-out arguments every
> three months.
> 
> > I mean, if vapier can maintain arm/sh/s390, by himself, to a better
> > degree than the mips *TEAM* can do, that should be an indication of a
> > problem.
> 
> That's an interesting assertion. Can you back it up?

Sure.  You can, too.  Just look at bugs.  If you think I'm taking the
time to do it to justify my statements to YOU, you're sorely mistaken.

Have a nice day,

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Ciaran McCreesh]

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

On Tue, 08 Jan 2008 18:38:07 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Wed, 2008-01-09 at 02:17 +0000, Ciaran McCreesh wrote:
> > Oh. Yeah. Because people with an attitude like yours think that the
> > correct way to fix a repoman message is to start nuking arch
> > keywords, ignoring what it does to the rest of the tree.
> 
> ...for the architecture in question which is proving incapable of
> keeping up with the state of the tree as it is...
> 
> Sorry, you fail.

Uh... So where do the original problems come from? Are you saying that
packages mysteriously start breaking on their own because no-one's
maintaining them?

-- 
Ciaran McCreesh

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

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

[Alec Warner]

On 1/8/08, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Tue, 08 Jan 2008 18:38:07 -0800
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > On Wed, 2008-01-09 at 02:17 +0000, Ciaran McCreesh wrote:
> > > Oh. Yeah. Because people with an attitude like yours think that the
> > > correct way to fix a repoman message is to start nuking arch
> > > keywords, ignoring what it does to the rest of the tree.
> >
> > ...for the architecture in question which is proving incapable of
> > keeping up with the state of the tree as it is...
> >
> > Sorry, you fail.
>
> Uh... So where do the original problems come from? Are you saying that
> packages mysteriously start breaking on their own because no-one's
> maintaining them?

Of course they do
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Tue, 8 Jan 2008 18:44:22 -0800
"Alec Warner" <antarus@gentoo.org> wrote:
> > Uh... So where do the original problems come from? Are you saying
> > that packages mysteriously start breaking on their own because
> > no-one's maintaining them?
> 
> Of course they do

Ah, right. Because of the magical elf that lives in the CVS server
that mysteriously goes around breaking dependencies when no-one's
looking.

Yes, a magical elf. Much more plausible than the theory that it's
actually developers screwing up by dropping keywords or best keyworded
version on a package's deps.

-- 
Ciaran McCreesh

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

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

[Ryan Hill]

Ciaran McCreesh wrote:
> "Alec Warner" <antarus@gentoo.org> wrote:

>>> Uh... So where do the original problems come from? Are you saying
>>> that packages mysteriously start breaking on their own because
>>> no-one's maintaining them?

>> Of course they do

> Ah, right. Because of the magical elf that lives in the CVS server
> that mysteriously goes around breaking dependencies when no-one's
> looking.

Hey, maybe he's the one behind the maintainer-needed bugs we keep 
getting too!  You know, the 250-odd bugs and growing that we have open 
right now on packages that no-one's maintaining.  Fucking elf!


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 02:47 +0000, Ciaran McCreesh wrote:
> On Tue, 8 Jan 2008 18:44:22 -0800
> "Alec Warner" <antarus@gentoo.org> wrote:
> > > Uh... So where do the original problems come from? Are you saying
> > > that packages mysteriously start breaking on their own because
> > > no-one's maintaining them?
> > 
> > Of course they do
> 
> Ah, right. Because of the magical elf that lives in the CVS server
> that mysteriously goes around breaking dependencies when no-one's
> looking.
> 
> Yes, a magical elf. Much more plausible than the theory that it's
> actually developers screwing up by dropping keywords or best keyworded
> version on a package's deps.

Actually, nobody ever said anything about things that magically break.
It's more the things like ebuilds with bad code that can't really be
changed without a revision bump, which would also require the arch team
in question to ACTUALLY DO SOMETHING to make stable.

Seriously, your thinly-veiled attempts at deflecting the conversation to
something that supports your pithy points is laughable.

The issue that was raised is that certain arch teams are incapable of
keeping up with the minimal workload they already have and what should
be done about it.  We want the Council to do something about this issue.
You can deny the issue all that you want or try to deflect conversation
from the actual issue, but your opinion isn't very important to the much
of the current developer pool, seeing as how it doesn't affect you in
any way, having been thrown from the project, and all.

Now, if you have something possibly constructive to add to this
conversation, as a user, feel free, but don't pretend like you're still
a member of the mips team.  You're not.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Matthias Langer]

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


On Wed, 2008-01-09 at 02:47 +0000, Ciaran McCreesh wrote:
> On Tue, 8 Jan 2008 18:44:22 -0800
> "Alec Warner" <antarus@gentoo.org> wrote:
> > > Uh... So where do the original problems come from? Are you saying
> > > that packages mysteriously start breaking on their own because
> > > no-one's maintaining them?
> > 
> > Of course they do
> 
> Ah, right. Because of the magical elf that lives in the CVS server
> that mysteriously goes around breaking dependencies when no-one's
> looking.
> 
> Yes, a magical elf. Much more plausible than the theory that it's
> actually developers screwing up by dropping keywords or best keyworded
> version on a package's deps.

Software that is not maintained is known to fail after some time; not
because the software changes, but the environment the software has to
interact with - but i guess you know that very well.

Really, this discussion is completely pointless unless some mips
users/developers join in - or aren't there any at all?

Matthias

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

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

[Fernando J. Pereda]

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

On Thu, Jan 03, 2008 at 08:02:39AM -0500, Caleb Tennis 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 like to request the council discuss, though not necessarily take action or
> vote on, the idea of "slacker arches" and what ebuild maintainers are allowed/can do
> to a package versions that are languishing due to not getting stable keywords on
> those arches.
> 
> I'm not trying to pick on any specific case, but I am hoping to find out if there's
> an allowable/acceptable period of time to which if an arch team is unable to
> stabilize a package to a newer version, for non-technical reasons, that it's okay to
> drop older unstable ebuilds.

Why taking it against arch teams? How is that different from "certain
maintainer not taking care of a bug that holds stabilization of certain
package by some time measured in months" ? I'll tell you my answer: 'no
difference at all'.

Note that I'm probably responsible for some real situations related to
what I said both as an ebuild maintainer and as an arch developer. So
nobody should take this as slacker-calling since we are all VOLUNTEERS
and we do what we want. However, a fine example of that is:
http://bugs.gentoo.org/show_bug.cgi?id=181275

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

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

[Caleb Tennis]

> Why taking it against arch teams? How is that different from "certain
> maintainer not taking care of a bug that holds stabilization of certain
> package by some time measured in months" ? I'll tell you my answer: 'no
> difference at all'.

You are right, there's not much difference.  However, I brought up the topic because
I felt like this particular situation was a bit of a problem that needed to be
addressed.  Yours is also one that can/should potentially be addressed, and I advise
you to recommend the council discuss it as well.

My goal wasn't to point fingers or to call anyone lazy.  My goal was to address that
if development in this certain area has stagnated, how can those of us who it
affects continue to move forward?  This is simply an area that is "gray" and needs
to be discussed.  There are many other gray areas that need to be discussed too.

I understand we all have real lives and are volunteers.  But if there are areas that
we are responsible for and we aren't able to meet the needs/demands of the other
developers in those areas, it's only fair to let them continue moving forward.

I never even mentioned any specific arch in my original request, nor did I call any
developer out.  So please, nobody needs to take this personally.

Caleb

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

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

[Christian Faulhammer]

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

Hi,

Christian Faulhammer <opfer@gentoo.org>:
>  A quick check [...]

 Hereby you have proven that you are not interested about
real arguments...some people have tried to gather facts and you pick
those that maybe have a weak reasoning or come from people you know how
to upset.  Congratulations.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 15:37:47 +0100
Christian Faulhammer <opfer@gentoo.org> wrote:
> Christian Faulhammer <opfer@gentoo.org>:
> >  A quick check [...]
> 
>  Hereby you have proven that you are not interested about
> real arguments...some people have tried to gather facts and you pick
> those that maybe have a weak reasoning or come from people you know
> how to upset.  Congratulations.

Actually, I've taken to ignoring people who're just outright wrong.

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Tue, 08 Jan 2008 18:59:29 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> The issue that was raised is that certain arch teams are incapable of
> keeping up with the minimal workload they already have and what should
> be done about it.

The issue was raised, with absolutely no proof or justification, and
every previous time said issue has been raised it's turned out to be
somewhere between highly misleading and utter bollocks.

> We want the Council to do something about this issue. You can deny
> the issue all that you want or try to deflect conversation from the
> actual issue, but your opinion isn't very important to the much of
> the current developer pool, seeing as how it doesn't affect you in
> any way, having been thrown from the project, and all.

Ah, so now what matters is who says something, not whether or not it's
true.

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 04:11:58 +0100
Matthias Langer <mlangc@gmx.at> wrote:
> Really, this discussion is completely pointless unless some mips
> users/developers join in - or aren't there any at all?

I'd imagine most of them are staying well clear of it because they've
already seen this discussion a dozen times before and know that it's
just the usual malcontents going around making largely bogus claims and
backing them up with lots of thinly veiled mips bashing rather than
anything relevant...

-- 
Ciaran McCreesh

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

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

[Alec Warner]

On 1/8/08, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Tue, 8 Jan 2008 18:44:22 -0800
> "Alec Warner" <antarus@gentoo.org> wrote:
> > > Uh... So where do the original problems come from? Are you saying
> > > that packages mysteriously start breaking on their own because
> > > no-one's maintaining them?
> >
> > Of course they do
>
> Ah, right. Because of the magical elf that lives in the CVS server
> that mysteriously goes around breaking dependencies when no-one's
> looking.
>
> Yes, a magical elf. Much more plausible than the theory that it's
> actually developers screwing up by dropping keywords or best keyworded
> version on a package's deps.

I was going to go with 'the stable glibc changed' or 'some lib this
software depended on was updated to a new version' or any other action
that could cause software to not work as intended.

I'm not trying to make the argument that developers don't screw up.
Certainly mr_bones can attest that they do it on a daily basis.

I think the argument here is that developers control ebuilds.  If a
given ebuild is causing 'trouble' for a maintainer it is within their
control to remove the ebuild.  Just as if a given package is causing
the maintainer grief it can be deleted from the tree, so can keywords
for a given arch be removed for a given ebuild (and possibly that
ebuild removed because it is known to be old and buggy.)

If the arch team wants that ebuild in the tree they should do some
work to keep a given package up to date in terms of other arches or we
should define some sort of metadata that notifies people that the arch
team is the 'maintainer' for a given version of a package.

I agree that you should not break the arch's tree by removing a given
package (or it's last stable ebuild).
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 06:58:40 -0800
"Alec Warner" <antarus@gentoo.org> wrote:
> I think the argument here is that developers control ebuilds.  If a
> given ebuild is causing 'trouble' for a maintainer it is within their
> control to remove the ebuild.  Just as if a given package is causing
> the maintainer grief it can be deleted from the tree, so can keywords
> for a given arch be removed for a given ebuild (and possibly that
> ebuild removed because it is known to be old and buggy.)
> 
> If the arch team wants that ebuild in the tree they should do some
> work to keep a given package up to date in terms of other arches or we
> should define some sort of metadata that notifies people that the arch
> team is the 'maintainer' for a given version of a package.

The problem is this: the impact upon an arch of dekeywording something
is almost always far higher than the impact of leaving things the way
they are. And even if, like some people here, you don't care about the
arch, the impact upon the rest of the tree when you dekeyword is often
massive. If, for example, an arch were to have their last stable
keyword of something like gtk+ removed by a developer who did it in
order to 'fix' a repoman message, a very large number of other
developers would then end up with a far bigger repoman mess.

Heck, most of the repoman messages people are moaning about are caused
by developers doing exactly this.

-- 
Ciaran McCreesh

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

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

[Fernando J. Pereda]

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

On Wed, Jan 09, 2008 at 09:25:11AM -0500, Caleb Tennis wrote:
> > Why taking it against arch teams? How is that different from
> > "certain maintainer not taking care of a bug that holds
> > stabilization of certain package by some time measured in months" ?
> > I'll tell you my answer: 'no difference at all'.
>
> You are right, there's not much difference.  However, I brought up the
> topic because I felt like this particular situation was a bit of a
> problem that needed to be addressed.  Yours is also one that
> can/should potentially be addressed, and I advise you to recommend the
> council discuss it as well.

Well, while discussing what you brought up, they should _also_ consider
what I said as part of the same (so-called) problem.

> My goal wasn't to point fingers or to call anyone lazy.  My goal was
> to address that if development in this certain area has stagnated, how
> can those of us who it affects continue to move forward?  This is
> simply an area that is "gray" and needs to be discussed.  There are
> many other gray areas that need to be discussed too.
>
> I understand we all have real lives and are volunteers.  But if there
> are areas that we are responsible for and we aren't able to meet the
> needs/demands of the other developers in those areas, it's only fair
> to let them continue moving forward.
>
> I never even mentioned any specific arch in my original request, nor
> did I call any developer out.  So please, nobody needs to take this
> personally.

I didn't take it personally myself, honestly, I couldn't care less.

Wonder why there is almost no non-mainstream arch team people
contributing to this thread?

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

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

[Caleb Tennis]

> I'd imagine most of them are staying well clear of it because they've
> already seen this discussion a dozen times before and know that it's
> just the usual malcontents going around making largely bogus claims and
> backing them up with lots of thinly veiled mips bashing rather than
> anything relevant...

Your demand for evidence in this thread doesn't seem balanced with your ability to
only offer speculation.

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

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

[Caleb Tennis]

> The issue was raised, with absolutely no proof or justification, and
> every previous time said issue has been raised it's turned out to be
> somewhere between highly misleading and utter bollocks.

Let's assume that you are right, and that dropping keywords is not a proper thing to
do.

What's the proper fix for when keyword requests stagnate in bugzilla?  If the arch
team in question was to completely disband and stop all keywording today, then
you're suggesting the proper thing to do is to never remove the ebuild from portage
that has keywords for that arch?

And thus, the current system of filing a stabilization request and waiting
indefinitely is sufficient?

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

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 10:36:13 -0500 (EST)
"Caleb Tennis" <caleb@gentoo.org> wrote:
> > The issue was raised, with absolutely no proof or justification, and
> > every previous time said issue has been raised it's turned out to be
> > somewhere between highly misleading and utter bollocks.
> 
> Let's assume that you are right, and that dropping keywords is not a
> proper thing to do.
> 
> What's the proper fix for when keyword requests stagnate in
> bugzilla?

That depends upon whether the keyword request is important. If it isn't,
you wait for the arch team to get around to it. If it is (and
legitimately so -- we're not talking spurious "I want to remove this
old version that doesn't affect anything, that works fine and isn't
causing any problems beyond it existing" here), you ask the arch team to
prioritise it, explaining why.

> If the arch team in question was to completely disband and
> stop all keywording today, then you're suggesting the proper thing to
> do is to never remove the ebuild from portage that has keywords for
> that arch?

If that ever comes remotely close to happening then the issue can be
raised when it does. You might as well ask what would happen if
suddenly all the KDE maintainers disappeared.

-- 
Ciaran McCreesh

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

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

[Wulf C. Krueger]

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

Hello Ciaran!

>> What's the proper fix for when keyword requests stagnate in
>> bugzilla?
> That depends upon whether the keyword request is important.

Let's take a real world example: KDE 3.5.5 is old, buggy and has some  
important issues which won't be fixed anymore.

At first, this wasn't too important, so we did what you suggested:

> If it isn't, you wait for the arch team to get around to it.

Nothing happened for months.

> If it is (and legitimately so

I hope you'll accept it when I say that 3.5.5 is such a legitimate case now.

> you ask the arch team to prioritise it, explaining why.

We did this. We asked on Bugzilla, by mail, I explained it in  
#gentoo-mips and in /queries. Nothing happened for months.

What would you suggest to do now? I think we've done all we could  
short of the following:

a) Drop all keywords but those of mips. Leaves mips and, more  
importantly, its users with a vulnerable and unmaintained set of  
packages.

b) package.mask 3.5.5 with a big, fat warning and let the users  
decide. Same drawbacks as a).

c) Drop 3.5.5 from the tree. The cleanest but most radical solution.  
If mips' users want KDE, they would have to bug (sic!) the mips team.

The solution I favour by far is c). What's your suggestion or did I  
miss any other viable solution? Just doing nothing is not an option  
here, I'd say, but state your case.

Best regards, Wulf

[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 17:49:40 +0100
"Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> >> What's the proper fix for when keyword requests stagnate in
> >> bugzilla?
> > That depends upon whether the keyword request is important.
> 
> Let's take a real world example: KDE 3.5.5 is old, buggy and has
> some important issues which won't be fixed anymore.

Yet it's the most proven version on mips.

> > If it is (and legitimately so
> 
> I hope you'll accept it when I say that 3.5.5 is such a legitimate
> case now.

Why? It was good enough to be keyworded stable at one point.

> What would you suggest to do now? I think we've done all we could  
> short of the following:
> 
> a) Drop all keywords but those of mips. Leaves mips and, more  
> importantly, its users with a vulnerable and unmaintained set of  
> packages.

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

> b) package.mask 3.5.5 with a big, fat warning and let the users  
> decide. Same drawbacks as a).

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

> c) Drop 3.5.5 from the tree. The cleanest but most radical solution.  
> If mips' users want KDE, they would have to bug (sic!) the mips team.

...and break the tree spectacularly, causing huge amounts of pain for
your fellow developers when they encounter horrible repoman output when
they try to do anything.

> The solution I favour by far is c). What's your suggestion or did I  
> miss any other viable solution? Just doing nothing is not an option  
> here, I'd say, but state your case.

3.5.5 was good enough to be keyworded stable at one point. Thus, it
can't be *that* bad.

-- 
Ciaran McCreesh

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

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

[Richard Freeman]

I wanted to take this thread in a slightly different direction so that 
the council has a little more to work with tomorrow.  Obviously there 
are multiple opinions on whether a problem currently exists - and the 
council will need to decide on this.  If no problem currently exists 
they will likely take no action.  However, if a problem does exist, what 
would be a reasonable solution?

Here's a proposal.  Maybe not a great one - feel free to come up with 
others (other than just do nothing - if we are going to do nothing we 
don't need to work out what that will be).  I think it gives arch teams 
a fair amount of time to keep up with stable requests, but also allows 
package maintainers to eventually get rid of cruft.  The exact 
timeframes are of course the easiest and most obvious things to modify.

My hope is that this will give everybody something to think about so 
that if a decision to enact policy is made tomorrow the policy is a good 
one...


Ebuild Stabilization Time

Arch teams will normally have until the LATER of the following two dates 
to stabilize ebuilds for non-security-related issues:
1.  60 days from the day the last substantial change was made to the 
ebuild (clock resets if a non-trivial change is made to the ebuild). 
That's 30 days to allow the package to be proven stable, and 30 days to 
do something about it.
2.  30 days from the day a bug was filed and keyworded STABLEREQ and the 
arch was CCed and the maintainer either filed the bug or commented that 
it was OK to stabilize (clock starts when all of these conditions are met).

Perhaps the guideline should be one week on both time periods for 
security bugs.


Technical Problems With Ebuild Revisions

If an arch team finds a technical problem with an ebuild preventing 
stabilization a bug will be logged as a blocker for the stable keyword 
request.  The bug being resolved counts as a substantial change for the 
purpose of #1 above.


Removing Stable Ebuilds.

If an ebuild meets the time criteria above and there are no technical 
issues preventing stabilization, then the maintainer MAY choose to 
delete an older version even if it is the most recent stable version for 
a particular arch.

If an ebuild meets the time criteria and there IS a technical problem 
preventing stabilization, but the package is subject to security issues, 
the maintainer MAY choose to mask the vulnerable versions in package.mask.

If an ebuild does not meet the time criteria or there is a technical 
problem preventing stabilization and there isn't an outstanding security 
issue, then the maintainer must not remove the highest-versioned stable 
ebuild for any given arch.


Spirit of Cooperation

Ebuild maintainers and arch teams are encouraged to work together for 
the sake of each other and end users in facilitating the testing and 
maintenance of ebuilds on obscure hardware or where obscure expertise is 
needed.  Package maintainers are encouraged to use discretion when 
removing ebuilds in accordance with this policy.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Fernando J. Pereda]

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

On Wed, Jan 09, 2008 at 12:11:47PM -0500, Richard Freeman wrote:
> snip

Simply put: No, thank you.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 12:11:47 -0500
Richard Freeman <rich0@gentoo.org> wrote:
> If an ebuild meets the time criteria above and there are no technical 
> issues preventing stabilization, then the maintainer MAY choose to 
> delete an older version even if it is the most recent stable version
> for a particular arch.

...and as soon as they do, everyone gets hit by pages and pages of
repoman output, and users get royally humped. Developers doing this
is by far the most common cause for people getting hit by the repoman
thing.

-- 
Ciaran McCreesh

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

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

[Wulf C. Krueger]

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

Hello Ciaran!

(On a totally unrelated side-note - how do you pronounce your name?)

>> Let's take a real world example: KDE 3.5.5 is old, buggy and has
>> some important issues which won't be fixed anymore.
> Yet it's the most proven version on mips.

Yes.

> ...and break the tree spectacularly, causing huge amounts of pain for
> your fellow developers when they encounter horrible repoman output when
> they try to do anything.

Yes, all three solutions would have disadvantages for some, indeed.

>> The solution I favour by far is c). What's your suggestion [...]

Unfortunately, you didn't explicitly answer this so I gather you're in  
favour of just keeping 3.5.5 around?

> 3.5.5 was good enough to be keyworded stable at one point. Thus, it
> can't be *that* bad.

Yes, because at that time, many of those issues, some of which are  
security ones, simply weren't known at that point. Security issues  
tend not to be known from the start (or they wouldn't exist at all :-)  
) but can turn up at any later time. This is the case for KDE 3.5.5.

-- 
Best regards, Wulf "grateful for an answer, remembering you declared  
to completely ignore morons ;-)" Krüger

[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Roy Marples]

On Wed, 2008-01-09 at 17:01 +0000, Ciaran McCreesh wrote:
> 3.5.5 was good enough to be keyworded stable at one point. Thus, it
> can't be *that* bad.

So what happens if a flaw is discovered in KDE 3.5.5 that allows root
access?

In your world you allow mips users to trivially install now flawed and
insecure software, instead of having to add
to /etc/portage/package.keywords or package.unmask

Yes, this breaks their tree, but it's fixable from the users end as we
can rest in the knowledge that mips users have acknowledged the security
flaw by adding the package to the above mentioned files.

Thanks

Roy

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

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

[Jan Kundrát]

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

Chris Gianelloni wrote:
> I have foo 1.0, which is mips.  There is foo 2.0, which is stable
> everywhere else.  The foo 1.0 ebuild does not conform to current ebuild
> standards.  I want to commit changes to foo 2.0, and repoman won't allow
> me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo
> 1.0, because it's been EOL for 2 years

Why don't fix repoman not to scream about such issues, then?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

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

[Alec Warner]

On 1/9/08, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Wed, 09 Jan 2008 17:49:40 +0100
> "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> > >> What's the proper fix for when keyword requests stagnate in
> > >> bugzilla?
> > > That depends upon whether the keyword request is important.
> >
> > Let's take a real world example: KDE 3.5.5 is old, buggy and has
> > some important issues which won't be fixed anymore.
>
> Yet it's the most proven version on mips.
>
> > > If it is (and legitimately so
> >
> > I hope you'll accept it when I say that 3.5.5 is such a legitimate
> > case now.
>
> Why? It was good enough to be keyworded stable at one point.
>
> > What would you suggest to do now? I think we've done all we could
> > short of the following:
> >
> > a) Drop all keywords but those of mips. Leaves mips and, more
> > importantly, its users with a vulnerable and unmaintained set of
> > packages.
>
> ...and break the tree spectacularly, causing huge amounts of pain for
> your fellow developers when they encounter horrible repoman output when
> they try to do anything.
>
> > b) package.mask 3.5.5 with a big, fat warning and let the users
> > decide. Same drawbacks as a).
>
> ...and break the tree spectacularly, causing huge amounts of pain for
> your fellow developers when they encounter horrible repoman output when
> they try to do anything.
>
> > c) Drop 3.5.5 from the tree. The cleanest but most radical solution.
> > If mips' users want KDE, they would have to bug (sic!) the mips team.
>
> ...and break the tree spectacularly, causing huge amounts of pain for
> your fellow developers when they encounter horrible repoman output when
> they try to do anything.

Actually if they dump kde-3.5.5 and anything depending on it, then
they don't break the tree and everyone is happy, no?
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 10:07:31 -0800
"Alec Warner" <antarus@gentoo.org> wrote:
> Actually if they dump kde-3.5.5 and anything depending on it, then
> they don't break the tree and everyone is happy, no?

Everyone except the users, who end up with pages and pages of horrible
Portage output...

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 17:27:52 +0000
Roy Marples <roy@marples.name> wrote:
> On Wed, 2008-01-09 at 17:01 +0000, Ciaran McCreesh wrote:
> > 3.5.5 was good enough to be keyworded stable at one point. Thus, it
> > can't be *that* bad.
> 
> So what happens if a flaw is discovered in KDE 3.5.5 that allows root
> access?

Then the one particular part of 3.5.5 that's affected gets fixed and
priority keyworded.

-- 
Ciaran McCreesh

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

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

[Wulf C. Krueger]

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

On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
> > So what happens if a flaw is discovered in KDE 3.5.5 that allows root
> > access?
> Then the one particular part of 3.5.5 that's affected gets fixed and
> priority keyworded.

So you suggest that mips keeps doing nothing and expect others to work 
*more* in exchange for that?

-- 
Best regards, Wulf

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

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 19:29:53 +0100
"Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
> > > So what happens if a flaw is discovered in KDE 3.5.5 that allows
> > > root access?
> > Then the one particular part of 3.5.5 that's affected gets fixed and
> > priority keyworded.
> 
> So you suggest that mips keeps doing nothing and expect others to
> work *more* in exchange for that?

Well, most users will simply ignore or postpone the mass upgrade, so
yes. Forcing a mass upgrade is rarely if ever the correct solution to
any security issue.

-- 
Ciaran McCreesh

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

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

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Tue, 08 Jan 2008 18:59:29 -0800
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> The issue that was raised is that certain arch teams are incapable of
>> keeping up with the minimal workload they already have and what should
>> be done about it.
> 
> The issue was raised, with absolutely no proof or justification, and
> every previous time said issue has been raised it's turned out to be
> somewhere between highly misleading and utter bollocks.
> 

So you just ignore for example my post about CIA activity for the mips team?

Regards,
Petteri


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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 20:50:38 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> So you just ignore for example my post about CIA activity for the
> mips team?

That falls into the highly misleading category.

-- 
Ciaran McCreesh

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

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

[Wulf C. Krueger]

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

On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
> > > Then the one particular part of 3.5.5 that's affected gets fixed
> > > and priority keyworded.
> > So you suggest that mips keeps doing nothing and expect others to
> > work *more* in exchange for that?
> Well, most users will simply ignore or postpone the mass upgrade, 

So far so good. If users postpone it, that's entirely their 
responsibility.

> so yes. 

That's not so good, though, and where we really disagree. Thanks for the 
straight answer, though. 

In my book, it's not acceptable to not do one's job properly and by that  
force others to do more. You basically told me the same when I suggested 
likewise measures against mips. :-)

The only difference being that we supported KDE 3.5.5 for a long time and 
gave mips months to get up to speed again.

> Forcing a mass upgrade is rarely if ever the correct solution to 
> any security issue.

I absolutely agree. This, IMO, is such a case, though.

-- 
Best regards, Wulf

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

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

[Ciaran McCreesh]

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

On Wed, 9 Jan 2008 20:06:00 +0100
"Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
> > > > Then the one particular part of 3.5.5 that's affected gets fixed
> > > > and priority keyworded.
> > > So you suggest that mips keeps doing nothing and expect others to
> > > work *more* in exchange for that?
> > Well, most users will simply ignore or postpone the mass upgrade, 
> 
> So far so good. If users postpone it, that's entirely their 
> responsibility.

It's all very well to say that, but which do you care about? Covering
your ass and claiming that you have a secure distribution, or the
security of end user systems?

-- 
Ciaran McCreesh

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

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

[Roy Marples]

On Wednesday 09 January 2008 18:16:24 Ciaran McCreesh wrote:
> On Wed, 09 Jan 2008 17:27:52 +0000
>
> Roy Marples <roy@marples.name> wrote:
> > On Wed, 2008-01-09 at 17:01 +0000, Ciaran McCreesh wrote:
> > > 3.5.5 was good enough to be keyworded stable at one point. Thus, it
> > > can't be *that* bad.
> >
> > So what happens if a flaw is discovered in KDE 3.5.5 that allows root
> > access?
>
> Then the one particular part of 3.5.5 that's affected gets fixed and
> priority keyworded.

Lets say that there's just 3.5.5 and 3.5.8 in the tree.
3.5.5 is keyworded stable mips
3.5.8 doesn't have the mips keyword because it's horribly broken on mips

A security flaw is discovered in 3.5.5, the solution is to upgrade to 3.5.8.
This flaw involves code that has radically changed from 3.5.5 to 3.5.8. For 
the sake of argument say it will take 1 month of time for anyone to create a 
patch for 3.5.5 that fixes the flaw OR makes 3.5.8 magically work on mips.

During this month, what do you propose happens to the end user?

The choices are
1) Carry on as we are, user is blissfully unaware of security flaw and doesn't 
have time to read GLSA's, etc has he's busy with real life thereby giving 
Gentoo the reputation of shipping insecure software.
2) Force the user to spend a few minutes adding 3.5.5 to a package.unmask, 
thereby acknowledging the security flaw but by his own choice keeping the 
highly insecure software.

Thanks

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

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

[Vlastimil Babka]

Ciaran McCreesh wrote:
>> a) Drop all keywords but those of mips. Leaves mips and, more  
>> importantly, its users with a vulnerable and unmaintained set of  
>> packages.
> 
> ...and break the tree spectacularly, causing huge amounts of pain for
> your fellow developers when they encounter horrible repoman output when
> they try to do anything.

Can somebody clarify to me why would it cause this? Maybe I just miss 
something.

VB
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Pierre-Yves Rofes]

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

Ciaran McCreesh a écrit :
> On Wed, 9 Jan 2008 20:06:00 +0100
> "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
>> On Wednesday, 09. January 2008 19:45:38 Ciaran McCreesh wrote:
>>>>> Then the one particular part of 3.5.5 that's affected gets fixed
>>>>> and priority keyworded.
>>>> So you suggest that mips keeps doing nothing and expect others to
>>>> work *more* in exchange for that?
>>> Well, most users will simply ignore or postpone the mass upgrade, 
>> So far so good. If users postpone it, that's entirely their 
>> responsibility.
> 
> It's all very well to say that, but which do you care about? Covering
> your ass and claiming that you have a secure distribution, or the
> security of end user systems?
> 

And what's the point in caring about the security of users systems, when
some of them don't care themselves in the first place? Remember, Gentoo
is all about choices. If users choose to skip security updates, it's up
to them and there's nothing you can do to change it. When their boxes
get rooted due to unpatched vulnerabilities, maybe they'll change their
mind. Ok, I admit that a few dumbasses will claim that Gentoo sucks and
switch to another distro instead, but hey, that's just the way it is.

- --
Pierre-Yves Rofes
Gentoo Linux Security Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHhSS/uhJ+ozIKI5gRAgJdAJjymZUrjZfg06W2TMohYZx3FSwsAJ9i4JD/
YZRXDJv/bZWzMXePfuP/Kg==
=SFc9
-----END PGP SIGNATURE-----
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 09:25 -0500, Caleb Tennis wrote:
> I never even mentioned any specific arch in my original request, nor
> did I call any developer out.  So please, nobody needs to take this
> personally.

Correct, you did not.  What I find absolutely *damning* is the fact that
as soon as any arches *were* mentioned, everybody was talking about the
same one.  It's rather funny that everybody seems to have the exact same
impression of what architecture might be a slacker and would be affected
by this.  I wonder why that is?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 14:44 +0000, Ciaran McCreesh wrote:
> > We want the Council to do something about this issue. You can deny
> > the issue all that you want or try to deflect conversation from the
> > actual issue, but your opinion isn't very important to the much of
> > the current developer pool, seeing as how it doesn't affect you in
> > any way, having been thrown from the project, and all.
> 
> Ah, so now what matters is who says something, not whether or not it's
> true.

Well, when a non-developer who was thrown out of the project because his
attitude and approach was unwanted points out something and makes
statements as if he actually were still involved in the process of
maintaining packages or working on an architecture team and is unable to
get others to agree with him and insists that there isn't a problem but
is unable to back it up, then yes, it definitely does matter.  I'm just
making sure that people are aware of the situation, as you like to
portray yourself as important to the Gentoo project, when the project
has deemed you as not important and forcibly removed you.  Thanks for
playing, but you fail.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Luca Barbato]

Ciaran McCreesh wrote:
> And why does repoman do that?
> 
> Oh. Yeah. Because people with an attitude like yours think that the
> correct way to fix a repoman message is to start nuking arch keywords,
> ignoring what it does to the rest of the tree.

Dropping keywords works perfectly to have repoman quit complaining, you
just have to do a recursive dropping on the rdeps of this package.

> Perhaps because the people maintaining those archs have better things
> to do that deal with the same silly ill-thought-out arguments every
> three months.

cia/cvs commits ml says something different, gentoo wise at least.

>> I mean, if vapier can maintain arm/sh/s390, by himself, to a better
>> degree than the mips *TEAM* can do, that should be an indication of a
>> problem.
> 
> That's an interesting assertion. Can you back it up?

Feel free to run imlate scripts and come up with some numbers.

Note that I hate whining and I love get solutions.

MOST of the packages runs fine if they build fine, MOST of the
endian-issues or the 64bit-issues got caught by ppc and amd64 and there
aren't that many right now. Ugly arch specific codepath could be
present, but, as I said, usually you catch those breaking on gcc. So
having some way to test if the package builds (cross toolchain) and if
the package at least runs (qemu) IS something that should let small
arches with large tree coverage improve a bit. Otherwise you can just
reduce the tree coverage.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 15:11 +0000, Ciaran McCreesh wrote:
> Heck, most of the repoman messages people are moaning about are caused
> by developers doing exactly this.

No, most of the ones we're complaining about have nothing to do with
KEYWORDS, at all, and everything to do with changes to policy and such
that have been enacted since the ebuild was last touched.  See, repoman
doesn't care if you're just making a KEYWORD change or if you're making
coding changes to an ebuild.  It still will fail if something fails a QA
check, even if the failure is on an ebuild you're not touching.  As
such, it is a serious pain in the ass for architecture teams and
developers who are *not* slacking when one particular architecture only
has ebuilds that are ancient marked stable.  It increases the support
burden for *EVERYONE* else to keep this one architecture's stable tree
as it currently sits.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Peter Volkov]

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

В Срд, 09/01/2008 в 13:13 +0100, Fernando J. Pereda пишет:
> Why taking it against arch teams? How is that different from "certain
> maintainer not taking care of a bug that holds stabilization of certain
> package by some time measured in months" ? I'll tell you my answer: 'no
> difference at all'.

No. There is difference. If you see maintainer does not care, you can
ask him and fix bug by yourself. In case of arch teams bugs, you must
have access to hardware.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 18:56 +0100, Jan Kundrát wrote:
> Chris Gianelloni wrote:
> > I have foo 1.0, which is mips.  There is foo 2.0, which is stable
> > everywhere else.  The foo 1.0 ebuild does not conform to current ebuild
> > standards.  I want to commit changes to foo 2.0, and repoman won't allow
> > me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo
> > 1.0, because it's been EOL for 2 years
> 
> Why don't fix repoman not to scream about such issues, then?

What, have repoman complain only about problems in ebuilds that have
been changed unless someone does "repoman full" ?

Honestly, that coupled with dropping all KEYWORDS except for the arch in
question (in other words, marking something KEYWORDS="mips" and then
ignoring it, as a maintainer) would be enough to keep package
maintainers and other architecture teams from having to deal with the
crap left all over the tree due to slacker arches.  Of course, tree
quality would probably go down even more, since these QA issues would
likely never be fixed on said architectures, but who really cares,
anyway.  The support burden gets lain on the people who are slacking,
and not on the package maintainers or other architecture teams.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 18:11 +0000, Ciaran McCreesh wrote:
> On Wed, 9 Jan 2008 10:07:31 -0800
> "Alec Warner" <antarus@gentoo.org> wrote:
> > Actually if they dump kde-3.5.5 and anything depending on it, then
> > they don't break the tree and everyone is happy, no?
> 
> Everyone except the users, who end up with pages and pages of horrible
> Portage output...

What, all six of them?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 18:45 +0000, Ciaran McCreesh wrote:
> On Wed, 9 Jan 2008 19:29:53 +0100
> "Wulf C. Krueger" <philantrop@gentoo.org> wrote:
> > On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote:
> > > > So what happens if a flaw is discovered in KDE 3.5.5 that allows
> > > > root access?
> > > Then the one particular part of 3.5.5 that's affected gets fixed and
> > > priority keyworded.
> > 
> > So you suggest that mips keeps doing nothing and expect others to
> > work *more* in exchange for that?
> 
> Well, most users will simply ignore or postpone the mass upgrade, so
> yes. Forcing a mass upgrade is rarely if ever the correct solution to
> any security issue.

This is why I find it funny that people even bother to listen to Ciaran,
at all.  All he cares about is his little pet projects/teams and doesn't
care if it increases workload for everybody else.  I mean, where would
Gentoo be if not for our support of mips?  Oh dear, we'd definitely be
nowhere near as popular... *cough*

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 20:50 +0200, Petteri Räty wrote:
> Ciaran McCreesh kirjoitti:
> > On Tue, 08 Jan 2008 18:59:29 -0800
> > Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> >> The issue that was raised is that certain arch teams are incapable of
> >> keeping up with the minimal workload they already have and what should
> >> be done about it.
> > 
> > The issue was raised, with absolutely no proof or justification, and
> > every previous time said issue has been raised it's turned out to be
> > somewhere between highly misleading and utter bollocks.
> > 
> 
> So you just ignore for example my post about CIA activity for the mips team?

Of course, it is common practice to ignore any factual data that
supports the opposing side of a discussion.  This is Gentoo, man!
Where've you been?  :P

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 18:56 +0000, Ciaran McCreesh wrote:
> On Wed, 09 Jan 2008 20:50:38 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > So you just ignore for example my post about CIA activity for the
> > mips team?
> 
> That falls into the highly misleading category.

Yes, hard numbers are always misleading, especially when they show that
the entire team is barely active, at all, and only one of those people
is doing *any* mips work.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Chris Gianelloni]

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

On Wed, 2008-01-09 at 20:45 +0100, Vlastimil Babka wrote:
> Ciaran McCreesh wrote:
> >> a) Drop all keywords but those of mips. Leaves mips and, more  
> >> importantly, its users with a vulnerable and unmaintained set of  
> >> packages.
> > 
> > ...and break the tree spectacularly, causing huge amounts of pain for
> > your fellow developers when they encounter horrible repoman output when
> > they try to do anything.
> 
> Can somebody clarify to me why would it cause this? Maybe I just miss 
> something.

He's making the assumption that this sort of thing would be done
improperly and would cause other developers issues.

I went and created a tiny script[1] to change mips KEYWORDS to ~mips in
the tree, and created a patch[2] against the current CVS tree.  Were the
Council to choose this course of action, the work is mostly done.

[1] http://dev.gentoo.org/~wolf31o2/killmips.sh
[2] http://dev.gentoo.org/~wolf31o2/mips_to_testing.patch

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer

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

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

[Caleb Tennis]

> Correct, you did not.  What I find absolutely *damning* is the fact that
> as soon as any arches *were* mentioned, everybody was talking about the
> same one.  It's rather funny that everybody seems to have the exact same
> impression of what architecture might be a slacker and would be affected
> by this.  I wonder why that is?

Righto.  I also have specific mips related issues, and while I'm certain all of the
mips conversation will play on lots of people's minds, I think it also is helpful
from the council point of view to address this generically as it may be a problem
for a different arch in the future.

In other words, if people want to use mips as an example, then so be it, but
whatever resolution eventually comes to play shouldn't be mips specific.



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

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Kumba]

Well, I guess it's something that's been needing to be faced for some time now, 
as difficult as it is to do.  Regardless of the accusations and 
counter-accusations flying around in this thread, I'll just go ahead and state 
the fact that yes, we are a "slacker arch".

Why?  Because there's just no time anymore these days and no one left really of 
the original team.  And a lot of that really is my fault.  Tuxus may have laid 
the first keel of our ship, but I was the one who, so long ago, made her 
seaworthy and crewed her.  But now, she's largely a ghost ship -- adrift in the 
seas, and a hazard to the other ships.

And for that, I apologize to all of you.


My availability lately has been diminished as I've started wearing more "hats" 
at work, and I find myself with barely five hours a night of free time to 
meander about in whatever entertains me in my free time.  Occasionally, I pull 
up the window that connects to my Octane and keyword a bunch of things, and 
knock out some bugs.  But I'll be honest, that's been a rare thing these days.

So many of you by now are probably thinking "Ah hell, he's jumping ship on us". 
  No, not yet.  I have to fix what I created before I even begin to ponder those 
thoughts.  To just up and leave with the mess I've allowed to occur would be 
unfair, and frankly, just not something that's in my character.

So how can this ship be righted?  I did a quick scan of most of the mails in the 
thread to get an idea of some of the existing opinions (while trying to pass 
over the arguments), and here's what I found that needed to be addressed.



1. It's been suggested that mips drop all stable keywords ('mips') leaving 
unstable keywords as-is ('~mips').

Contrary to whatever damage and/or impact this may create, I think this is a 
good idea for us.  I've always ran ~arch on my Octane, and with a few 
exceptions, have found ~arch to be pretty usable.  Does something sometimes 
break?  Sure, but when one looks at all the wacky crap that exists in our arch, 
sometimes you're left wondering how it all manages to work anyways.

Besides, we've always been a more experimental arch to begin with.  Usually 
we've been the first to try some new hair-brained idea (like automated netboot 
builds via catalyst or running the most bleeding edge glibc), so this would just 
be another item in our tumultuous history to take a swing at.

That said, however, I don't think it would be appropriate to commit a patch to 
portage that wipes out all our stable keywords in one go.  I think it would be 
more appropriate to phase such a change in gently, because as far as I know, no 
one else has really done this.  The other archs typically maintain a 
stable/unstable set of keywords in the tree.  So I think this should be managed 
by the profiles.  I've been needing to do some profile cleanup anyways, so I can 
probably fiddle with a 2008.0-dev profile set to only do ~arch, and then see how 
that goes.

Thus as 2007.0 and 2007.1-dev die off, so does our stable keywords.  This frees 
up other package maintainers to not have to worry about one of our "pesky" 
keywords holding things back, and should give us more freedom to move at our own 
pace, relative to those who have free time and those who don't.



2. Many have wandered if we as a team are still alive.

And the answer to that really is a resounding "No".  Individually, me and 
Redhatter are probably the only ones who still do anything (and Redhatter, 
thanks for all the work you've done keeping things alive).  The rest had other 
priorities come up in their lives that ultimately required them to resign or 
fade into some un-indexed inode someplace.  And it's my fault for not replacing 
those lost team members with new folks.

I've got a guy in mentoring right now, but even that's been really slow as both 
of us have found time to be a scarce thing.  But I'd like to get some kind of a 
"team" back together, and hopefully get them on the right track to run things so 
that I can step off the platform as "Lead" and take more of a backseat role, 
which I feel is something better suited for me anyways.  It's not like I've lost 
faith in Gentoo or found I have zero time, it's just that I don't have enough 
time to operate effectively in the role of a Team Lead anymore.  Right now, I 
fit in better as "That crazy old guy who lives in a cave", or something equivalent.

But I can't do that till I get things back in shape, and so, I'll need help from 
the rest of you guys.  I need people to step up who want a chance to play with 
an arch that's about as insane as a pikachu slamming PCP.  People who don't mind 
running machines that are heavy, sometimes noisy, usually slow, and weren't 
exactly designed with "energy conservation" in mind.  People who want to help 
bring us closer to the rest of Gentoo, rather than off in our own little world, 
as we are oft found to be.

I'll fill those interested in all the dirty information they need to hunt down a 
machine we support (but to make it easy, just acquire an Octane), so e-mail me 
and ask whatever questions you need to know.



3. Should Gentoo even continue to support mips?  Do people even *use* mips?

My opinion is that yes, we should continue to support mips.  Ultimately, I'll 
leave that decision to the higher authority, but I think if a new team can be 
assembled, and I can be allowed to step aside to more of an advisory role, that 
mips can function normally again.  And maybe, regain some of the respect we've 
lost over the years for various reasons.

As for whether we even have users, I can say affirmatively that we do.  Not many 
for sure, like say Sparc or PPC, but we do.  Part of the problem with this is 
our area of focus.  The Mips Team really only focuses on SGI Hardware, because 
this hardware is readily available on eBay, and usually at good prices.  Mips as 
an architecture spans a swamp-load more of various devices.  Everything from a 
PSP to your cable modem is usually run by some variant of a mips processor.

However, I made the decision long ago to only focus on the workstation hardware 
because I wanted Gentoo to be the "User's Distro" on these machines.  I didn't 
want us to run off and support these obscure development boards that cost an arm 
and a leg, and are only available to very specific individuals who just happen 
to know the right people.  Lord knows the SGI machines alone keep things 
interesting as far as support matrices go.

But largely, Linux/MIPS leaves people with two choices for a distribution: 
Debian or Gentoo.  And while I give props to the Debian people for keeping the 
mips binary world alive, I don't think it'd be right for us to pull out and 
reduce those choices to one.  After all, Gentoo is all about letting the users 
have choices, right?




So there you all have it.  My thoughts, my opinions, my apologies.  In the end, 
I'll go along with whatever the rest of the distribution wants to do to rectify 
things.  After all, most of it stems from my own inactivity, by and large, and 
that hasn't made us a lot of friends around here.  So it's time to fix that, and 
put an end to all this pointless, utterly stupid bickering that drives away some 
of the best talent we have.

Besides, BSG returns in two months.  I will probably become more scarce than 
George Carlin at Catholic Mass when that happens, permanently affixed to my 
television trying to grok whatever crazy stuff Moore throws out in this final 
season.

So, thoughts?


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Mike Frysinger]

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

On Wednesday 09 January 2008, Kumba wrote:
> Well, I guess it's something that's been needing to be faced for some time
> now, as difficult as it is to do.  Regardless of the accusations and
> counter-accusations flying around in this thread, I'll just go ahead and
> state the fact that yes, we are a "slacker arch".
>
> Why?  Because there's just no time anymore these days and no one left
> really of the original team.  And a lot of that really is my fault.  Tuxus
> may have laid the first keel of our ship, but I was the one who, so long
> ago, made her seaworthy and crewed her.  But now, she's largely a ghost
> ship -- adrift in the seas, and a hazard to the other ships.

thanks ... you've always been a straight shooter without any bs mixed in.

> 1. It's been suggested that mips drop all stable keywords ('mips') leaving
> unstable keywords as-is ('~mips').
>
> That said, however, I don't think it would be appropriate to commit a patch
> to portage that wipes out all our stable keywords in one go.  I think it
> would be more appropriate to phase such a change in gently, because as far
> as I know, no one else has really done this.  The other archs typically
> maintain a stable/unstable set of keywords in the tree.  So I think this
> should be managed by the profiles.  I've been needing to do some profile
> cleanup anyways, so I can probably fiddle with a 2008.0-dev profile set to
> only do ~arch, and then see how that goes.

that certainly sounds reasonable to me.  if the stable cant be maintained, let 
the common workflow of developers transition it back to ~arch until someone 
has the time to keep arch usable.  changing profiles.desc accordingly should 
be done ahead of time.  perhaps a new category for profiles.desc ?  "exp" for 
such ports ?  i could see all *-fbsd ports being moved there.  tweak repoman 
to be less verbose about dep issues for such profiles and we're set.

> 3. Should Gentoo even continue to support mips?

i see dropping keywords as a very last resort.  getting a port *back* into the 
tree is a *tremendous* amount of work (i went through it and it was hell), 
while keeping ~arch alive is a sliver of effort and generally not a blocker 
for package maintainers.

> Do people even *use* mips? 

mips certainly sees use on the embedded side.  there should be no doubt 
whatsoever about its usage.
-mike

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 12:52:37 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> I went and created a tiny script[1] to change mips KEYWORDS to ~mips
> in the tree, and created a patch[2] against the current CVS tree.
> Were the Council to choose this course of action, the work is mostly
> done.

Ooooops! Your script doesn't work! You forgot about profiles and
eclasses.

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 11:54:47 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> On Wed, 2008-01-09 at 09:25 -0500, Caleb Tennis wrote:
> > I never even mentioned any specific arch in my original request, nor
> > did I call any developer out.  So please, nobody needs to take this
> > personally.
> 
> Correct, you did not.  What I find absolutely *damning* is the fact
> that as soon as any arches *were* mentioned, everybody was talking
> about the same one.  It's rather funny that everybody seems to have
> the exact same impression of what architecture might be a slacker and
> would be affected by this.  I wonder why that is?

Because we all know it's a euphemism, like "state rights".

-- 
Ciaran McCreesh

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

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

[Ciaran McCreesh]

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

On Wed, 09 Jan 2008 12:33:40 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> This is why I find it funny that people even bother to listen to
> Ciaran, at all.  All he cares about is his little pet projects/teams
> and doesn't care if it increases workload for everybody else.  I
> mean, where would Gentoo be if not for our support of mips?  Oh dear,
> we'd definitely be nowhere near as popular... *cough*

Ah yes, you're entirely right. We should all listen to you instead,
because of the brilliant job you're doing on your pet projects, 2007.1
and the GWN.

In the mean time, I'll just say that if you don't drop the personal
attacks and apologise, I'll have no choice but to take it up with
devrel. You're supposed to be arguing technically here, but all you do
is go around name calling.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Markus Ullmann]

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

Thanks for your input on this, really made it look by 200% better from 
what we have so far on this list and gives a much better point of view 
to judge from.

Kumba++

Greetz
-Jokey


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

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Alin Năstac]

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

Mike Frysinger wrote:
>> 3. Should Gentoo even continue to support mips?
>>     
>
> i see dropping keywords as a very last resort.  getting a port *back* into the 
> tree is a *tremendous* amount of work (i went through it and it was hell), 
> while keeping ~arch alive is a sliver of effort and generally not a blocker 
> for package maintainers.
>   

How about arm, s390 and sh arches? If I'm not mistaken, you are the only
one taking care of these arches and apparently you loosed interest in
maintaining them.


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

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Mike Frysinger]

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

On Thursday 10 January 2008, Alin Năstac wrote:
> Mike Frysinger wrote:
> > > 3. Should Gentoo even continue to support mips?
> >
> > i see dropping keywords as a very last resort.  getting a port *back*
> > into the tree is a *tremendous* amount of work (i went through it and it
> > was hell), while keeping ~arch alive is a sliver of effort and generally
> > not a blocker for package maintainers.
>
> How about arm, s390 and sh arches? If I'm not mistaken, you are the only
> one taking care of these arches and apparently you loosed interest in
> maintaining them.

i'm afraid we differ in opinion quite drastically here.  i routinely update 
the arches according to the tree.  i do not go through bugzilla though and 
remove my cc's until much later.

i imagine on KEYWORDREQ, these arches take quite a while, but not for 
STABLEREQ.
-mike

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

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

[Jeroen Roovers]

On Thu, 10 Jan 2008 07:08:46 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> In the mean time, I'll just say that if you don't drop the personal
> attacks and apologise, I'll have no choice but to take it up with
> devrel.

s|devrel|userrel|


Thanks,
     JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2008-01-10 at 07:08 +0000, Ciaran McCreesh wrote:
> On Wed, 09 Jan 2008 12:33:40 -0800
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > This is why I find it funny that people even bother to listen to
> > Ciaran, at all.  All he cares about is his little pet projects/teams
> > and doesn't care if it increases workload for everybody else.  I
> > mean, where would Gentoo be if not for our support of mips?  Oh dear,
> > we'd definitely be nowhere near as popular... *cough*
> 
> Ah yes, you're entirely right. We should all listen to you instead,
> because of the brilliant job you're doing on your pet projects, 2007.1
> and the GWN.

I'm afraid that once again, you simply don't have a clue what you're
talking about.  I've not been doing the GWN for a few months now, nor
was it *ever* a pet project of mine.  Keep it coming.  You're
entertaining the *hell* out of me.  *grin*

> In the mean time, I'll just say that if you don't drop the personal
> attacks and apologise, I'll have no choice but to take it up with
> devrel. You're supposed to be arguing technically here, but all you do
> is go around name calling.

Feel free to bring up an issue with Developer Relations.  They'll likely
throw it out because YOU ARE NOT A DEVELOPER.  Also, you'll notice that
rather than call you names, which is really your forte, I have instead
pointed out why I think your opinion is completely worthless to Gentoo.
If you feel insulted by people pointing out things like you being fired
from the project due to your attitude, perhaps you shouldn't have gone
and gotten yourself fired?  I mean, you made your bed, now lie in it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer

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

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

[Alexander Færøy]

On Thu, Jan 10, 2008 at 11:49:24AM -0800, Chris Gianelloni wrote:
> I've not been doing the GWN for a few months now

Yes, we noticed that.

What about 2007.1? As release engineering lead that *should* be your pet
project.

-- 
Alexander Færøy
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 10 Jan 2008 11:49:24 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> Feel free to bring up an issue with Developer Relations.  They'll
> likely throw it out because YOU ARE NOT A DEVELOPER.  Also, you'll
> notice that rather than call you names, which is really your forte, I
> have instead pointed out why I think your opinion is completely
> worthless to Gentoo. If you feel insulted by people pointing out
> things like you being fired from the project due to your attitude,
> perhaps you shouldn't have gone and gotten yourself fired?  I mean,
> you made your bed, now lie in it.

I'm sorry, what do you do around here again?

-- 
Ciaran McCreesh

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

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

[Chrissy Fullam]

> Ciaran McCreesh wrote:
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> > Feel free to bring up an issue with Developer Relations.  They'll 
> > likely throw it out because YOU ARE NOT A DEVELOPER.  Also, you'll 
> > notice that rather than call you names, which is really 
> your forte, I 
> > have instead pointed out why I think your opinion is completely 
> > worthless to Gentoo. If you feel insulted by people pointing out 
> > things like you being fired from the project due to your attitude, 
> > perhaps you shouldn't have gone and gotten yourself fired?  I mean, 
> > you made your bed, now lie in it.
> 
> I'm sorry, what do you do around here again?

Could everyone just drop the 'mud slinging' already, from all parties/in all
directions. The topic of this thread, and the relevant posts as best as I
can tell, were about the council meeting. It's going on as I type, so the
thread should be over. Join us in #council if you want to see your council
at work, addressing the Gentoo business that you requested them to.

Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 


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

[gentoo-dev] Re: Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Ryan Hill]

Kumba wrote:

> So how can this ship be righted?  I did a quick scan of most of the 
> mails in the thread to get an idea of some of the existing opinions 
> (while trying to pass over the arguments), and here's what I found that 
> needed to be addressed.

a) thanks for the post.

b) thanks for helping me with mips questions (and thanks to redhatter, 
spbecker, and eroyf).  hopefully i can start helping you guys out soon.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Kumba]

Mike Frysinger wrote:
> 
> that certainly sounds reasonable to me.  if the stable cant be maintained, let 
> the common workflow of developers transition it back to ~arch until someone 
> has the time to keep arch usable.  changing profiles.desc accordingly should 
> be done ahead of time.  perhaps a new category for profiles.desc ?  "exp" for 
> such ports ?  i could see all *-fbsd ports being moved there.  tweak repoman 
> to be less verbose about dep issues for such profiles and we're set.

Sounds like a plan.  'exp' would be the 'status' field?  I need to remove 
2006.1, as that profile has been a big holdup due to it not being glibc-2.4 
friendly (or one of the newer glibcs back in that era; I forget).  Even 
pondering just outright booting 2007.0, as I've been using 2007.1-dev since I 
commited it long ago, and haven't had an issue with it really.  I can then put 
2008.0-dev together and use it as a launch platform for ~arch migration.



> i see dropping keywords as a very last resort.  getting a port *back* into the 
> tree is a *tremendous* amount of work (i went through it and it was hell), 
> while keeping ~arch alive is a sliver of effort and generally not a blocker 
> for package maintainers.

Aye, I believe that was sh's removal and subsequent re-add?

Part of the hangup lately has been our kernel support.  O2 systems are dead in 
the water in 2.6.24, and only work in 2.6.23 if you apply a hack to serial_core 
(a hack that only masks a problem rather than fixes it).  Octane's I can still 
forward port, but with the upstream author having moved onto other interests, if 
something breaks badly enough from one version to the next, then I run the risk 
of getting stuck on a particular version permanently.

Indigo2 R10000's may wind up getting resurrected, as support for that is 
actually headed into upstream now, so it'll be the end of patching for that 
system.  Though the gcc patch needs fixing.

And I'm really considering dropping our mips3 (Indigo2/Indy R4x00) support to 
cut back on the number of stages and netboots pumped out (-3 and -1, 
respectively, when they get pumped out).  R4x00 is an odd CPU, with a ton of 
variations, and of them, only the R4400 ever seems to work well at all.

The hard part is finding time and motivation.  My attention span lately has been 
worse than a goldfish's.  That said, however, profiles should be doable come the 
weekend, at least for removing 2006.1, renaming 2007.1, and pondering 2007.0's fate.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Stuart Longland]

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

Kumba wrote:
> Mike Frysinger wrote:
>>
>> that certainly sounds reasonable to me.  if the stable cant be
>> maintained, let the common workflow of developers transition it back
>> to ~arch until someone has the time to keep arch usable.  changing
>> profiles.desc accordingly should be done ahead of time.  perhaps a new
>> category for profiles.desc ?  "exp" for such ports ?  i could see all
>> *-fbsd ports being moved there.  tweak repoman to be less verbose
>> about dep issues for such profiles and we're set.
> 
> Sounds like a plan.  'exp' would be the 'status' field?  I need to
> remove 2006.1, as that profile has been a big holdup due to it not being
> glibc-2.4 friendly (or one of the newer glibcs back in that era; I
> forget).  Even pondering just outright booting 2007.0, as I've been
> using 2007.1-dev since I commited it long ago, and haven't had an issue
> with it really.  I can then put 2008.0-dev together and use it as a
> launch platform for ~arch migration.

This is fine by me too.  At the moment, my 2007.1 stages are built with
stable keywords in mind, but that's something the user can easily fix. ;-)

>> i see dropping keywords as a very last resort.  getting a port *back*
>> into the tree is a *tremendous* amount of work (i went through it and
>> it was hell), while keeping ~arch alive is a sliver of effort and
>> generally not a blocker for package maintainers.
> 
> Aye, I believe that was sh's removal and subsequent re-add?
> 
> Part of the hangup lately has been our kernel support.  O2 systems are
> dead in the water in 2.6.24, and only work in 2.6.23 if you apply a hack
> to serial_core (a hack that only masks a problem rather than fixes it). 
> Octane's I can still forward port, but with the upstream author having
> moved onto other interests, if something breaks badly enough from one
> version to the next, then I run the risk of getting stuck on a
> particular version permanently.

Lately, I've been slacking for the last few weeks... no excuses... I've
been concentrating on other projects and interests.

Part of this is that I've been trying to get µClibc stages going so we
can build some newer netboot images (at this point, I'm considering
doing a few bloated ones based on glibc) but thus far, I haven't been
successful.  I haven't bothered since my trip down to Gibraltar Ranges
National Park.

I've got one of the Lemote boxes building a userland that'll hopefully
become a LiveUSB image that'll allow a user to try out Gentoo on one of
these systems, and install it (by hand... although ultimately having the
Gentoo Installer would be good too).  At last check, it was building KDE
3.5.8.  Presently, the only way to install Gentoo, is to use my
precompiled kernel and stage3 tarball to boot the box using
Root-over-NFS, so I'd like to get this going properly soon.

My TODO list at present (no specific order):
o Build a new netboot image for Cobalt
o Rebuild my Qube2 using the 2007.1 stage3
o Build boot media for Lemote Fulong
o Test X11-related patches for Fulong on other MIPS systems to make sure
  they don't break anything (at some point, I'd like to see these
  systems supported out-of-the-box by Gentoo)
o Check the documentation is still accurate
o Clean up the bugzilla list

Kumba,
	Since you're otherwise busy with other things, did you want me to build
some new big-endian stages based on the 2007.1-dev profile?  If so,
could I get access to the SWARM?  (I could do it on my O2, but I think
the SWARM will easily outperform it.)
-- 
Stuart Longland (aka Redhatter)              .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.


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

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Alec Warner]

Continuing on a side angle.  I have a 300mhz Octane I'll ship to
someone in the US if they need more mips hardware.  If you ask nice I
might even pay for the shipping.  I haven't booted it in ages but it
used to work ;)

-Alec

On 1/10/08, Stuart Longland <redhatter@gentoo.org> wrote:
> Kumba wrote:
> > Mike Frysinger wrote:
> >>
> >> that certainly sounds reasonable to me.  if the stable cant be
> >> maintained, let the common workflow of developers transition it back
> >> to ~arch until someone has the time to keep arch usable.  changing
> >> profiles.desc accordingly should be done ahead of time.  perhaps a new
> >> category for profiles.desc ?  "exp" for such ports ?  i could see all
> >> *-fbsd ports being moved there.  tweak repoman to be less verbose
> >> about dep issues for such profiles and we're set.
> >
> > Sounds like a plan.  'exp' would be the 'status' field?  I need to
> > remove 2006.1, as that profile has been a big holdup due to it not being
> > glibc-2.4 friendly (or one of the newer glibcs back in that era; I
> > forget).  Even pondering just outright booting 2007.0, as I've been
> > using 2007.1-dev since I commited it long ago, and haven't had an issue
> > with it really.  I can then put 2008.0-dev together and use it as a
> > launch platform for ~arch migration.
>
> This is fine by me too.  At the moment, my 2007.1 stages are built with
> stable keywords in mind, but that's something the user can easily fix. ;-)
>
> >> i see dropping keywords as a very last resort.  getting a port *back*
> >> into the tree is a *tremendous* amount of work (i went through it and
> >> it was hell), while keeping ~arch alive is a sliver of effort and
> >> generally not a blocker for package maintainers.
> >
> > Aye, I believe that was sh's removal and subsequent re-add?
> >
> > Part of the hangup lately has been our kernel support.  O2 systems are
> > dead in the water in 2.6.24, and only work in 2.6.23 if you apply a hack
> > to serial_core (a hack that only masks a problem rather than fixes it).
> > Octane's I can still forward port, but with the upstream author having
> > moved onto other interests, if something breaks badly enough from one
> > version to the next, then I run the risk of getting stuck on a
> > particular version permanently.
>
> Lately, I've been slacking for the last few weeks... no excuses... I've
> been concentrating on other projects and interests.
>
> Part of this is that I've been trying to get µClibc stages going so we
> can build some newer netboot images (at this point, I'm considering
> doing a few bloated ones based on glibc) but thus far, I haven't been
> successful.  I haven't bothered since my trip down to Gibraltar Ranges
> National Park.
>
> I've got one of the Lemote boxes building a userland that'll hopefully
> become a LiveUSB image that'll allow a user to try out Gentoo on one of
> these systems, and install it (by hand... although ultimately having the
> Gentoo Installer would be good too).  At last check, it was building KDE
> 3.5.8.  Presently, the only way to install Gentoo, is to use my
> precompiled kernel and stage3 tarball to boot the box using
> Root-over-NFS, so I'd like to get this going properly soon.
>
> My TODO list at present (no specific order):
> o Build a new netboot image for Cobalt
> o Rebuild my Qube2 using the 2007.1 stage3
> o Build boot media for Lemote Fulong
> o Test X11-related patches for Fulong on other MIPS systems to make sure
>   they don't break anything (at some point, I'd like to see these
>   systems supported out-of-the-box by Gentoo)
> o Check the documentation is still accurate
> o Clean up the bugzilla list
>
> Kumba,
>         Since you're otherwise busy with other things, did you want me to build
> some new big-endian stages based on the 2007.1-dev profile?  If so,
> could I get access to the SWARM?  (I could do it on my O2, but I think
> the SWARM will easily outperform it.)
> --
> Stuart Longland (aka Redhatter)              .'''.
> Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
> . . . . . . . . . . . . . . . . . . . . . .   .'.'
> http://dev.gentoo.org/~redhatter             :.'
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
>
>
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

[Mike Frysinger]

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

On Friday 11 January 2008, Kumba wrote:
> Mike Frysinger wrote:
> > that certainly sounds reasonable to me.  if the stable cant be
> > maintained, let the common workflow of developers transition it back to
> > ~arch until someone has the time to keep arch usable.  changing
> > profiles.desc accordingly should be done ahead of time.  perhaps a new
> > category for profiles.desc ?  "exp" for such ports ?  i could see all
> > *-fbsd ports being moved there.  tweak repoman to be less verbose about
> > dep issues for such profiles and we're set.
>
> Sounds like a plan.  'exp' would be the 'status' field?

yeah.  i'll fork a new thread on the topic.

> > i see dropping keywords as a very last resort.  getting a port *back*
> > into the tree is a *tremendous* amount of work (i went through it and it
> > was hell), while keeping ~arch alive is a sliver of effort and generally
> > not a blocker for package maintainers.
>
> Aye, I believe that was sh's removal and subsequent re-add?

arm actually.  i blame solar.

thanks Kumba, i'd wager my left one that without you there would be no mips.
-mike

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