Re: [gentoo-dev] Little respect towards Daniel please

2007-03-04 Thread Stuart Herbert

Hi Daniel,

On 3/4/07, Daniel Robbins [EMAIL PROTECTED] wrote:

Just as a note, I've resigned as a Gentoo dev so I'm going to at some
point today unsubscribe from -dev and stop replying to -dev emails.

-Daniel


Thanks for trying, but Gentoo just has too many folks who don't
understand the issue with the behaviour of folks like Ciaran.  Our
recruitment was too focused on technical skills; we never focused on
recruitment based around a shared culture, and I honestly think it's
too late now (which is why I quit).

What do you plan on doing next with your time?

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/28/06, Andrew Gaffney [EMAIL PROTECTED] wrote:

You make it sound like releng doesn't care at all about non-desktop packages.


That wasn't how it was meant.  Was simply meant as a statement of
fact.  Releng activities are currently exclusively desktop-oriented.
Until that changes, releng snapshots aren't fit for the purpose of
being a non-moving tree, as far as servers are concerned.


The reason for the exclusivity is that the media that's typically built for
release (GRP, LiveCD) is targetted for the largest audience...desktop users. If
someone wants to volunteer to create a set of server-related GRP and a server
LiveCD (as silly as this is for most things), they wouldn't be blocked outright.


I'd like to see some figures proving that our largest audience is
desktop users.  I'm not prepared to take that on faith.  (Alas,
producing these figures is non-trivial in the extreme, if not
impossible).


 b) Release trees have a nasty habit of picking up last minute changes
 (such as gcc 4.1) to suit the release, not stability.

Gcc 4.1.1 wasn't a last minute change.


I can't agree with you there.  It doesn't matter how many months of
planning and work you guys put into getting gcc-4.1 fit for stable.
If you're doing it off in your own little corner of the world, and
then springing it on the rest of us just days before the release
happens, then to the much larger dev community, it comes as a last
minute change.

If you're testing the crap out of something, but only in an
exclusively desktop-oriented way ... well, that can only really be
partial testing, can't it?


The release tree isn't really for minimal breakage.


But that is what Steve (who started this thread) asked for.  And what
he has asked for in his previous thread too.


The *real* intent (at
least from my POV) is to have a non-moving target for vendors to certify their
software against (wouldn't it be nice for Oracle to be actually supported on
Gentoo 2007.0 or something like that?),


Well, there's a dichotamy here.  Sun were able to certify Gentoo
against their hardware without such a tree.  Has anyone approached
Oracle and asked them what their actual requirements are?  Do Oracle
actually want to certify Oracle on Gentoo at all?

I personally deplore this habit of trying to second guess what someone
else wants.  Assumptions are the mother of all fuckups.  Let's see an
email to -dev from someone at Oracle w/ their shopping list of needs,
and then base the discussion around that.


and so admins don't have to do the
upgrade dance once a week or even every day (like I do).


A slower-moving tree will substantially reduce this amount of work,
but it isn't going to go away, unless your boxes are on a private
network w/ no local security threats at all.

There'll always be GLSA's to respond to.  That's another issue that
needs to be handled w/ a slow-moving tree.  Are you going to restrict
changes in the slow-moving tree only to changes against a GLSA?


The non-stagnant nature of Gentoo isn't the only reason that people use
Gentoo. People use Gentoo for the configurability and customizability. As
someone who admins more than a handful of Gentoo servers, I would absolutely
*love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades
easier to deal with.


I honestly don't think you're ever going to get that out of Gentoo,
because of the lack of backporting.  Can you live with a slower-moving
tree?  Or do you personally really need a non-moving tree?

If you really need a non-moving tree, I think you're better off with
RHES or Ubuntu.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Andrew Gaffney [EMAIL PROTECTED] wrote:

The 3-4 weeks of releng filing a ton of doesn't build with gcc-4.1.1 bugs
wasn't a big enough clue? :)


No.  We get those all the time; there's always someone trying out an
unsupported release of gcc.


Also, the arch teams (or at least the arch's
release coordinator...if they didn't tell the rest of their team, that's not
releng's fault) that were moving to it and people in base-system working on it
were in the know.


What about everyone else, who isn't part of an arch team?  Sorry, but
I just don't get how you expected us to know it was coming, when you
didn't announce it, and you don't even feel that an announcement was
your (releng's) responsibility (even though stabilisation of gcc-4.1
was for you).

You personally went out of your way earlier this year to critisise me
about bad communication, just for announcing that work had started on
something in Gentoo.  And yet here you are today, somehow expecting
the rest of us to rely on clairvoyance to know in advance about a
change that your team pushed onto the entire tree.

It's a great illustration why the releng snapshots, as things stand
today, aren't the right way to deliver a meaningfully stable tree to
our users.  It's simply difficult to trust you with the way you choose
to behave today.


Yes, that's part of wolf31o2's idea. The tree would be non-moving except for
GLSA's and any dependencies required by the updated version of the
security-affected package.


How are you going to ensure that all the security fixes that never get
a GLSA get into the tree?


A slower-moving (or non-moving with security updates) tree is perfect for me,
and I'm sure for many other people as well.


Before you release these trees to users, I trust you'll be doing the
responsible thing, and ensuring that upgrades from one tree to the
next work?  You can't take that for granted; package maintainers
cannot be relied upon to test upgrades spanning that length of time.
(Which is why upgrade early, upgrade often is a practical way to
manage Gentoo boxes)

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

As of this release, I kept a copy of all of the distfiles for the entire
release, and can make a DVD of it, on request.  This fulfills our
requirements with the GPL.


What are the arrangements should you go under a bus on the way home
from work tonight?

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Andrew Gaffney [EMAIL PROTECTED] wrote:

 From other developers, most of which were releng members?


I get most of mine from users, who are normally kind enough to submit
the required patches at the same time.


It's stupid to blame releng for the stabilization of gcc-4.1.1.   We didn't 
force
it on people.


You're responsible for it being stabilised when it was.  It's
disappointing that you choose to disavow all responsibility for that
happening.

I'm not arguing that gcc-4.1 shouldn't have been stabilised at some
point in time (although the performance penalty it introduces is a
shame).  I'm just pointing out a flaw with the idea that the releng
snapshots are fit for the purpose of being a non-moving tree for our
users.


And as always, if you wanted to know what was going on as part of the release,
the info was there for everyone to see in the usual places (such as the
gentoo-releng mailing list or the #gentoo-releng IRC channel). This argument
about people not knowing what releng is doing seems to come up after every
release. It's crap.


I don't agree with you, sorry.

Releng members in the past have complained about not knowing what is
going on elsewhere in Gentoo; they have _specifically_ complained
because information was not _actively_ sent in their direction.  But,
when the point is raised in the opposite direction, your answer is
it's crap.

I'm left very disappointed by that.


If it doesn't get a GLSA, it doesn't get in the release tree. This may mean that
we need to modify the GLSA process a bit so that ~arch packages found to be
vulnerable get GLSAs as well. Although, release tree users won't have these
~arch versions anyway, so I don't see it being *that* big of an issue.


It would be worth checking to make sure that all security bugs for all
stable packages get GLSAs first.  I don't know whether they do or they
don't.


Absolutely, it would be stupid to release it to users without testing that the
upgrade path is even feasible. However, we can't test the upgrade with *all*
packages in the tree, but we can certainly do it with certain profiles (gnome
desktop, kde desktop, LAMP server, etc.) to try to cover as many bases as
possible. This testing can be easily scripted.


Cool.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

 What are the arrangements should you go under a bus on the way home
 from work tonight?

You'd like that, wouldn't you?


That was _completely_ uncalled for.

go under a bus is just a phrase that's commonly used here in the UK
(because our major public transport infrastructure consists of buses
and trains) when talking about business continuity of key personnel.

Our liabilities under the GPL are ultimately the Foundation's
responsibility.  It's perfectly reasonable to want to know understand
how we'd meet that liability if something did happen to you.


Well, since you asked, the distfiles are stored on Release Engineering's
server, under /release/2006.1/distfiles, which is accessible to anyone
in Release Engineering, as well as the OSL and Infra.


Thank you.  Do we have backups in place covering these files?  Have we
tested the backups to confirm that they actually work?

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Mike Doty [EMAIL PROTECTED] wrote:

Stuart Herbert wrote:
I have a couple of locations where I could store backups, depending on
size and projected growth.  I suppose it'll have to wait until 2007.0
though so we can actually gage it as opposed to speculating wildly.


If anything happens to poseiden ... does anyone have a backup anywhere
that we can use to rebuild the distfiles archive for 2006.1?

What's the situation with older releases?  Do we have the distfile
archives for those on poseiden too?  Would that give you the sizing
data you need to put backups in place?

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

On 11/29/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

I'm sorry, but how the hell do you know?  You are not a member of
Release Engineering, and have *NO CLUE* what we do over there.  What we
release isn't the only thing we do.


Then this is a great opportunity to set the record straight, by
explaining what server-oriented work releng do with each release.


Luckily, I'm not asking you.  Instead, I'm asking interested developers
to assist us in making what we plan on doing much more viable.  Feel
free to sit over there and naysay until you're blue in the face.  We'll
be over here getting something accomplished via teamwork.


Odd; I'm trying to get involved, by providing feedback and asking questions.


Except it was announced before we even made the snapshot,


Sorry, I've looked, but the only announcement I found on gentoo-dev
was posted two days before gcc-4.1 was stabilised [1].  I must have
missed the earlier announcement?


Just because we didn't take the time out to stop and make
sure you were personally comfortable with the change doesn't mean we
didn't prepare for it and announce it.


I'm sorry that you've gone with the I always know best, you're a
fucking chump so shut the fuck up type of response :(  That seems to
be your answer of choice to all feedback these days.

I'm sorry you feel that my input isn't welcome in your world.

[1] http://marc.theaimsgroup.com/?l=gentoo-devm=115672836418923w=2

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Stuart Herbert

Hi,

On 11/29/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:

Maybe you should read the replies you got the first time you made this claim
on this list [1].


Many thanks for these links.  I didn't see your original email.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-28 Thread Stuart Herbert

On 11/28/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

As I have said, I've mentioned several times the idea of doing a
release tree to go along with each release.


The release tree is not the basis for this.

a) Releases (and the releng work that goes into it) are exclusively
desktop-oriented.
b) Release trees have a nasty habit of picking up last minute changes
(such as gcc 4.1) to suit the release, not stability.


No version changes on any packages, except those which are necessary due
to a security violation, or a vulnerable package's dependencies.


Tying a minimal-b0rkage tree to the arbitrary schedule of our releases
does not serve all of our users.  We are back to the same arguments we
had when I said that the Seeds project would have to have its own
independent release schedules :(

Thereś little merit in us creating mostly stagnant trees.  Other Linux
distros are already very good at doing that - far better than we will
be at it - because they have advantages such as a paid workforce and
more upstream developers on their books.

A minimal-b0rkage tree needs to move to reflect the packages that we
believe our users should be using for a stable environment.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-27 Thread Stuart Herbert

On 11/27/06, paul [EMAIL PROTECTED] wrote:

You can't take workload out of the picture since it's the main issue
here. Stable tree means backport fixes and I don't see this happening as
it can't be automated:


Stable tree means backport fixes is an assumption, not a requirement.

It's one reason why the word stable is a poor choice for any such
tree, just as it is a poor choice for the current Portage tree.

I think the original poster hit the nail on the head.  The real
barrier preventing a slower-moving tree is cultural.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



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

2006-11-08 Thread Stuart Herbert

On 11/8/06, Steve Long [EMAIL PROTECTED] wrote:

What I was wondering about was what mechanism you might use to provide those
binary packages; would other devs also be contributing? Or is there simply
nothing that might be useful for a binary distro?


Wrt the Seeds project, it's too early to have definitive answers for
these questions, sorry.

Speculatively, we'd have a binary repository for each seed that could
be rsynced down to your local system.  But it's just speculation at
this stage.


I understand what you're saying in the sense that binary distros break too.
Is that what you mean?


Partly.  The point I'm trying to get across is the system breakage
that users have to put up with has little-to-nothing to do with the
fact that Gentoo is a source-based distro.


Is it correct that versioning the tree would solve it by allowing various
releases to stick to lower versions of packages until they have been QAed
by the gentoo community?


Yes.

The Gentoo package tree is a live tree - whatever we commit goes
straight out to the rsync mirrors for users to download and use.

Live trees are not compatible w/ a high quality product.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



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

2006-11-07 Thread Stuart Herbert

On 11/7/06, Steve Long [EMAIL PROTECTED] wrote:

I accept that has been the position. As for devs not wanting to do it, I'm
thinking it would be part of the standard emerge process (ie binhost/PKGDIR
and -b) but you would need to add tagging of USE flags if the binary format
ATM does not include which flags were used.

So yes, it might add time/ network in terms of uploading but nothing else.


Sorry, that's not correct.

If random-joe-developer simply uploaded whatever packages he has
locally to a central repository, you'll just end up with a large
binary mess.  The binary packages need to be built as a set, to be
sure that there is no ABI breakage going on.


Stuart Herbert wrote:
 If the Seeds project proves successful, I'd be interested in providing
 binary packages for seeds.  Whether that'll be as part of Gentoo, or
 whether it'll be better to move downstream (so to speak) to do so is
 up for debate.

So you are looking to provide /some/ sort of binary packages as part of an
official Gentoo project then.


See above.  I'm interested in providing binary packages for updating
systems, yes - systems that are running seeds.  Whether they're
provided through Gentoo or not hasn't yet been discussed at all.  We
need to actually finish and release the LAMP Server seed first :)

I'm not interested in providing binary packages for a generic Gentoo
'binary' release.  My personal opinion is that this isn't what Gentoo
is about.


I accept that for the enterprise compiling from source may well be better,
based on Robin Johnson's reply. However this point about system breakage is
serious *for users*.


Yes - but binary packages on their own have nothing to do with
preventing system breakage.  You're chasing completely the wrong bus
to solve that problem.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Patent threat?

2006-11-07 Thread Stuart Herbert

On 11/7/06, Jeff Rollin [EMAIL PROTECTED] wrote:

I'd like to ask how many Gentoo devs get paid for contributions to Gentoo?
How many of you (paid or non-paid) think MS's threat to sue over patents is
a real danger?


I think this is a non-issue until Microsoft issues a direct threat (or
litigation) against a named opensource company or developer.  I don't
think there's any benefit in speculating on what Microsoft will (or
will not) do at this time.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Patent threat?

