Re: [gentoo-dev] coldplug and hotplug
On Wednesday 03 May 2006 19:27, Greg KH wrote:
> On Wed, May 03, 2006 at 01:22:39PM +0100, Roy Marples wrote:
> > On Wednesday 03 May 2006 12:26, Jakub Moc wrote:
> > > Well, it should not be loaded first of all... Hence why I want to have
> > > an ability to turn off the coldplug thing *completely* on udev level.
> >
> > So maybe I should be clear in conf.d/rc that the RC_{COLD,HOT}PLUG stuff
> > only affects services started and not the actual plugging itself.
>
> Yes. I'll be working on a udev specific option to enable/disable the
> coldplug functionality that it is currently causing (loading all modules
> for all devices at boot time right now.)
Excellent news. Hopefully we can trigger that by the same RC_COLDPLUG="yes|no"
variable so our users only have to configure it once.
--
Roy Marples <[EMAIL PROTECTED]>
Gentoo/Linux Developer (baselayout, networking)
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo: State of the Union
> Having a live tree requires people to be perfect. People are not > perfect and requiring it is ridiculous. I love having commits in my > local tree within the hour, but having a stable and unstable branch > makes a lot of sense. Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? Agreed. That doesn't make sense. Subversion has what is known as pre-commit hooks. Using those it's very easy to: * prevent (most or some) committers from designating ebuilds as stable * allow committers to designate ebuilds as stable under a certain path only * strictly limit a commiters access to a part of the tree Slightly harder, but could be done too: * deny commits if it breaks ebuild dependencies If you want central control of what's happening in the repository, Subversion seems like the way to go. SVN requires at least 2x the tree size for storage on the local machine, This is a feature, not a bug. It allows you to keep operations local, fx. do a diff without being online with the repository. checkouts take something akin to an order of magnitude longer than CVS. In the past Subversion performance was sub-par. I haven't systematically tested performance, but I would expect it to be much better now. Performance is gradually improved, see fx. r18867, r18944 and r19420: http://svn.collab.net/viewvc/svn?view=rev&revision=18867 http://svn.collab.net/viewvc/svn?view=rev&revision=18944 http://svn.collab.net/viewvc/svn?view=rev&revision=19420 GIT might perform better, since Linus specifically emphasized non-O(n^2) performance in the design. But being a decentralized tool, I'm not sure how well it fits the needs here. The former is annoying, but liveable, but the latter is a deal-breaker. I don't think so. You really rarely do a complete checkout. - No changeset/merge tracking Solutions exist, including svnmerge and svk. "Official" solution actively worked on at the moment, check out the svn dev list. A benefit of Subversion that I personally like is that FSFS repositories are extremely easy to rsync. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] staffing needs expirations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lo, On Wednesday 03 May 2006 19:51, Grant Goodyear wrote: > I just had somebody ask me about whether or not we still needed LDAP > help. It's a good question, and I didn't know the answer, which is > rather embarrassing since I'm the one who filed the LDAP staffing > request. Since then I believe that lcars had taken LDAP over nope, lcars is not on the ldap team, though he was doing some dox. > , or is > otherwise assisting robbat2 (or the LDAP team, if we have one now). In > any event, I doubt that I'm the only irresponsible dev who's added an > entry to the staffing-needs page and forgot about it, so perhaps we > need to have items expire unless explicitly renewed? Thoughts? I'd say ldap is fine right now. I think we've got most of the big issues out of the way and I'm happy to update whatever documentation people think needs updating if someone would point me at the current versions. > PS. Does anybody know if we do still need people to help w/ LDAP? I'd say we're fine now. - -- Benjamin Smee (strerror) crypto/forensics/netmail/netmon/ldap -BEGIN PGP SIGNATURE- Version: GnuPG v1.9.20 (GNU/Linux) iD8DBQFEWcdHAEpm7USL54wRAoqvAJ9SHNacD3bT1FRp0jErr9f3pPNaoQCdG57P 14y2Cq0wQf+QX3qunz0DqjQ= =QEWk -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Quoting Molle Bestefich <[EMAIL PROTECTED]>: Does it? How does having a stable and unstable branch differ from having stable and unstable keywords? Agreed. That doesn't make sense. It does if you have a separate stable tree per-arch. With the current tree design, it's too easy to break an arch that you've no intention of affecting. However, if you have a separate tree per-arch, that tree can be tested and approved for release as a single unit. From a SCM point of view, arches are a subset of the full Gentoo tree. They would fit very well into a branching model - and Subversion's support for branching would make it a breeze for us to support without overloading the arch teams. If you want central control of what's happening in the repository, Subversion seems like the way to go. Better to fix the design of the repository, so that it can't be broken in the first place, than to try putting band-aids in place to cover the gaps. I don't think so. You really rarely do a complete checkout. I'd be interested to see some stats from our CVS logs to back that up. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
(sorry if you receive this mail twice, my subscription was not ok) Philip Webb wrote: > 060404 Caleb Tennis wrote: >> historically we were much more bleeding edge with our stable KDE >> versions, but if you've spent any significant time playing with 3.5.0 or >> 3.5.1, you would agree that they are terribly less stable than 3.4.3. > > Not here ! I've used both (successively) every day > & can't recall a single crash or noteworthy (indeed any) problem. > It's true that I don't use Kmail & similar exchange-type apps > & some comments suggest that is where the bulk of instability lies. > > The fact that KDE itself is no longer accepting bugs for 3.4.3 > really does suggest there's something wrong with Gentoo's current > criteria. > As a user I have to add my opinion here. I have been using Gentoo for some years now and it was always fairly up to date. Currently KDE is really behind on the current situation upstream. And then I wonder why. What makes us think we can not trust the KDE devs? Does compiling KDE introduce so many bugs? I mean, let's be serious, all other distributions have a stable 3.5.x now. Don't they experience all those horrible bugs? Seriously, this is really becoming an issue. As I pointed out in a bug I filed for a stable KDE (for which I apologize, I should have looked here first), some people are leaving Gentoo because of this slow upgrade process. The classical answer from devs is "it's ready when it's ready". From a user point of view this is very, very vague. Please give users a more clear explanation, this creates great frustration when looking at other distributions. Because it's stable there. These are my 2 cents as a user. One that loves Gentoo. One that loves KDE. One that's frustrated by the current situation. I am a CS so I know how hard programming can be, don't get me wrong there. I do appreciate what you guys do. But I can't understand why you do it this way right now. Bart -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote: > From a SCM point of view, arches are a subset of the full Gentoo > tree. They would fit very well into a branching model - and > Subversion's support for branching would make it a breeze for us to > support without overloading the arch teams. Are you kidding me? What about people that commit for multiple arches? They're now going to have to do the same commit over $x number of trees? How exactly will that not overload the arch teams? The more I hear about all of these great features of qall of these alternative SCM's, the more I think that somebody just has a hard-on for getting rid of CVS and plans on doing it, no matter the cost to efficiency and other developers. No, I'm pointing to anyone in particular. It just seems that everyone wants to blame CVS for our problems, when our problems are almost entirely cultural. Seriously, if I were forced to commit to multiple trees, or branches, or whatever, I'd simply leave the project since it would be such an enormous waste of time. I'm sure lots of others feel the same. Our version control system is supposed to be a tool to help us get our work done, not a hindrance. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo: State of the Union
On 5/4/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: On Thu, 2006-05-04 at 11:44 +0100, Stuart Herbert wrote: > From a SCM point of view, arches are a subset of the full Gentoo > tree. They would fit very well into a branching model - and > Subversion's support for branching would make it a breeze for us to > support without overloading the arch teams. Are you kidding me? What about people that commit for multiple arches? They're now going to have to do the same commit over $x number of trees? How exactly will that not overload the arch teams? Talking about an SVN perspective ... provided the trees live in a single repository (which would make a lot of sense), it would be very straightforward to provide a tool to copy a particular ebuild & its files from an unstable tree simultaneously to the other trees. The difficulties with such a tool would be taking over the right files/ contents (something which is solveable), and what to do about signing (where a distribtued system like Git probably makes much more sense anyway). Given such a tool, you could promote a version of a package to any number of per-arch trees at the same time. The more I hear about all of these great features of qall of these alternative SCM's, the more I think that somebody just has a hard-on for getting rid of CVS and plans on doing it, no matter the cost to efficiency and other developers. What we're talking about here is a step in the development cycle commonly called 'integration', where something's taken from the development bucket, put into the 'release' bucket, and tested to ensure that it plays nice with everything else already in the 'release' bucket. It should be listed in RUP, CMM, or whatever development methodology you use locally in your day job. Adopting this approach would be far more painful with CVS than with (say) subversion. Branch management in subversion is infinitely easier than with CVS. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thu, 2006-05-04 at 13:48 +0200, Bart Braem wrote: > Does compiling KDE introduce so many bugs? I mean, let's be serious, all > other distributions have a stable 3.5.x now. Don't they experience all > those horrible bugs? Compiling KDE doesn't introduce bugs. Compiling KDE with any combination of USE/CFLAGS/CXXFLAGS/GCC/Glibc/etc does. Remember that we're a from-source distribution. Guys like Debian or Red Hat just have to compile it *once* then they make a package of it, with exactly *one* set of options (USE), C(XX)FLAGS, gcc, glibc, etc. making their job infinitely easier. > Seriously, this is really becoming an issue. As I pointed out in a bug I > filed for a stable KDE (for which I apologize, I should have looked here > first), some people are leaving Gentoo because of this slow upgrade > process. Honestly, if they're leaving over something so minor, they're free to go. We're not a commercial distribution. We don't sell Gentoo. We're not concerned with market share. > The classical answer from devs is "it's ready when it's ready". From a user > point of view this is very, very vague. Please give users a more clear > explanation, this creates great frustration when looking at other > distributions. Because it's stable there. As I stated above, they have a *much* lower barrier of entry for making something stable than we do. We've tried making this explanation over and over again. The problem is that every single version of $package, people don't look at the last explanation and ask again... and again... and again... and again. It gets very old to answer the same question over and over again. The simple answer is really "when we don't have major showstopper bugs anymore". Again, remember that we have to support countless combinations from our users. Other distributions need to support only one. They can use forms of tricks to get it to compile that *one* time, including adding patches and other things that might not be suitable for a from-source distribution. > These are my 2 cents as a user. One that loves Gentoo. One that loves KDE. > One that's frustrated by the current situation. I am a CS so I know how > hard programming can be, don't get me wrong there. I do appreciate what you > guys do. But I can't understand why you do it this way right now. Quite simply, we don't want to give you crap. If we followed others blindly, as so many users suggest, then we would have stabilized KDE 3.5 ages ago, and every single one of you KDE users would be complaining about how our QA sucks because KDE doesn't compile or breaks badly in so many places. We would hear about how Gentoo sucks where they can't even test such a major application as KDE properly. We would have users leaving in droves. Now, we can't have both fast stabilization *and* actual stability, so we err on the side of caution. We don't like hearing complaints any more than anyone else, but we'd rather hear a few "why isn't KDE stable yet" questions than *everyone* saying we suck because KDE is broken. I hope that sums it up for you. By the way, this isn't just for KDE. This is how we do *every* package. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
All,If I might weigh in at this late stage:How did we end up here in the first place? Isn't the point of ~arch that we can put stuff here that might WELL be unstable? Sure, we'll get lots of "I set my ACCEPT_KEYWORDS to ~arch and now my system is broken," messages, but if people are going to try ~arch, or Gentoo in general, despite warnings that it's "not for newbies" (and I have personal experience of this), we can't really stop them without turning the community into a fascist state, can we? Gentoo (like all projects) has a finite amount of developers, and if we spend to much time on ~arch then surely arch will suffer Just my 0.2 cents (sic)Jeff.On 04/05/06, Bart Braem <[EMAIL PROTECTED]> wrote: (sorry if you receive this mail twice, my subscription was not ok)Philip Webb wrote: > 060404 Caleb Tennis wrote:>> historically we were much more bleeding edge with our stable KDE>> versions, but if you've spent any significant time playing with 3.5.0 or>> 3.5.1, you would agree that they are terribly less stable than 3.4.3.>> Not here ! I've used both (successively) every day> & can't recall a single crash or noteworthy (indeed any) problem.> It's true that I don't use Kmail & similar exchange-type apps > & some comments suggest that is where the bulk of instability lies.>> The fact that KDE itself is no longer accepting bugs for 3.4.3> really does suggest there's something wrong with Gentoo's current > criteria.>As a user I have to add my opinion here. I have been using Gentoo for someyears now and it was always fairly up to date. Currently KDE is reallybehind on the current situation upstream. And then I wonder why. What makes us think we can not trust the KDE devs?Does compiling KDE introduce so many bugs? I mean, let's be serious, allother distributions have a stable 3.5.x now. Don't they experience all those horrible bugs?Seriously, this is really becoming an issue. As I pointed out in a bug Ifiled for a stable KDE (for which I apologize, I should have looked herefirst), some people are leaving Gentoo because of this slow upgrade process.The classical answer from devs is "it's ready when it's ready". From a userpoint of view this is very, very vague. Please give users a more clearexplanation, this creates great frustration when looking at other distributions. Because it's stable there.These are my 2 cents as a user. One that loves Gentoo. One that loves KDE.One that's frustrated by the current situation. I am a CS so I know howhard programming can be, don't get me wrong there. I do appreciate what you guys do. But I can't understand why you do it this way right now.Bart--gentoo-dev@gentoo.org mailing list -- --Argument against Linux number 6,033:"...So this is like most Linux viruses. You have to download the virus yourself, become root, install it and then run it. Seems like a lot of work just to experience what you can get on Windows with a lot less trouble."
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
I think that sums up some good answers to my questions, too.Jeff.On 04/05/06, Chris Gianelloni <[EMAIL PROTECTED] > wrote:On Thu, 2006-05-04 at 13:48 +0200, Bart Braem wrote:> Does compiling KDE introduce so many bugs? I mean, let's be serious, all > other distributions have a stable 3.5.x now. Don't they experience all> those horrible bugs?Compiling KDE doesn't introduce bugs. Compiling KDE with anycombination of USE/CFLAGS/CXXFLAGS/GCC/Glibc/etc does. Remember that we're a from-source distribution. Guys like Debian or Red Hat just haveto compile it *once* then they make a package of it, with exactly *one*set of options (USE), C(XX)FLAGS, gcc, glibc, etc. making their job infinitely easier.> Seriously, this is really becoming an issue. As I pointed out in a bug I> filed for a stable KDE (for which I apologize, I should have looked here> first), some people are leaving Gentoo because of this slow upgrade > process.Honestly, if they're leaving over something so minor, they're free togo. We're not a commercial distribution. We don't sell Gentoo. We'renot concerned with market share.> The classical answer from devs is "it's ready when it's ready". From a user > point of view this is very, very vague. Please give users a more clear> explanation, this creates great frustration when looking at other> distributions. Because it's stable there.As I stated above, they have a *much* lower barrier of entry for making something stable than we do. We've tried making this explanation overand over again. The problem is that every single version of $package,people don't look at the last explanation and ask again... and again... and again... and again. It gets very old to answer the same questionover and over again. The simple answer is really "when we don't havemajor showstopper bugs anymore". Again, remember that we have to support countless combinations from our users. Other distributions needto support only one. They can use forms of tricks to get it to compilethat *one* time, including adding patches and other things that might not be suitable for a from-source distribution.> These are my 2 cents as a user. One that loves Gentoo. One that loves KDE.> One that's frustrated by the current situation. I am a CS so I know how > hard programming can be, don't get me wrong there. I do appreciate what you> guys do. But I can't understand why you do it this way right now.Quite simply, we don't want to give you crap.If we followed others blindly, as so many users suggest, then we would have stabilized KDE 3.5 ages ago, and every single one of you KDE userswould be complaining about how our QA sucks because KDE doesn't compileor breaks badly in so many places. We would hear about how Gentoo sucks where they can't even test such a major application as KDE properly. Wewould have users leaving in droves. Now, we can't have both faststabilization *and* actual stability, so we err on the side of caution. We don't like hearing complaints any more than anyone else, but we'drather hear a few "why isn't KDE stable yet" questions than *everyone*saying we suck because KDE is broken.I hope that sums it up for you. By the way, this isn't just for KDE. This is how we do *every* package.--Chris GianelloniRelease Engineering - Strategic Leadx86 Architecture TeamGames - DeveloperGentoo Linux -BEGIN PGP SIGNATURE-Version: GnuPG v1.4.3 (GNU/Linux)iD8DBQBEWfErkT4lNIS36YERAtKVAKDE9aVxS6dq34fleM1WPi2vOC9TGgCfb+ctGhTF595T05xwiL60103fkAk==YYvC-END PGP SIGNATURE- -- --Argument against Linux number 6,033:"...So this is like most Linux viruses. You have to download the virus yourself, become root, install it and then run it. Seems like a lot of work just to experience what you can get on Windows with a lot less trouble."
Re: [gentoo-dev] Gentoo: State of the Union
On Thu, 04 May 2006 11:44:18 +0100 Stuart Herbert <[EMAIL PROTECTED]> wrote: > However, if you have a separate tree per-arch, that tree can be tested > and approved for release as a single unit. How big would this tree be? Would it be every package? How will this make the arch teams' life easier and/or the users' experience better? I still fail to see how this will work any differently than what we have today. Today we have ~arch, someone tests the package for stability on an arch system, and marks it stable. The tester is effectively integrating the package into a stable system. Maybe you could explain how the procedure might go with branches for getting a package from just put into the tree to ~arch to arch and what happens with version bumps. ~tcort pgp4rW3LFoaWO.pgp Description: PGP signature
[gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
Bart Braem posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 04 May 2006 13:48:03 +0200: > As a user I have to add my opinion here. I have been using Gentoo for some > years now and it was always fairly up to date. Currently KDE is really > behind on the current situation upstream. > And then I wonder why. What makes us think we can not trust the KDE devs? > Does compiling KDE introduce so many bugs? I mean, let's be serious, all > other distributions have a stable 3.5.x now. Don't they experience all > those horrible bugs? > Seriously, this is really becoming an issue. As I pointed out in a bug I > filed for a stable KDE (for which I apologize, I should have looked here > first), some people are leaving Gentoo because of this slow upgrade > process. I'm just another user, not a dev. Please keep that in mind as you read the following. That KDE was two releases behind, even on cooker for AMD64 (which unfortunately followed stable for i586, not cooker for i586), was the reason I left Mandrake, so I know exactly where you are coming from. That said, you've hit a sore spot -- illogical people asking for something, choosing it when given the choice, and then when they get it, complaining about what they chose in the first place, when the other choice remains right at hand for them to change their mind and switch to at any point! Exactly that -- illogical! /Why/ are people leaving over this?? The ebuilds are there in ~arch and have been for some time. If people want cutting edge, Gentoo continues to provide pretty damn close, often having (still masked because upstream isn't available at the time) ebuilds in the tree even before public release, as I know for a fact has been the case with KDE, as I've seen the ebuilds and the masks there, before the releases, complete with the reason for masking given as upstream not released yet. Stable is there if they want it, too. They can choose to run stable. There's nothing wrong with that, just as there's nothing wrong with making an informed decision to run unstable. If they want to leave for some other distribution, for whatever reason, that's fine and good. There are legitimate reasons to do so, places (like binary packages and periodic releases with few updates between them) where Gentoo isn't as strong, because it chooses other areas to emphasize. Deciding to stick with (IMO consistently outdated, but hey, if people want stable...) stable, then being unhappy with devs for not choosing to stable-keyword something with known issues, isn't such a legitimate reason, when they have the choice to upgrade at any time they choose, regardless of stable status, as the ebuilds are there for them to do so and the general Gentoo documentation is clear in its instructions as to how to do so, if desired. It's up to an admin whether they want to risk running unstable on nothing, individual packages, whole categories (kde-base) of packages, or their entire system. Why then are those same admins complaining when devs take their responsibility to do the best they can to ensure something's stable before marking it such, seriously. I can envision the /same/ admins complaining that the devs didn't do their job if the issues remained and the packages were stabilized even with known issues. As for trusting or not the KDE devs, that's not the issue. Either there are still known problems on Gentoo, or there aren't. It doesn't matter if those were upstream problems or Gentoo problems, in this case, only whether there are problems on Gentoo or not. As it happens, many of the problems with 3.5.0 were upstreamm and have been resolved with 3.5.1 or 3.5.2. That took time. 3.5.0 won't ever make stable as it has issues since fixed with further upstream releases. 3.5.1 likely won't either. 3.5.2 has fixed many/most of them, but it hasn't been much more than 30 days since its release, and Gentoo normally requires a package to be bug-free for 30 days in ~arch before going stable, so it's only now qualified. Meanwhile, those who want to risk running the unstable packages and are willing to live with or provide patches for the bugs (bugs which after all are there in bugzilla, if anyone wants to know what the holdup is)... can do just that since the ebuilds are there from the day of release and often even /before/ release! That they don't choose to do so is their choice and their responsibility, not that of Gentoo. Note that due to Gentoo slotting, it's not even necessary to give up the stable KDE to merge the still unstable version! With slots, they can exist quite well in parallel. Now it'd be rather different if the ebuilds weren't there. As I said, I left Mandrake over such things. However, they /are/ there. The choice to merge them or not is the user/admin's. If they chose not to do so, why are they then blaming Gentoo for their own choice? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program,
Re: [gentoo-dev] Gentoo: State of the Union
On Thursday 04 May 2006 14:17, Stuart Herbert wrote: > Talking about an SVN perspective ... provided the trees live in a > single repository (which would make a lot of sense), it would be very > straightforward to provide a tool to copy a particular ebuild & its > files from an unstable tree simultaneously to the other trees. The > difficulties with such a tool would be taking over the right files/ > contents (something which is solveable), and what to do about signing > (where a distribtued system like Git probably makes much more sense > anyway). The files content problem should be solved anyway. That way one could even make selfcontained ebuild packages including source. A way of distributing that would be more appropriate for external ebuilds. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpImatmLNLKQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thursday 04 May 2006 14:21, Jeff Rollin wrote: > All, > > If I might weigh in at this late stage: > > How did we end up here in the first place? Isn't the point of ~arch > that we can put stuff here that might WELL be unstable? Sure, we'll get > lots of "I set my ACCEPT_KEYWORDS to ~arch and now my system is > broken," messages, but if people are going to try ~arch, or Gentoo in > general, despite warnings that it's "not for newbies" (and I have > personal experience of this), we can't really stop them without turning > the community into a fascist state, can we? Gentoo (like all projects) > has a finite amount of developers, and if we spend to much time on > ~arch then surely arch will suffer Actually the testing keywords are not for unstable packages. If something is unstable it must be masked. If we however want to test our packaging we put it in ~arch. If something is in ~arch that means that it works for the packager, but that your mileage may vary. ~arch may sometimes have unexpected problems, especially involving migration from old versions to new versions. Actually most time is spent on ~arch, as there is where development happens. As a package is seen to be stable, then it gets promoted to arch. This is just a change of the keyword. The developer then goes on to newer versions of the package. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3RB0vTgeMO.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
I'm just an user here, but I'd like to ask a simple question: For Gnome 2.14 there is a tracker bug on b.g.o [1]. I think this is really usefull for users like me who want to know the status of this release at any time (and I hope this is useful for devs too :)). Why such a tracker doesn't exist for KDE 3.5 ? That way, users may easily see why KDE still isn't stable. Please don't take this as a reproach. Perhaps you devs have no need for a tracker, and I can perfectly understand that. Regards, Guillaume [1] http://bugs.gentoo.org/show_bug.cgi?id=119872 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
Paul, That cleared it up for me, thanks Jeff.On 04/05/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: Actually the testing keywords are not for unstable packages. If somethingis unstable it must be masked. If we however want to test our packagingwe put it in ~arch. If something is in ~arch that means that it works for the packager, but that your mileage may vary. ~arch may sometimes haveunexpected problems, especially involving migration from old versions tonew versions. Actually most time is spent on ~arch, as there is where development happens. As a package is seen to be stable, then it getspromoted to arch. This is just a change of the keyword. The developerthen goes on to newer versions of the package.Paul-- Paul de VriezeGentoo DeveloperMail: [EMAIL PROTECTED]Homepage: http://www.devrieze.net -- --Argument against Linux number 6,033:"...So this is like most Linux viruses. You have to download the virus yourself, become root, install it and then run it. Seems like a lot of work just to experience what you can get on Windows with a lot less trouble."
Re: [gentoo-dev] staffing needs expirations?
On Thu, May 04, 2006 at 10:20:04AM +0100, Benjamin Smee (strerror) wrote: > I'd say ldap is fine right now. I think we've got most of the big issues > out of the way and I'm happy to update whatever documentation people > think needs updating if someone would point me at the current versions. > > > PS. Does anybody know if we do still need people to help w/ LDAP? > > I'd say we're fine now. Staffing needs updated. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] coldplug and hotplug
On Thu, May 04, 2006 at 09:54:53AM +0100, Roy Marples wrote:
> On Wednesday 03 May 2006 19:27, Greg KH wrote:
> > On Wed, May 03, 2006 at 01:22:39PM +0100, Roy Marples wrote:
> > > On Wednesday 03 May 2006 12:26, Jakub Moc wrote:
> > > > Well, it should not be loaded first of all... Hence why I want to have
> > > > an ability to turn off the coldplug thing *completely* on udev level.
> > >
> > > So maybe I should be clear in conf.d/rc that the RC_{COLD,HOT}PLUG stuff
> > > only affects services started and not the actual plugging itself.
> >
> > Yes. I'll be working on a udev specific option to enable/disable the
> > coldplug functionality that it is currently causing (loading all modules
> > for all devices at boot time right now.)
>
> Excellent news. Hopefully we can trigger that by the same
> RC_COLDPLUG="yes|no"
> variable so our users only have to configure it once.
Yes, I'll try to use that variable.
thanks,
greg k-h
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Packages that need maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following packages require a new maintainer, some might just be absorbed into their herds w/o a direct maintainer leaving them to the teams maintaining those herds, others might face extinction w/o a direct maintainer. ./app-admin/gtkdiskfree ./sci-astronomy/celestia ./net-firewall/ipkungfu ./media-gfx/povray ./net-misc/tightvnc ./x11-wm/icewm ./dev-libs/boost ./dev-perl/Event-ExecFlow (dvd::rip dep) ./dev-perl/AnyEvent(dvd::rip dep) ./dev-util/ketchup ./app-benchmarks/cpuburn ./app-benchmarks/bonnie++ ./media-video/kino ./media-video/dvdrip ./app-cdr/dvdshrink ./games-emulation/mupen64-riceplugin ./games-emulation/mupen64-glide64 ./games-emulation/mupen64-glN64 ./games-emulation/mupen64-blight-tr64gl ./games-emulation/mupen64-blight-input ./games-emulation/mupen64-jttl_sound ./games-emulation/mupen64 ./games-emulation/mupen64-blight-uhleaudio ./media-plugins/xmms-xf86audio This list might not be perfect, but a simple grepping the tree shows those listing [EMAIL PROTECTED] as direct maintainer, with the exception of icewm (which has [EMAIL PROTECTED] and [EMAIL PROTECTED] listed) also as the only one. Some items have currently open bugs which i will try to eliminate or at least minimize as much as possible. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEWomz/aM9DdBw91cRAuv+AJ9trfMlCXUNv7Iu+H6UtNwqswOAuwCgvVkJ 7Sy4fUBcv2O2Ags4XYY9W7w= =Oc/z -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thursday 04 May 2006 05:21, Jeff Rollin wrote: > All, > > If I might weigh in at this late stage: > > How did we end up here in the first place? Isn't the point of ~arch that we > can put stuff here that might WELL be unstable? Sure, we'll get lots of "I > set my ACCEPT_KEYWORDS to ~arch and now my system is broken," messages, but > if people are going to try ~arch, or Gentoo in general, despite warnings > that it's "not for newbies" (and I have personal experience of this), we > can't really stop them without turning the community into a fascist state, > can we? Gentoo (like all projects) has a finite amount of developers, and > if we spend to much time on ~arch then surely arch will suffer > > Just my 0.2 cents (sic) > > Jeff. I think the problem is that Gentoo is falling into the same sandtrap the Debian project has been mired in forever. "arch" and "~arch" are polarizing into "stable, but horribly out of date", and "maybe it will work". This leads to people trying to maintain a frankenstinian /etc/portage/package.keywords file, constantly adding to it and never knowing when things can be removed from it. I would suggest opening a middle ground tag, where things can be moved to from "~arch" when they work for reasonable configuration values, but still have open bugs for some people. That way, people who prefer stability over the latest features can run "arch", and everyone who bitches about packages being out of date can run the middle tag, and "~arch" can be kept for testing. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages that need maintainers
I have a question that I havn't been able to find that is somewhat related to the following email. I know and understand Linux very well. I also know how ebuilds work. So how do I go about maintaining packages and getting them into portage. For example I would like to maintain a munin, munin-plugin, and tightvnc ebuild. Where can I find this information. I don't know where to start. Thanks, Michael On Thu, May 04, 2006 at 06:09:39PM -0500, Daniel Goller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The following packages require a new maintainer, some might just be > absorbed into their herds w/o a direct maintainer leaving them to the > teams maintaining those herds, others might face extinction w/o a direct > maintainer. > > ./app-admin/gtkdiskfree > ./sci-astronomy/celestia > ./net-firewall/ipkungfu > ./media-gfx/povray > ./net-misc/tightvnc > ./x11-wm/icewm > ./dev-libs/boost > ./dev-perl/Event-ExecFlow (dvd::rip dep) > ./dev-perl/AnyEvent(dvd::rip dep) > ./dev-util/ketchup > ./app-benchmarks/cpuburn > ./app-benchmarks/bonnie++ > ./media-video/kino > ./media-video/dvdrip > ./app-cdr/dvdshrink > ./games-emulation/mupen64-riceplugin > ./games-emulation/mupen64-glide64 > ./games-emulation/mupen64-glN64 > ./games-emulation/mupen64-blight-tr64gl > ./games-emulation/mupen64-blight-input > ./games-emulation/mupen64-jttl_sound > ./games-emulation/mupen64 > ./games-emulation/mupen64-blight-uhleaudio > ./media-plugins/xmms-xf86audio > > This list might not be perfect, but a simple grepping the tree shows > those listing [EMAIL PROTECTED] as direct maintainer, with the exception > of icewm (which has [EMAIL PROTECTED] and [EMAIL PROTECTED] listed) also > as the only one. > > Some items have currently open bugs which i will try to eliminate or at > least minimize as much as possible. > > Daniel > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEWomz/aM9DdBw91cRAuv+AJ9trfMlCXUNv7Iu+H6UtNwqswOAuwCgvVkJ > 7Sy4fUBcv2O2Ags4XYY9W7w= > =Oc/z > -END PGP SIGNATURE- > -- > gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages that need maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 spradlim wrote: > I have a question that I havn't been able to find that is somewhat > related to the following email. I know and understand Linux very well. > I also know how ebuilds work. So how do I go about maintaining packages > and getting them into portage. For example I would like to maintain a > munin, munin-plugin, and tightvnc ebuild. Where can I find this > information. I don't know where to start. > > Thanks, > Michael As a user you must find a sponser in order to take full maintership. You might be able to find a dev to handle your commits and reviews until such a time you find a sponser. Jory -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEWrppGDfjNg8unQIRAmP6AJ0YFfW8TM2GGNDjXr9iyAf3a3OlxgCff7vz QOTjgi8ZXTCTgxszCRjUqHs= =hApA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
I think the problem is that Gentoo is falling into the same sandtrap the Debian project has been mired in forever. "arch" and "~arch" are polarizinginto "stable, but horribly out of date", and "maybe it will work".This leads to people trying to maintain a frankenstinian /etc/portage/package.keywords file, constantly adding to itand never knowing when things can be removed from it.I would suggest opening a middle ground tag, where things can be moved to from "~arch" when they work for reasonable configuration values, but still haveopen bugs for some people.That way, people who prefer stability over the latest features can run "arch",and everyone who bitches about packages being out of date can run the middle tag, and "~arch" can be kept for testing.--gentoo-dev@gentoo.org mailing listOr maybe we could move to a fixed release cycle. Debian uses 18 (?) months, but maybe a 3- or 6-month release cycle would suit us better Jeff.-- --Argument against Linux number 6,033:"...So this is like most Linux viruses. You have to download the virus yourself, become root, install it and then run it. Seems like a lot of work just to experience what you can get on Windows with a lot less trouble."
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On Thu, 04 May 2006 16:29:56 -0700 Michael Kirkland <[EMAIL PROTECTED]> wrote: > This leads to people trying to maintain a > frankenstinian /etc/portage/package.keywords file, constantly adding > to it and never knowing when things can be removed from it. If you use specific versions in the package.keywords file (i.e. do "=category/package-version-revision ~arch" instead of "category/package ~arch", this doesn't happen. You just need to watch for downgrades in case a ~arch version is removed without ever going stable, and every so often go through it looking for package versions that have been superseded. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Packages that need maintainers
On Thu, 4 May 2006 21:20:48 -0500 spradlim <[EMAIL PROTECTED]> wrote: > I have a question that I havn't been able to find that is somewhat > related to the following email. I know and understand Linux very > well. I also know how ebuilds work. So how do I go about maintaining > packages and getting them into portage. For example I would like to > maintain a munin, munin-plugin, and tightvnc ebuild. Where can I > find this information. I don't know where to start. Gentoo Developer Handbook, "Becoming a developer" http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2 In the first instance, do the work on bugzilla. Look for open bugs for existing packages, and post fixes/patches there. For packages not currently in portage, raise a new bug. -- Kevin F. Quinn signature.asc Description: PGP signature
