Re: [gentoo-dev] default desktop profile
Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +startup-notification Actually, rereading that list, I wouldn't mind adding this one. Gnome and a couple of core Gnome apps hard-depend on it, as I am must sure must be the case in KDE. Samuli also told me that xcfe4 really needed it anyway. I guess this is one where most people would easily agree on adding it to the desktop profile. Cheers, Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Bugday tomorrow!
Hi, It's bugday tomorrow! This announcement is going out a 'lil early, seeing as I will not be around tomorrow, or for the rest of the week, and most of the team seem to be afk, so I can't poke them too easily, unfortunately. :( (hopefully, they'll be around on the day :P) Anyways, as per usual, the bugday channel is #gentoo-bugs, and there's a list of potentially suitable bugs at http://bugday.gentoo.org If anyone has any suitable bugs which they would like adding, feel free to poke me on IRC, and I'll get them added to the page ASAP. Hope you all have a good bugday! welp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
Donnie Berkholz wrote: Mike Frysinger wrote: my point though wasnt to knock ati (although it was fun), the point was that i do not believe any closed source driver in our tree should ever be grounds for preventing stabilization of a kernel ebuild so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts If we're gonna go with this policy here, I'm also going to adopt it for X so we don't get stuck in limbo as happened fairly recently. If we're going to do this, we should just keep the unfree drivers in testing. Marijn -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] 2.6.22 stable plans
On Friday 03 August 2007, Daniel Drake wrote: All that aside, my advice for developers considering maintaining kernel code in portage outside of the kernel still remains as don't do it. Your package grows bugs overnight. It's a continual challenge trying to keep up, and it's a headache for me trying to poke you into action. Or, if you really must do this, never mark your package stable (that way I can ignore it). i pity the foo who doesnt listen to dsd ! -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 2.6.22 stable plans
Donnie Berkholz wrote: so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts If we're gonna go with this policy here, I'm also going to adopt it for X so we don't get stuck in limbo as happened fairly recently. This is how it has been for a while, and not only closed source drivers. We have many open source kernel drivers/filesystems in the tree which regularly break with new kernel releases. When these packages break in this way, it is a bug in such packages, not in the kernel. [For those wondering why the kernel keeps changing, see Documentation/stable-api-nonsense.txt : it is by design, maintaining kernel code outside of the kernel is discouraged for this reason, solution is get it in the kernel] Maintainers of these packages got unhappy that they didn't really have warning when new kernels were going stable, so I started announcing that (and usually giving more notice on gentoo-dev than this time around, sorry about that). That helped, but trying to encourage maintainers to fix their stuff every few weeks gets old and some maintainers become less responsive. Kernels go stable anyway and so users complain. I now take it a step further, and create package regression tracker bugs for each kernel release. bug #184683 is the 2.6.22 one, a little smaller than usual. For each bug that gets added to the tracker, I comment on any patches that have been posted (e.g. that's the correct fix) or if there aren't already patches, I explain how to fix the code based on the compile error. This is work I'd rather not do (I really don't care about your package), but seems to work relatively well. There are times when after I 'approve' a patch, another developer asks me to commit it. I think that's a little unreasonable. I'm not prepared to go *that* far at the moment, especially as I usually can't test the package in question. The model seems to work relatively well. One associated challenge is making sure maintainers fix their packages in the stable tree (not only unstable) before stabilization takes place, but that has certainly been improving lately, e.g. Stefan did a great job fixing up many external wireless drivers this time around, and I didn't have to reopen any of the bugs :) All that aside, my advice for developers considering maintaining kernel code in portage outside of the kernel still remains as don't do it. Your package grows bugs overnight. It's a continual challenge trying to keep up, and it's a headache for me trying to poke you into action. Or, if you really must do this, never mark your package stable (that way I can ignore it). Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
On Fri, August 3, 2007 2:07 am, Robin H. Johnson wrote: Heya, The upstream rules_du_jour folk have had issues over the last few months with DDoS and other attacks. Additionally, the nature of their original update mechanism causes a lot of traffic. Everybody that is using rules_du_jour is strongly encouraged to move to using the sa-update mechanism that is included with recent versions of SpamAssassin. Here is a guide to using SARE rulesets with sa-update: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt mail-filter/spamassassin-ruledujour will be p.masked on August 4th, and removed one month thereafter. Do you have references for this security issues? Maybe a bug should be opened to decide if we release a maskglsa for this one. -- Pierre-Yves Rofes Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: archfs - filesystem for rdiff-backup archives
Er it's been pointed out to me that this is a Google SoC project, so apologies for the beginners info. (I'd forgotten your earlier post.) Oh, no problem, I am a beginner after all :-) And I always forget to add project's homepage to the message :-/ BTW I don't recommend autotools (there's a reason they're called autohell ;) Yeah, now I know that myself ;-) especially if you're not writing from scratch. (That's why you get all those redundant configure checks..) A simple system.mk which gets included in the makefile is a lot easier for everyone. ion3 (which is now in mabi's overlay iirc) does this, and it's a doddle to configure. (I think it was one or two sed calls.) Well, you are third person, that is telling me that (though you all differ with alternative tools - from CMake, to pkg-config, to what you are suggesting now). If only I knew it, when I was getting down to it. Unfortunately, my lack of experience doesn't make this project any easier, it's my first 3 months, that I'm doing anything like this. However, for the time being I will stick to what I could create with those autotools - I get shivers, when I imagine, that I have to learn something like this again ;-) -- Filip Gruszczyński
Re: [gentoo-dev] 2.6.22 stable plans
On Friday 03 August 2007, Marijn Schouten (hkBst) wrote: Donnie Berkholz wrote: Mike Frysinger wrote: my point though wasnt to knock ati (although it was fun), the point was that i do not believe any closed source driver in our tree should ever be grounds for preventing stabilization of a kernel ebuild so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts If we're gonna go with this policy here, I'm also going to adopt it for X so we don't get stuck in limbo as happened fairly recently. If we're going to do this, we should just keep the unfree drivers in testing. i dont think that logically follows the previous argument -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 2.6.22 stable plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: so next time dsd (or whoever the ninja kernel maintainer happens to be at the time) says hey i plan on stabilizing Linux x.y.z and someone goes wait, you cant until we get closed source driver package foo working, the reply is of course blow it out your arse^H^H^H^Htalk to the package maintainer, this will not hold up stabilization efforts -mike They can always use the previous kernel version that worked too, it's not like OMG BBQ i'm not on the latest bleeding edge version!!one. - -- Gustavo Zacarias Gentoo/SPARC monkey -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGs2nuV3G/IBCn/JARAsaeAJ9i+hH8cv16jRSlMLruC7X8jpG0lACbBxGi N8lgqzbyJUxVokrhWeANtrg= =MTXP -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Thu, 2007-08-02 at 18:53 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. I am very strongly in support of ppds, as I consider it critical for us to make printers easier to set up. This one should be on, actually. It was enabled for 2006.1 but somehow got turned back off for 2007.0's release. I'll make sure it is enabled on the 2007.1 release on the desktop profiles. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 09:09 +0200, Rémi Cardona wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +startup-notification Actually, rereading that list, I wouldn't mind adding this one. Gnome and a couple of core Gnome apps hard-depend on it, as I am must sure must be the case in KDE. Samuli also told me that xcfe4 really needed it anyway. I guess this is one where most people would easily agree on adding it to the desktop profile. I've added ppds and startup-notification to the default USE for the newly-created x86 development profiles for 2007.1, which I'd ask people to base any change requests on, rather than the 2007.0 profiles. Basically, if it isn't in the 2007.1 profile and you want it, ask for it on gentoo-releng. If we think we need more discussion on a particular USE flag, we'll bring it back here. One thing to remember, I do *not* consider our desktop profiles to be opt-in but rather to be a good out-of-box experience for the user. If you want to think of the desktop profiles as bloated, feel free to use the versioned profile (like 2007.0) instead, as it will be much closer to the opt-in idea and only has USE flags which are common between desktops and servers and are much less likely to get additional flags added to them, since I want these to be as minimal as possible while still providing important functionality. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] default desktop profile
Chris Gianelloni kirjoitti: One thing to remember, I do *not* consider our desktop profiles to be opt-in but rather to be a good out-of-box experience for the user. If you want to think of the desktop profiles as bloated, feel free to use the versioned profile (like 2007.0) instead, as it will be much closer to the opt-in idea and only has USE flags which are common between desktops and servers and are much less likely to get additional flags added to them, since I want these to be as minimal as possible while still providing important functionality. That sounds good to me. It's easy enough to turn off use flags too. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
Pierre-Yves Rofes [EMAIL PROTECTED] wrote: On Fri, August 3, 2007 2:07 am, Robin H. Johnson wrote: The upstream rules_du_jour folk have had issues over the last few months with DDoS and other attacks. Additionally, the nature of their original update mechanism causes a lot of traffic. Everybody that is using rules_du_jour is strongly encouraged to move to using the sa-update mechanism that is included with recent versions of SpamAssassin. Here is a guide to using SARE rulesets with sa-update: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt mail-filter/spamassassin-ruledujour will be p.masked on August 4th, and removed one month thereafter. Do you have references for this security issues? Maybe a bug should be opened to decide if we release a maskglsa for this one. It's not a vulnerability in Rules du Jour. It's a bunch of spammers attacking the Rules du Jour servers and ISP. SARE has also been down a whole bunch over the last couple of months due to the same attack. -- Such things have often happened and still happen, and how can these be signs of the end of the world? -- Julian, Emperor of Rome 361-363 A.D. pgph1wQZnM4M8.pgp Description: PGP signature
Re: [gentoo-dev] default desktop profile
Chris Gianelloni wrote: On Thu, 2007-08-02 at 18:53 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. I am very strongly in support of ppds, as I consider it critical for us to make printers easier to set up. This one should be on, actually. It was enabled for 2006.1 but somehow got turned back off for 2007.0's release. We disabled it to try to get the size of the x86/amd64 LiveCDs down. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 14:56 -0500, Andrew Gaffney wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 18:53 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: On Thu, 2007-08-02 at 11:27 +0200, Martin Schwier wrote: +ppds (everyone has a printer, and this is needed to configure it without further investigations. cups is already in) +startup-notification Well, we don't add local USE flags to the default profiles unless there is a *very* good reason. I really don't have a problem with any of these being added, but I'd rather hear the opinions of my peers. I am very strongly in support of ppds, as I consider it critical for us to make printers easier to set up. This one should be on, actually. It was enabled for 2006.1 but somehow got turned back off for 2007.0's release. We disabled it to try to get the size of the x86/amd64 LiveCDs down. Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Some ideas on how to reduce territoriality
More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. - HOMEPAGE changes - LICENSE changes - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. - *DEPEND changes due to changes in your packages - If a package that you maintain moves, splits, or otherwise changes in a manner that requires dependency changes on any other packages in the tree, you should make those changes yourself. You're free to ask for assistance, of course, but you have the power to make the changes yourself without asking permission. After all, you're the one breaking the package, so you should be the one to fix it. - Manifest/digest fixes - metadata.xml changes There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to cp the ebuild - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. So, what do you guys think? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
On Fri, 2007-08-03 at 12:48 -0700, Drake Wyrm wrote: It's not a vulnerability in Rules du Jour. It's a bunch of spammers attacking the Rules du Jour servers and ISP. SARE has also been down a whole bunch over the last couple of months due to the same attack. Which will probably never happen to gentoo, because of the rather bg mirroring system. So, would it be possible to host daily (or hourly) snapshots of these rule files (or something like that) and tell the world that we do so and that they can download these in the nightly cronjob? That migth solve a problem and i don't see it becoming a problem for the gentoo mirror infrastructure. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Chris Gianelloni wrote: [snip] There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to cp the ebuild This is more on a per package basis. it's not fair to force the maintainer to support a new version before he feels it's ready. For example, I'd love to bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't want it bumped. It wouldn't be fair to him for me to bump it unless I took the burden of support. - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. arch teams are the definitive authority on keywording for their arch. That said, if there is a disagreement between maintainer and arch team, the support burden falls on whoever did the keyword. Teamwork should solve this problem every time. I think the territoriality issue is one of support burden more than anything else. --taco -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Chris Gianelloni kirjoitti: More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. I don't find anything wrong with doing the changes after you find that the maintainer is not responsive. If the maintainer is responsive, he will a) do the changes b) give you the permission to do it c) give reasoning on why the proposed changes should not be done. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Philipp Riegger kirjoitti: On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp No. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 14:28 -0700, Chris Gianelloni wrote: Of course, the LiveDVD will have everything on it, as it does now. Pretty please for ext4 for the ricers that just *have* to try it and need to recover their systems. It's a good ask as it is *in* the kernel even if marked experimental. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Petteri Räty wrote: Philipp Riegger kirjoitti: On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp No. We really need to get a -commits mailing list going again. If the subject and/or sender are set appropriately, it should be easy to filter for items of interest. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 2007-08-04 at 01:34 +0300, Petteri Räty wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? No. Might that be an interesting feature for helping devs keep up to date with their maintained packages? Or are there reasons against this? This could of course be muteable... Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:19 -0700, Mike Doty wrote: Chris Gianelloni wrote: [snip] There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to cp the ebuild This is more on a per package basis. it's not fair to force the maintainer to support a new version before he feels it's ready. For example, I'd love to bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't want it bumped. It wouldn't be fair to him for me to bump it unless I took the burden of support. This is why I said it should be discussed. Also, it might very likely be better to opt-out rather than opt-in on this. I really don't know, myself. - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. arch teams are the definitive authority on keywording for their arch. That said, if there is a disagreement between maintainer and arch team, the support burden falls on whoever did the keyword. Teamwork should solve this problem every time. Well, I meant that this should be doable without the maintainer's consent. Meaning, I ask you to stabilize 1.0-r1 and a few weeks later, you can decide to stabilize -r2 without me having to file a bug. Basically, the maintainer decides the minimal revision he wants to go stable (so bugs are fixed, etc) but the revisions after that are up to the arch teams, unless the maintainer sees a need for everyone to update (major bug, security). My main goal here is to reduce the we have to wait on the maintainer to ask issue within a given version of a package. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
On Sat, Aug 04, 2007 at 01:01:11AM +0300, Philipp Riegger wrote: On Fri, 2007-08-03 at 12:48 -0700, Drake Wyrm wrote: It's not a vulnerability in Rules du Jour. It's a bunch of spammers attacking the Rules du Jour servers and ISP. SARE has also been down a whole bunch over the last couple of months due to the same attack. Which will probably never happen to gentoo, because of the rather bg mirroring system. So, would it be possible to host daily (or hourly) snapshots of these rule files (or something like that) and tell the world that we do so and that they can download these in the nightly cronjob? That migth solve a problem and i don't see it becoming a problem for the gentoo mirror infrastructure. This doesn't solve the problem at all. We still need to get the rules from upstream, and the DDoS is against upstream. Really, just move to using sa-update instead. It has the IDENTICAL rulesets, but the update-needed checks are preformed via DNS instead of an HTTP operation. -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpi2tVv9T5Bm.pgp Description: PGP signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. Arch bugs that obviously don't affect other arches. An example of this is the pine/uw-imap/c-client stuff which does this make lnx Great! Make linux. Sucks for FreeBSD so I've been changing it to if use elibc_FreeBSD ; then make bsf else make lnx fi Obviously that's very simplified, but you get the idea. In this case I don't expect the ebuild maintainer to use Gentoo/FreeBSD. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 2007-08-04 at 01:23 +0300, Petteri Räty wrote: Chris Gianelloni kirjoitti: More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. I don't find anything wrong with doing the changes after you find that the maintainer is not responsive. If the maintainer is responsive, he will a) do the changes b) give you the permission to do it c) give reasoning on why the proposed changes should not be done. Why should someone have to go through all of that just to make these minor fixes? Is it really necessary for someone to be required to try to track down and contact the maintainer to tell them that they put ebiuld instead of ebuild into an ebuild? This is my entire point. Why are we forcing a process that only fosters inefficiency? It is much simpler to say if you see one of these, fix it than to force every single action to go through the maintainer. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Donnie Berkowitz wrote: Petteri Räty wrote: Philipp Riegger kirjoitti: On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp No. We really need to get a -commits mailing list going again. If the subject and/or sender are set appropriately, it should be easy to filter for items of interest. Thanks, Donnie some of us infra types were entertaining a RS feed for this... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Mike Doty wrote: Donnie Berkowitz wrote: Petteri Räty wrote: Philipp Riegger kirjoitti: On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp No. We really need to get a -commits mailing list going again. If the subject and/or sender are set appropriately, it should be easy to filter for items of interest. Thanks, Donnie some of us infra types were entertaining a RS feed for this... stupid spell checker, that's RSS feed and sorry for mangling your name. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 23:39 +0100, Roy Marples wrote: On Fri, 2007-08-03 at 14:28 -0700, Chris Gianelloni wrote: Of course, the LiveDVD will have everything on it, as it does now. Pretty please for ext4 for the ricers that just *have* to try it and need to recover their systems. It's a good ask as it is *in* the kernel even if marked experimental. I don't even know what ext4 needs, but if someone files a bug, I'll add it to the specs. Otherwise, I'll forget. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, Aug 03, 2007 at 04:06:25PM -0700, Mike Doty wrote: We really need to get a -commits mailing list going again. If the subject and/or sender are set appropriately, it should be easy to filter for items of interest. some of us infra types were entertaining a RS feed for this... stupid spell checker, that's RSS feed and sorry for mangling your name. Alternatively, we try to create custom headers for the relevant portion of the mails. X-VCS-Repository: gentoo-x86 X-VCS-Directories: profiles/ licenses/ X-VCS-Files: profiles/foo licenses/bar etc? (Suggest more headers that can be gained PURELY from the commit data). -- Robin Hugh Johnson Gentoo Linux Developer Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgphcV8wpptbF.pgp Description: PGP signature
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 16:18 -0700, Chris Gianelloni wrote: On Fri, 2007-08-03 at 23:39 +0100, Roy Marples wrote: Pretty please for ext4 for the ricers that just *have* to try it and need to recover their systems. It's a good ask as it is *in* the kernel even if marked experimental. I don't even know what ext4 needs, but if someone files a bug, I'll add it to the specs. Otherwise, I'll forget. Just the kernel modules and sys-fs/e2fsprogs-1.4 or better :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. - HOMEPAGE changes - LICENSE changes - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. I am not sure about this last one ... what if for example this patch is only for supporting a special option of the package for that architecture, but the maintainer of the package found out that such a patch is unnecessary and/or will cause other kind of problems in the package, therefore preferring avoiding such a patch ... or he just wouldn't like to apply the patch for X or Y; or even further, he just wouldn't like to have such a package available for that architecture just yet for Z or W. - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. - *DEPEND changes due to changes in your packages - If a package that you maintain moves, splits, or otherwise changes in a manner that requires dependency changes on any other packages in the tree, you should make those changes yourself. You're free to ask for assistance, of course, but you have the power to make the changes yourself without asking permission. After all, you're the one breaking the package, so you should be the one to fix it. - Manifest/digest fixes - metadata.xml changes There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to cp the ebuild - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. I think these two cases should still be handled by the herd or maintainer of the package. The stabilization idea sounds good and it could free maintainers from filing similar bugs over and over ; but wouldn't this be more and harder work for arch teams?. For example, they should carefully track the history of all the packages to know when and if they should stabilize it yet. So, what do you guys think? The other list of things look fine and safe to be changed by any maintainer. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9 tKDsHyNAWsliFCx0MMzcIpA= =RGhM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] default desktop profile
On Fri, 2007-08-03 at 14:28 -0700, Chris Gianelloni wrote: Thanks. I knew there had to be some reason for it, but couldn't remember what it was off the top of my head. Luckily, this won't be much of an issue with the next release, since we're switching to Xfce rather than GNOME to bring the size down even further and to try to produce a more useful (as in more tools) LiveCD. Of course, the LiveDVD will have everything on it, as it does now. Sad to know that our livecd will be xfce based. I think the current live cd gnome based provides a much better environment than xfce and that is good for the users who will preform and instalation. Of course you don't need to build all gnome for the livecd and i bet there will be enough space for another tools (a graphical package manager!?). -- [EMAIL PROTECTED] mailing list