2006-11-07 Thread Stuart Herbert

On 11/7/06, Duncan [EMAIL PROTECTED] wrote:

No devs get paid directly for working on Gentoo -- they are all
volunteers.


That statement may or may not be true.  We don't require Gentoo
developers to disclose this information, so it's always possible that
some Gentoo developers are paid to work on Gentoo and the rest of us
just don't know about it.

What is true is what Chris says - the Gentoo Foundation (owner of
Gentoo's IPR) does not pay anyone to work on Gentoo.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Retirement

2006-11-04 Thread Stuart Herbert

On 11/3/06, Jon Portnoy [EMAIL PROTECTED] wrote:

I've been mostly inactive for a good while but hanging on mostly for
sentimentality's sake, it's past time for that to stop.


It's a damn shame to see you go.  I guess most of today's devs won't
know or appreciate just how much you've done for Gentoo over the
years.

Best of luck in whatever you're up to next, and if you ever make it
over to this side of the pond, I still owe you a beer.

All the best,
Stu
--
PS: Here's hoping Uncle Seemant can talk you out of it :)
--
gentoo-dev@gentoo.org mailing list



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

2006-11-04 Thread Stuart Herbert

On 11/3/06, Grant Goodyear [EMAIL PROTECTED] wrote:

Steve Long wrote: [Fri Nov 03 2006, 02:47:52AM CST]
 The main problem I see is USE flags (devs already
 compile with standard C-flags right?) but I was thinking about standardising
 for 2 or 3 types of network- SOHO, medium and large enterprise (eg for LDAP
 etc) would solve most cases. We can always tag pkgs with USE flags.


If the Seeds project proves successful, I'd be interested in providing
binary packages for seeds.  Whether that'll be as part of Gentoo, or
whether it'll be better to move downstream (so to speak) to do so is
up for debate.

Genux tried providing binary packages for generic Gentoo systems.
They ultimately failed as a business.


 If gentoo is still serious about enterprise adoption, it needs a binary repo
 (so we can avoid system breakage) which would of course be a little bit
 behind. I'd be happy to contribute time, as I'm sure many other users would.


I think that's total rot, sorry.  A binary distro can break a system
just as much as a source based one.  A source-based distro is just as
practical in the enterprise; in fact, for web stuff, it's a lot more
practical, because it gives you the flexibility to build a box to your
exact needs, rather than having to compromise on what binary distro
vendors provide you with.

I think what you really need is an alternative package tree, one
that's versioned and tested as a whole, and one that isn't live.


As for Gentoo being serious about enterprise adoption, I don't agree
that we need a binary repo.  I think we ought to make it easy for our
users to create and use their own, customized, distribution.  That's our
strength as a meta-distribution.  (We also need to make it easy to
install and replicate custom distributions, but we already have Catalyst
and the Seeds project addressing those issues.)


Definitely.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Gentoo group on Flickr - repost from pl.g.o

2006-10-31 Thread Stuart Herbert

Reposted from http://planet.gentoo.org for the devs who live in
caves^H^H^Hdon't read planet.gentoo.org.

Best regards,
Stu
--

http://www.flickr.com/groups/gentoo/

Whilst sat here this morning waiting for the NX packages to build, it
occured to me that we don't have our own group on Flickr. Bit odd
really, when you think of how many of us enjoy photography as a hobby.

Well, we do now :)

So, if you're a Gentoo dev, come join the group, and share your photos
with the rest of us :) Let's see if, between us, we can build a rich
and varied view of the world that we live, work, and play in.

Just one request ... please, no screenies. Let's keep this to photography.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Only you can prevent broken portage trees

2006-10-31 Thread Stuart Herbert

On 10/31/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:

Uh, security bugs are not the highest priority.


Would it be possible to have some arch team leaders join in this
debate?  Atm, it just seems to be bouncing back and forwards between
package maintainers asking questions, and a Gentoo user filling the
void left by the responses from the arch team folks.

(Or, to put it another way, I'm not sure anyone's actually learning
anything here, except for Ciaran's personal opinions on how he'd like
things to be).

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



Re: [gentoo-dev] Only you can prevent broken portage trees

2006-10-31 Thread Stuart Herbert

On 10/31/06, Stephen Bennett [EMAIL PROTECTED] wrote:

Having a system that actually works is usually reckoned to be more
important than patching minor security holes on architectures that
aren't security-supported anyway. On systems that are almost never used
in production or in externally visible roles, security bugs are much
akin to simple enhancements to a package that already works, and fixing
packages that don't work takes precedence.


Thanks for that.  It's much appreciated.

This leaves package maintainers in the situation that there are
'old'/'insecure'/insert preferred adjective here versions of
packages that are hanging around only because arches have fallen
behind.  Package maintainers want to be able to remove these old
versions, but currently cannot because of keywording-lag.

At the moment, it looks like there are a few choices:

1)  Leave the older versions in the tree, even though they are
insecure and possibly/probably no longer supported by package
maintainers.  This keeps minority arches happy at the expense of the
larger group of package maintainers.

2) Or, remove the older versions from the tree after a suitable
waiting period (say, 3 months for arguments sake).  This will keep
package maintainers happy, and our users (less cruft in the tree to
rsync and metadata-cache), but causes real trouble for minority
arches.

3) ??

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Only you can prevent broken portage trees

2006-10-31 Thread Stuart Herbert

Hi Chris,

On 10/31/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

On Tue, 2006-10-31 at 17:02 +0100, Stuart Herbert wrote:
 3) ??

Get your hands on some of the minority arch hardware and help out?


It's a good idea.  It's not an option for me, but hopefully others
will follow your advice.

Personally, I like the idea of package maintainers updating old
ebuilds with a prominent warning that the package is known to have
security holes, and then leaving it to the user to decide whether or
not to use the package.  A suitable elog message (pointing the user at
the security bugs in question, and warning them that the package is
now unsupported as a result) in pkg_setup would do the trick.

If there's any interest in this solution, it'd wouldn't take very long
to add a suitable function to the eutils eclass, so that we can
standardise the behaviour.

Of course, it'd be even better if Portage itself could support this,
so that the warning could occur without manual intervention.  But in
the meantime, adding a simple 'einsecure' function would be
sufficient.

