Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote: Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. This is not related to PMS. Paludis for example does it already with the current EAPIs. So how does Paludis handle those issues? (Read my comments about emerge atomicy below) It is a problem which can _only_ be solved at the PM level. You have to tell the PM when API breakages happen. Either by slotting the lib or by something else. ^^^ This is important - as slotting is not a practical solution. What is it then? Using guesswork to determine whether or not a library should be removed may be a temporary solution. Remember: you're partially ignoring a users request since he wanted the package to be removed - and we all know how things like protect the user from himself end up. Unconditionally removing libraries (instead of preserving them) and making their reverse runtime dependencies reinstalled is unacceptable because emerge process involving multiple packages is not atomic. Simple as that. Is this what you suggest? Correct me if I'm wrong: 1. Users wants to uninstall or reinstall package, we let him do it provided reverse runtime dependencies are satisfied afterwards. Let's say he wants to upgrade expat. 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime reverse deps will still be satisfied when we upgrade. 3. Expat has been upgraded sucessfully, 4a. emerge discovers reverse runtime dependencies are broken and it starts to rebuild them, then it bails out due to error ld: libexpat.so.sth not found. Because step 3 cannot be rolled back (no atomicy) - game over. or 4b. emerge does not discover those and does nothing. python is broken so emerge cannot be used anymore. Game over -- regards MM
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: Unconditionally removing libraries (instead of preserving them) and making their reverse runtime dependencies reinstalled is unacceptable because emerge process involving multiple packages is not atomic. Simple as that. Is this what you suggest? Correct me if I'm wrong: 1. Users wants to uninstall or reinstall package, we let him do it provided reverse runtime dependencies are satisfied afterwards. Let's say he wants to upgrade expat. 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime reverse deps will still be satisfied when we upgrade. 3. Expat has been upgraded sucessfully, 4a. emerge discovers reverse runtime dependencies are broken and it starts to rebuild them, then it bails out due to error ld: libexpat.so.sth not found. Because step 3 cannot be rolled back (no atomicy) - game over. or 4b. emerge does not discover those and does nothing. python is broken so emerge cannot be used anymore. Game over This is called 'nondeterministic resolution'- known issue also w/ proposals of that sort. Pretty much everytime someone proposes it as a solution, it gets smacked down by most folk since an emerge -p invocation that is a single pkg upgade shouldn't be able to go rebuild your entire world. The alternative is a slotted ABI var- basically a counter (although it doesn't have to be) w/in ebuilds themselves to indicate if they're carrying a new ABI from upstream for that slotting. For example, you've got EXPAT merged w/ ABI=2, version 2.0. version 2.0.1, for whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or 3, as said it's an arbitrary value). Via that, the resolver can see that a rebuild is necessary and plan a rebuild of all consumers (whether NEEDED based or revdep). Note preserve-lib would be rather useful here- specifically holding onto the intermediate lib while doing rebuilding. This however breaks down a bit when the ABI change is in reverse of normal versioning. Usually whenever I've floated this idea, it's gotten smacked down by devs due to the extra work it may entail- someone doing an experiment on this would be rather useful (someone with a tinderbox specifically). ~harring pgpzALSfinToO.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, 05 Apr 2010 03:33:52 +0200 Tobias Heinlein keytoas...@gentoo.org wrote: 3) Questions that aren't that important at all and would just be nice to know. [snip] Examples for these: 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH inside SRC_URI, DEPEND, etc? [Devmanual, Caching] How the heck is this not important? Anyone who doesn't immediately know the answer to this has absolutely no business touching any ebuild that might end up being given to someone else. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 05, 2010 at 08:48:08AM +0100, Ciaran McCreesh wrote: On Mon, 05 Apr 2010 03:33:52 +0200 Tobias Heinlein keytoas...@gentoo.org wrote: 3) Questions that aren't that important at all and would just be nice to know. [snip] Examples for these: 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH inside SRC_URI, DEPEND, etc? [Devmanual, Caching] How the heck is this not important? Anyone who doesn't immediately know the answer to this has absolutely no business touching any ebuild that might end up being given to someone else. That question really needs chunking up offhand- there are valid usages of $(), but the question doesn't really ask when it's not explicitly. You see it, I see it, so lets skip getting into it further lest someone have a very easy google answer on it ;) Either way, file a bug re: it for wording improvements if you'd like. ~harring pgpWfiRITo8We.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/05/2010 05:36 AM, Alistair Bush wrote: On 4/3/10 3:40 PM, Ben de Groot wrote: Are there any other ideas on how to improve our recruitment process? The idea appeared before, but I think it's worth noting. Either merge the ebuild and end quizzes, or make the split actually meaningful. In my case I just finished both at the same time, but was confused why they are separate. I think I've seen similar comments from other developers. I think I'd rather prefer merging the quizzes. One thing i've noticed is that the ebuild quiz is far more difficult than the eom quiz. We seem to have the biggest hurdle first. What I would like to see is either the quizzes be merged or An easier first quiz that covers the basics which after being answered the user can become a gentoo developer ( ie @gentoo.org email, ssh access to d.g.o, etc) but no access to push directly to the tree. Instead all commits must be pushed thru their mentor, who is responsible for qa'ing and giving advice. Currently I don't think mentors really have much of a role. There is certainly no requirement for a mentor to qa their charges commits, but if they are the ones pushing to the tree the mentor has all the responsibility. This might just make mentors more responsible for the quality of recruits. Yeah would be easy to implement if we get git some day. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Should we disable RESOLVED LATER from bugzilla?
mån 2010-04-05 klockan 03:54 +0300 skrev Mart Raudsepp: The problem is really the RESOLVED connotation and the hiding that goes along with that on searches, etc. The LATER status itself can be useful when used properly (more as ASSIGNED LATER). In the lack of that some bigger teams might need to think of other methods to get things meant for LATER out of main views of huge bug lists. Actually I think this is the best yet. I have always found the sounding of RESOLVED LATER so harsh. ASSIGNED LATER would more sound like we know there is a problem, and we know it should be fixed, but we cannot do it now for different reasons.
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring: On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote: Unconditionally removing libraries (instead of preserving them) and making their reverse runtime dependencies reinstalled is unacceptable because emerge process involving multiple packages is not atomic. Simple as that. Is this what you suggest? Correct me if I'm wrong: 1. Users wants to uninstall or reinstall package, we let him do it provided reverse runtime dependencies are satisfied afterwards. Let's say he wants to upgrade expat. 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime reverse deps will still be satisfied when we upgrade. 3. Expat has been upgraded sucessfully, 4a. emerge discovers reverse runtime dependencies are broken and it starts to rebuild them, then it bails out due to error ld: libexpat.so.sth not found. Because step 3 cannot be rolled back (no atomicy) - game over. or 4b. emerge does not discover those and does nothing. python is broken so emerge cannot be used anymore. Game over This is called 'nondeterministic resolution'- known issue also w/ proposals of that sort. Pretty much everytime someone proposes it as a solution, it gets smacked down by most folk since an emerge -p invocation that is a single pkg upgade shouldn't be able to go rebuild your entire world. The alternative is a slotted ABI var- basically a counter (although it doesn't have to be) w/in ebuilds themselves to indicate if they're carrying a new ABI from upstream for that slotting. For example, you've got EXPAT merged w/ ABI=2, version 2.0. version 2.0.1, for whatever reason, breaks ABI- thus v2.0.1 in the tree is ABI=2.0.1 (or 3, as said it's an arbitrary value). Via that, the resolver can see that a rebuild is necessary and plan a rebuild of all consumers (whether NEEDED based or revdep). Note preserve-lib would be rather useful here- specifically holding onto the intermediate lib while doing rebuilding. No, it doesn't help since you may have the same problems some people try to solve in this thread. This however breaks down a bit when the ABI change is in reverse of normal versioning. How so? Such a var should just specify the ABI and the PM only has to check whether it changed from one PVR to the other. The how is completely irrelevant. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/05/2010 03:48 AM, Ciaran McCreesh wrote: On Mon, 05 Apr 2010 03:33:52 +0200 Tobias Heinleinkeytoas...@gentoo.org wrote: 3) Questions that aren't that important at all and would just be nice to know. [snip] Examples for these: 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH inside SRC_URI, DEPEND, etc? [Devmanual, Caching] How the heck is this not important? Anyone who doesn't immediately know the answer to this has absolutely no business touching any ebuild that might end up being given to someone else. My concern with these kinds of questions is that there really isn't any page where we have key gotchas consolidated like don't execute external programs in global scope. Sure, it is in the devmanual, and if you read the whole thing then maybe you might remember that one bit in particular. I agree that somebody who doesn't know this particular fact shouldn't be committing ebuilds. My concern is that we don't really have any way to make people aware of that particular fact. Honestly, I think it would be just as effective to simply write up a single webpage with thou shalt not's, and not make people go hunting all over the place to figure out the whys. By all means have a link on each thou shalt not to the reason. There are lots of people who would be perfectly capable of doing many developer activities who might not come in knowing about the metadata cache. They don't need to know the nuts and bolts of how it works, just what they need to do to avoid problems with it. In any case, giving hints as to the location of the answer in this kind of a question seems fine to me. The important thing is that the candidate dev learn about the potential problem - not that they figure it out 100% on their own. Still, the socratic method is a good approach to teaching, so I'm not opposed to the QA format of the quiz in general. We just need to let candidates know that we're there to help them succeed and the quiz is a tool - the goal isn't to eliminate any potential contributor who doesn't come to the table knowing as much about Gentoo as any seasoned dev. Rich
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski: On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote: Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. This is not related to PMS. Paludis for example does it already with the current EAPIs. So how does Paludis handle those issues? (Read my comments about emerge atomicy below) It is a problem which can _only_ be solved at the PM level. You have to tell the PM when API breakages happen. Either by slotting the lib or by something else. ^^^ This is important - as slotting is not a practical solution. What is it then? Using guesswork to determine whether or not a library should be removed may be a temporary solution. Remember: you're partially ignoring a users request since he wanted the package to be removed - and we all know how things like protect the user from himself end up. Unconditionally removing libraries (instead of preserving them) and making their reverse runtime dependencies reinstalled is unacceptable because emerge process involving multiple packages is not atomic. Simple as that. A side mark: preserving libs may work in a number of cases, but there are a lot of (possible) examples where the rdeps (and/or the preserved libs) are nevertheless broken or become useless (think of: ui-files, plugins, dlopen'ed libs, etc.). Please forget your atomicity. It's a really nice idea (and I'd like to see it too) but not possible now or in the near future. Is this what you suggest? Correct me if I'm wrong: 1. Users wants to uninstall or reinstall package, we let him do it provided reverse runtime dependencies are satisfied afterwards. Let's say he wants to upgrade expat. 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime reverse deps will still be satisfied when we upgrade. 3. Expat has been upgraded sucessfully, 4a. emerge discovers reverse runtime dependencies are broken and it starts to rebuild them, then it bails out due to error ld: libexpat.so.sth not found. Because step 3 cannot be rolled back (no atomicy) - game over. or In that case you most probably have a problem in your dep-tree (either unspecified deps or a dep-resolver bug) -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/04/2010 02:09 PM, Denis Dupeyron wrote: All ideas regarding improving recruitment are welcome, thanks. However if, during your review, you were not given the impression that your maturity and other social skills were being assessed then you were being blissfully naive. :o) That actually wasn't what I was trying to convey (guess I need to work on those communications skills :) ). I did recognize that you were looking to assess this, and that you felt that this was of critical importance. What I was getting at is trying to identify what aspects of the whole recruitment process added the most value and which added the least, and adjusting accordingly. I think that assessing attitude and maturity, and providing the tools and education needed are the most critical aspects of recruitment. That's why I'm all for changing the approach to quizzes - from my experience it wasn't the quizzes themselves that really added the most value for me. The interaction that they triggered and getting me to consider some of the more critical issues that come up in ebuild maintenance added far more value than getting every detail of the answers 100% correct. The quizzes are just a tool - not the ultimate validators of ability. Let's use every tool at our disposal in the best way possible. Rich
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote: Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: I think this is a good starting point to get rid of the some important questions are too hard to answer dilemma that can be implemented relatively fast. On top of that I like Sebastian's idea to order the quizzes by difficulty -- this means just ordering by the categories I just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. Agreed... I've been following this discussion with mixed feelings. When we originally began using the quiz system the idea was simply to try to force new developers to RTFM -- and I was not such a fan of the entire concept (as I recall, the quizzes were a suggestion from Daniel). As it turns out, the quiz system has repeatedly proven itself useful in another way: developers who whine/bitch/moan and are hesitant to even attempt to complete the quizzes often turn out to be bitchy, unmotivated, or unpleasant developers. I don't want to name any names, but I've seen this often. IMO, those boring too much like high school quizzes serve one extremely valuable function: finding out up front who's a team player (or at least willing to do something mildly unpleasant for the Greater Good) If that's causing potential devs to drop out... perhaps the system is working as it should? :)
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 05, 2010 at 04:07:01PM +, Jon Portnoy wrote: On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote: Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: I think this is a good starting point to get rid of the some important questions are too hard to answer dilemma that can be implemented relatively fast. On top of that I like Sebastian's idea to order the quizzes by difficulty -- this means just ordering by the categories I just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. Agreed... I've been following this discussion with mixed feelings. When we originally began using the quiz system the idea was simply to try to force new developers to RTFM -- and I was not such a fan of the entire concept (as I recall, the quizzes were a suggestion from Daniel). As it turns out, the quiz system has repeatedly proven itself useful in another way: developers who whine/bitch/moan and are hesitant to even attempt to complete the quizzes often turn out to be bitchy, unmotivated, or unpleasant developers. I don't want to name any names, but I've seen this often. IMO, those boring too much like high school quizzes serve one extremely valuable function: finding out up front who's a team player (or at least willing to do something mildly unpleasant for the Greater Good) If that's causing potential devs to drop out... perhaps the system is working as it should? :) There should be a process of weeding out developers that bitch and/or whine, but if most of the teams are understaffed then there has to be done something about it. The way I see it there are two options: a) Scale down the size of the operation, reduce packages offered, and if there are more packages wanted, let the users maintain them. b) Look at an effective way of making the process of become a developer (and being a developer for that matter) more attractive. The first option could be somewhat simple, we already have overlays so those could simply be used. The second option (which would be the best IMO) is a fair bit harder. The first thing that needs to be done is find out why people don't want to become developers. I've heard a few users mention the quiz, but it seems that the thing keeping most people away from becoming developers are all the flame wars that have occured, and the fact that it (to us users) seems like the council isn't doing much of anything about it. So while I believe that improving (and/or updating) the recruitment process is important, I think there would be more success if it seemed like a nice place to be a part of, and that bad behaviour is dealt with. -- Zeerak Waseem pgpEY8rDY73LF.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 05/04/2010 17:07, Jon Portnoy wrote: On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote: Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: I think this is a good starting point to get rid of the some important questions are too hard to answer dilemma that can be implemented relatively fast. On top of that I like Sebastian's idea to order the quizzes by difficulty -- this means just ordering by the categories I just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. Agreed... I've been following this discussion with mixed feelings. When we originally began using the quiz system the idea was simply to try to force new developers to RTFM -- and I was not such a fan of the entire concept (as I recall, the quizzes were a suggestion from Daniel). As it turns out, the quiz system has repeatedly proven itself useful in another way: developers who whine/bitch/moan and are hesitant to even attempt to complete the quizzes often turn out to be bitchy, unmotivated, or unpleasant developers. I don't want to name any names, but I've seen this often. IMO, those boring too much like high school quizzes serve one extremely valuable function: finding out up front who's a team player (or at least willing to do something mildly unpleasant for the Greater Good) If that's causing potential devs to drop out... perhaps the system is working as it should? :) That assumes the system is working perfectly and the whole fact that we are having this discussion would go against that. From what i've read in the community, lots of people would have no problems helping out maintaining packages, they just don't want the baggage that comes with it. You could say they're lazy or they're not the type of developers you want but at the end of the day they're just different developers, most of whom probably just want to make sure the packages they like are in the tree and updated.
Re: [gentoo-dev] Is Gentoo a Phoenix?
On Mon, Apr 5, 2010 at 9:33 AM, Richard Freeman ri...@gentoo.org wrote: What I was getting at is trying to identify what aspects of the whole recruitment process added the most value and which added the least, and adjusting accordingly. I think that assessing attitude and maturity, and providing the tools and education needed are the most critical aspects of recruitment. Agreed. Although the education part should come from the mentor. Recruiters are only supposed to fill in the gaps because there's only so much they can do. Nowadays most mentors only really care about making sure their mentee gets the quiz answers right. That's a big mistake. I've been mentoring somebody to help me with sci-electronics for months now (hi Rafael!), and the quizzes are less than 5% of what we spend time on. So what is it then? English and how to communicate was the big thing at first but he's doing much better now, then working on a lot of ebuilds in and outside of bugzilla, but also how to efficiently deal with people, why things happen in a volunteer project and most importantly why they don't, how to not get discouraged by many little annoying things, etc... That's the kind of things a mentor and thus every gentoo developer should invest time in because it pays back big time. I've been toying with a project about training mentors but can't find the time to set it up. The idea was to have interactive sessions on irc with a few interested devs. That's why I'm all for changing the approach to quizzes - from my experience it wasn't the quizzes themselves that really added the most value for me. The interaction that they triggered and getting me to consider some of the more critical issues that come up in ebuild maintenance added far more value than getting every detail of the answers 100% correct. I do make sure that answers are 100% correct since I consider that part of the necessary paperwork to be recruited. However during the review I use the quizzes mostly as a way to engage conversation on a lot of topics, not only technical. That's the reason a review with me lasts anywhere from 5 to 12 hours. So in a sense what you're thinking of is already happening. Denis.
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/05/2010 09:26 PM, Zeerak Mustafa Waseem wrote: The first option could be somewhat simple, we already have overlays so those could simply be used. The second option (which would be the best IMO) is a fair bit harder. The first thing that needs to be done is find out why people don't want to become developers. I've heard a few users mention the quiz, but it seems that the thing keeping most people away from becoming developers are all the flame wars that have occured, and the fact that it (to us users) seems like the council isn't doing much of anything about it. So while I believe that improving (and/or updating) the recruitment process is important, I think there would be more success if it seemed like a nice place to be a part of, and that bad behaviour is dealt with. Developers are not required to be subscribed to any of the mailing lists where the huge threads happen so if they want they can just ignore them and go about maintaining their packages. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: I see no reason whatsoever to keep it open. How about this one: preventing users from filing dupes. If we start doing that, we'll end up with tons of extra bugs on our hands. What's the big deal? You know you'll be adding/bumping the package at some point. Just close the bug when you do so. It's certainly less work than marking it RESOLVED FIXED once and then DUPLICATE many times after that. The point of bugzilla is tracking bugs, not a tool to arbitrate a pissing contest about who has the least bugs open. If you can't/don't want to fix a bug that's OK, but it's not a good enough reason to pretend it never existed. Denis.
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 05, 2010 at 05:50:49PM +0100, George Prowse wrote: That assumes the system is working perfectly and the whole fact that we are having this discussion would go against that. From what i've read in the community, lots of people would have no problems helping out maintaining packages, they just don't want the baggage that comes with it. You could say they're lazy or they're not the type of developers you want but at the end of the day they're just different developers, most of whom probably just want to make sure the packages they like are in the tree and updated. Which is all well and good -- the you wrote some ebuilds so here's your commit privs and @gentoo.org approach to recruitment worked great when Gentoo had a few dozen developers. Today QA is a bit more important, and development is often rather more complex than new version, bump the ebuild -- it's important that new developers have a firm understanding of ebuild complexities. I have no dog in this fight, I don't even like resurfacing to post to -dev. Just here to offer some insight on why we originally kept the quiz system.
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sat, Apr 3, 2010 at 9:25 AM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. Reassigning the bug to yourself (or the herd) if necessary, accepting it, and then explaining what/who/why/etc in a comment is the way to go in that case. No system, however good it is, will replace proper communication. Denis.
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Mon, Apr 05, 2010 at 03:27:34PM +0200, Tiziano MMMller wrote: Via that, the resolver can see that a rebuild is necessary and plan a rebuild of all consumers (whether NEEDED based or revdep). Note preserve-lib would be rather useful here- specifically holding onto the intermediate lib while doing rebuilding. No, it doesn't help since you may have the same problems some people try to solve in this thread. Might I suggest in the future purning down what you're responding to, to just that blurb? At first read of your response I thought you were arguing against the ABI var itself (which didn't make a helluva lot of sense). Meanwhile, yes, using preserve lib there still has some issues- the reason I mentioned it possibly being held onto is that if we're talking about something like openssl, having your system be horked for the intervening period isn't a great thing thus it may be useful as an option at the least. This however breaks down a bit when the ABI change is in reverse of normal versioning. How so? Such a var should just specify the ABI and the PM only has to check whether it changed from one PVR to the other. The how is completely irrelevant. That comment is in reference to if preserve-lib is still enabled for the rebuild. ~harring pgpYBJABgPHnz.pgp Description: PGP signature
[gentoo-dev] [RFC] Gentoo Wiki Project
After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. We'd also like to invite any users and developers, who are willing to help to make this a success, to join us. At this point we are especially looking for people who can help with: - the initial setup and configuration of a MediaWiki instance - the design of a custom Gentoo theme for MediaWiki (including graphics and CSS) - the internal organization of the wiki - moderation 1: http://www.gentoo.org/proj/en/wiki/ Cheers, -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 5, 2010 at 11:57 AM, Jon Portnoy av...@eris.oppresses.us wrote: Which is all well and good -- the you wrote some ebuilds so here's your commit privs and @gentoo.org approach to recruitment worked great when Gentoo had a few dozen developers. Today QA is a bit more important, and development is often rather more complex than new version, bump the ebuild -- it's important that new developers have a firm understanding of ebuild complexities. That's a very important point. On one side there are developers and would-be developers who want an easier way to recruit people. Most ideas revolve around lowering the technical/social barriers. On the other side there's QA and a bunch of other developers who want fewer people screwing up the tree. Those are proponents of being stricter during the recruiting process (i.e. in the end recruiting fewer people) and firing more devs. None of them though help the poor guys in the middle. Those are the recruiters who could swing completely one way or the other for simplicity, or be more subtle and try and make the best out of the situation and resources. When you're all done barking, and in case you really consider helping here are two things you can do: - join the recruiters - actually *mentor* people to become developers. And by that I don't mean passing them your quiz answers, but really training them and preparing them to become good and well behaved developers. When people ask me how to go about that my usual answer is do as you were teaching your son/little brother how to fly fish (or replace fly fishing with what you do best). Start from the start, progress from there, don't overlook any aspect of the art (there's more to being a dev than writing ebuilds), and be ready to spend hours explaining and re-explaining. If your recruit doesn't get it then it can only be your fault, so try harder. Before you replace/change a system you should first try and make it work. II don't even like resurfacing to post to -dev. Just here to offer some insight on why we originally kept the quiz system. Hi Jon, long time no see. Thanks for doing that. Denis.
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 05/04/10 11:07, Jon Portnoy wrote: On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote: Just replying randomly. On 05.04.2010 04:33, Tobias Heinlein wrote: I think this is a good starting point to get rid of the some important questions are too hard to answer dilemma that can be implemented relatively fast. On top of that I like Sebastian's idea to order the quizzes by difficulty -- this means just ordering by the categories I just mentioned would be sufficient: 1 first, then 2, then 3. I am not against this idea but frankly, I do not understand what is so demotivating about the ebuild quiz. If you get demotivated because of a single exam, perhaps the problem is with the motivation and not with the exam itself. I took the published quiz just for the fun of it and to see where I missed. It is not that long. Agreed... I've been following this discussion with mixed feelings. When we originally began using the quiz system the idea was simply to try to force new developers to RTFM -- and I was not such a fan of the entire concept (as I recall, the quizzes were a suggestion from Daniel). As it turns out, the quiz system has repeatedly proven itself useful in another way: developers who whine/bitch/moan and are hesitant to even attempt to complete the quizzes often turn out to be bitchy, unmotivated, or unpleasant developers. I don't want to name any names, but I've seen this often. IMO, those boring too much like high school quizzes serve one extremely valuable function: finding out up front who's a team player (or at least willing to do something mildly unpleasant for the Greater Good) If that's causing potential devs to drop out... perhaps the system is working as it should? :) My problem with the quizzes is not that they have to be done, but rather the way they are structured. I have read through the dev manual (which is excellent in explaining some things, and a little rough in others), but it would be much more enlightening to me to work on creating ebuilds while working one-on-one with a mentor. For instance, in a recent ebuild I wrote, the application installed successfully but yielded sandbox errors. By jumping on IRC and chatting with a few people, I readily found a solution to that problem. Later, it was brought to my attention that there were other problems with the ebuild. I would have never known about these issues solely from the information presented in the devmanual. Therefore, I think the most valuable aspect of the recruitment process is hands-on time with ebuilds, commits, et cetera WHILE working with a mentor. --Zach
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On 05/04/10 13:12, Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. We'd also like to invite any users and developers, who are willing to help to make this a success, to join us. At this point we are especially looking for people who can help with: - the initial setup and configuration of a MediaWiki instance - the design of a custom Gentoo theme for MediaWiki (including graphics and CSS) - the internal organization of the wiki - moderation 1: http://www.gentoo.org/proj/en/wiki/ Cheers, As I posted on the fora, I would be willing to work on the initial installation of MediaWiki, organisation, and moderation. Let me know what needs to be done and I will start. Thanks Ben. --Zach
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 5, 2010 at 12:51 PM, Nathan Zachary nathanzach...@gentoo.org wrote: [...] but it would be much more enlightening to me to work on creating ebuilds while working one-on-one with a mentor. The whole purpose of the training period between the ebuild quiz and the end quiz (see [1]) is exactly this. If your mentor isn't doing that with you then look for another one who will mentor your properly. Don't blame the system when it's not used. Denis. [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On Mon, 5 Apr 2010 20:12:49 +0200, Ben de Groot yng...@gentoo.org wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. We'd also like to invite any users and developers, who are willing to help to make this a success, to join us. At this point we are especially looking for people who can help with: - the initial setup and configuration of a MediaWiki instance idl0r and I are offering to arrange things with infra. As they are busy at the moment, I created a test wiki for us to test extensions and styling: http://gentoowiki.a3li.li/index.php?title=Main_Page I have installed a captcha extension, as well as the flagged revision extension. Contact me off-list for editor privileges for that. - the design of a custom Gentoo theme for MediaWiki (including graphics and CSS) In that aforementioned wiki, there is a hacked together purplified version of MediaWiki's new Vector theme. Maybe that's already enough. If not maybe someone wants to use it as a starting point (contact me off-list for details) Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On Monday 05 April 2010 21:12:49 Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. Thank you for all your hard effort We'd also like to invite any users and developers, who are willing to [..] - moderation I am willing to join the moderation userspace 1: http://www.gentoo.org/proj/en/wiki/ Cheers, -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On Mon, Apr 05, 2010 at 10:15:21PM +0300, Markos Chandras wrote: On Monday 05 April 2010 21:12:49 Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. Thank you for all your hard effort +1 It's great to see that this project is starting :-) We'd also like to invite any users and developers, who are willing to [..] - moderation I am willing to join the moderation userspace 1: http://www.gentoo.org/proj/en/wiki/ Cheers, -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org If someone could give me a description of what internal organization of the wiki intails I might be willing to help out with it (being that it's something I actually know about ;) ) otherwise I'd be more than willing to help out with moderation. -- Zeerak Waseem pgpSiWMnRSmU1.pgp Description: PGP signature
RE: [gentoo-dev] [RFC] Gentoo Wiki Project
Date: Mon, 5 Apr 2010 23:37:31 +0200 From: zeera...@gmail.com To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Gentoo Wiki Project On Mon, Apr 05, 2010 at 10:15:21PM +0300, Markos Chandras wrote: On Monday 05 April 2010 21:12:49 Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. Thank you for all your hard effort +1 It's great to see that this project is starting :-) We'd also like to invite any users and developers, who are willing to [..] - moderation I am willing to join the moderation userspace 1: http://www.gentoo.org/proj/en/wiki/ Cheers, -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org If someone could give me a description of what internal organization of the wiki intails I might be willing to help out with it (being that it's something I actually know about ;) ) otherwise I'd be more than willing to help out with moderation. -- Zeerak Waseem I'd like to help with the moderation too Sylvain aka d2_rac...@gentoo.org _ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Mon, Apr 5, 2010 at 11:24 PM, Denis Dupeyron calc...@gentoo.org wrote: On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: I see no reason whatsoever to keep it open. How about this one: preventing users from filing dupes. We already advise our users to check RESO bugs before filing bugs; and the advice seems to have trickled down quite well, and users only file duplicate bugs once before getting the idea. Overall, IMO it has worked. We only keep a single bug open for the entire GNOME 2.xx so people don't file dupes for that (we get a lot of dupes for that, but not specific packages). If we start doing that, we'll end up with tons of extra bugs on our hands. What's the big deal? You know you'll be adding/bumping the package at some point. Just close the bug when you do so. It's certainly less work than marking it RESOLVED FIXED once and then DUPLICATE many times after that. The point of bugzilla is tracking bugs, not a tool to arbitrate a pissing contest about who has the least bugs open. If you can't/don't want to fix a bug that's OK, but it's not a good enough reason to pretend it never existed. That's not the point; as I have explained above; our purpose is to prevent bug reports for packages that will go in with the major release from being filed. We usually have a [Tracker] bug open for the major release anyway; so the choice is either RESO DUPLICATE against that, or RESO LATER. We often do the latter to prevent noise on the tracker bug, or if it hasn't been filed yet, and the user is doing a stupid zero day bump request (or a development version bump request). For packages that are not in the gnome set, or gnome external deps set, we obviously keep the bump request bug open. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] last rites: games-strategy/castle-combat
# Michael Sterrett mr_bon...@gentoo.org (05 Apr 2010) # Needs dev-python/numeric which is going away. # No release since 2006 # Masked for removal on 20100505 games-strategy/castle-combat
[gentoo-dev] [git migration] The problem of ChangeLog generation
One of the few remaining problems to be solved for the migration to git for our gentoo-x86/ and gentoo/ trees (besides other projects/overlays) is the problem of how to handle ChangeLogs. Gist: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts * Proposed is to generate ChangeLogs from git commits on the rsync server side when metadata generation is done - Scripts to do this already exist[1] Now, there are obviously problems with this. Some of them are documented below alongwith their proposed solutions. If people foresee other problems with this; they are requested to comment. They are also welcome to comment if they have a better solution to the problems listed below. Also, please try to keep this thread on-topic. Problems: * Messages in ChangeLog are not always the same as the commit messages (~1% are different) * Some people place additional information in the commit message which is intended only for developer use - Most of the difference in ChangeLog/commit messages comes from this * Trivial changes are often not documented in ChangeLogs - This is upto the developer's personal preference - Some folks do this because of the extra time it takes + This use-case becomes irrelevant due to automatic generation of ChangeLog Solutions: * Do not re-generate the existing ChangeLog; rather make the ChangeLog generation script smart enough to only append - Solves the messages not same problem for existing commits * Use a separator in the commit message like == \n to denote that everything after this is dev-only information and should be skipped from the user ChangeLog - Solves the problem for people who like to add extra dev-only info in the CVS commit message * Ignore commits with [$tag][trivial] in the tag[2] from being added to ChangeLog - Keeps the wishes of the developer and does not pollute ChangeLog with such info 1. http://live.gnome.org/Git/ChangeLog 2. http://live.gnome.org/Git/CommitMessages -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05-04-2010 18:26, Zeerak Mustafa Waseem wrote: On Mon, Apr 05, 2010 at 04:07:01PM +, Jon Portnoy wrote: There should be a process of weeding out developers that bitch and/or whine, but if most of the teams are understaffed then there has to be done something about it. The way I see it there are two options: a) Scale down the size of the operation, reduce packages offered, and if there are more packages wanted, let the users maintain them. b) Look at an effective way of making the process of become a developer (and being a developer for that matter) more attractive. The first option could be somewhat simple, we already have overlays so those could simply be used. The second option (which would be the best IMO) is a fair bit harder. The first thing that needs to be done is find out why people don't want to become developers. I've heard a few users mention the quiz, but it seems that the thing keeping most people away from becoming developers are all the flame wars that have occured, and the fact that it (to us users) seems like the council isn't doing much of anything about it. So while I believe that improving (and/or updating) the recruitment process is important, I think there would be more success if it seemed like a nice place to be a part of, and that bad behaviour is dealt with. The Council has a very important role in Gentoo, but if everyone keeps turning to them to do everything, nothing will get done and they'll get swamped trying to do anything. Bad behaviour in the mailing lists is something that all of us have an obligation to prevent and help fix - including every developer and all interested community members. If and when someone violates Gentoo's Code of Conduct[1] and or exhibits a repetitive abrasive behaviour, please contact either the User Relations[2] or the Developer Relations[3] teams in case of an user or a developer. As Petteri already replied, developers who chose to focus in their corner are free to ignore most of the mailing lists and have no requirement to participate or even read the flames. In other words, if you'd like to become a developer but have kept away because of the flames, don't worry as you don't have to get involved on them. However and despite all the recent complaints about flames in the mailing lists, as someone that has been following the mailing lists for a while, the amount and level of flames has been substantially reduced in the last 2 years or so. We still have flames, but nothing like we used to have before. Also noteworthy, the number of people involved in the flames is very small and the majority is well known. [1] - http://www.gentoo.org/proj/en/council/coc.xml [2] - http://www.gentoo.org/proj/en/userrel/ [3] - http://www.gentoo.org/proj/en/devrel/ - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLupmUAAoJEC8ZTXQF1qEPXzgQAISLb1K8s4Fa2ORYK4+Lef/Y YeAYiM5xzNPl6kTi6rJF1IoQwDuaS0G/YfRRtzDYeibcYBE0GLVQL0cAyQDTF371 EvgQblvMpTpay8hiNmtdNAb0X6Bm5WUhZoTeY+ayrh6Yih+cniGP5K+zP70550vQ vvI0y9AdebwZzWrjedeEkUutaxNoBrED7IOfdixDpgD2110NuRcBHpdiBqen0exr Q2iBdG2ynfdEzYyYAgGHvHcjibtlboLe9DWkQ/APW5uOJHCt0M5QW8HtF7eaPvNf DS27KNwzoV1VLKxSD5I6cLFz5+NTikI7htZrxqvqjJx0zdk3X+whDOZBXT+7Amv3 2Jaiym4VCsmVXu2hWtZTlbhh0hp07ybx3NmLqNiRkNXX2636A5dCg6fwAUy/CC/g bmCIMtkTe7oXj+m23AVB1tU5zQuaBMhuV6BucRl3on2bAkSr53Hg0dFbGwwCdiMc FDULTNrXI1c1P5AKrqFWY6wHj6HW+m6rOVPowXHkuMEmde+T152jci0XYVOCj4v4 YjwKvDyQphk2rzb4S7hLTHpiMIzmM3cbt2/u0zfeviRkMueeT+zfIl8PMi3IN+5W fvwbTPEq3Eh1JfEaTDDhcYXeIZjrLFx1Es2MYgBKOVzRXCZm9z1Lm15A0LgjpP9O e09KPDVHG33o/pVc/pqA =AdOw -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On 04/05/10 13:12, Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. We'd also like to invite any users and developers, who are willing to help to make this a success, to join us. At this point we are especially looking for people who can help with: - the initial setup and configuration of a MediaWiki instance - the design of a custom Gentoo theme for MediaWiki (including graphics and CSS) - the internal organization of the wiki - moderation 1: http://www.gentoo.org/proj/en/wiki/ Cheers, It'd be good if the project page said something about how this relates to the existing Gentoo wiki. It's obvious that they serve different purposes, but the page right now makes no mention of what the distinction is. --Ravi
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On 2010-04-06 04:12, Ben de Groot wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. This is a good move indeed. There's a lot of stuff I'd like to be able to throw online for users' benefit that really doesn't belong in places like the handbook, but could be useful on the wiki. How are you off for moderators? I don't have a lot of time to sit around waiting for stuff to compile these days (which is why I've been very inactive on the MIPS and Mozilla fronts) but I could look help out with the moderation. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
Le 03/04/2010 11:50, Petteri Räty a écrit : I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems You're basically blaming LATER and other resolutions for users failing to *search* correctly. How about changing how users search instead? Let's make the small search box search for ALL bugs instead of just opened ones. *That* should help tremendously. That, and what Mart suggested. That's a good idea too. Cheers, Rémi
