Re: [gentoo-dev] Little respect towards Daniel please
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
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
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-dev&m=115672836418923&w=2 Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Versioning the tree
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: Re: Versioning the tree
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: Versioning the tree
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
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
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: Versioning the tree
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
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
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
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: Patent threat?
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] Patent threat?
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: Monthly Gentoo Council Reminder for November
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] Re: Monthly Gentoo Council Reminder for November
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
Re: [gentoo-dev] Retirement
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] Only you can prevent broken portage trees
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
Re: [gentoo-dev] Only you can prevent broken portage trees
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'/ 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
On 10/31/06, Stephen P. Becker <[EMAIL PROTECTED]> wrote: You do realize that Ciaran *was* a member of several arch teams, right? Of course. But "was" _is_ the operative word. It's not like I'm asking for him to be banned from the Gentoo mailing lists or anything. Chill, ffs. Arch team leaders set policy on this issues, not Ciaran. It's useful for developers (especially ones who have joined Gentoo since Ciaran was expelled) to be clear on what the arch team policies actually are. I would agree with pretty much everything he has said on this topic. Perhaps you should consider that the reason that not many arch team folks have chipped in is because we agree with him. All I'm asking is for arch team leaders to say so. It's hardly unreasonable or controversial to ask that. Don't dismiss his responses as noise from some random "Gentoo user" who has no idea what they are talking about. You should know better then that Stuart. I'm not dismissing his responses. I'm just asking for arch team leaders (which is who the questions in this thread were addressed to) to chip in, tis all. Which, I'm glad to say, they've been happy to do. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Only you can prevent broken portage trees
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
[gentoo-dev] Gentoo group on Flickr - repost from pl.g.o
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] Changing the metastructure (was: [Council] Summary of the last meeting)
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] Changing the metastructure (was: [Council] Summary of the last meeting)
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)
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)
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
[gentoo-dev] Changing the metastructure (was: [Council] Summary of the last meeting)
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] Re: New Devrel Subproject: Gentoo Devmatch
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
[gentoo-dev] Re: [gentoo-nfp] New Trustees - My Resignation
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
[gentoo-dev] Re: [gentoo-nfp] New Trustees - My Resignation
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
Re: [gentoo-dev] New Devrel Subproject: Gentoo Devmatch
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
Re: [gentoo-dev] RFC: per-package default USE flags
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] *plop*
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
[gentoo-dev] Proposed new USE-EXPAND: 'SEEDS_EXTRA'
Hi, In the Seeds overlay, I've been working on an experimental profile for the LAMP Server seed (*). The overlay uses a new USE-EXPAND, which I've called SEEDS_EXTRA, to cleanly control the 'extra', or 'value-added' features that a Seed can include when it is built from source [1]. The intention is that Seeds will ship with a default set of SEEDS_EXTRA features enabled [2]; users who would prefer to customize a seed by building from source will be supported too. Why a new USE-EXPAND, instead of just using USE flags? We're using SEEDS_EXTRA to define the high-level functionality that a seed comes with. We started out mixing this up in USE flags along with everything else, but we feel things are much clearer for ourselves and for users if they're separated out into their own USE-EXPAND. [1] http://overlays.gentoo.org/proj/seeds/browser/trunk/profiles/desc/seeds_extra.desc [2] http://overlays.gentoo.org/proj/seeds/browser/trunk/profiles/seeds/lamp-server/x86/release-1/make.defaults (*) The profiles will need to change to take advantage of multiple inheritance, and Chris's new profiles, once they hit the tree. We don't expect those changes to affect the SEEDS_EXTRA USE-EXPAND. 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] RFC: per-package default USE flags
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] RFC: per-package default USE flags
On 10/13/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: Except that a USE flag's state isn't metadata. It's something that comes from the profile. The default USE flags, enabled to reflect the same results as running ./configure w/ no enable/disable flags, _is_ metadata; metadata about an individual package. Perhaps you should look into getting Portage to allow separate profiles per repository. That'd get around the overlay issues... Not really. The problem's not enabling the USE flags in the profile in the overlay (something that seems to work already w/ Portage), but the trouble of moving those flags across from the overlay to Portage when the package itself moves across. As the default USE flags are metadata about the package (not the profile), it makes sense to store that data in the ebuild, along with the rest of the package's metadata. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
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
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
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
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] a new TLP to "unify" programming langiages?
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] Re: GLEP 42?
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
Re: [gentoo-dev] Re: GLEP 42?
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] a new TLP to "unify" programming langiages?
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] a new TLP to "unify" programming langiages?
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] Re: GLEP 42?
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] GLEP 42?
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
[gentoo-dev] GLEP 42?
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] Missing: Universal-CD - Gentoo discriminates shell and networkless users
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
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] RFC: multiple inheritance support for profiles, Round 2
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] Resignation
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
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
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] [DOWNTIME devmanual.gentoo.org]
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
[gentoo-dev] o.g.o: planet upgraded
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] Gentoo World Domination. a 10 step guide
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
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
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
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
Re: [gentoo-dev] Re: New project: Gentoo Seeds
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
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, PHP4&5, 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] New project: Gentoo Seeds
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
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
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
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
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: Fw: [gentoo-dev] New project: Gentoo Seeds
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
[gentoo-dev] New project: Gentoo Seeds
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: [gentoo-dev] KDE and Ruby herd call for help
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] Last rites for www-apps/drupal
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] Last rites for www-apps/drupal
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
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
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] Looking for a confcache maintainer
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] Re: Re: packages going into the tree with non-gentoo maintainers
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-core] Re: [gentoo-dev] Global USE flags bite the dust...
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] Re: Trustees Announcement
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-dev] Trustees Announcement
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
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. Feels like one rule for one group (the package maintainers) and another for another group (releng / x86 arch team) to me. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo 2006.1
On 9/3/06, Alec Warner <[EMAIL PROTECTED]> wrote: in the end GCC-4.1 going stable is up to releng and arch teams (heck it doesn't technically have to go stable on all arches). So who "screwed up" in this case? Well, for a package like PHP, the package maintainers take responsibility for ensuring that there are useful and adequate announcements up front. GCC I suspect is surrounded by more confusion. Either the package maintainers or the arch teams could have made an announcement giving fair warning; alas, neither did. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo 2006.1
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
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] Paid support
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
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] Democracy: No silver bullet
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_ man
Re: [gentoo-dev] Democracy: No silver bullet
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_ man
Re: [gentoo-dev] Democracy: No silver bullet
Hi Donnie, On 8/24/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: I started my fourth year as a Gentoo developer in June, and Gentoo's changed a lot since I started back in 2003. We've become a drastically more democratic organization. But the question remains — _Is this a good thing?_ Oh yes. It corrected major inbalances, and added significant credibility to our claim to be a community-based distro. When I think about where Gentoo was when we turned into a democracy years ago, and where Gentoo is now, I don't see much of a difference on the large scale. We lack any global vision for where Gentoo is going, we can't agree on who our audience is, and everyone's just working on pretty much whatever they feel like. We've had a global vision for where Gentoo is going from before I joined - Gentoo is here to create a source-based distribution where each package is as close to what $UPSTREAM intended it to be as possible. We're not trying to take $UPSTREAM packages and innovate with them - we're here to do a first class job of packaging them up. It's a somewhat Daoist approach, and as such is completely alien to most Western thinking (which is based around modelling the world to our thoughts, instead of modelling ourselves to our world). Don't be afraid of it. In business terms, it's out "sweet spot" - it's the place we occupy that our more commercial competitors simply can't make in-roads on. It gives us a unique identity. "Everyone just working on pretty much what they feel like" is Gentoo's other major strength. What we work on is what is important to us. We work on what we need, and what we're motivated to do. Do you know how many companies wish they could say the same about their workforces? The flip side is that it's important we have a diverse and changing developer team. Our strength is also our weakness. If you get too much of an inbalance in the profiles and interests of the developers, you'll end up with a distro that's equally inbalanced. And it will be that which eventually kills off Gentoo. For example, if the work and decision making was dominated mainly by students or research academics - folks it could be said have no experience or understanding of the demands of the corporate workplace - eventually Gentoo would warp and turn into something that was too eclectic to fit in corporates. And the same is equally true the other way around. When I joined, Daniel Robbins was in charge, period. Seemant Kulleen and Jon Portnoy were basically his lieutenants. What Daniel said was what happened, and woe to anyone who angered him. This generally worked out pretty well, but _as Gentoo grew, it didn't scale_. Everything significant still had to go through Daniel for personal approval. Scaling wasn't the only issue. There were too many topics - especially when it came to servers and web-related issues - that were just beyond Daniel's experience and understanding. You also left Kurt out as one of the lieutenants. Shortly after I finished training and became an "official" developer, Gentoo gained its first real structure via Gentoo Linux Enhancement Proposal (GLEP) 4 — "Gentoo top-level management structure proposal". The GLEP process itself was quite new then; GLEP 4 was really only the second proposed GLEP (the first two were details related to the GLEP process) and the first one that was accepted. _Its goal was to improve communication and coordination as well as increase accountability_. GLEP 4 formalized a hierarchy of so-called "top-level" projects — between 5 and 10 major areas into which everything in Gentoo could be divided. Daniel appointed the original project managers, who served under him. That hierarchy was always flawed. Server-related matters never had a seat at the top table, and ended up being represented by the base systems manager. That actually turned out quite well for us, because folks simply left us alone to get on with things. Democratic elections entered Gentoo when we realized that we needed to create a new top-level project for all the desktop work, because it didn't fit into any existing project. Since managers already voted amongst themselves on GLEPs, it seemed like a natural extension for them to vote on a new manager. The call for nominations is archived online. I'd been a developer for around six months at this point, and by then I was the lead X maintainer. Brandon Hale was active in maintaining window managers and other miscellaneous applets and such. Turns out that the vote tied, so we became co-managers. I didn't realize it at the time, but that was the beginning of a very slippery slope. Gentoo used to be a courteous, friendly development community where nobody was afraid to speak his mind for fear of insult and injury. I see a clear correlation between the growth in democracy and the departure of courtesy. Once people are empowered to vote on every decision, rather than just having their discussion taken as input in a decision, they
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
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] per-package USE defaults
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] use.force as a complement to use.mask in profiles
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] Endless frustrations again :(
On 8/7/06, Enrico Weigelt <[EMAIL PROTECTED]> wrote: 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
[gentoo-dev] Gentoo Overlays: Status Report
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] www-apps/wordpress
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
Re: [gentoo-dev] logwatch needs love
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
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
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
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] architectures which support Java
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] Nominations open for the Gentoo Council 2007
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] New category: net-voip
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