Any interest?

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Stuart Herbert

Hi,

On 10/25/06, Donnie Berkholz [EMAIL PROTECTED] wrote:

Danny van Dyk wrote:
  Design phase for new projects: New projects need to post an RFC
containing information about their goals, the plan on how to
implement their goals and the necessary resources to -dev prior to
creating the project.

This proposal was accepted with 6 members voting yes and one member
abstained from voting

Could someone amend GLEP 39 to reflect this new requirement?


(This _isn't_ intended to turn into a flamefest.  It's intended to
start a discussion on a point of principle).

The current metastructure (as documented in GLEP 39) is a little
unusual; it's a proposal that was voted in by all Gentoo developers.

As such, as a point of principle, should the council be able to
change/override/replace the rules in GLEP 39 w/out putting it to a
vote of all Gentoo developers?

(As a second principle, if GLEP 39 is amended, wouldn't it be better
to publish a new GLEP to superceed it, rather than revise the existing
GLEP?)

Please - let's not get sidetracked about the nature of the change, or
its merits.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Stuart Herbert

Hi Chris,

On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

Also, I'd like to know what you would propose we do if we were to follow
something like this.  Would we post something like GLEP 39a, as an
amendment to GLEP 39, or would we have to rewrite the whole thing, with
just the one change, to supersede?

Perhaps we need an amendment to GLEP 1 to allow explictly-stated
amendments?


I think it'd be common sense to post -r1, -r2 etc, and extend the XML
syntax so that we could easily indicate which sentences had been
changed.  I think it'll make things easier  than a
read-GLEP-39-now-read-GLEPs-39a-to-39z type of approach.

We could also have a 'Revisions' section somewhere (if we don't have
one already) in the GLEP listing the date, a link to the Council
meeting logs approving the change, and a (very) brief summary of the
change.

I'm sure there are other ways we could do this that would also be practical.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Stuart Herbert

Hi Chris,

On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

Well, let's make it simpler, then.  Does it say anywhere in GLEP 39 that
the elected Council cannot change it?  Does it limit the council's
powers in any way?


No, it does not.  That's why I've asked for a discussion of this as
point of principle, rather than as a point of law, so to speak.
Reading the council logs and seeing this item, it occurred to me that
it's something that I don't think we've ever actually debated as a
group.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Stuart Herbert

On 10/25/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:

The Council has already done so, with the addition of the final bullet
point in Specification list B.


Thanks for pointing that out.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)

2006-10-25 Thread Stuart Herbert

Hi Chris,

On 10/25/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

I think the likely best way would be to do something like:


[snip]

Yeah, that works for me.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New Devrel Subproject: Gentoo Devmatch

2006-10-23 Thread Stuart Herbert
Hi Alec,

Alec Warner [EMAIL PROTECTED] wrote: 
Bonuses:

Developers with long-standing conflicts will be able to voice their 
personal feelings via fists and feets.

Heh.  Maybe we should hire some of those inflatable sumo suits [1] for the
dev conference? ;-)

[1]
http://www.find-me-a-gift.co.uk/gifts-for-men/unusual-gadgets/inflatable-sumo-costume.html

Best regards,
Stu
-- 
--
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo-nfp] New Trustees - My Resignation

2006-10-23 Thread Stuart Herbert

On 10/23/06, Stuart Herbert [EMAIL PROTECTED] wrote:

Anyone know where I can find a copy of the Foundation's by-laws, to
see what it says about this situation?


Never mind, I found them [1].  Section 5.7 says that the remaining
Trustees can vote in a replacement for Seemant.  It doesn't require us
to re-open voting with the membership.

Grant - as you're now the senior Trustee, can we rely on you to
organise a Trustees meeting to discuss this, and hopefully vote in a
successor for Seemant?

[1] http://www.gentoo.org/foundation/en/bylaws.xml

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo-nfp] New Trustees - My Resignation

2006-10-23 Thread Stuart Herbert

On 10/23/06, Seemant Kulleen [EMAIL PROTECTED] wrote:

Dear All (specifically, the voting members of the foundation),

Thank you all so much for expressing your confidence in me with the most
recent Trustee elections.  I fear, however, that for personal reasons I
will be unable to assume my position on the board.  I thus respectfully
resign my position.


I'll grumble @ Seemant about this off-list :)

So, what now?

a) We promote rl03 (as the first losing candidate) to the Board of
Trustees, without requiring another vote.
b) We re-open nominations, and hold another vote.

Anyone know where I can find a copy of the Foundation's by-laws, to
see what it says about this situation?

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: New Devrel Subproject: Gentoo Devmatch

2006-10-23 Thread Stuart Herbert

On 10/23/06, Caleb Cushing [EMAIL PROTECTED] wrote:


  Weapons allowed?

melee weapons only, maybe?


Guns for show; knives for a pro.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-17 Thread Stuart Herbert

On 10/17/06, Stephen Bennett [EMAIL PROTECTED] wrote:

There is no analogy to be made there. Arguing against carrying profile
metadata in IUSE is trying to prevent a design decision, not trying to
work around one by forcing extra work on people.


There seems to be very little support for your position (and Ciaran's)
that a package's default USE flags are exclusively profile metadata.
The only email I found from anyone else in support of your position
was from Danny.  My apologies to anyone else who I've missed.

The broad concensus of the discussion is that a package's default USE
flags (as intended by the package maintainer) belong with the package
itself, with profiles being able to override these settings as needed.

The different positions appear intractable.  I suggest there's no real
point carrying on with this discussion.  Both the official Portage
team, and the external Paludis maintainer, have had plenty of feedback
via this thread.  I suggest that both teams go forward and implement
support how they see fit, and (as always) we leave it up to the
external Paludis maintainer to decide whether he wants to make Paludis
compatible with Gentoo's official package manager's implemented
solution or not.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] a new TLP to unify programming langiages?

2006-10-13 Thread Stuart Herbert

Hi George,

On 10/13/06, George Shapovalov [EMAIL PROTECTED] wrote:

The suggested projects are:

Projects to be moved (tentative, may opt out):
Common Lisp
java
perl
php
python


The PHP team will be opting out.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Stuart Herbert

Hi Zac,

On 10/13/06, Zac Medico [EMAIL PROTECTED] wrote:

I've written a patch for portage [1] that implements per-package default USE 
flags at
both the ebuild and profile levels (discussed a couple of months ago [2] on this
list).  At the ebuild level, default flags are specified in IUSE with a + 
prefix as
described in bug #61732 [3].  At the profile level, I've added support for
package.use which behaves like /etc/portage/package.use that everyone is 
familiar
with.  The intention is that the IUSE defaults will be used for default flags 
that
should be enabled regardless of profile.  Then, package.use will be used for 
flags
that might vary depending on the profile.  For example, a server profile might 
enable
server flags and a desktop profile might enable client flags.


:)  This is excellent news, both for the PHP Herd (per-package USE
flags) and the Seeds project (per-profile USE flags).


Should we include support in portage for one or both types of per-package 
default USE
flags?  If support is included for IUSE defaults now, we won't be able to use 
them in
the tree until after a waiting period or an EAPI bump [4].


I can make good use of both, and would really love to see both supported.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Stuart Herbert

On 10/13/06, Paul de Vrieze [EMAIL PROTECTED] wrote:

I would go for the EAPI bump. Even then I think it would be smart to
wait a short while for packages to use this as we ensure that the
supporting portage version is stable.


+1 from me on that.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Stuart Herbert

On 10/13/06, Jakub Moc [EMAIL PROTECTED] wrote:

Yeah, the big picture here is that make.defaults has been bloated by use
flags needed/relevant for one or two ebuilds only for quite some time
and users and devs alike have been ranting about the same for quite some
time...


I believe Ciaran's saying that package.use in a base profile would do
the same job as supporting default USE flags in IUSE.  It's worth
thinking about ... after all, package.use will just be ignored by
older Portage implementations, whereas +flag in IUSE causes more
breakage.

The downside of it (and it's a big one) is that we'd be putting
metadata about a package into a profile, instead of into the ebuild
where arguably it belongs - and where the rest of the metadata already
is.  That'll make life harder for folks on o.g.o.

On balance, I prefer +flag in IUSE, even w/ the b/c breakage it'll
cause users who don't keep Portage up to date.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Stuart Herbert

On 10/13/06, Stephen Bennett [EMAIL PROTECTED] wrote:

Sure they do. They should be enabled by default, so put them in the
place where the default USE flags are set.


They should be enabled by default _only_ for the package that needs
them enabled.  Support for package.use in profiles gives us that,
allowing us to override the package maintainer's defaults included in
each ebuild's IUSE.

Stuff in make.default gets enabled across the whole system.  That's
not what always what we want or need.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: per-package default USE flags

2006-10-13 Thread Stuart Herbert

On 10/13/06, Stephen Bennett [EMAIL PROTECTED] wrote:

The examples he gave were of flags that should be enabled by default
for every package that uses them. Even if that's just one or two
packages, there's no reason not to put them in global defaults.


That's one way.  I know some folks prefer it, and there's nothing
wrong with doing so.

Personally, I prefer to keep the global USE down to a minimum, and
tweak each package's USE flags via /etc/portage/package.use.  I find
it helps ensure that what gets installed onto a box is much closer to
what you intended.  My personal experience is that it makes boxes a
little easier to support as a result, because less installed packages
== less to go wrong.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] *plop*

2006-10-13 Thread Stuart Herbert

Hi Thierry,

On 10/13/06, Thierry Carrez [EMAIL PROTECTED] wrote:

Hello everyone,

I think the time has come for me to leave this project after two and a
half years of service.


Congrats on the new family.  And many thanks for everything you've
done for Gentoo during your time as a dev.  Here's hoping we see you
come back one day.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] a new TLP to unify programming langiages?

2006-10-12 Thread Stuart Herbert

On 10/12/06, George Shapovalov [EMAIL PROTECTED] wrote:

Funnily I already got questions like is this thing only to move stuff around?
I would be all for it if it had a bit more meat. I added that PPS expecting
questions like that would be asked. Of course, realistically I do not
think anything other than repositioning a few projects comes out of it - yet.
If anybody steps forward saying I want to do so and so and it seems to fit
under this umbrella then I think would be the right time to consider the
structure or what exactly is going to be done. As it stands now, I don't
think it is worth overly worrying about this.


