[gentoo-dev] Duplicated entries in use.desc and use.local.desc
Well, the subject really says it all. On bug #89056 it seems to be thought that the duplication is not necessarily a bad thing. I'm not sure this is such a great idea myself, since if the USE flag needs a separate description for a package, it means that the behaviour from that flag could be different from package to package. Currently most of the duplicated flags that I looked at are not at all different and are just restating the same thing in two files. So, what do we want to do about this? Should we have some repoman warning if a USE flag exists in both files, or should it be acceptable? -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpmrmdUiVjvE.pgp Description: PGP signature
Re: [gentoo-dev] Duplicated entries in use.desc and use.local.desc
On Sun, 12 Feb 2006 03:19:25 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: | So, what do we want to do about this? Should we have some repoman | warning if a USE flag exists in both files, or should it be | acceptable? The whole idea of global USE flags is that they're the same for all packages that use said flag, and thus do not get a use.local.desc entry. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Making PROFILE_ARCH more useful?
PROFILE_ARCH is currently used for various sub-architectures (e.g. sparc32 vs sparc64, 32 bit ppc vs ppc64, xbox vs normal x86) that don't have their own keyword but that do occasionally need special behaviour. It can be used in conditionals, but because no-one ever quite got around to it, it *can't* legally be used to alter metadata. Is there any particular reason PROFILE_ARCH shouldn't be added to USE_EXPAND? One example of something that could be fixed this way is sys-apps/s390-oco (bug #99255). There're various others too, most of which are in the "different upstream-provided binaries for different subarchs" category but there's the odd dep here and there too (e.g. on some multi ABI archs, certain kernel-related packages should dep upon a special compiler). The original idea was that PROFILE_ARCH would get expanded in a special way, like ARCH does, but it never got implemented. Doing things that way could still be an option, but expand seems to be the cleaner solution now. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Ciaran McCreesh wrote: > On Sun, 12 Feb 2006 03:19:25 -0500 Mark Loeser <[EMAIL PROTECTED]> > wrote: > | So, what do we want to do about this? Should we have some repoman > | warning if a USE flag exists in both files, or should it be > | acceptable? > > The whole idea of global USE flags is that they're the same for all > packages that use said flag, and thus do not get a use.local.desc > entry. a global USE flag duplicated in use.local.desc could be used to give specific information about exactly what effect the flag has on a certain package, or if for some reason it does differ slightly from the global meaning. global use flags (searching: doc) [-] doc - Adds extra documentation (API, Javadoc, etc) local use flags (searching: doc) [-] doc (app-examples/fakeapp): Build user manuals in PDF format (requires ps2pdf) it's been mentioned before but i don't think anyone jumped on the idea. i personally don't care either way, just wanted to bring it up while it's on topic. ;P --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
R Hill wrote: > a global USE flag duplicated in use.local.desc could be used to give specific > information about exactly what effect the flag has on a certain package, or if > for some reason it does differ slightly from the global meaning. > > global use flags (searching: doc) > > [-] doc - Adds extra documentation (API, Javadoc, etc) > > local use flags (searching: doc) > > [-] doc (app-examples/fakeapp): > Build user manuals in PDF format (requires ps2pdf) That'd be bad practice. When a new global use flag is made, the requirement is that all local use flags which would get united have *the same meaning*. If the meaning is the same, it doesn't make sense to mention it twice. If the meaning differs (slightly or not), it should get a local use flag. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Eclass for prime numbers
Hello
For an ebuild I'm working on, I need a function to test wether a number
is a prime number. For that, I wrote an Eclass you find attached to this
e-mail. Can this be commited?
Thanks,
Michael
--
Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/
We apologize for the inconvenience, but we'd still like yout to test out
this kernel.
-- Linus Torvalds, announcing another kernel patch
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Original Author: Michael Hanselmann <[EMAIL PROTECTED]>
# Purpose: Functions for prime numbers
ECLASS="prime"
INHERITED="$INHERITED $ECLASS"
EXPORT_FUNCTIONS primes is_prime
# Prints a list of primes between min and max inclusive
#
# Note: this functions gets very slow when used with large numbers.
#
# Syntax: primes
primes() {
local min=${1} max=${2}
local result= primelist=2 i p
[[ ${min} -le 2 ]] && result="${result} 2"
for ((i = 3; i <= max; i += 2))
do
for p in ${primelist}
do
[[ $[i % p] == 0 || $[p * p] -gt ${i} ]] && \
break
done
if [[ $[i % p] != 0 ]]
then
primelist="${primelist} ${i}"
[[ ${i} -ge ${min} ]] && \
result="${result} ${i}"
fi
done
echo ${result}
}
# Checks wether a number is a prime number
#
# Syntax: is_prime
is_prime() {
local number=${1} i
for i in $(primes ${number} ${number})
do
[[ ${i} == ${number} ]] && return 0
done
return 1
}
pgpkYeUBO4UOa.pgp
Description: PGP signature
Re: [gentoo-dev] Eclass for prime numbers
On Sun, 2006-02-12 at 18:22 +0100, Michael Hanselmann wrote: > Hello > > For an ebuild I'm working on, I need a function to test wether a number > is a prime number. For that, I wrote an Eclass you find attached to this > e-mail. Can this be commited? In what range do you need the random numbers? Your implementation uses a naive test that runs in O(n), so any large input will cause it to take excessively long: time primes 100 1000 real0m0.160s time primes 1 10100 real0m7.309s And I guess a 32-bit prime is out of reach :-) -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Eclass for prime numbers
Hello Patrick On Sun, Feb 12, 2006 at 06:42:01PM +0100, Patrick Lauer wrote: > In what range do you need the random numbers? For this ebuild, lower than 1000. > And I guess a 32-bit prime is out of reach :-) Indeed. Greets, Michael -- Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/ Not that I have anything much against redundancy. But I said that already. -- Larry Wall in <[EMAIL PROTECTED]> pgpSEyELjha0X.pgp Description: PGP signature
Re: [gentoo-dev] Eclass for prime numbers
On Sunday 12 February 2006 12:22, Michael Hanselmann wrote: > For an ebuild I'm working on, I need a function to test wether a number > is a prime number. For that, I wrote an Eclass you find attached to this > e-mail. Can this be commited? i cant really see how this would be useful to anything, but i guess you found something :p also, your eclass has bugs, remove these three lines completely: ECLASS="prime" INHERITED="$INHERITED $ECLASS" EXPORT_FUNCTIONS primes is_prime -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Eclass for prime numbers
Michael Hanselmann wrote: >> In what range do you need the random numbers? > > For this ebuild, lower than 1000. > >> And I guess a 32-bit prime is out of reach :-) > > Indeed. So maybe use a precomputed table of primes <1000 ? -- Krzysiek Pawlik key id: 0xBC51 desktop-misc, desktop-dock, x86, java... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Eclass for prime numbers
Hello On Sun, Feb 12, 2006 at 06:22:00PM +0100, Michael Hanselmann wrote: > [prime.eclass] After discussing it with Simon Stelling (blubb), I decided to put the code into the ebuild directly for now. Since this is experimental stuff, that's no problem for now. The code will be moved to an eclass once it's appropriate. Greets, Michael PS: The reason why I never wrote the actual package name is to prevent another MTA flamewar. -- Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/ note to self: do *not* let the soldering iron sit against the power cord. pgpaYpoSjwiH9.pgp Description: PGP signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
On Sun, 12 Feb 2006 17:49:26 +0100 Simon Stelling <[EMAIL PROTECTED]> wrote: > R Hill wrote: > > a global USE flag duplicated in use.local.desc could be used to > > give specific information about exactly what effect the flag has on > > a certain package, or if for some reason it does differ slightly > > from the global meaning. > > > > global use flags (searching: doc) > > > > [-] doc - Adds extra documentation (API, Javadoc, etc) > > > > local use flags (searching: doc) > > > > [-] doc (app-examples/fakeapp): > > Build user manuals in PDF format (requires ps2pdf) > > That'd be bad practice. When a new global use flag is made, the > requirement is that all local use flags which would get united have > *the same meaning*. If the meaning is the same, it doesn't make sense > to mention it twice. If the meaning differs (slightly or not), it > should get a local use flag. IIRC the idea behind duplication was not to use a flag for different purposes, but have a generic description in use.desc (like "doc: build additional docs") and give a more detailed description in use.local.desc (like "doc: build API docs and manual as pdf and html"). See http://thread.gmane.org/gmane.linux.gentoo.portage.devel/618 and http://thread.gmane.org/gmane.linux.gentoo.devel/26035 for the original threads about this. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Eclass for prime numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Feb 2006, Michael Hanselmann wrote: Hello Patrick On Sun, Feb 12, 2006 at 06:42:01PM +0100, Patrick Lauer wrote: In what range do you need the random numbers? For this ebuild, lower than 1000. Um, there are 167 primes smaller that 1000. Why not just build them in? And I guess a 32-bit prime is out of reach :-) Indeed. Greets, Michael -- Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/ Not that I have anything much against redundancy. But I said that already. -- Larry Wall in <[EMAIL PROTECTED]> Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD732hQa6M3+I///cRAnudAKCGKcN1v+EC1eWAL+JDKKcUCKs1qgCfU2Cq MqMhBHNtNsm8xVa7IrMtTlU= =aG5A -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] /etc/rc.conf
Hello all, I believe that rc.conf contains many values that could be put into conf.d. For example, DISPLAYMANAGER and KEYMAP. DISPLAYMANAGER could be put into conf.d/xdm. Then, this variable would not exist with a non-X environment, and configuration could be more modularized. Forrest Voight -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/rc.conf
Forrest Voight wrote: > Hello all, > >I believe that rc.conf contains many values that could be put into > conf.d. For example, DISPLAYMANAGER and KEYMAP. DISPLAYMANAGER could > be put into conf.d/xdm. Then, this variable would not exist with a > non-X environment, and configuration could be more modularized. DISPLAYMANAGER should stay in rc.conf is because XSESSION is in rc.conf, and it doesn't make sense to split them up. XSESSION is unrelated to any service, so there's not really a better place for it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Marius Mauch <[EMAIL PROTECTED]> said: > IIRC the idea behind duplication was not to use a flag for different > purposes, but have a generic description in use.desc (like "doc: build > additional docs") and give a more detailed description in > use.local.desc (like "doc: build API docs and manual as pdf and html"). > See http://thread.gmane.org/gmane.linux.gentoo.portage.devel/618 and > http://thread.gmane.org/gmane.linux.gentoo.devel/26035 for the original > threads about this. In all of the examples I have seen it seems that the "more detailed description" doesn't really give that much more useful information. It just seems to be duplicating the same information in different words. Currently the flags I found in both use.desc and use.local.desc are exact copies, so I will talk to the maintainers for those packages and make sure they are alright with removing their entry. On a more global scale, we should decide if this is valid though. I haven't exactly been convinced that it is useful, but I'm not opposed to the idea. I'd just like to see a decision one way or another. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpdWFbh3JH5A.pgp Description: PGP signature
Re: [gentoo-dev] Find apps not ported to modular X
The last change: 320 to 260, over 5 days -- that's 12 packages a day, which is reasonable. Props to Josh_B, games, desktop-wm and cjk herds for fixing 10+ packages. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060212 Herds and people with 5 or more unported packages, and change in # of packages: 69 games (-20) 51 none (individual or no maintainer) (-6) 28 (no metadata.xml) (-2) 16 desktop-wm (-13) 14 video (-0) 11 cjk (-11) 7 afterstep (-0) 6 sound (-2) 5 common-lisp (-0) --- Total: 207 of 260 unported IRC: #gentoo-x Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, ask in #gentoo-x. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Bugzilla etiquette suggestions
I wrote most of this a while ago but didn't get round to finishing it. This seems appropriate at this time, so here it is :) Here are some small *suggestions* for how I think we can motivate users on Bugzilla to contribute more, and to contribute more often. I'm not suggesting this be enforced as policy, but it would be nice to see other developers giving this some thought. I'm far from perfect here, but I am working on sticking to my own suggestions more and more. Remember that Bugzilla is the only way we communicate with most of our external contributors so it is important to make them feel appreciated and give them a good impression of the Gentoo developer community. 1. Don't bitch at contributors Even if they did something totally wrong, violated all known policies, and you are *sure* they just filed the bug to annoy you, don't write aggressive sounding responses. Reasons being: - You'll reduce the chances they'll think about contributing again in the future - They probably won't listen to a word you say, yet will feel the need to respond - Bugzilla is a public medium, and other potential contributors (who maybe wouldn't have made such 'obvious' mistakes) will be put off when reading the aggressive dialog. (I'm not suggesting that you send abuse privately instead!) - Like we aren't paid to fix bugs, the users aren't paid to file them: at the end of the day, someone went out of his/her way to file the bug, to try and help. 2. Be careful with INVALID resolutions The term invalid _is_ harsh in bugzilla context, so make sure you write a quick thankful-sounding comment to go with it. Maybe we should consider alternatives. I quite like the NOTABUG resolution they have on the GNOME bugzilla. Marking bugs as duplicates is also dodgy ground: Comments like "Please search" can easily be taken the wrong way. I'm probably asking too much for people to spend lots of time thinking up appreciative duplicate messages, however... 3. Always record contributions by name If you commit something in response to a bug report that has been filed, always thank the user by full name (and bug number) in the ChangeLog and commit message. Do the above even if you already knew about the bug (i.e. you would have committed the same fix even if the user hadn't alerted you). This also applies for ebuild requests, ebuild submissions, and version bump requests/submissions. Might sound pointless for 'trivial' reports/requests but it is important to credit the user if they have gone to the trouble of filing a bug. This also applies to contributors who you know well, contributors who you have named times before, and other Gentoo developers too. 4. Give the user a chance to make minor corrections If a user contributes a patch/ebuild which is slightly wrong, and the issue is non-critical, don't immediately correct it on their behalf and commit it to get the bug out of the way. Instead, provide an explanation of their mistake and give the user a day or two to correct it and attach an updated version. This has the bonuses that the user definately won't repeat that mistake in future contributions, and they will have the nice feeling of full credit for the contribution after you name them in the ChangeLog :) If they don't respond in that time, make the correction yourself and commit it anyway. 5. Be thankful when marking FIXED When marking a bug as FIXED, I often forget that the user has tested 4 kernel versions, moved their network card over to another computer, filed an identical bug report upstream, tested the solution, and reported back to me. I think a short note of thanks in the bugzilla comment can go a long way (suggestion: thank them for something in particular so that it doesn't sound so generic). 6. Don't forget about email As a Gentoo developer, you have been automatically granted the ability to sound important and make others feel important too. When Seemant mailed me over 2 years ago, I was a relative idiot and was a new Gentoo user at that time. It felt great to receive a complimentary email from a well-known and respected Gentoo developer, and that email eventually led to me becoming a developer myself (amongst other things!). I've had the same kind of effect on people since then, for example, I sent a very quick "thanks" mail to the guy who authored the wordpress theme I run on my weblog, and he was overjoyed that I was using it - he happened to be a Gentoo user who already read my blog via the Planet site. There probably aren't many situations where you would email a user who communicates with you on bugzilla. But don't forget about this nice ability that we have :) That's all I can think of for now. I'd certainly be interested to hear any comments on the above and similar suggestions that others may have. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
Hi, On Sun, Feb 12, 2006 at 09:11:33PM +, Daniel Drake wrote: > 2. Be careful with INVALID resolutions > > The term invalid _is_ harsh in bugzilla context, so make sure you write > a quick thankful-sounding comment to go with it. > > Maybe we should consider alternatives. I quite like the NOTABUG > resolution they have on the GNOME bugzilla. I second that. I've always missed the not-so-harsh-sounding NOTABUG resolution I used to use so frequently back when I used gnome bugzilla on a daily basis. > 3. Always record contributions by name > > If you commit something in response to a bug report that has been filed, > always thank the user by full name (and bug number) in the ChangeLog and > commit message. > > Do the above even if you already knew about the bug (i.e. you would have > committed the same fix even if the user hadn't alerted you). > > This also applies for ebuild requests, ebuild submissions, and version > bump requests/submissions. Might sound pointless for 'trivial' > reports/requests but it is important to credit the user if they have > gone to the trouble of filing a bug. I don't really get this part. Why should I give credit to someone else for providing a fix for a bug which I already fixed myself locally? Why should I give credit to a user who filed a version bump request two hours after release and more or less doubled my work in actually performing the version bump? I fear the above policy will only lead to more pointless bugs being filed by the rare end-users who seem to like seeing their own name on print... > This also applies to contributors who you know well, contributors who > you have named times before, and other Gentoo developers too. Credit where credit is due, of course. Ebuild submissions, well thought-out and well-tested patches, problem analysis and similar should of course be credited - but to credit each and every user who just happened to be the first to file an enhancement request for version bump? First post, anyone? > 4. Give the user a chance to make minor corrections > > If a user contributes a patch/ebuild which is slightly wrong, and the > issue is non-critical, don't immediately correct it on their behalf and > commit it to get the bug out of the way. > > Instead, provide an explanation of their mistake and give the user a day > or two to correct it and attach an updated version. This has the bonuses > that the user definately won't repeat that mistake in future > contributions, and they will have the nice feeling of full credit for > the contribution after you name them in the ChangeLog :) > > If they don't respond in that time, make the correction yourself and > commit it anyway. This will also double if not tripple my work-load. I understand the motivation for this, but let's face it: developers are here for the fun too - personally I am not here to educate end-users about minor details which they might as well have read up on first by themselves. I know that may sound harsh, it's not meant that way. I just think I have more important things to spend my time on than first writing a small essay on how the user could improve his work, then discuss the details, then realize that I need to put in the changes myself after all since the user didn't respong within a given time period - and last but not least, test and commit the stuff to CVS (Rather than just making the small changes required, test and commit). > 5. Be thankful when marking FIXED > > When marking a bug as FIXED, I often forget that the user has tested 4 > kernel versions, moved their network card over to another computer, > filed an identical bug report upstream, tested the solution, and > reported back to me. > > I think a short note of thanks in the bugzilla comment can go a long way > (suggestion: thank them for something in particular so that it doesn't > sound so generic). Agreed. I always try to remember posting a small thank you note when closing a bug. Often it ends up as a pretty generic note, though. I'll try to improve that :) Just my thoughts on the above. All in all a good summary/reminder about our behavior towards end-users who are being/trying to be helpful. Thank you for taking the time to write it up. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgp6sNqrncoEX.pgp Description: PGP signature
Re: [gentoo-dev] /etc/rc.conf
On Sunday 12 February 2006 14:16, Forrest Voight wrote: >I believe that rc.conf contains many values that could be put into > conf.d. sounds like your system is outdated > For example, DISPLAYMANAGER Donnie already covered this > and KEYMAP. this was moved to /etc/conf.d/keymaps a while ago, you should think about updating -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: > Herds and people with 5 or more unported packages, and change in # of > packages: > > 69 games (-20) > 51 none (individual or no maintainer) (-6) > 28 (no metadata.xml) (-2) > 16 desktop-wm (-13) > 14 video (-0) > 11 cjk (-11) > 7 afterstep (-0) > 6 sound (-2) > 5 common-lisp (-0) > --- Don't want to make them feel left out ... 6 vapier (-0) 6 stuart (-0) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, Feb 12, 2006 at 09:11:33PM +, Daniel Drake wrote: > I wrote most of this a while ago but didn't get round to finishing it. > This seems appropriate at this time, so here it is :) > > Here are some small *suggestions* for how I think we can motivate users > on Bugzilla to contribute more, and to contribute more often. I'm not > suggesting this be enforced as policy, but it would be nice to see other > developers giving this some thought. I'm far from perfect here, but I am > working on sticking to my own suggestions more and more. Agree with and try to follow most of this myself, but I'm hesitant about: > 4. Give the user a chance to make minor corrections > > If a user contributes a patch/ebuild which is slightly wrong, and the > issue is non-critical, don't immediately correct it on their behalf and > commit it to get the bug out of the way. > > Instead, provide an explanation of their mistake and give the user a day > or two to correct it and attach an updated version. This has the bonuses > that the user definately won't repeat that mistake in future > contributions, and they will have the nice feeling of full credit for > the contribution after you name them in the ChangeLog :) > > If they don't respond in that time, make the correction yourself and > commit it anyway. I think this is too much effort, especially for small corrections. I tend to fix them myself, commit with a message like "...based on an ebuild from ... (bug #)" and comment on the bug like "Committed with minor changes". It would probably be a good thing if I went into a bit more detail about what the "minor changes" were and why I made them, I guess :) > I think a short note of thanks in the bugzilla comment can go a long way > (suggestion: thank them for something in particular so that it doesn't > sound so generic). I am extremely bad at the "not sounding generic" bit... :( -- Marien. pgp8ekbbuVh0A.pgp Description: PGP signature
[gentoo-dev] Re: Bugzilla etiquette suggestions
Daniel Drake posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 12 Feb 2006 21:11:33 +: > 2. Be careful with INVALID resolutions > > The term invalid _is_ harsh in bugzilla context, so make sure you write > a quick thankful-sounding comment to go with it. I like all the suggestions, but this one hits a particular sore spot, as I had it happen to me, with I think my second Gentoo bug filing. What made things worse is that the filing was after my arch team had asked for volunteers to perform specific tests (multilib-strict), and I had gone to significant effort to do so, having builds die that would otherwise have completed successfully. As it happens, the bug /was/ valid, and was eventually resolved (impressively quickly, I might add =8^) when I refiled it when the next version came out. I had something inadvised in my CFLAGS that the developer had seized upon as an opportunity to mark the bug invalid and get it out of his way, that in reality had nothing to do with the bug (a 64-bit shared object installed to lib instead of lib64, independent of CFLAGS, inadvised or not). Calling the bug "invalid" can be taken personally as saying the opinion and work that the user put into getting and filing the bug was "invalid", therefore, that the user shouldn't bother spending his time on Gentoo at all, as they don't matter and they and there opinion are "invalid". Consider this: INVALID is strong enough, under the wrong circumstances, that it /could/ set an emotionally unstable user off, causing them to commit suicide or something. I /know/ it was deeply depressing here, that first time, altho the effect on me would have been to simply push me back to Mandrake and cause me to become another anti-Gentoo activist, as I wasn't already suicidal. Some people /might/ be! One never knows the emotional state of someone filing a bug, so consider carefully the effect INVALIDating the bug might possibly have on their entire life. Would /you/ want that on your conscience, that it had been /your/ action, the marking of that one last bug they filed as INVALID, that finally tipped them over? I know I wouldn't! Obviously, I like the idea of NOTABUG better, or consider using WORKSFORME or WONTFIX. Those get the same general message across, without having the implication of INVALIDating the user's bug, possibly/likely conveying the message that they are not welcome as a Gentoo user, or worse yet to someone already unstable, that their whole life is INVALID. Thanks, Daniel! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
Henrik Brix Andersen wrote: 3. Always record contributions by name If you commit something in response to a bug report that has been filed, always thank the user by full name (and bug number) in the ChangeLog and commit message. Do the above even if you already knew about the bug (i.e. you would have committed the same fix even if the user hadn't alerted you). This also applies for ebuild requests, ebuild submissions, and version bump requests/submissions. Might sound pointless for 'trivial' reports/requests but it is important to credit the user if they have gone to the trouble of filing a bug. I don't really get this part. Why should I give credit to someone else for providing a fix for a bug which I already fixed myself locally? Maybe not if you have already done the work. I was thinking more of the scenario, upstream does a release. You are on the mailing list so you know about the new version. You decide you'll bump it in portage tomorrow. Overnight, someone files a request for a version bump. Maybe they attach a new ebuild or state that the existing one needs bumping. Even though you knew about it, I was suggesting that you credit the user for filing the bug. I'm not sure of the best way to handle the situation where the user files a bug that you have already solved locally. Why should I give credit to a user who filed a version bump request two hours after release and more or less doubled my work in actually performing the version bump? I'd say doubling is a bit of an exaggeration, since it really isn't that much work to mark a bug fixed. Not that bumping an ebuild is complicated anyway. The issue I am trying to approach is that the user who filed the bug is likely to check the ChangeLog, and will be mildly upset if they are not mentioned yet it appears that their bug report *may* have triggered the bump. Put another way, what is the harm of putting a name in the ChangeLog when it may motivate that person to contribute more? The "damage" (them filing the bug, when you didn't strictly need it) is already done, and by showing them this kind of respect they hopefully won't repeat their "mistake". Credit where credit is due, of course. Ebuild submissions, well thought-out and well-tested patches, problem analysis and similar should of course be credited - but to credit each and every user who just happened to be the first to file an enhancement request for version bump? First post, anyone? "Gentoo is like a drug" Indeed, if enforced globally then we might end up with a situation like that and something would need to be done. I somehow doubt that would be the case. But people racing to contribute would also have its desirable effects :) 4. Give the user a chance to make minor corrections This will also double if not tripple my work-load. I understand the motivation for this, but let's face it: developers are here for the fun too - personally I am not here to educate end-users about minor details which they might as well have read up on first by themselves. I know that may sound harsh, it's not meant that way. That is a fair point, and if you can't afford to spend the time on it then I'm not complaining. However, there are situations where this can *save* you time. One example that springs to mind: http://bugs.gentoo.org/119178 - I have very little clue about jfsutils - I suck at ebuilds - I know of flag-o-matic's existence but had no clue how to use it It obviously didn't take me much time to add the comments that I wrote there, and it definitely saved me time in solving the bug, and educated me as well. Just my thoughts on the above. All in all a good summary/reminder about our behavior towards end-users who are being/trying to be helpful. Thank you for taking the time to write it up. Thanks for the feedback. Indeed it does have some "perfect world" implications, but I'm not suggesting this should happen every time everywhere. I just think that more consideration in this area would make a real difference. On a similar note, I received a very interesting book as a birthday present last year. It's called "How to win friends and influence people" by Dale Carnegie and can be picked up very cheaply at any decent bookshop. That probably indirectly influenced some of the above - highly recommended for people interested in motivating others. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
Marien Zwart wrote: I think this is too much effort, especially for small corrections. I tend to fix them myself, commit with a message like "...based on an ebuild from ... (bug #)" and comment on the bug like "Committed with minor changes". It would probably be a good thing if I went into a bit more detail about what the "minor changes" were and why I made them, I guess :) Perhaps you could try this a couple of times when the opportunity next arises. If done well, you only need to type a sentence or two if it is just minor issues that need correcting. Also bookmark Ciaran's nice mini FAQ which covers lots of common mistakes: http://dev.gentoo.org/~ciaranm/docs/mw-faq It may feel a little harsh to give someone a canned response just by pasting a URL in the comment field, but curious readers will find his faq.txt which explains nicely that we aren't evil/lazy, we just have a lot of work to do. Thanks Ciaran! I guess the only other downside to this approach is that it delays the fix - instead of fixing it right then, you have to wait for another round of communication to complete before closing the bug. That is undesirable for people with busy schedules. Thanks for the feedback. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/rc.conf
On Sun, 2006-02-12 at 11:38 -0800, Donnie Berkholz wrote: > Forrest Voight wrote: > > Hello all, > > > >I believe that rc.conf contains many values that could be put into > > conf.d. For example, DISPLAYMANAGER and KEYMAP. DISPLAYMANAGER could > > be put into conf.d/xdm. Then, this variable would not exist with a > > non-X environment, and configuration could be more modularized. > > DISPLAYMANAGER should stay in rc.conf is because XSESSION is in rc.conf, > and it doesn't make sense to split them up. XSESSION is unrelated to any > service, so there's not really a better place for it. Isn't XSESSION *only* used by display managers? I know for a fact that it isn't used by "startx" or anything. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
Duncan wrote: 2. Be careful with INVALID resolutions The term invalid _is_ harsh in bugzilla context, so make sure you write a quick thankful-sounding comment to go with it. I like all the suggestions, but this one hits a particular sore spot, as I had it happen to me, with I think my second Gentoo bug filing. I'm glad that you can relate to it - reassures me that I'm not pulling this out of thin air :) > What made things worse is that the filing was after my arch team had asked for volunteers to perform specific tests (multilib-strict), and I had gone to significant effort to do so, having builds die that would otherwise have completed successfully. As it happens, the bug /was/ valid, and was eventually resolved That's another issue which is worth thinking about. I'm just as bad at this myself - if I can close a bug report without doing any work (i.e. the case for most INVALID bugs) then it's almost like a small personal victory. We should also try not to jump the gun so much in this kind of situation. Thanks for the feedback, if bugzilla ever drives you to suicide I will be sure to file a bug report at the official Bugzilla bugzilla so that it can be corrected :) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/rc.conf
Chris Gianelloni wrote: Isn't XSESSION *only* used by display managers? I know for a fact that it isn't used by "startx" or anything. It is used by startx. The following commands have their expected effect: # XSESSION="fluxbox" startx # XSESSION="gnome" startx Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /etc/rc.conf
Chris Gianelloni wrote:
> On Sun, 2006-02-12 at 11:38 -0800, Donnie Berkholz wrote:
>> Forrest Voight wrote:
>>> Hello all,
>>>
>>>I believe that rc.conf contains many values that could be put into
>>> conf.d. For example, DISPLAYMANAGER and KEYMAP. DISPLAYMANAGER could
>>> be put into conf.d/xdm. Then, this variable would not exist with a
>>> non-X environment, and configuration could be more modularized.
>> DISPLAYMANAGER should stay in rc.conf is because XSESSION is in rc.conf,
>> and it doesn't make sense to split them up. XSESSION is unrelated to any
>> service, so there's not really a better place for it.
>
> Isn't XSESSION *only* used by display managers? I know for a fact that
> it isn't used by "startx" or anything.
Do you now? It's used by my startx.
Take a look at /etc/X11/xinit/xinitrc:
# First try ~/.xinitrc
if [ -f "$HOME/.xinitrc" ]; then
XINITRC="$HOME/.xinitrc"
exec /bin/sh "$HOME/.xinitrc"
# If not present, try the system default
elif [ -n "`/etc/X11/chooser.sh`" ]; then
exec "`/etc/X11/chooser.sh`"
in chooser.sh:
# If $XSESSION is "", source first /etc/conf.d/basic, and then /etc/rc.conf
if [ -z "${XSESSION}" ]
then
[ -f /etc/conf.d/basic ] && source /etc/conf.d/basic
[ -f /etc/rc.conf ] && source /etc/rc.conf
fi
# Find a match for $XSESSION in /etc/X11/Sessions
GENTOO_SESSION=""
for x in /etc/X11/Sessions/*
do
if [ "`echo ${x##*/} | awk '{ print toupper($1) }'`" \
= "`echo ${XSESSION} | awk '{ print toupper($1) }'`" ]
then
GENTOO_SESSION=${x}
break
fi
done
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: /etc/rc.conf
I was using an old gentoo system. Forget about KEYMAP.
But, what about UNICODE? That is related to KEYMAP and consolefont.
Shouldn't EDITOR and XSESSION be in a user-specific place?
Forrest
On 2/12/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Chris Gianelloni wrote:
> > On Sun, 2006-02-12 at 11:38 -0800, Donnie Berkholz wrote:
> >> Forrest Voight wrote:
> >>> Hello all,
> >>>
> >>>I believe that rc.conf contains many values that could be put into
> >>> conf.d. For example, DISPLAYMANAGER and KEYMAP. DISPLAYMANAGER could
> >>> be put into conf.d/xdm. Then, this variable would not exist with a
> >>> non-X environment, and configuration could be more modularized.
> >> DISPLAYMANAGER should stay in rc.conf is because XSESSION is in rc.conf,
> >> and it doesn't make sense to split them up. XSESSION is unrelated to any
> >> service, so there's not really a better place for it.
> >
> > Isn't XSESSION *only* used by display managers? I know for a fact that
> > it isn't used by "startx" or anything.
>
> Do you now? It's used by my startx.
>
> Take a look at /etc/X11/xinit/xinitrc:
>
> # First try ~/.xinitrc
> if [ -f "$HOME/.xinitrc" ]; then
> XINITRC="$HOME/.xinitrc"
> exec /bin/sh "$HOME/.xinitrc"
> # If not present, try the system default
> elif [ -n "`/etc/X11/chooser.sh`" ]; then
> exec "`/etc/X11/chooser.sh`"
>
> in chooser.sh:
>
> # If $XSESSION is "", source first /etc/conf.d/basic, and then /etc/rc.conf
> if [ -z "${XSESSION}" ]
> then
> [ -f /etc/conf.d/basic ] && source /etc/conf.d/basic
> [ -f /etc/rc.conf ] && source /etc/rc.conf
> fi
>
> # Find a match for $XSESSION in /etc/X11/Sessions
> GENTOO_SESSION=""
> for x in /etc/X11/Sessions/*
> do
> if [ "`echo ${x##*/} | awk '{ print toupper($1) }'`" \
> = "`echo ${XSESSION} | awk '{ print toupper($1) }'`" ]
> then
> GENTOO_SESSION=${x}
> break
> fi
> done
>
>
>
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
Forrest Voight wrote: > I was using an old gentoo system. Forget about KEYMAP. > But, what about UNICODE? That is related to KEYMAP and consolefont. > Shouldn't EDITOR and XSESSION be in a user-specific place? I guess you didn't really understand the code. They can be in a user-specific place. If ~/.xinitrc exists, then it gets used instead. Other variables can easily be set in one's ~/.bashrc, but generally people want a usable system default as well. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: /etc/rc.conf
Then why can't it be in /etc/skel? On 2/12/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Forrest Voight wrote: > > I was using an old gentoo system. Forget about KEYMAP. > > But, what about UNICODE? That is related to KEYMAP and consolefont. > > Shouldn't EDITOR and XSESSION be in a user-specific place? > > I guess you didn't really understand the code. They can be in a > user-specific place. > > If ~/.xinitrc exists, then it gets used instead. > > Other variables can easily be set in one's ~/.bashrc, but generally > people want a usable system default as well. > > Thanks, > Donnie > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Feb 2006, Daniel Drake wrote: Henrik Brix Andersen wrote: > 3. Always record contributions by name > > If you commit something in response to a bug report that has been filed, > always thank the user by full name (and bug number) in the ChangeLog and > commit message. > > Do the above even if you already knew about the bug (i.e. you would have > committed the same fix even if the user hadn't alerted you). > > This also applies for ebuild requests, ebuild submissions, and version > bump requests/submissions. Might sound pointless for 'trivial' > reports/requests but it is important to credit the user if they have > gone to the trouble of filing a bug. I don't really get this part. Why should I give credit to someone else for providing a fix for a bug which I already fixed myself locally? Maybe not if you have already done the work. I was thinking more of the scenario, upstream does a release. You are on the mailing list so you know about the new version. You decide you'll bump it in portage tomorrow. Well, the user did the work, too, and doesn't know that you did it (if I understand your case correctly). So the user deserves as much credit as you do. (At least, from the user's point of view. Consider, if you don't credit the user, to the user it just looks like you took the fix and called it your own. You know that's not the case, but the user doesn't and likely is justifiably upset.) The issue I am trying to approach is that the user who filed the bug is likely to check the ChangeLog, and will be mildly upset if they are not mentioned yet it appears that their bug report *may* have triggered the bump. By the way, I really like the proposal which triggered this discussion. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD79mAQa6M3+I///cRAlZMAJ9F8sew14KN4jmdqwHHVVFrQcYdnwCeMTcD r9bihtdF/W7cU8bqMy1OEM8= =p+Fd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Sun, 2006-02-12 at 19:56 -0500, Forrest Voight wrote: > On 2/12/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > Forrest Voight wrote: > > > I was using an old gentoo system. Forget about KEYMAP. > > > But, what about UNICODE? That is related to KEYMAP and consolefont. > > > Shouldn't EDITOR and XSESSION be in a user-specific place? > > > > I guess you didn't really understand the code. They can be in a > > user-specific place. > > Then why can't it be in /etc/skel? Changing /etc/skel only affects new users. /etc/rc.conf affects all users that don't override it in their env. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
Edward Catmur wrote: > On Sun, 2006-02-12 at 19:56 -0500, Forrest Voight wrote: >> On 2/12/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: >>> Forrest Voight wrote: I was using an old gentoo system. Forget about KEYMAP. But, what about UNICODE? That is related to KEYMAP and consolefont. Shouldn't EDITOR and XSESSION be in a user-specific place? >>> I guess you didn't really understand the code. They can be in a >>> user-specific place. >> Then why can't it be in /etc/skel? > > Changing /etc/skel only affects new users. /etc/rc.conf affects all > users that don't override it in their env. And even then, it's only copied over when you specify the -m option to useradd. It isn't done by default. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
On Sun, 12 Feb 2006 14:49:55 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: > Marius Mauch <[EMAIL PROTECTED]> said: > > IIRC the idea behind duplication was not to use a flag for different > > purposes, but have a generic description in use.desc (like "doc: > > build additional docs") and give a more detailed description in > > use.local.desc (like "doc: build API docs and manual as pdf and > > html"). See > > http://thread.gmane.org/gmane.linux.gentoo.portage.devel/618 and > > http://thread.gmane.org/gmane.linux.gentoo.devel/26035 for the > > original threads about this. > > In all of the examples I have seen it seems that the "more detailed > description" doesn't really give that much more useful information. > It just seems to be duplicating the same information in different > words. > > Currently the flags I found in both use.desc and use.local.desc are > exact copies, so I will talk to the maintainers for those packages > and make sure they are alright with removing their entry. For the record, I didn't look at the current cases nor do I have a positions for or against the idea, just providing some general background info. > On a more global scale, we should decide if this is valid though. I > haven't exactly been convinced that it is useful, but I'm not opposed > to the idea. I'd just like to see a decision one way or another. Yeah, unfortunately none of the people proposing the idea ever wrote a glep or even filed a bug regarding this (AFAIK), also as the quoted threads show there are a number of possible solutions for this. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Marius Mauch <[EMAIL PROTECTED]> said: > Yeah, unfortunately none of the people proposing the idea ever wrote a > glep or even filed a bug regarding this (AFAIK), also as the quoted > threads show there are a number of possible solutions for this. It doesn't seem that too many people feel strongly in favor of it (judging by responses so far), so why don't we just say that it is invalid until such a time where someone can come up with real-life examples where this would prove to be beneficial. Is this something that repoman could check for (should I file a bug), or just something to keep my eye out for? I don't see this as a groundbreaking change that requires a GLEP or anything, especially since I eliminated most of the duplicates today, after talking with the respective maintainers. There are probably only 3 or 4 left. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgp6bP1klamaJ.pgp Description: PGP signature
[gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Marius Mauch wrote: On Sun, 12 Feb 2006 14:49:55 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: On a more global scale, we should decide if this is valid though. I haven't exactly been convinced that it is useful, but I'm not opposed to the idea. I'd just like to see a decision one way or another. Yeah, unfortunately none of the people proposing the idea ever wrote a glep or even filed a bug regarding this (AFAIK), also as the quoted threads show there are a number of possible solutions for this. TGL did some work on this under bug #84884, though his changes are more invasive than what i had in mind. I don't see the need for portage to dig through use.*desc when euse already works and equery can pretty easily be made to. Anyways I just like anything that makes use.desc more useful than foo - adds support for foo --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
Thank you for taking the time to put preXX doc this mail together. I find it personally inspiring and a reminder to watch how I/we handle bugs which is often easy to overlook. On Sun, 2006-02-12 at 21:11 +, Daniel Drake wrote: > I wrote most of this a while ago but didn't get round to finishing it. > This seems appropriate at this time, so here it is :) > > Here are some small *suggestions* for how I think we can motivate users > on Bugzilla to contribute more, and to contribute more often. I'm not > suggesting this be enforced as policy, but it would be nice to see other > developers giving this some thought. I'm far from perfect here, but I am > working on sticking to my own suggestions more and more. > > Remember that Bugzilla is the only way we communicate with most of our > external contributors so it is important to make them feel appreciated > and give them a good impression of the Gentoo developer community. > > 1. Don't bitch at contributors > > Even if they did something totally wrong, violated all known policies, > and you are *sure* they just filed the bug to annoy you, don't write > aggressive sounding responses. > > Reasons being: > - You'll reduce the chances they'll think about contributing again in > the future > - They probably won't listen to a word you say, yet will feel the need > to respond > - Bugzilla is a public medium, and other potential contributors (who > maybe wouldn't have made such 'obvious' mistakes) will be put off when > reading the aggressive dialog. > (I'm not suggesting that you send abuse privately instead!) > - Like we aren't paid to fix bugs, the users aren't paid to file them: > at the end of the day, someone went out of his/her way to file the bug, > to try and help. > > 2. Be careful with INVALID resolutions > > The term invalid _is_ harsh in bugzilla context, so make sure you write > a quick thankful-sounding comment to go with it. > > Maybe we should consider alternatives. I quite like the NOTABUG > resolution they have on the GNOME bugzilla. > > Marking bugs as duplicates is also dodgy ground: Comments like "Please > search" can easily be taken the wrong way. I'm probably asking too much > for people to spend lots of time thinking up appreciative duplicate > messages, however... > > 3. Always record contributions by name > > If you commit something in response to a bug report that has been filed, > always thank the user by full name (and bug number) in the ChangeLog and > commit message. > > Do the above even if you already knew about the bug (i.e. you would have > committed the same fix even if the user hadn't alerted you). > > This also applies for ebuild requests, ebuild submissions, and version > bump requests/submissions. Might sound pointless for 'trivial' > reports/requests but it is important to credit the user if they have > gone to the trouble of filing a bug. > > This also applies to contributors who you know well, contributors who > you have named times before, and other Gentoo developers too. > > 4. Give the user a chance to make minor corrections > > If a user contributes a patch/ebuild which is slightly wrong, and the > issue is non-critical, don't immediately correct it on their behalf and > commit it to get the bug out of the way. > > Instead, provide an explanation of their mistake and give the user a day > or two to correct it and attach an updated version. This has the bonuses > that the user definately won't repeat that mistake in future > contributions, and they will have the nice feeling of full credit for > the contribution after you name them in the ChangeLog :) > > If they don't respond in that time, make the correction yourself and > commit it anyway. > > 5. Be thankful when marking FIXED > > When marking a bug as FIXED, I often forget that the user has tested 4 > kernel versions, moved their network card over to another computer, > filed an identical bug report upstream, tested the solution, and > reported back to me. > > I think a short note of thanks in the bugzilla comment can go a long way > (suggestion: thank them for something in particular so that it doesn't > sound so generic). > > 6. Don't forget about email > > As a Gentoo developer, you have been automatically granted the ability > to sound important and make others feel important too. > > When Seemant mailed me over 2 years ago, I was a relative idiot and was > a new Gentoo user at that time. It felt great to receive a complimentary > email from a well-known and respected Gentoo developer, and that email > eventually led to me becoming a developer myself (amongst other things!). > > I've had the same kind of effect on people since then, for example, I > sent a very quick "thanks" mail to the guy who authored the wordpress > theme I run on my weblog, and he was overjoyed that I was using it - he > happened to be a Gentoo user who already read my blog via the Planet site. > > There proba
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
R Hill <[EMAIL PROTECTED]> said: > Anyways I just like anything that makes use.desc more useful than > > foo - adds support for foo That's really a completely separate issue. By allowing duplicate entries we just allow people to put useless information in two places instead of one. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpbhl8GXhU3b.pgp Description: PGP signature
[gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Mark Loeser wrote: R Hill <[EMAIL PROTECTED]> said: Anyways I just like anything that makes use.desc more useful than foo - adds support for foo That's really a completely separate issue. By allowing duplicate entries we just allow people to put useless information in two places instead of one. Alright then. Seems reasonable by me. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
On Sun, 12 Feb 2006 22:19:29 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: | I don't see this as a groundbreaking change that requires a GLEP or | anything, especially since I eliminated most of the duplicates today, | after talking with the respective maintainers. There are probably | only 3 or 4 left. The original "someone should GLEP this" was on adding extended USE flag descriptions to metadata.xml. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
