Re: [gentoo-dev] Packages that need maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Mylchreest wrote: On Thu, May 04, 2006 at 06:09:39PM -0500, Daniel Goller [EMAIL PROTECTED] wrote: Assuming there are no objections I can take over the following. ./app-benchmarks/cpuburn ./app-benchmarks/bonnie++ Regards, John thanks for your interest -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEXaP2/aM9DdBw91cRAqsoAJ9C3u6tMW/MxOaHGnoVcSrO0ZUjgACgwqoB ZVUarlGEapDuQEB/hPyrRj8= =W2a8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages that need maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Buisse wrote: On Fri, May 5, 2006 at 10:02:10 +0200, 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. If no one objects, I can take ./dev-util/ketchup get it while it's hot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEXaQQ/aM9DdBw91cRArDsAJ0dUO9/MfZCyZg7fQfEMcLik+giUACdHDdG TNPQPo35K2Ana39+BExl5Ck= =+9QD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages that need maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denis Dupeyron wrote: On 5/5/06, Daniel Goller [EMAIL PROTECTED] 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. [...] ./media-video/kino [...] Does the media-video herd^H^H^H^Hgroup automatically inherit this one ? If not, and if nobody volunteers, I'm willing to salvage it. I have somewhere an ebuild for kino-0.8.1 that includes an --as-needed fix. Denis. although it would be absorbed by them, if you already did the work and are willing to work on it, noone should stop you ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEXqpH/aM9DdBw91cRAvD5AKDRGIKE7MVLz2zdm2cvgfylaeMpDQCdGzbw oaPXDtx1wGfuG02Y0DenSto= =Wyzs -END PGP SIGNATURE- -- 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] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What is interesting is that Source Mage Linux has already voted on a proposal similar to mine[2]. I truly think that making some changes in the gentoo way would benefit us and make gentoo a truly better distribution. Ryan Gentoo Developer [1] http://article.gmane.org/gmane.linux.gentoo.devel/37599 [2] http://lists.ibiblio.org/pipermail/sm-discuss/2006-April/014069.html I would really like to hear more on [2], get something like it going, then we could all vote on the scm of choice this thread has succumb to. Although switching away from cvs is one of the many topics of this mail (and if you want a foundation for some of the others), it is not the only one. I would like to hear more on changing how we vote (unless you all really like how voting is done now, be it problem resolution or technical innovation), more on developer growth (we should be an open inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. I don't just mean to hear the hells nos also the hells yeahs, especially those that are just reading and then thinking it. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEU20L/aM9DdBw91cRAkPxAKCNB10kVHzVF+okuTc7Pc1Ysuza5QCcCdZ8 cYBVs1j9tBce2wTlCF7x7Tg= =WWf3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Apr 29, 2006 at 08:41:31AM -0500, Daniel Goller wrote: inviting community) and why you think stricter test make for better developers, why you think harder tests would cut down more on the quick in and out people. Empirical evidence agrees. Our current quiz practices have done a good job keeping out a lot of the incompetence that used to slip through before we took that approach. Stricter tests make for more knowledgable developers and folks with a lack of commitment to Gentoo are usually not willing to tackle the learning curve. As for whether or not we're inviting or not, anybody can contribute. They don't need to be @gentoo.org to do so. What we really need is to focus more on those outside contributions. so that is where this is all coming from, who said that we should hand out @gentoo.org ? i never said that, they don't need it, and everyone gets to feel all special about the @gentoo.org the way they are used to, a committing contributor does not require a @gentoo.org and unless you give them a general aptitude and attitude test, you do not know a thing about the person who answered a few technical questions (more) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEU3pZ/aM9DdBw91cRArKPAKCCr/9TYUc+VTqldUueqXN5RRCUWgCfbSH8 5QfB8r0xd2qAr018yFICd9o= =aMhC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: On Fri, 28 Apr 2006 21:42:57 +0200 Bryan Ăstergaard [EMAIL PROTECTED] wrote: So.. What can we do to improve things? I think that there should be some sort of organized way of connecting potential mentors and potential recruits. There is a very enthusiastic user who has been contributing great work to my overlay, but I cannot find anyone to mentor him (I've e-mailed [EMAIL PROTECTED] as well as [EMAIL PROTECTED] without much success). Maybe we should create a list of developers who are willing to mentor new devs? It would make finding a mentor much easier. ~tcort wait till you have your required months at gentoo, then you mentor him, if you truly like his work, tell him you have to wait before you can mentor him, iirc 6 months from joining? he could wait till then, and maybe appreciate your working relationship even more, 6 months is a nice time to see if his performance is consitent too no dev has to refer anyone to someone else unless they are not long enough with the project, and then it is only a matter of time :) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUpCw/aM9DdBw91cRAkzvAJsFPdeCZzjH5niV9V0TOO2zQN5togCfd/gf dckrYu+XPRFbIJ0oZLGqhgM= =v6W5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Phillips wrote: Donnie Berkholz [EMAIL PROTECTED] said: Tim Yamin wrote: Speaking of which, has anybody done any tests with svk? (http://svk.elixus.org) And: http://svk.elixus.org/?WhySVK -- it would be interesting to compare checkout performance on it as well. I've been planning to do a more detailed comparison of all the popular SCM's out there for probably 6 months, but I just don't have the time right now. If someone wants to pick this up, please let us know. Recommended reading: http://www.keltia.net/EuroBSDCon/slides.pdf and www.keltia.net/EuroBSDCon/paper.pdf SCMs to test: cogito - Not practical * the lots of little files doesn't scale well with the size of the portage tree * In addition, git only allows checkins from the project parent. A deal breaker in my opinion cvs - Branching sucks - Merging is terrible - File deletes are bad - Atomic Commits svn + Atomic Commits + Merging/tagging/brancing is a simple copy operation http://svnbook.red-bean.com/en/1.1/ch04.html + lots of benefits http://svnbook.red-bean.com/nightly/en/svn.intro.features.html there is more I'm sure people can come up with - 2x Drive space Thanks Ryan, what we see is: the only - really is none at all localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/ 768M/cvs/gentoo-x86/ 768Mtotal localhost64 ffmpeg-0.4.9-p20060302-shared # du -csh /cvs/gentoo-x86/ - --apparent-size 224M/cvs/gentoo-x86/ 224Mtotal i waste more on the wrong block size with /cvs/gentoo-x86/ being on my 4K block size partition than the file size would add we could trick around to get all that smaller but let's be real for a moment, let's double the 768M, 1536M is nothing on today's machines, drive space is cheap, and if your disk is small, then you have no business running cvs or svn or anything with lot's of small files on 4k block size so looking at the list of SCMs, svn has only plus, and a theoretical - side that in 2006 is none --apparent-size print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in (`sparse') files, internal fragmentation, indirect blocks, and the like so put svn on a partition with small blocksizes/inode sizes and let's get on with the program Daniel darcs - haskell dependency - doesn't work on some architectures - IMHO, deal breaker svk - not a contender, it is subversion. if someone wanted to use svk with the subversion tree they could; it is transparent to any other. -ryan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUpTY/aM9DdBw91cRAvdFAKDUh9dNv025td6lm64YgKzZ6PwBbwCgvxL0 BIkORaLea2xiBzmbXpm6GSU= =lD3P -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: Is there a reason for this besides the definitions not falling into place as they should? I'm not seeing a benefit from this to be honest. People refer to teams as herds a lot of the time. It has become a statement over time that people understand. I'm not sure why we want to try and change that to something else, even if that was what it was supposed to mean to begin with. It's a niggling thing and nothing major as such. But ideas flow from concepts. And the idea that developers are in herds is not a solid concept from which to begin. While the Ciaran episode has come to an end, the circumstances that led to that episode have not changed: mutual respect for fellow developers. That is the idea. The concept should lay that down: a developer is not a mindless follower, but a human being and a talented developer worthy of respect. This is a very small issue in the scheme of things, and a small hole to fill. I'd rather fill it in now :) Because it's supposed to be fun, too. Thanks, Seemant At the very least it carries an interesting message, and is so positive we could all think about it and maybe we could go cool. I like the idea. (But i guess you figured that out already ;) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUCVP/aM9DdBw91cRAhwZAJ9iZfCATRYUk6ApxuLaY+aNRIdfJQCeIXXI ZDX5NFtScuc07p8wG52IPYs= =EtMC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Daniel Goller posted [EMAIL PROTECTED], excerpted below, on Sun, 23 Apr 2006 23:50:17 -0500: * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. you shouldn't disagree about this policy, or you might as well not have this document, write disagree on the solution maybe? Don't take this wrong but you did mention you weren't a native English speaker, and I think this the interpretation demonstrates that. (That isn't to say it couldn't be made clearer, just that your interpretation isn't likely to occur to a native English speaker, thus the discussion.) no, there should not be disagreement on the QA policy, seriously, only disagreement on the solution is logical and possible the exception is not covered by policy, the possibility for exceptions is however integrated into the policy, so the only disagreements could be in how the exception is implemented, maybe 3 QA devs find solution A best while 5 find B best, but all devs should agree that an exception is granted because the current tools do not allow adherence to usual QA standards To me (as a native English speaker), it's strange to consider that a reference to /this/ policy. Rather, the reference is to QA policy and decision making in general -- how a disagreement on QA policy between members of the QA team is to be handled. to me a policy is the writing as a whole with all the bullet points, not each individual point being a policy, and even if you would explain yes each point is a policy, then the points should not be argued within QA, see above for what would leave room for argument That this is the case would be particularly obvious in context, coming after (as it does) the previous point, dealing with exceptions due to imperfect tools and mentioning that there /are/ such exceptions. The point in question above doesn't /only/ deal with that, thus it's its own bullet point, but the thought is clearly to provide some guidance in dynamic situations, where for whatever reason there's a difference of opinion within QA on how to proceed (as an imperfect tool exception could legitimately provoke, again, the handy example, not the only case, thus it's not a sub-point but its own bullet point). The other alternative would be unanimous agreement or the decision of the maintainer in question rules, altho there is of course the middle possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered to overrule the maintainer. As I said, your interpretation, that it applied to /this/ policy, wouldn't be likely to occur to a native English speaker, and does in fact seem a bit odd. However, that's not to say the point isn't valid, as it's certainly best that the document be clear to all, including non-native English speakers to whom the point as now written obviously isn't entirely clear. i'm afraid i have to repeat that the policy is the sum of all points, the writing, so all QA devs should agree on this one policy, and only have discussions on solution to individual points, and not the actual points of the policy, if there was room for discussion of the points of the policy, then the policy is not ready for consumption by the developer community Actually, the point about a 2/3 (or whatever) super-majority, vs. simple majority of the QA team needed to overrule a maintainer, is a good one to debate as well. Perhaps developers would be less worried about abuse if the majority required was stronger, thus improving the safety margin. Assuming that's the case, the policy as a whole could probably have more teeth in the case of a super-majority required, than would be possible if it's only a simple majority. If some sort of a super-majority was required, it should be easier to accept certain decisions, when they seriously impact a developer or Gentoo in general. I know if I had a disagreement and out of a five member team, two sided with me and three against, making it a majority-of-one, I'd be less comfortable with the outcome than if it had required a 2/3 majority, and thus 4 members of the team voting against me. Another way to approach it would be to state that for purposes of packages (s)he maintains, a developer gets one vote on the QA as well. Thus, in ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1 would be deadlock with the developer siding on the keep things as they are side. The idea in either case is to minimize the possibility of something occurring without enough of a majority opinion to make the decision look arbitrary or subject to immediate reversal upon the whims of a single QA team member, without making it impotent in certain cases due to a requirement for a unanimous decision. Reason in the middle ground? well, i do find your majority rules interesting, something that should be discussed
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: Daniel Goller [EMAIL PROTECTED] said: Mark Loeser wrote: Here is the newest revision of my proposal. Not much has changed, but I added and changed some small things. Constructive feedback is appreciated. I'd like to get this voted on by the council at the next meeting. * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. describe what makes it necessary and what actions will be taken or if the paragraphs below are meant to do that, you can save that line in that paragraph What makes it necessary is if something is broken or goes against policy, and the actions are listed below. I was pretty sure this went without saying. is what you are saying that the line is superfluous since it is covered by the paragraph below ? * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. define emergency, define as soon as possible (some bugs might be quite tricky to track and might be put on back burner and what little time is available used on things not taking up equal times), how do you know ia dev is not cooperating or if i he/she is just prioritizing emergency - something that is broken and affects a great number of users you could elaborate on broken some more, since you seem to have skipped over my addendum to my email and the terms 'broken' and 'breakage' are used as if they define themselves as soon as possible - exactly what it says, as soon as possible Basically, use common sense here please :) common sense ain't that common, to think any two people consider the same thing as common sense is an assumption, and those are not that good * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. you shouldn't disagree about this policy, or you might as well not have this document, write disagree on the solution maybe? It was not referring to *this* policy, but the exact policy that is dealing with the problem at hand. In this context, it was meant to be read that what some of us to believe is a problem is actually a problem here, and that the solution is reasonable. I will write the whole thing out to improve clarity. ok, so we refer to points of this policy as policies. do not leave wiggle room, either it is a problem or not. discuss the solutions? yes of course. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. Then you must be talking about coding style here? remove the point and add it above to coding style, as an example why you will deal with the coding style maybe? no other violation should be left to such vagueness No, I'm talking about problems that were not noticed before and we just realized the implications of what we are doing. this can then be struck or combined to the point where you say the list is not finite, i really wish you would say it is comprehensive yet not finite, like list everything as a reference, so people can look at it if they go oh i think i can do it this way! then they read the list and find it in the minor/major/critical section of the comprehensive yet not finite document. comprehensive does not mean finite, so i would like to understand why you refuse to make it a comprehensive list and call it that * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. define persistently, how do you presistently cause breakage? maybe this is one of those non native english speaker moments, but doesn't that mean like every commit is botched? Not every commit, but a recognizable pattern can be seen. let's say someone consistently brings us good on the toolchain, but in the process we get a few hiccups, is that such a pattern that would get him to meet devrel? (considering it is him who does all the work and the fixing as soon as possible anyway) are (picking a number) 10 wrong digests the same as 10 instances where glibc/gcc wouldn't build, or did build but caused a broken system? * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: Here is the newest revision of my proposal. Not much has changed, but I added and changed some small things. Constructive feedback is appreciated. I'd like to get this voted on by the council at the next meeting. * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. describe what makes it necessary and what actions will be taken or if the paragraphs below are meant to do that, you can save that line in that paragraph * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible. define emergency, define as soon as possible (some bugs might be quite tricky to track and might be put on back burner and what little time is available used on things not taking up equal times), how do you know ia dev is not cooperating or if i he/she is just prioritizing * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. Coding style issues fall under this category, and while they are not severe, they can make automated checks of the tree more difficult. thanks for the offer, sounds good * There will be cases when our tools are incapable of handling a certain situation and policy must be broken in order to get something working completely. This will hopefully not occur very often but each time it does occur, the QA team and the maintainer will come to some agreement on an interim solution and it is expected that a bug will be opened with the appropriate team to work towards a correct solution. sounds reasonable * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. you shouldn't disagree about this policy, or you might as well not have this document, write disagree on the solution maybe? * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. The default could be that the ebuild not be touched unless it is a issue that breaks the tree or is security related where time is of the essence. word it in that direction? * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. Then you must be talking about coding style here? remove the point and add it above to coding style, as an example why you will deal with the coding style maybe? no other violation should be left to such vagueness * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. define persistently, how do you presistently cause breakage? maybe this is one of those non native english speaker moments, but doesn't that mean like every commit is botched? * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. as said in the other two posts, maybe write it is a comprehensive list, just that it is not finite? that might clear this point up. * In order to join the QA team, you must be a developer for at least 4 months and must ask the current lead for approval. that shouldn't be too hard * The QA team will work with Recruiters to keep related documentation and quizzes up to date, so that up and coming developers will have access to all of the necessary information to avoid past problems. sounds good * QA will take an active role in cleaning up unmaintained and broken packages from the tree. It is also encouraged of members of the QA team to assist in mentoring new developers that wish to take over unmaintained packages/herds. i am not sure how to read this one, it could mean broken packages that are unmaintained, but how it is written it could also mean unmaintained || broken, not only unmaintained broken, i really wish you would at least consider not killing off unmaintained and not broken
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. define persistently, how do you presistently cause breakage? maybe this is one of those non native english speaker moments, but doesn't that mean like every commit is botched? defining 'breakage' here might also be a good idea, sorry for not adding this to the previous post, i really should have asked for that one Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETFpo/aM9DdBw91cRAsBvAKDABphEPy1zWVGaHqqZ8JhBYvOTEgCeNa5B mwUCZpBBis2TnK3gyejjn9Q= =/ig2 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Proposal v3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * QA will take an active role in cleaning up unmaintained and broken packages from the tree. I hope this is meant to read more like: QA will take an active role in cleaning up unmaintained packages from the tree if they are severly broken or have open security issues. What i mean here is that unmaintained != broken (if it works, leave it be), and partially broken != unworthy to be in the tree, for example if nothing provides equal functions, why get rid of something that works for the most part, so unmaintained with some bugs just means maintainer needed, not buhbye! severly broken here would mean does not even compile, or gui comes up but most functions just create a segfault. In short, i would like to see the above sentence changed to something a little less radical. (example provided) Thanks Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESvGh/aM9DdBw91cRArWqAJ9JhfuUr1JvJr4xgOZn0aAlMeil6wCeN22x rwtxKd77YT2mNTAZbIEyPps= =akQa -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ebuild Developer: Christian Hartmann (ian!)
On Mon, 2006-04-17 at 01:15 +0200, Danny van Dyk wrote: Hi, It is my pleasure to announce publicly that ian! has passed all necessary quizzes to touch our holy gra^H^H^H portage tree. He'll be helping mcummings in his perpetuate combat with perl and its dependencies. May the source be with him. Congratulations Christian! :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project congrats to mcummings signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enroll users for testing packages
On Wed, 2006-04-12 at 09:48 -0400, Stephen P. Becker wrote: didn't he ask for people who know a particular application very well? If you actually read the GLEP, you will note that there is a provision to expand the idea to include herd testers. someone might like to help with testing one or a few packages, w/o the full load of being a herd tester, since he might know nothing about the other packages in that herd, while being very proficient with one package out of 5 different herds, so to help he would be part of those 5 herds, and if you then reply well he could be marked as those packages in those herds well then why not just keep a list of users per package we appreciate their help that way just as much w/o flooding them with can you test xyz sorry, i only know klm in the herd oh, sorry, didn't check what package you help with, just the herd scenarios less procedures, less hassle and hopefully in return even more involvement i think there is a big difference between agreeing to test one particular package since they know it very well and want to make sure noone breaks it vs. being a full AT with all the things they get asked to test The herd tester concept would cover this as far as I can see. so no, i don't think the blanket glep covers a per package list of user who are interested to help see it as an extension to the glep instead, another level of accepting and appreciating user contributions w/o burdening them with more than they might be interested in doing -Steve signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enroll users for testing packages
On Tue, 2006-04-11 at 09:36 -0400, Stephen P. Becker wrote: Eldad Zack wrote: Hello, Sometimes it becomes a problem whenever a new release or a tricky bugfix comes up for a certain package. To improve QA we can let our userbase help, especially people who use certain packages quite heavily - they can provide good or even superior QA than devs. I think it would be a nice idea to keep a userlist for anyone who'd like to volunteer testing packages they regularly use. We can consider a web interface for enrolling users to specific packages, and maybe even get a bug.g.o account for the list, this way a bug can be opened for the testers to comment on whenever a change that requires testing or maybe just aiding arch teams to stablize packages. Maybe this was already pitched but it has just occured to me. Comments? Isn't this why we already have the arch tester position as described by GLEP 41 (http://www.gentoo.org/proj/en/glep/glep-0041.html)? Furthermore, are you saying that users would enroll themselves via this hypothetical web interface, or that an arch team would do so for users who have proven themselves to be worthy? If the former, this would be a serious step back in terms of QA (think about sorting out all the crap reports from ricer overlay users with OMGFAST CFLAGS from the decent ones). If the latter, I think the arch tester position already covers this sort of thing. -Steve didn't he ask for people who know a particular application very well? i think there is a big difference between agreeing to test one particular package since they know it very well and want to make sure noone breaks it vs. being a full AT with all the things they get asked to test signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2 use flag must die
On Mon, 2006-04-03 at 01:17 +0200, Carsten Lohrke wrote: On Monday 03 April 2006 00:29, foser wrote: Already security related issues have been dropped by upstream for the simple reason that it hasn't been maintained since the day gtk went 2.0 . Why didn't you file (Gentoo) security bugs? Perfect reason to drop Gtk1 support, if no one steps up to fix them. you are really trying hard to get gtk(1) Carsten signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sun, 2006-04-02 at 21:20 +0200, Carsten Lohrke wrote: On Sunday 02 April 2006 04:48, Daniel Goller wrote: exactly, what's the point of removing it so fast? give people a chance to miss it, it does not matter if it's removed or masked only as far as going woah, what? and if masked it is a matter of unmasking rather than recommitting We haven't had a single issue with the usual seven day period as far as I can remember, so please come up with a valid argument against it, instead assuming turning my argument would be one. in short, if it's slowing down the process, why do you need it to be quick in the first place? Getting the junk out of tree and mind as fast as possible is a value in itself. you should apply a finer granularity and not call them all junk, even a unmaintained package that only has 50% of its features working might be the only thing someone has, where does this hurt anyone?, or maybe it is unmaintained but has no single (uncovered flaw), where does this hurt anyone? or or or, point is, say you would like certain vulnerable packages removed quicker, without making the waiting the usual 30 days sound insane. with that kind of grace period you give people the chance to say oh hey, i have this patch in my patch overlay, let me give it to you just wait a little, it hurts noone usually, if it's a security issue, say it is and use a shorter time, noone is gonna have a problem, unless carlo suddenly goes under the cloak of security and yanks everything he wants under those pretences... :) my $1 Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
On Sat, 2006-04-01 at 19:18 +0200, Carsten Lohrke wrote: On Thursday 30 March 2006 01:55, Mark Loeser wrote: Not directed specifically at you, but it seems a lot of people are masking stuff and removing it very quickly, and I'd really like to see everyone wait the 30 days to remove something from the tree. That way anyone using this package in some way will get the message from p.mask, and know what they should upgrade to. With that being said, is there any reason that the package should be removed so quickly? Yes, there is. It's slowing down the process, getting into the flow. Waiting 30 days is a lot of time. A regular user does not necessarily follow the dev-gentoo mailing list and it doesn't matter for him, if the package is masked or removed. He can always get it from (web-)cvs. The time to wait is to give others the time to step up to maintain the package. And if some dev missed the announcement, nothing is stopping him to reintroduce the it. Honestly, I don't see the point. exactly, what's the point of removing it so fast? give people a chance to miss it, it does not matter if it's removed or masked only as far as going woah, what? and if masked it is a matter of unmasking rather than recommitting in short, if it's slowing down the process, why do you need it to be quick in the first place? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] nss-config nspr-config
On Fri, 2006-03-24 at 08:40 -0500, Chris Gianelloni wrote:
On Thu, 2006-03-23 at 20:04 -0600, Jory A. Pratt wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As many are aware nss-3.11 and nspr-4.6.1 are in the tree. Many
packages still set the {nss|nspr}-libs and includes. With nss-3.11 and
nspr-4.6.1 the proper configs and pkgtools files are included. Any
package in the tree that has them hardcoded in the ebuild should be able
to drop. There are a few packages that will have issues, i.e.
gaim-encrytpion which I have patched and have had applied upstream
already. So lets clean up the tree as we continue to update our ebuilds.
Any chance you could make a list of file a bug? I happen to know that
nothing that I maintain wouldn't be affected, but can everyone say that?
everything you maintain will be affected? how unfortunate ;)
Thanks,
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Making the developer community more open
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. wrong The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. we are not just talking about new ebuilds/bumps having someone do all the work and having to only verify the end results of the users work is a big help, instead of having to look into the problem, checking if a fix exists elsewhere, or digging through the source yourself, you verify the fix solves the problem and does only that. and everyone wins On 3/22/06, Thomas Cort [EMAIL PROTECTED] wrote: A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Making the developer community more open
On Thu, 2006-03-23 at 18:34 -0500, Dan Meltzer wrote: On 3/23/06, Daniel Goller [EMAIL PROTECTED] wrote: On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. wrong The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. we are not just talking about new ebuilds/bumps having someone do all the work and having to only verify the end results of the users work is a big help, instead of having to look into the problem, checking if a fix exists elsewhere, or digging through the source yourself, you verify the fix solves the problem and does only that. and everyone wins So it sounds like you are asking them to do everything developers do, why not just make them be developers? because they do not want more than take care of their one package and do not want more than someone taking care of their work, maybe? or maybe because they don't like a lot of devs due to bad experiences, and would not want to be any part of the group, but still enjoy working on packages there are people who i would love to see as devs, but are not particularly interested on having to deal with some of the devs, having a proxy allows them to help gentoo w/o being exposed to the people they otherwise would have to deal with signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Making the developer community more open
On Tue, 2006-03-21 at 13:09 +0100, Simon Stelling wrote: Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Users can (and do) attach patches to any bug in bugzilla. When applying such patches, the committing dev hopefully checks the patch and makes sure it's clean, so he already is the kind of proxy you are asking for. -- maybe he more means having a working relationship with people rather than sending them to attach patches to bugzilla. make it more personal than clinical circumventing the requirement for an AT position, a casual i give you patches as i come across problems on my box, can you take care of them relationship for people who can and will contribute occasionally, w/o the time to take on a dev position w/o commit access (aka Arch Tester) like the people you hang out with on irc even, the ones that help other users, or the kind you see active on forums, take their occational patch/ebuild like less red tape, more acceptance of the occasional contribution how about that as proxy? Daniel Kind Regards, Simon Stelling Gentoo/AMD64 Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Sunday 26 February 2006 16:58, Ciaran McCreesh wrote: On Sun, 26 Feb 2006 17:22:17 -0500 Mark Loeser [EMAIL PROTECTED] wrote: | Yes, Gentoo is supposed to be fun, but we also have a responsibility | to our users to ensure we are providing them with the best possible | distro we can. What, you mean the tree isn't someone's personal playground? I do not know what he did refer to, however the following quote from ChrisWhite's blog does come to mind: [snip] Well, I was told by ciaranm to stop treating the tree like your toy or something to that effect. Now, I'm going to respond to this with Yes, it is my toy. Before you all go phsyco and what not, let's take a look at what Gentoo really is. [/snip] Following this is a rather sad rationalization as to why it is a toy. http://www.securesystem.info/tiki-view_blog_post.php?blogId=3postId=111 | * The QA team may also offer to fix obvious typos and similar minor | issues, and silence from the package maintainers can be taken as | agreement in such situations. Should probably clarify that one. It's in there because there are some situations where we find obvious typos (e.g. 'souce' instead of 'source' in DEPEND) and file a bug to alert the maintainer. If the maintainer fixes it within a few days, there's no problem, but if not there's no point in letting the bug sit there -- someone from QA should be able to fix it themselves. Equally, we don't want to just fix stuff without telling people that they made a mistake, because then they're more likely to do it again. | * The QA team will maintain a list of current QA Standards. The | list is not meant by any means to be a comprehensive document, but | rather a dynamic document that will be updated as new problems are | discovered. Hrm, do we want to include the thing about the QA standards providing rationale and explanations rather than hard rules here? pgpp2BzNR8wEK.pgp Description: PGP signature
Re: [gentoo-dev] Re: Last rites for media-video/dvdrip
On Sunday 11 December 2005 09:32 pm, R Hill wrote: Diego 'Flameeyes' Petten wrote: Oh well, media-video/dvdrip has many issues reported in bugzilla (some have patches, most haven't), and depends on a version of transcode with many issues, too (and force us to leave transcode 1 masked). Nobody in video herd is looking at it right now, last bump was done by morfic, and more would be needed. working on dvdrip is one of the things on my todo list, as soon as i finish rebuilding my system. please reconsider dropping packages just because they don't currently have a dedicated maintainer. if upstream is alive and people are using it, leave it alone. especially if it's a popular package with just a handful of bugs. also, it's a lot more likely you'll find a new maintainer for a package when it's already in the tree for people to discover and use. isn't this what the maintainer-needed alias is for? --de. sorry there hasn't happened much yet wrt dvd::rip the system i worked on with dvdrip had a disk die, art of a md0, system is gone, so i too reinstall, some real life worries and usual lack of enough time for everything i started out keeping icewm maintained, and eventually took on other things short version is better i guess: we always appreciate user contributions, if i am slow, it does not represent any lack of interest between you and chandler dvd::rip s hould stay, one concern is that transcode 1 i had on the laptop, on the system dvd::rip worked on has 0.6.14, when i tried dvd::rip on here, it seems to have finished the plugin scan the hangs, scanning plugins was what i did on the XP, then the hdd died :) i too am frightened to see good working apps go, i still consider readding kcpuload which worked then was gone, works still well from an overlay ;) you get the idea i will add your email to the dvd::rip filter in kmail so i hopefully do not miss things wife's surgery is friday, so i don't expect to do much before then Thanks, Daniel Goller pgpzxz08W7VDT.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Friday 09 December 2005 08:19 pm, Mike Frysinger wrote: On Sat, Dec 10, 2005 at 01:09:50AM +0100, Luca Barbato wrote: Mike Frysinger wrote: so the video herd policy is to remove packages until you're left with a small enough subset of packages you can handle ? I'd rather say that we select packages that evolve and fit the needs and kill what isn't suitable anymore. fair enough, but i thought we've establish that there are *no* alternatives to dvdrip regardless of what diego may think -mike well, it's maintained now, better slow progress than certain death, works too well for me to see it go pgpTLSrvyBwb8.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote: On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | Arch teams need to be allowed to override maintainers where | appropriate, | | Why not talk to the package maintainers instead, and convince them | that you need a different version marking maint instead? Why | override (which, tbh, smacks of we arch teams know best, life would | be better without package maintainers) when you could work with | people instead? You're *not* in competition with package | maintainers. We're all supposed to be working towards the same | thing :) Sure, we do that anyway. However, sometimes package maintainers are outright wrong. agreed talk/communcation is fine, if the maintainer is only trying to flex muscles and does not have a good reason, the arch team ought to be able to do what is best for gentoo and not be shot down by a (hm) stubborn(?) maintainer, if the maintaner could do that, the arch team would be quite limited in its effectiveness | I've no personal problem with arch teams sometimes needing to do their | own thing, provided it's confined to a specific class of package. | Outside of the core packages required to boot maintain a platform, | when is there ever a need for arch maintainers to decide that they | know better than package maintainers? Pretty regularly. A significant number of package maintainers have a very shoddy attitude towards QA, and a significant number of upstreams have no clue what portability is. | If this isn't confined - if arch maintainers are allowed to override | package maintainers wherever they want to - then arch teams need to | take on the support burden. Fair's fair - if it's the arch team | creating the support, it's only fair that they support users in these | cases. It's completely unfair - and unrealistic - to expect a | package maintainer to support a package he/she thinks isn't fit to be | stable on an arch that he/she probably doesn't use anyway. In such a | conflict of egos, the real losers remain our users. If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. pgp9ahKI3ctaR.pgp Description: PGP signature
Re: [gentoo-dev] tentative x86 arch team glep
On Sunday 04 September 2005 04:52 pm, Stuart Herbert wrote: On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote: If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. Agreed, but we both know that it's just not how many devs work atm. Perhaps that is a problem that also needs to be solved? There's also the issue that many users are happy running ~arch packages, but are reluctant to test masked packages (making it difficult to get enough feedback to move the package to ~arch anyway). This is a bit of a chicken and egg situation - one that the maintainer arch may provide a new solution to. sounds like you suggest to trick ~arch users into testing unripe ebuilds/bumps/versions by sending it into ~arch to get the testing done while someone in a chroot would be much better equipped for doing the testing with? Best regards, Stu pgpFrUo735khK.pgp Description: PGP signature
Re: [gentoo-dev] Abuse by gentoo developer
Allen Parker wrote: parrot yah, what he said! /parrot On another note, Casey, you should attempt to figure out if anything you've said might have been taken the wrong way... a while back, i managed to get myself banned from #apache after going off like an idiot and then making a comment that was interpreted as sarcasm when i was only being genuine... I'm not saying you're to blame, but I'm saying you should look at what you said to see if anything you said could have been seen in the wrong light. It's possible that something you didn't intend as a negative was taken in an unintentional manner. sounds more like Anarchy had another bad day, one of many he seems to have had, and his bad days are getting quite tiresome i would say ciao, infowolfe On 7/19/05, Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 19 July 2005 10:21 pm, Nathan L. Adams wrote: i think Nathan did a pretty good job of summing up anything i thought i might add ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a #g-d first impression might represent process and metastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Northrup wrote: | Joshua Baergen wrote: | | |2) There are gentoo.org references to #gentoo-dev, but the process of |interfacing, mentoring, and recruiting are self-referential beginning |with a bootstrap of being on the good side of an existing developer. So |for those of us who do not establish favorable dialogues by filing a |bug, the door starts out closed. | | | |In reference to the difficulties outlined regarding becoming a |developer above, I am in the process of becoming a dev without any |contact with developers beforehand except for filing a bug that |probably annoyed devs more than helped :P I contacted the recruiting |group in response to a requirement for developers and they were glad |to get the process started provided that I showed evidence that I |would be an asset, mainly through input on bugs currently open. | |I doubt that I am the only one who has this story, but that doesn't |mean your claim in #2 could not have happened to other people. Did |you have any specific situations you were referring to when you wrote |that? | | | | I was up late on a friday evening hacking up a nifty addition to my | system and in my excitement and exuberance jumped on IRC to the dev | channel to get pointers to the best official references to ebuild | crafting and submission. | | As it was absolutely silent, I waited a few minutes and requested voice | from the first notice of motion i saw in the channel.. re, or some | similar indication of important offical business commencing. I was | informed that the bottom line was voice was only granted to developers, | period, end of story, no exceptions, and I was obviously misinformed and | should be elsewhere. Instead of anything like assistance I wound up | being told | 1) (condescension) it was people like me who try to skirt the gentoo | process which are actually the problem even if we think it's contributing, | 2)these important people in this channel are only here so that they can | occasionally ping each other and see thier nickname had been highlighted. | 3) that under no circumstance was I going to get an audience in | #gentoo-dev, now or in future context, because it was for developers, | and regardless of 20 years coding experience or working on linux since | 0.99, I was not a developer | 4) I could feel free to file a bug if I thought there was an issue, or | talk to a recruiter about something to help out with. | First, let me say i am sorry you had this experience, i freuqntly voice people in #gentoo-dev if they seem to have the need to speak there, the reasons could be many, maybe someone uses icewm and finds it way outdated, and helps the maintainer by testing for him, being a quasi maintainer a while dow the road and eventually becoming a gentoo dev (might i add imhoi would say we have more maintainers than developers/imho?) and taking care of icewm completely then and making it a habit to apply the many gcc 3.4 patches who have been submitted to bugzilla, and lay dead and dusty there for no dev to be touched (ok so now it would be gcc4.0 but that dev might have brought on a guy who takes care of those by now ok enough stories about how use having +v in #gentoo-dev is possible, is normal, and can lead to things | my reply was that I enter #gentoo-dev, and request voice when it seems | helpful and important, without incident in all previous occasions | the response was that these developers were obviously in error and it | was irrelevant to the discussion. | | I said I'm willing to take my chances as being perceived as noise. | the response was an unceremonious kick. | | This developer was possessed with zeal and determination. to be sure. | | Anyways, it happened, it's over. the order and exact words may have | been different but the tone and the impression stuck. I spent the due | dillegence perfecting my system hack, but I did not succeed in making it | available, or finding a likely benefactor project for voip qos | settings. This was beneath the involvment of #gentoo-dev at the time i | made the approach. I spent several hours researching volumes of gentoo | info alternating between the recruitment process and the ebuild process, | on a busy weekend i had planned to spend apart from a console. | | so.. as an aside, is there a package with an interest in iptable | configuration for broadband voip qos configs? what i really replied for is to ask, if i can forward your email to a friend of mine who happens to be involved with telephony with his company, i know zero about that, i do know he does use VoIP, so maybe he finds your hack nifty | | Jim hope you better luck next time in #gentoo-dev Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCqlguUpKYMelfdYERAtt8AJ4p937DdhoHGKuhgKEO8V6QLfM+gwCdHCeJ d226J9epAw42oIsGkj0+5r8= =QAsX -END PGP SIGNATURE- -- gentoo-dev@gentoo.org
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | On Thu, 2005-05-26 at 22:15 -0500, Daniel Goller wrote: | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |Mike Frysinger wrote: || On Thursday 26 May 2005 10:04 am, Chris Gianelloni wrote: || ||I'm asking because I will need to modify the livecd-tools scripts to ||take into account a way to disable DHCP when either nodhcp or ||nodetect are passed to the release media. || || || speaking of livecd updates, someone pointed out on a bug that we |shouldnt need || to check CDBOOT anymore in the volume addon code |(lvm/lvm2/evms/raid/etc) ... || the livecd should set RC_VOLUME_ORDER to ... maybe we can do this |in the || ebuild ? || -mike |you mean so i will not have to use 'gentoo nolvm2' on the next livecd on |my system? | | | That had nothing to do with the init scripts, so these changes would no | affect that in any way. All of the no* commands affect things that are | specific to the livecd. | then i'll have to make sure to test as many of the next livecd release candidates to see if it still requires me to specify that or not -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCmJZSUpKYMelfdYERAidpAJ4iy8x1IFFijFBSWnVAz0g7r90lmQCfch5C 8Xbt4qqCbmMBs2UOKefq3+o= =6mRj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | yes, it's finally that time ... after months of hearing us say 'we want to get | new baselayout stable asap', we're serious | | so can people please try out baselayout-1.11.12-r2+ and see if they notice any | regressions ? the 'best' tests are simply rebooting and seeing if your | system comes up :) | | common gotchas: | - many config options have moved from /etc/rc.conf into /etc/conf.d/ files | - /etc/hostname and /etc/*domainname have been moved into /etc/conf.d/ files | - the net scripts have been completely rewritten thanks to UberLord ... old | config styles should work fine, but it's best if you update | your /etc/conf.d/net syntax ... just review /etc/conf.d/net.example or this | URL: http://dev.gentoo.org/~uberlord/net-book/ | | somethings to note ... | regressions with lvm/lvm2/evms will not be considered ... they have had all | their code forked into the respective packages and thus are no longer part of | baselayout ... bugs with those packages should be taken up with their | respective maintainers | -mike booted for me on ~x86 no raid/lvm/lvm2/evms to help you there hope this helps -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClQ7TUpKYMelfdYERAk15AJ0fiaIuY8cGjezr0br0p3NRC6fAIgCghtBt 8nGxZXiQT1/nMrFq0uy/QRY= =eznV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] encode useflag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: | Another useflag-related question. | | Currently, the encode useflag is defined as follow: | | encode - Adds support for MEncoder or LaME encoder, wherever applicable | | this is a loose definition which is quite useless for medium user, as it's | used also in a non-complete-standard way in all ebuilds. | | My proposal is to start using lame useflag to enable lame support (in software | which is just encoding on itself), and using encode with a slight different | definition for example: | | encode - Adds support for encoding files in addiction to decoding should this be ok'ed make sure to put addition, not addiction | | so that it can be used to enable generic encoding support instead of specific | using lame or mencoder. | | Comments? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFChuvPUpKYMelfdYERAm5XAJ0QKEhbGcBiPju0RWYoDDIeU4NNsQCfby8l Hy1CnYNhXUTkeOT5t8ZoelE= =wYmu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