This isn't going to bring any benefits to anyone.  If you want to help
users find docs on programming languages on Gentoo (assuming there
_are_ any users who don't know how to Google for such things), just
get the docs team to organise 'Programming Languages on Gentoo' docs
category on [1].  _That_ would be much more useful to users.

Creating a TLP just to order some docs ... sorry, but it seems a very
bizarre thing to do.

[1] http://www.gentoo.org/doc/en/index.xml

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 42?

2006-10-12 Thread Stuart Herbert

On 10/11/06, Stephen Bennett [EMAIL PROTECTED] wrote:

We also use space-delimited depend atoms everywhere else. It makes no
sense to break that when a comma works equally well.


I'm sorry, are you telling everyone that it's too difficult for you to
write an ungreedy regex that also tests for the possibility of a list
bounded by [ and ] being part of an atom?

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 42?

2006-10-12 Thread Stuart Herbert

On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:

Not an issue for me. It's an issue for random people writing scripts,
for people using command line things and for people who don't want to
use a full parser framework for some quick hack. There's no need to
make things harder for random developers here.


Wouldn't a resolver API be the better approach to solving that?  We're
not here to support x-random number of independent, unofficial
implementations of atom parsers.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] GLEP 42?

2006-10-11 Thread Stuart Herbert
Hi,

Whatever happened to the work to implement GLEP 42?  Is there anyone
actively working on this atm?

Best regards,
Stu
-- 
--
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 42?

2006-10-11 Thread Stuart Herbert

Hi Zac,

This is all good news.

On 10/11/06, Zac Medico [EMAIL PROTECTED] wrote:

2) Default USE flags at the ebuild and/or profile level [2].


This one would be very very useful for Seeds, if we can set per-ebuild
USE flags at the profile level.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 42?

2006-10-11 Thread Stuart Herbert

On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:

Spaces in dep atoms would be highly evil, since it'd mean they were no
longer simply space delimited. Commas [foo,-bar,baz] would be fine...


Write a better parser then :P

We use space-delimited USE flags everywhere else.  It would make a lot
of sense to keep it consistent here.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] a new TLP to unify programming langiages?

2006-10-11 Thread Stuart Herbert

Hi George,

On 10/11/06, George Shapovalov [EMAIL PROTECTED] wrote:

Hi gang.

As I looked for a place where to put some documentation naturally falling in
a project domain for Ada, I realized that we have TLPs for many individual
(programming) languages. First I though to ping some people on irc, but, as I
went down the page the noticed number became nontrivial, so I decided to
throw an email here instead.


We don't need a management hierarchy just to bring some structure to
the docs on the website.I don't see any benefit in creating a TLP
for programming languages.  If we were to move programming languages
around, for example, I'd want to bring PHP and Ruby under webapps, as
that's a more natural fit than a 'programming languages' category.

(And no, I'm not pushing for PHP and Ruby to move at all).

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users

2006-10-10 Thread Stuart Herbert

On 10/10/06, Seemant Kulleen [EMAIL PROTECTED] wrote:

If the design was in any way user-centric, then that was a side-effect
of the design being developer-centric.  The choices are all about
enabling development and developers. The Gentoo philosophy is about
empowerment -- we provide a platform for you to do what you want with
it.  That's our only promise, all the rest is just gravy.  Rel. Eng. and
others do what they do because, at its root, that's what they *want* to
do -- that's how they exercise their own empowerment.  Feel free to join
in the fray and exercise your own :)


Or, to put it another way ...

... One aspect of the Gentoo Way(tm) is this: if you don't like how
part of Gentoo works, the thing to do is to volunteer to become a
developer, and work from the inside to change it.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2

2006-10-08 Thread Stuart Herbert

Hi Zac,

On 10/8/06, Zac Medico [EMAIL PROTECTED] wrote:

I'm only proposing that we add support to portage now because it
seems like it will be useful in the future.  How and when people
make use of this support does not concern me much.

Zac


I believe that multiple parent support would be useful for the Seeds
project; it would allow the LAMP Developer Desktop (for example) to
inherit from both the generic 2006.1/x86 profile and the LAMP Server
profile.

I'm not saying we'd definitely end up going that way, but it would be
something worth testing when the time comes.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2

2006-10-08 Thread Stuart Herbert

Hi Danny,

On 10/8/06, Danny van Dyk [EMAIL PROTECTED] wrote:

I for one favour a more flattened profiles/ and a way to mark a profile
as 'not standalone', similar to a deprecated file, that isn't inherited,
to stop users biting their own asses. The following sample is not
complete, but should give the right impressions.

The Seeds project could do something like this:
+-Seeds
  |
  +-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp
specific useflags/packages.

But i lack knowledge here. Stuart?


I think Seeds could work with a structure like that.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Resignation

2006-10-07 Thread Stuart Herbert

Hi Tim,

On 10/7/06, Tim Yamin [EMAIL PROTECTED] wrote:

I would like to wish all of you the very best, and would like to thank
all of you who have (and haven't) made my time here so enjoyable.


All the very best with whatever you do next.  It's been a real
pleasure working with you on Gentoo, and at the Gentoo UK conferences,
and you'll be sorely missed.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] o.g.o: planet upgraded

2006-10-06 Thread Stuart Herbert
Hi,

Just a note to say that I've upgraded overlay.gentoo.org's copy of Planet to
the latest nightly release.  (We use Planet to generate o.g.o's front page).

If you notice any problems, please let me know.

Best regards,
Stu
-- 
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [DOWNTIME devmanual.gentoo.org]

2006-10-06 Thread Stuart Herbert

Hi Ciaran,

On 10/6/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:

Meh, but since this has been brought out in public, here's the full
text. Hopefully it'll help dispel some of the fud a few people are
spreading:


Anyone spreading FUD over this issue should be ashamed of themselves.
The whole f/oss world owes its existance to folks honouring the
licenses that material is published under.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-06 Thread Stuart Herbert

On 10/7/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

If anyone had still any doubt about this, he can easily try to tweak a
release :P
I've been doing releng-like work lately to build Gentoo/FreeBSD stages with
catalyst and I have to say that releng is doing a heck of an hard job to
produce the releases, and my requirements are waaay more open than their own
(as Gentoo/FreeBSD is still highly experimental)...


And if anyone's still not convinced, try remembering what it was like
before Chris started getting releng into some semblence of shape.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-04 Thread Stuart Herbert

On 10/4/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

Work is done in the overlays, tested, improved, then committed
into the main tree once the kinks have been worked out.  We get a
stronger core tree with fewer developers and a better interaction with
the community.


And a Gentoo that's so deeply loved by those who enact this plan that
they've strangled it with their love.

Ugh.  No thanks.

Gentoo's not just a project, it's a community.  Those of us who work
within it have a moral duty to preserve it, and all the opportunities
it offers people, for the developers who will come after us.  It is
_not_ for us to steal those opportunities from future generations.

Gentoo isn't ours.  We just hold it in trust for the moment.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] LAMP Server beauty contest: server monitoring

2006-10-01 Thread Stuart Herbert

Hi,

One of the things that the LAMP Server seed will install will be
something to do automatic server monitoring - CPU, RAM, swap, disk
space, bandwidth, and so on.

I'm a cacti user myself on my own boxes, but I'm interested to hear if
anyone has any strong preference for an alternative tool.  I'd prefer
it if the tool we finally choose is SNMP-based, to make it easy for
folks who want to deploy the LAMP Server in a web farm / multi-server
environment.

Please reply to the list naming your favourite tool for this job, and why.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The Seed Project - Try 2

2006-09-21 Thread Stuart Herbert

On 9/21/06, Lance Albertson [EMAIL PROTECTED] wrote:

Stuart: When you get a chance, can you please either message me on irc
or send em an email with your thoughts on how hosting might work so we
can start planning that?


Lance: Will do.

Everyone else: Please stop speculating about how we're going to host
and distribute seeds.  We're a long way off from having a releasable
seed to worry about.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Daniel Ostrow [EMAIL PROTECTED] wrote:

On Wed, 2006-09-20 at 00:56 +0200, Carsten Lohrke wrote:
 First step should imho be, that you work with the Portage team on having
 proper set support implemented. Current meta ebuilds do suck, really.

No need for meta ebuilds...stage4 specs + catalyst.

--Dan


To start with, we'll be using meta ebuilds as well as a catalyst spec
file.  We'd like to keep the door open for folks who want to install a
seed from an existing Gentoo installation.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

Uhh... seeds?


Yes, seeds.  Seems to describe what we're working towards as well as
any other name.


bring the work to the main tree?

As in... duplicate functionality already provided by catalyst for quite
some time?


No.  As in, bring the packages and profiles from the overlay into the
main tree, once we're happy with them.


Why hasn't anybody even *tried* to contact Release Engineering on
something like this, considering we already have all of the tools
necessary to complete this, as well as the expertise?


We have, and folks there have been very helpful.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

 Catalyst doesn't provide ongoing maintenance or migration of installed
 systems ... you need more than just a spec file for one of these seeds.

Like what?  It sounds like they aren't providing anything but tarballs.


Tarballs, VMware images, vserver images, Xen images, and CDs are what
we'll eventually deliver, sure.  Before then, we'll be putting
together packages and (we expect) profiles too.  It's likely that
we'll also support folks who want to install seeds from source (ie,
from a generic stage3 install) as well as folks who want to seed
directly from a stage4 tarball or equivalent.  We have already made a
(small) start in the project's overlay, and we've started documenting
our ideas and hopes on our project's wiki.

We don't pretend to have all the answers; part of the joy of this
project will be learning how to do this stuff, and what can be
achieved with the tools that we all have access to.


Because it's *REALLY* stupid and shows just how unprofessional we are
when we have multiple groups doing the *EXACT* same thing using
different policies and procedures and all pushing it as if it were
*OFFICIAL* for the distribution.


How exactly do rants like this look professional at all?


I mean, we're really getting to the point where this is getting
*COMPLETELY* ludicrous.  Instead of trying to work together, we have
every yahoo with an @gentoo.org address who wants to do something
*slightly* differently coming up with a new project for it.


We are working together.  I'm sorry if you feel left out, but we've
been talking to the folks that we need help from, and I'd like to
publicly say thank you to them for how helpful and supportive
they've been.  I hope Chris' email won't discourage anyone from
continuing to help us.

Until this childish tantrum arrived in my Inbox, I didn't know anyone
was unhappy.

Btw, I would thank you for coming to talk to me directly about this
issue first (which is how we ask Gentoo developers to behave) - but
unfortunately, you didn't, so I can't.


Why can't we simply try to work *together* on things instead of this
whole I'll start a new project mentality that we have?


I think you've just demonstrated the problem far better than I could have.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Matthew Marlowe [EMAIL PROTECTED] wrote:

3) We are where we are at today.  Stuart comes up with a great idea for the
seeds project which might help address the virtualization address image and
it appears releng doesnt like it, so progress could be delayed by another 6
months to year.


I can't claim credit for the idea; plenty of other folks have had the
same idea, and I'm sure plenty of our users are already doing this for
themselves in their own way.

Please be assured that Chris's comments today haven't discouraged me
(or, as best I know, any of the other contributors) from making this
happen.

I was hoping to avoid having to say this - actually I was hoping to
avoid this whole drama -  but we _don't_ need releng's approval to do
this.  To delay progress, Chris will need to make a formal complaint
to the Council.

I don't think Chris wants that.  Everyone, please give him some credit.

Besides, I'm sure we'll delay our own progress whilst we figure out
how to make seeds work well ;-)  I think folks are getting carried
away here!  Let's get stuff working first, eh?


Note that I am only bringing this issue up because I thought releng was being
unfair to stuart's proposal.


I wouldn't like to assume that Chris is speaking for releng here.  I
think it'd be fairer to assume that this is his personal opinion,
until something is explicitly said to the contrary.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Danny van Dyk [EMAIL PROTECTED] wrote:

Hi Stuart,

The pages are correct.


Cool.


He didn't called you a liar.


You haven't spoken to anyone on the genkernel or catalyst development
teams.  - was in response to me saying that I had.  It's difficult to
interpret that as anything other than calling me a liar.


However, what you wrote is not quite
correct. You did talk to 2 people of a whole bunch of people. Neither
Chris, Lars, Tobias, Andrew nor me knew anything about it.


??  I never said we'd talked to all of you.  I said we'd spoken to
folks on the teams.  What I said is correct.


If I understand you correctly, you did talk about usage of catalyst,
but you never informed Releng (as a project) about your intentions.
And that is what Chris is complaining about. And I agree with him here.


Duly noted.


Your project sounds really interesting though. I'd like to ask you some
questions:

* Are you aiming to release vserver images/stage4s together with
  the normal bianual releases?


Sorry, thought I'd covered this earlier (in fact, I know we did).
We're not at the stage of having that answer.  Our focus at the moment
is on getting a working seed defined and tested.

My personal feeling is that seeds are more likely to have a release
schedule based on what their respective $UPSTREAMs are doing.
$UPSTREAMs have their own, individual schedules; I believe that we
need agility to match.  Tying all seeds, irrespective of their
purpose, to the release of our generic release media doesn't seem like
the only answer that will work here.


* If yes, are you going to use the same snapshots?


We haven't discussed it.  Atm, we're focused on step 1, which is to
get the seeds themselves working from our overlay.


* If yes, for what arches do you want to release?


That will vary from seed to seed.  There's no automatic need to try
and release each seed on each and every arch that Gentoo as a whole
supports.

The advantage of the meta-package approach is that the bulk of the
value of the seed will be available on any arch where the packages are
keyworded.  We don't need create release media for each and every seed
for each and every arch.  We can deliver that release media for the
seed/arch combos where it makes sense.

A blanket policy of creating release media for every seed on every
arch doesn't seem practical or desirable.


* How do you want to implement the profiles?


We've only talked about profiles so far for a single seed.  We'd
prefer to inherit from the hardened profile, but we have a number of
questions that we need to answer before we can be sure on that.  We
won't know for certain what the answer is until we've been able to
define and field-test the LAMP Developer Desktop seed.  We don't
expect to deliver that seed until we've put out a LAMP Server seed for
testing and feedback.


* Re: the meta-ebuilds you'd been talking about in this thread: Have you
  yet considered to use the profiles' packages file?


Yes.  We think that we'll be making use of that, but we don't want
profiles to replace the meta-ebuilds.  We're going to try both, and
play with that for awhile to see where the balance best lies.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Danny van Dyk [EMAIL PROTECTED] wrote:

As long as we have no package sets support in portage, I do indeed think
that this is the best way to go. Didn't realize that you mentioned it,
too.
@Stuart: What do you think?


Right now, I'm not too concerned about the lack of package set
support.  That might change down the road, after we've lived with it
for awhile.

One of the things we're going to trial is supporting USE flags in the
seeds themselves.  We'll try out having the
seeds/lamp-server/release-1 profile (or whatever it ends up being
called) setting a suitable set of USE flags to support a LAMP
environment that includes Apache, PHP45, Perl, Python, and Rails.
The seeds-base/lamp-server package itself will rely on USE flags to
switch on all those options.  If anyone wants to build the seed from
source locally, they'll be able to change the USE flags (for example)
to build a LAMP Server that's dedicated to just Rails, or just Python.

We think that'll make the LAMP Server seed more useful to our users in
practice.  The folks who want a quick stage4 tarball to seed a box -
they'll get the whole nine yards.  But folks who want to customise
things (by compiling from source, probably using a stage3 tarball and
the standard minimal install CD) - they're catered for too.

That's why - atm - we don't want to just lump everything into a
profile, or just into a catalyst spec file.  Maybe one of those will
turn out to be the right way to go, but we'd like to explore this
approach first, and see how things turn out.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/20/06, Andrew Gaffney [EMAIL PROTECTED] wrote:

Well, now it's gotten to the point where people are being sneaky and underhanded
about this whole thing. Stuart (I believe) said that they had talked to members
of releng about this, but the truth seems to be that Stuart talked with rocket
and Xen support in stages and some random user associated with this project
talked to plasmaroo about using catalyst for stage4 builds.


Could you be a little more polite about our users _please_?  There was
a day when I was just some random user, just as there was for you
and everyone else who is, or has been, a Gentoo dev.

Here's one thing I don't get.  We have a project (Gentoo Seeds), which
is attracting interest and volunteers both from inside the Gentoo dev
ranks and (especially) outside.  Granted, it's not a lot of people,
but interest is always welcome.  Assuming we go on, and are successful
in establishing a sustainable project, that translates into extra
folks working on releases (and fresh eyes to boot).  It might only be
one or two people, but that's still one or two people more than what
we had midnight last Sunday.

Given all the complaints from releng in general (and Chris in
particular) about there not being _enough_ folks working on releases,
isn't this a _great_ opportunity for releng to recruit some
additional, motivated folks to help solve that problem?  Can't you see
that?

How much of a dent in this opportunity do you think this afternoon's
outpouring has made?  How many folks, reading what you've said (and
what you've ignored), will still feel motivated to consider maybe
moving on to releng in the future?

Could you have a think about that, and re-consider the unnecessary
hostility and unjustified accusations that you're filling this thread
with?

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



Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-20 Thread Stuart Herbert

On 9/21/06, Luca Barbato [EMAIL PROTECTED] wrote:

Could you please planning something about acting as liason between
projects touched by seeds?

E.G. random guy starts contributing a media seed, I'd like to be
notified and maybe have also x11 people notified, just in case the seed
overlay is doing something that I won't support.

Sounds reasonable?


Very reasonable.  We'll do our very best to achieve that.

One other rule I'll be operating is that every seed needs to be owned
by a full Gentoo developer, preferably someone who is from the project
that the seed most directly relates to.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New project: Gentoo Seeds

2006-09-19 Thread Stuart Herbert
Hi,

I've created a new project, called Gentoo Seeds [1].  The aim of the project
is to create stage4 tarballs which can be used to 'seed' new boxes with
ready-built Gentoo solutions.

At the moment, we're working on a basic LAMP Server (which is why we're
hanging out in #gentoo-php), and talking about following up with a LAMP
Developer Desktop.  If you'd like to help, we'd love to work with you.

We'd more than welcome other people who want to create completely different
seeds.  We're doing LAMP because it's an obvious thing to seed; we hope that
all sorts of seeds will appear down the road.

Until we've gone through a few iterations and worked out the best way to
create seeds, we're working in an overlay [2].  We certainly hope to bring
the work into the main tree once things have settled down.

[1] http://www.gentoo.org/proj/en/seeds/
[2] http://overlays.gentoo.org/proj/seeds/

Best regards,
Stu
-- 
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



signature.asc
Description: OpenPGP digital signature


Re: Fw: [gentoo-dev] New project: Gentoo Seeds

2006-09-19 Thread Stuart Herbert

Hi Matt,

On 9/19/06, Matthew Marlowe [EMAIL PROTECTED] wrote:

Can we integrate this somehow with a project (new?) to build ready-to-use
vmware or xen images?  It would be silly to duplicate the work, and
testing would be much better this way.


Sure.  For the moment, we're focusing on getting the basic packages built.


I would see the workflow proceed in the following manner:
Releng herd makes available new official gentoo releases
   After a few weeks, the seeds herd takes releng product and creates new
application/environment specific stage4 images
   Then, after a few more weeks, the virtualization herd takes seed
product and adds appropriate vmware/xen/etc modifications to create
ready-to-run virtualization images.


I think that sort of detail is a long way in the future for us.

When we get there, I don't think it'll necessarily work best to
strictly tie the release of seeds to the generic Gentoo release media.
It would probably make sense for the seeds release schedules to also
be influenced by their respective $UPSTREAMs.

I don't think we need to worry about it too much until we've actually
got working seeds that are stable enough to be considered for release.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] KDE and Ruby herd call for help

2006-09-15 Thread Stuart Herbert

On 9/14/06, Doug Goldstein [EMAIL PROTECTED] wrote:

 Caleb,


 question... gem is the official package manager for Ruby.  Why do we
 put Ruby stuff, other than the bare minimums to get Ruby running, in the
 portage tree?  Why not just let gem handle it?


I favor this the same way I favor pear and pecl to handle those
extensions. But to each his own I guess... Aaron and I will have our own.


It makes sense to put gems into Portage if they are deps for other
packages, or (in the case of something like mongrel) if they're an
important package in of themselves.

If we had the man-power (which we don't), I'd favour having ebuilds
for as many gems as possible.  When you're managing servers, it's very
nice to be able to audit your server against what the package manager
says should be there :)

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Looking for a confcache maintainer

2006-09-11 Thread Stuart Herbert

On 9/8/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

After sending this mail, I'll be removing myself from the metadata of
dev-util/confcache ; I've tried maintaining the ebuild and supporting
confcache usage in Gentoo, but I'm unable to proceed with this task.


I'll take it back.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for www-apps/drupal

2006-09-11 Thread Stuart Herbert

On 9/9/06, Christel Dahlskjaer [EMAIL PROTECTED] wrote:

Drupal has had QA bug #98542 open for over a year now, and has seen no
progress in resolving it. It has now been package.masked, and unless
someone jumps up to fix the outstanding issues will be removed in 30
days.


Why didn't you escalate this to either of the webapps herd leads
first?  You've certainly had the opportunity to do so before now.

We're all meant to be working _together_.  This is _not_ a shining
example of how to do so.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for www-apps/drupal

2006-09-11 Thread Stuart Herbert

On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:

Uhm, web-apps has been CCed on the bug since the beginning. Last time I
asked, noone wanted to touch the FUBARed ebuild, IIRC. :)


The package was masked without Christel (on behalf of QA) posting an
advance warning of their actions.  That's not trying to work together.
It's not trying to work with existing teams.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for www-apps/drupal

2006-09-11 Thread Stuart Herbert

On 9/10/06, Luca Barbato [EMAIL PROTECTED] wrote:

Alec Warner wrote:
upstream for that reason


Upstream sucks badly here.


us because we haven't a tool like the one BaSS wrote for the ebooks.


Such a tool would deal with many modules, but not all of them.  Some
modules require additional dependencies, which a tool just isn't going
to know about.  Last count, there were 187 modules for Drupal
upstream; there are probably more now.

I have new ebuilds for drupal, and a number of modules (I think I got
up to 'f') locally.  I'll get them into the webapps overlay, so that
folks can test them, and help out.

Drupal's such a beast that it probably needs its own herd to keep on
top of things.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for www-apps/drupal

2006-09-11 Thread Stuart Herbert

On 9/11/06, Roy Marples [EMAIL PROTECTED] wrote:

I'm more than happy for you to take Drupal instead of me :)
However, is there any reason that the main drupal ebuild cannot stay in
portage?


No reason at all, that I know of.

Drupal's a package I can't really work on; I work for a company that
writes and sells a very successful (and proprietry) CMS.  Looking
after the main ebuild isn't that much work for someone; it's sorting
out all the modules that's a full-time job.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Stuart Herbert

On 9/7/06, Carsten Lohrke [EMAIL PROTECTED] wrote:

How wonderful this sort of maintenance is you can read here:

https://bugs.gentoo.org/show_bug.cgi?id=146626

Am I the only one who has a problem with this?


No.  And I'm sure I'm not the only one who has a problem with your
comment in that bug either.  Bugzilla isn't there for flaming other
devs.

There was a time when we used to suspend devs for doing that.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Trustees Announcement

2006-09-06 Thread Stuart Herbert

On 9/6/06, Stephen P. Becker [EMAIL PROTECTED] wrote:

Actually, I *think* he was trying to ask why Stuart feels that he can
take on the responsibility of being a trustee if he felt that he didn't
have the time to take on the responsibility of being a council member.
I also must admit that I'm curious of the answer to that in light of the
fact that he admittedly plans on leaving Gentoo sometime soon.


To save everyone a bit of time, it'd be quicker just to read the
existing thread on -core where I explained why I was standing as a
trustee.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-core] Re: [gentoo-dev] Global USE flags bite the dust...

2006-09-06 Thread Stuart Herbert

On 9/6/06, Alin Nastac [EMAIL PROTECTED] wrote:

Doug Goldstein wrote:
 dba
 dio
 ingres
 msession
 mcve

 are all used by 1 ebuild... and that's dev-lang/php... they should be
 moved to local's.


Consequence: php eclasses code should be moved in dev-lang/php ebuild.


Please don't do that.  The PHP eclasses are there because we used to
support building other PHP SAPIs (specifically thttpd).  That's also
why the USE flags were made global, as they'll need to be supported by
all of web servers that will bundle PHP support.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Trustees Announcement

2006-09-05 Thread Stuart Herbert

On 9/5/06, Stephen P. Becker [EMAIL PROTECTED] wrote:

I just remembered something.  Didn't Stuart say that he planned on
leaving Gentoo when he was nominated for the Council recently (and
declined)?


Yes I did.  There are a few things I want to achieve before I leave;
being on the Council would have been a distraction from that.

Best regards,
Stu
--
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo 2006.1

2006-09-03 Thread Stuart Herbert

On 9/3/06, Alec Warner [EMAIL PROTECTED] wrote:

And no one has implemented any kind of solution.


You need someone to implement a solution?  Surely what we need is for
folks to actually make an announcement in the first place?

I asked for what has become GLEP 42 because we do have a problem
reaching folks with announcements.  But you know what?  GLEP 42
wouldn't help in cases like this, where there's either no announcement
at all, or the announcement comes at the last minute.

Technology is just a tool.  A technical solution needs something fed into it.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo 2006.1

2006-09-03 Thread Stuart Herbert

On 9/3/06, Alec Warner [EMAIL PROTECTED] wrote:

Because the thought that stable is always stable or that because we
released things are stable is incorrect ;)


You're not supposed to break the stable tree; that surely must include
stabilising a compiler (which is the _default_ for new installs) that
can't compile all the packages marked stable for your arch.

grumbleFeels like one rule for one group (the package maintainers)
and another for another group (releng / x86 arch team) to
me./grumble

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo 2006.1

2006-09-02 Thread Stuart Herbert

On 9/2/06, Alec Warner [EMAIL PROTECTED] wrote:

Give us about 3000 more developers, and sure* ;)


I don't think that that's good thing to be saying to our users.

We didn't need 3000 more developers ... we just needed to give the
developers we have more reasonable notice.

This is the second time in recent weeks that we've acted like this, by
stabilising a major package with little or no notice.  It's the same
group of folks involved both times.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Paid support

2006-09-02 Thread Stuart Herbert

Hi,

On 9/2/06, Donnie Berkholz [EMAIL PROTECTED] wrote:

It might be worth putting together a list of folks interested in doing
this on the Gentoo website, under a Third-party Paid Support section. We
already have a Support link on the top of www.g.o, it could be on that page.


This is a good idea.

If you do it, it would be a very good idea to also post basic advice
for Gentoo developers who put their name down for this.  Folks'll need
to know about contracts, documenting their work, and insurance.
Per-country advice on independent contracting would also be helpful.

We'll also need to sort out a process for handling complaints against
developers from the folks they help.  Doesn't matter how well we make
it clear that these folks are independent; their actions will
reflect on Gentoo as a whole, and unhappy customers _will_ complain to
us sooner or later.  Rather than pretent it won't happen, better we're
pro-active and have something prepared.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo 2006.1

2006-09-02 Thread Stuart Herbert

On 9/2/06, Dan Meltzer [EMAIL PROTECTED] wrote:

On 9/2/06, Stuart Herbert [EMAIL PROTECTED] wrote:
 On 9/2/06, Alec Warner [EMAIL PROTECTED] wrote:
  Give us about 3000 more developers, and sure* ;)

 I don't think that that's good thing to be saying to our users.

Is it a bad thing to be saying to your developers?


It wasn't said to developers, it was said to a user.


The gcc-4.1 stabilization bug has been open for a month and a half.


That's great, but that's not an announcement.  Folks aren't going to
go digging through bugs to find stuff like this.


Thats fairly good notice...


Only to the folks who knew about that bug.  For the wider community
... it's not notice.


Warnings have also appeared on
planet.gentoo.org, and in the GWN.


Tsunam posted that there was a push on to get gcc-4.1 stable, but
there was no target date, and no firm statement that said it would
definitely be happening.  He posted this on July 19th.  Was there
another warning, with dates and stuff?

The GWN warning was last week.  My apologies if there was an earlier
one that I missed.

My apologies, but I've been unable to find an announcement on -dev.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Democracy: No silver bullet

2006-08-25 Thread Stuart Herbert

On 8/24/06, Donnie Berkholz [EMAIL PROTECTED] wrote:

A distribution is more than just an entity that packages upstream
tarballs. I agree with your point, but it misses a large chunk of what
we do.


We do more than that, sure, but the vast majority of the day to day
work in Gentoo is exactly that - packaging software released by
upstream, and fixing bugs reported back from users.

What do you do that goes beyond this?


If this is the Gentoo vision, then why are we even doing anything else?


Because folks want to?  Because we've been recruiting people to
shoulder the load, instead of recruiting them into a culture?  Because
we want to see Gentoo run on a wider variety of hardware than
$upstream has access to?  Because we want to make Gentoo more
accessible to folks than it was in the past?

What activities are we doing that don't directly support the Gentoo vision?


We've already reached our only goal, which is packaging stuff, and all
we need to do is bump it.

People need to feel that Gentoo is _moving forward_, that it's actually
going somewhere.


We have no organisation that's going out there making deals with
commercial entities, ISV partners, nor users.  In that respect, we're
a completely different beast to RedHat, SuSE and Ubuntu.

You're not the first, and you won't be the last, to complain that
we're not going anywhere.  My question is simple : where do folks want
to go, and what is stopping them getting there?  Seriously - what
exactly is this enormous brick wall that folks need a boost from
management to climb over?


Then why wasn't the hierarchy fixed? Instead we somehow ended up in this
huge metastructure debate and changed everything around.


It was hardly a huge debate, unless your only metric of measurement
is number of posts.  Take that debate, and then re-imagine it as an
event in the physical world, with folks having face to face contact.
You'll find that none of these debates are really that big.  They just
seem big, because electronc communications can be so inefficient.

Personally, I'm opposed to a return that that hierarchy.  The idea
that somehow desktop, server, and other such projects should sit at an
exclusive top-table doesn't work for me.

Gentoo would be much more effective with having a core management team
that covered our key operations (infra, devrel, userrel, pr, releng,
and 'tools' - portage and catalyst), and which ensured that they all
worked together to give the outward appearance of an organised
distribution.  Have management focus on what forms the spine of the
Gentoo organisation.

The lack of this management structure is, to pick one example, behind
the grief Infra are getting over the long-term problems with bugzilla.
Folks aren't complaining about bugzilla any more; they're complaining
about the problem continuing.  Effective senior management would have
done three things in particular here which would each have made a
difference:

 a) They would have provided oversight on Infra's handling of the problems.
 b) They would have communicated effectively with the wider
organisation, explaining what was going on, why, and when it would be
resolved.  This communication would be early, it would be frequent.
 c) They would provide Infra with resources they can't get on their
own to solve the problem, including additional budget.

It's been agreed on -dev that it's not the existing Council's job to
do any of these things wrt the ongoing bugzilla problems.  So
everyone's left with a service that's not fit for purpose at the
moment, and only Infra to grumble about.  Everyone loses sight of the
steps Infra is taking to resolve matters, and nobody wins.

Your top table of herds does nothing to address what Gentoo really
needs.  It's a step backwards at best.


Official votes, sure. But what about GLEP discussions on -dev? That's
the only way anything major ever happens, and it might as well be a
requirement for a unanimous vote among all ~350 developers. The only
time I can recall even a single dissenter before a GLEP moved on to the
council was brix on Sunrise.


I call bullshit on this.  Big time.

There are lots of major things happening all the time - you're one of
the people who make this happen - and they don't require GLEPs.  GCC
upgrades, X.Org 7, Portage 2.1, Gentoo Overlays, Java 1.5 - these and
many _many_ more are all major things for the users affected by them.

What major things do you want to see that aren't getting done because
of the perceived need for GLEPs?

It's also worth pointing out that we're hardly snowed under with
GLEPs.  There has been only 51 in the last three years; that's less
than two a month on average, and just under 50% of GLEPs were filed in
the first twelve months of the GLEP process's existance.

Your recollection is faulty; there _is_ no GLEP for sunrise.


 The basic cause always comes down to weak or non-existent management.

Yes, and that's exactly my point. We need stronger management.


We need _appropriate_ management.  

Re: [gentoo-dev] Democracy: No silver bullet

2006-08-25 Thread Stuart Herbert

On 8/24/06, Donnie Berkholz [EMAIL PROTECTED] wrote:

A distribution is more than just an entity that packages upstream
tarballs. I agree with your point, but it misses a large chunk of what
we do.


We do more than that, sure, but the vast majority of the day to day
work in Gentoo is exactly that - packaging software released by
upstream, and fixing bugs reported back from users.

What do you do that goes beyond this?


If this is the Gentoo vision, then why are we even doing anything else?


Because folks want to?  Because we've been recruiting people to
shoulder the load, instead of recruiting them into a culture?  Because
we want to see Gentoo run on a wider variety of hardware than
$upstream has access to?  Because we want to make Gentoo more
accessible to folks than it was in the past?

What activities are we doing that don't directly support the Gentoo vision?


We've already reached our only goal, which is packaging stuff, and all
we need to do is bump it.

People need to feel that Gentoo is _moving forward_, that it's actually
going somewhere.


We have no organisation that's going out there making deals with
commercial entities, ISV partners, nor users.  In that respect, we're
a completely different beast to RedHat, SuSE and Ubuntu.

You're not the first, and you won't be the last, to complain that
we're not going anywhere.  My question is simple : where do folks want
to go, and what is stopping them getting there?  Seriously - what
exactly is this enormous brick wall that folks need a boost from
management to climb over?


Then why wasn't the hierarchy fixed? Instead we somehow ended up in this
huge metastructure debate and changed everything around.


It was hardly a huge debate, unless your only metric of measurement
is number of posts.  Take that debate, and then re-imagine it as an
event in the physical world, with folks having face to face contact.
You'll find that none of these debates are really that big.  They just
seem big, because electronc communications can be so inefficient.

Personally, I'm opposed to a return that that hierarchy.  The idea
that somehow desktop, server, and other such projects should sit at an
exclusive top-table doesn't work for me.

Gentoo would be much more effective with having a core management team
that covered our key operations (infra, devrel, userrel, pr, releng,
and 'tools' - portage and catalyst), and which ensured that they all
worked together to give the outward appearance of an organised
distribution.  Have management focus on what forms the spine of the
Gentoo organisation.

The lack of this management structure is, to pick one example, behind
the grief Infra are getting over the long-term problems with bugzilla.
Folks aren't complaining about bugzilla any more; they're complaining
about the problem continuing.  Effective senior management would have
done three things in particular here which would each have made a
difference:

 a) They would have provided oversight on Infra's handling of the problems.
 b) They would have communicated effectively with the wider
organisation, explaining what was going on, why, and when it would be
resolved.  This communication would be early, it would be frequent.
 c) They would provide Infra with resources they can't get on their
own to solve the problem, including additional budget.

It's been agreed on -dev that it's not the existing Council's job to
do any of these things wrt the ongoing bugzilla problems.  So
everyone's left with a service that's not fit for purpose at the
moment, and only Infra to grumble about.  Everyone loses sight of the
steps Infra is taking to resolve matters, and nobody wins.

Your top table of herds does nothing to address what Gentoo really
needs.  It's a step backwards at best.


Official votes, sure. But what about GLEP discussions on -dev? That's
the only way anything major ever happens, and it might as well be a
requirement for a unanimous vote among all ~350 developers. The only
time I can recall even a single dissenter before a GLEP moved on to the
council was brix on Sunrise.


I call bullshit on this.  Big time.

There are lots of major things happening all the time - you're one of
the people who make this happen - and they don't require GLEPs.  GCC
upgrades, X.Org 7, Portage 2.1, Gentoo Overlays, Java 1.5 - these and
many _many_ more are all major things for the users affected by them.

What major things do you want to see that aren't getting done because
of the perceived need for GLEPs?

It's also worth pointing out that we're hardly snowed under with
GLEPs.  There has been only 51 in the last three years; that's less
than two a month on average, and just under 50% of GLEPs were filed in
the first twelve months of the GLEP process's existance.

Your recollection is faulty; there _is_ no GLEP for sunrise.


 The basic cause always comes down to weak or non-existent management.

Yes, and that's exactly my point. We need stronger management.


We need _appropriate_ management.  

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

2006-08-15 Thread Stuart Herbert

On 8/14/06, Thierry Carrez [EMAIL PROTECTED] wrote:

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


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

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

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



Re: [gentoo-dev] Endless frustrations again :(

2006-08-08 Thread Stuart Herbert

On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote:


big_snip

Okay, you simply don't want to talk or even think about this issue.


You have had lots of help from many different Gentoo developers and
users on your recent issues.  All of these people are volunteers, and
have given their time and expertise to you for free.

Folks have been *very* patient with you - far more than *you* have
been with them.


I won't waste more of my lifetime with it, and I won't let you
do more acts of demotiviation. If you wouldn't have descrited my
intensions this way and these personal attacks didn't happen,


Again - folks have been *very* patient with you, and have worked hard
to explain to you why the suggestions you've made are ones that we
don't agree with.

Instead of trying to fight all of Gentoo, you would do better to first
learn how a Gentoo system (and its packages) are intended to work, and
why.  Gentoo's radical improvements over binary distros can be both
overwhelming and confusing at first.


I would have set up my own overlay for this project and simply
fix the problem. But obviously this isn't wanted here.


We welcome contributions to Gentoo.  Folks are free to contribute by
contacting package maintainers directly, by getting involved on
mailing lists, by filing bugs and patches in bugzilla, by contributing
to official overlays (on o.g.o and elsewhere), and by contributing to
the Sunrise project.  We're truly a community distro - one of only two
(Debian being the other) - and we live or die by the support we get
from the wider community.

I think setting up your own overlay is a great idea.  I can't think of
a better way for you to learn about upgrades, downgrades, SLOTing and
dependency atoms than by maintaining a bunch of packages for a year or
two.


All my other improvement efforts were simply ignored either or
directly discredited, so they're also not wanted.


If you are saying that patches from you have been included into Gentoo
without appropriate credit, please let us know.  That should not
happen.

On the other hand, if you are saying that you are feeling ignored ...
well, imagine how we feel.  We've tried to help you, and explain
what's where and why, and we feel that you're either not listening or
just not understanding what we're saying.


You just want
to remain in your traditional grid of thinking. You won't ever
listen, so I'll let you stay there in peace.


Maybe *you* need to learn to listen, in order for others to listen to you?


I'm now warned that I it's not wise to use gentoo for mission
critical environments.


Bullshit.  Gentoo is a *great* solution for mission critical environments.

We have suggested to you that it's not wise for *you* to be using
Gentoo.  You either don't want to learn how to use Gentoo the way it
is meant to be used, or it's too difficult for you.  Either way, until
that changes, it's difficult to see how you will be happy using
Gentoo, or trying to contribute back to it.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] use.force as a complement to use.mask in profiles

2006-08-08 Thread Stuart Herbert

Hi Zac,

On 8/8/06, Zac Medico [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

I've written a patch [1] that implements support for use.force and package.use.force as originally 
described by Sven Wegener [2] over a year ago.  Basically, this feature is the exact opposite of 
use.mask and package.use.mask.  It forces USE flags to be enabled.  The only way to disable these 
forced flags is to mask them via use.mask/package.use.mask or to unforce them in the 
profile stack.  Users can unforce them via /etc/portage/profile/{use.force,package.use.force} in 
the usual -flag way.


Looks useful for arch teams.  Doesn't seem very interesting for
package maintainers.

Any chance of per-package USE defaults support?  That's much more useful to me.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] per-package USE defaults

2006-08-08 Thread Stuart Herbert

Hi Zac,

On 8/8/06, Zac Medico [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stuart Herbert wrote:
 Any chance of per-package USE defaults support?  That's much more useful
 to me.

Attached to bug 61732 there's a patch that implements this via a new 
IUSE_DEFAULTS ebuild variable.  If people like that particular implementation, 
then I'll update the patch so that it applies to portage-2.1.1_pre.  Some might 
suggest that an EAPI bump is proper for the addition of this type of 
functionality, but perhaps we can slide it in without that extra annoyance.

Zac


As a package maintainer, I'm happy :)  Is this going to cause problems
for arch teams at all?

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] www-apps/wordpress

2006-08-04 Thread Stuart Herbert

Hi,

On 8/4/06, Aaron Kulbe [EMAIL PROTECTED] wrote:

I am the current maintainer of WordPress.  Let's just say I've lost
interest in maintaining it.  At this point, I don't even use it any
more, other than to test out new builds on my system, when a bump is
required. I have switched over to another solution I prefer.

I am not going to drop the ball on WordPress, but if any Gentoo dev
wants to jump in and take it over, I'm not going to raise any
objections.

Anyone interested?


Just to follow-up on this ... Wordpress has had a chequered history
w.r.t. $upstream's attitude to security.  Whoever takes this over will
need to build up a good relationship with $upstream, to make sure that
we can handle security issues in a timely manner.

Don't want to put anyone off ... just want to make sure folks know
what they are letting themselves in for.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Gentoo Overlays: Status Report

2006-08-04 Thread Stuart Herbert

Hi,

Everything we had planned for Gentoo Overlays [1] phase 1 is now in place:

  * Active admin team
  * overlays.gentoo.org site, hosted on Gentoo infrastructure
  * Trac and Subversion for each overlay
  * Homepage aggregating the RSS feeds from each overlay
  * Developers and Users Guides online [2], [3]
  * #gentoo-overlays channel to provide support for overlay owners
  * Overlays available over https

We have over thirty overlays currently hosted.  If you'd like yours adding, 
drop by #gentoo-overlays and we'll get you hooked up.


I think we're ready to announce the service, but before we do, I thought 
it'd be a good idea to get feedback from the wider dev community.


Best regards,
Stu
--

[1] http://overlays.gentoo.org
[2] http://www.gentoo.org/proj/en/overlays/devguide.xml
[3] http://www.gentoo.org/proj/en/overlays/usersguide.xml

--
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] logwatch needs love

2006-08-01 Thread Stuart Herbert

Hi Mike,

On 8/1/06, Mike Frysinger [EMAIL PROTECTED] wrote:

i'm tired of looking at this package, anyone care about this thing enough to
be its maintainer ?
-mike


I'll take it, if no-one else wants it.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Funding from Gentoo UK 2006 event

2006-07-25 Thread Stuart Herbert

Lisa Seelye wrote:
 Is there any news on a 2007 event? This time, really, I promise I'll be
 in the country to attend!

No, and you won't hear anything from me. I won't be in the country.

Daniel


Someone needs to step up and volunteer to organise next year's conference.

Dunno about other folks, but I'd be very happy to see us return to the
Resource Centre once more.  I thought that it worked well as a venue,
and that London is the right place to hold the conference.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New category: net-voip

2006-07-23 Thread Stuart Herbert

Jakub Moc wrote:
as .cfg_** files. The end user still has to run an etc-update and 
pray that it was not a file he/she had in masking.


Err, no? You don't need to run etc-update/dispatch-conf to get those
updated on package moves.


Incorrect.  You do have to run etc-update/dispatch-conf.

Best regards,
Stu
--
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New category: net-voip

2006-07-23 Thread Stuart Herbert

Kevin F. Quinn wrote:

An advantage to this approach is that package moves just become aliases
- existing stuff doesn't break yet you get the new categorisation as
well.


That's actually a disadvantage.  The whole point of moving a package is to 
take it *out* of its existing category.  Just adding an alias into a second 
category makes the tree more of a mess - not less.


Best regards,
Stu
--
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New category: net-voip

2006-07-21 Thread Stuart Herbert

On 7/19/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:

In my opinion moving packages from one category to another just causes
unnecessary disruption to the tree - all relevant dependencies
throughout the tree have to be altered, putting current installations
out-of-date with respect to it.


Some other folk hold a different opinion.  It's both perfectly natural
and desirable for packages to migrate out of -misc type categories
into more targetted categories over time.  We've done it in the past,
and it's something we need to be able to continue to do in the future.
It helps folks look for things when they don't know the name of what
they're looking for, and it stops -misc type categories from becoming
dumping grounds.


The key issue is that categories are semantically inadequate.


Do you have any evidence to show that this is a widely-held opinion?
Have you done any research amongst the wider user community to find
out how they view categories?


Deciding
which category a package fits into is subjective, frequently a package
fits into many categories yet the category system insists that a
package belong to one and only one category.


All classification systems are subjective, imperfect, and prone to
change over time.  Portage's is no worse than any other in this
respect.

(What is worse is the way Portage copes with change ... I agree with
Mike here, we should be fixing our tools, rather than being
artificially restricted by them).


Usually these big package moves occur when people want to align herds
with categories, which is a waste of time - also it's daft as packages
can sensibly belong to more than one herd.  Unfortunately we see a lot
of it in the tree.


You think it's daft, but that's just one perspective.

What would you prefer?  A tree where packages never ever move
category?  Christ, if we followed that dogma, then categories really
would be useless, because we'd have far too many packages filed in the
wrong place, or in general catchall -misc type categories.

I think it's more important that the tree can be flexible, and can
change structure over time.


This week it's packages that have voip functionality that are being
moved to net-voip.  In six months time it'll be someone else wanting to
move all packages with IM functionality into net-im.  In herd-speak,
these packages could easily belong to both the voip and im herds,
should such exist; those providing c++ libraries could also belong to
the cpp herd.  This is useful, as the maintainers of those herds can
each deal with issues in their field.  It doesn't matter which category
it's in.


It seems a bit odd that a language herd like cpp (using your own
example) would maintain a package just because the package itself is
written in cpp, irrespective of what the package actually does.  For
example, the PHP herd is focused on packages that provide the PHP
language and it's supporting infrastructure ... not on applications
that are written in PHP.  Those are left to other herds, who are more
expert in the problems that those applications solve.


The only concrete thing categories give us is the ability to have two
packages with the same upstream name without having to mangle the
upstream name.


Not true.  They provide us with an organisational ability too, whether
its grouping packages to ensure people don't dump stuff in the tree
(dev-perl being the classic example here), grouping packages by origin
(gnome-*) or by common purpose (sys-fs).  If a user needs something,
but doesn't know which package they want, they can look inside the
relevant category, and see what their choices are.

In fact, categories do not give us the complete ability to have two
packages with the same upstream name in the tree ... because binary
packages do not support category names at all.


Unfortunately the category system is deeply embedded in portage and the
tree, so changing that system is simply not going to happen, which is
why I've stopped whinging about the semantic inadequacy of the system.


Instead of whinging about why the existing categories are bad, why not
instead put forward an alternative (preferably with code, but a clear
and consistently argued position would be a start) for something
better?  Otherwise, you *are* going to be ignored ... and with good
reason.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-21 Thread Stuart Herbert

On 7/6/06, Patrick Lauer [EMAIL PROTECTED] wrote:

So here's my nominations:

Flameeyes
brix
lu_zero
kosmikus
Stuart
jakub
marienz
patrick


Thanks, but I don't accept.  I'm planning on leaving Gentoo.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] architectures which support Java

2006-07-21 Thread Stuart Herbert

Hi Mike,

On 7/21/06, Mike Frysinger [EMAIL PROTECTED] wrote:

in Gentoo or in general ?  in general, kaffe should support pretty much all
our arches, but in Gentoo, i dont have time to get it working for:


Last time I checked, kaffe didn't provide a libjvm, which is used for
embedding Java in other applications (such as PHP).

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for net-misc/ssh

2006-07-11 Thread Stuart Herbert

Hi,

On 7/11/06, Gustavo Felisberto [EMAIL PROTECTED] wrote:

I'm removing net-misc/ssh from the tree as Tectia no longer provides a free
version of they're ssh client and server. The last update to this package was
one year and half so I'm a bit afraid of security issues that might exist that
were not reported.


Have you tried contacting them, and asking them for a license for
their product, so that you can provide an ebuild for the non-free
version?

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Off with your heads!

2006-07-07 Thread Stuart Herbert

On 7/7/06, Steve Dibb [EMAIL PROTECTED] wrote:

If your blog is being aggregated on Planet Gentoo / Universe, it's time to send
us a copy of your smiling face.  I'm putting out a request for some
hackergotchis.  Really, you don't want just a few of us to have all the fun, do 
you?


Any chance of you updating the template so that the heads don't look
quite so naff?  They're a bit of an afterthought atm, and it shows.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Replacing cpu-feature USE flags

2006-07-06 Thread Stuart Herbert

On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
[Snip]

Note that you  need to set your CFLAGS corretly or it will, by default, tell
you that everything is disabled.

Thoughts? Comments?


The one advantage of using USE flags for this is that the support can
be controlled very easily on a per-package basis.  CFLAGS is much more
of a system-wide setting.

Are there examples where we'd want to have these CPU feature flags
enabled for one package, but disabled for another (for performance or
stability reasons)?

If this is an ability we no longer need, then I like your idea.

Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL and Source code providing

2006-06-28 Thread Stuart Herbert

Hi,

On 6/28/06, Mivz [EMAIL PROTECTED] wrote:

Hello,

I have just read the following story, which scared me a bit:

http://software.newsforge.com/article.pl?sid=06/06/23/1728205tid=150

Does this obligation, to provide your own source, also count for a none
Gentoo developer making a overlay tree for one of his projects which is
licensed under de GPL-2? Because that is a derived distro form Gentoo
right?
Would that mean that, if u write software using the portage system, that
every package that is used by one of your own should be available from a
server of your own?
If, the developer should also provide it's own file server with all
those packages, this would cause that every developer that wanted to
make a overlay should be a Gentoo file mirror?

Do my senses run wilde? Your just my imagination?
Do I understand this right?

Mivz


Questions on how the law affects Gentoo are best put to the Gentoo
Trustees, who have access to our lawyers.  They're the only people who
should be commenting on legal stuff like this.

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL and Source code providing

2006-06-28 Thread Stuart Herbert

On 6/28/06, Mivz [EMAIL PROTECTED] wrote:

How free is free software if you need a lawyer and a expensive server
just to be able to publish your addition under your own name?


With the GPL v2, you don't need a server at all.  You're perfectly
entitled to distribute the code on DVD (for example), for a fee.  You
don't have to keep the source online at all.

If the GPL v3 does require you to keep the source online, that'd be a
shame.  Relying on third parties (such as SourceForge, or Berlios) to
host your source online is risky ... if they disappear, *you* are
still liable to keep your source code online (presumably the three
year rule still applies).  If the third party disappears, taking older
versions of the code with it, what then for you?  Technically, you're
in violation.

The idea that everyone has cheap hosting available to them is sadly an
incomplete view of the world :(

Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list



  1   2   3   >