Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 5 Nov 2005, Ciaran McCreesh wrote: On Sat, 05 Nov 2005 11:28:33 +0100 Grobian <[EMAIL PROTECTED]> wrote: | > Preemptive | > Users should be told of changes *before* they break the user's | > system, after the damage has already been done. | | style suggestion for unambigous interpretation: | perhaps a "because if applied afterwards" instead of "after" Ugh. Wonder how many comments I'm going to get on that one... There should be a "not" before "system", which I accidentally killed by pressing the wrong key in Vim. I can't resist. I think you mean '"not" after "system,"': "...*before* they break the user's system, not after " Regards, - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (sparc, devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDbPLTQa6M3+I///cRAsAhAKDgotmZ+E9TMdLAgzUbVj8s3++mVwCfeVoj 9TSuRiLKvIofQFPp/RRrC4I= =1MKl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: ABI breakage
On Mon, 2005-12-05 at 11:36 -0800, Donnie Berkholz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > > With 7.0rc3 that's been entering the tree last weekend, there was an ABI > change in libdrm and subsequent bump from .so.1 to .so.2. > > This means you'll need to run revdep-rebuild after upgrading, otherwise > you'll get problems from 3D just not working to packages being unable to > find libGL. > If you make sure to re-emerge mesa immediately after the libdrm upgrade, the revdep-rebuild is much less intimidating. > Thanks, > Donnie Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Annoying X.Org tarball naming (and how to deal with it)
On Wed, 2005-12-21 at 21:34 -0800, Donnie Berkholz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'd appreciate some ideas better than what I've come up with so far to > deal with the very strange X.Org release naming. > > When modular tarballs are part of a full X.Org release (7.0, 7.1, etc), > then they are named PN-PV-XORG_RELEASE.tar.(gz|bz2) and S matches. When > modular tarballs are independently released outside a full X.Org > release, they are named the standard way -- PN-PV.tar.(gz|bz2), same for S. > > Dealing with this all in an automated fashion in x-modular.eclass is > somewhat difficult, and here's what I've come up with: > > A variable (XORG_PV), set by the ebuild, to tell _which_ release it's > part of when it is part of a full release. If it's set, that means (1) > it is part of a full release and (2) indicates which release it's part of. > > What does this mean for the future? All modular X ebuilds that are part > of a full release will require XORG_PV to be set. All modular X ebuilds > that aren't part of a full release will not require anything new. I'm > doing it this way because I expect there to be more packages that aren't > part of a full release than ones that are. > > Please give me your input on this. Seems fine to me. I hope you are right in your assumption about packages in full releases. > > Thanks, > Donnie > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQFDqjr2XVaO67S1rtsRAhlPAKCMvjj82U6sNPpVYsUOnKOsRwAF4QCgibKM > Ccs1TnSQbXI66BVpf4P8Ed4= > =NFr1 > -END PGP SIGNATURE- -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC --- Thoughts on devrel bug content
The attached note in form of RFC contains some thoughts on how to make a
devrel bug reporting inappropriate behavior more effective. The
original has been reviewed by the people most immediately involved in
processing such bugs (devrel, qa, ombudsman), and the attached version
incorporates improvements suggested by ferringb, kingtaco, and
plasmaroo. I am now distributing it to the gentoo-dev community for
comments and for consideration when submitting new bug reports against
personnel.
The reason for the RFC is that recently there have been several new
developer bug reports submitted, and some of them are hard to interpret
and process correctly because of incomplete context. The theme of the
RFC is that a report of a misbehaving developer is similar to a report
of a misbehaving package, and should contain analogous information. The
RFC itself is much less pretentious than this introduction.
The RFC is also available on-line at
http://dev.gentoo.org/~fmccor/devrel/DevrelBug.rfc.txt --- if you wish
to compare, the original version is present in the ~fmccor/devrel
directory too.
Regards,
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Sparc, Devrel)
THOUGHTS ON EFFECTIVE DEVREL PERSONNEL BUGS
== = == =
I. BACKGROUND
A bug reporting some developer's inappropriate behavior is similar to a
bug reporting some package's inappropriate behavior. And for devrel to
process such a personnel bug effectively and correctly, we need as much
context information as posible, just as the package maintainer needs as much
information as possible to process a failure report.
("fmccor is a disrespectful and incompetent developer" is as hard to do much
with as is "gcc is broken because it won't compile any of my programs".)
However, now that I have had time to gain some experience reviewing
devrel personnel bugs, I can say that this background information is sometimes
missing. Because of this, we (devrel) can miss the point of the report,
misclassify it, underreact (leading to "devrel never does anything"), or
overreact (leading to "devrel is just looking for reasons to hammer me").
This is frustrating, it slows the process, and it works to no one's benefit.
Consequently, here are some thoughts about information to include in a
bug reporting a misbehaving developer.
II. CONTENT
Generally, conform to the analogy to a product bug, or consider the form
of a legal brief for that matter. In some rational order (not fixed, but
perhaps depending on the bug), some or all of the following information can be
useful.
A. Brief (one or two sentence) summary of what the bug is about. If
possible, use the Bugzilla Summary field for this.
B. "Jurisdiction" --- why this is something for devrel to consider (policy
violation or whatever). This is a categorization of the report, not an
argument why it is valid. (This could be handled by a predefined set of
reasons by an existing Bugzilla field similar to "Component," but currently
it is not.)
C. What happened --- what specifically you are reporting. This is a
recounting of the incident(s) triggering the report. It should include
context and background information, as explicit as possible description of the
problem, and generally what you believe to be relevant. If you are reporting
a specific instance of a pattern of inappropriate behavior, this would be a
good place to mention it.
D. Why devrel cares. Not every infraction is worth pursuing. If you have
specific reasons for why this particular instance should be processed, make
the case for it here. This is another good place to talk about things like
patterns, why this bug reports an especially egregious violation, and such
like.
E. What you have done to solve the problem. For example, have you spoken
directly to the developer whose behavior you are reporting, have you spoken
with the appropriate top level project leads, have you spoken with an
ombudsman, and so on. It is important that we know what you have already done
in order for us to proceed most effectively.
F. What devrel should do. If you are reporting a bug against a developer,
you want something to happen. Give us a clue what you have in mind.
Examples: (1) Nothing --- just establish a tracker for this developer because
you think this is part of an emerging pattern; (2) Issue a warning; (3) Issue
a "cease and desist" note (like an injuction) violation of which will result
in more serious consequences; (4) Suspend the developer (or perhaps some of
the developer's access privileges); (5) Terminate the developer.
If you provide guidance here, please be aware of devrel policy, as explained
at http://www.gentoo.org/proj/en/devrel/policy.xml --- unless there is history
or evid
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Lisa Seelye wrote:
On Wed, 2006-01-11 at 14:51 -0800, Robin H. Johnson wrote:
I've been cleaning up media-fonts/ to work with modular-X, and I see a
lot of ebuilds with stuff like this:
for font in *.bdf; do
/usr/X11R6/bin/bdftopcf ${font} > `basename $font .bdf`.pcf
done
gzip *.pcf
For having 100 files in *bdf, this is so serial it's painful.
And here I was hoping Distcc would get some usage. :(
Distcc gets lots of usage with modular X. But for the fonts? :)
--
Regards,
Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (sparc, devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDxaBWQa6M3+I///cRAv/UAKCmOh2vFoZoAstFIOoynlYk5IhdFQCgntpt
XYfbsIWLAmbdu38ksgKdmP4=
=YDDI
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC --- Thoughts on devrel bug content
On Wed, 2006-01-11 at 14:08 -0700, Duncan wrote: > Ferris McCormick posted > <[EMAIL PROTECTED]>, excerpted below, on > Wed, 11 Jan 2006 19:04:19 +: > > > B. "Jurisdiction" --- why this is something for devrel to consider (policy > > violation or whatever). This is a categorization of the report, not an > > argument why it is valid. (This could be handled by a predefined set of > > reasons by an existing Bugzilla field similar to "Component," but > > currently it is not.) > > An enumeration or list of examples would be rather helpful, here. Since > you say it could be a predefined list, enumerating it in the RFC, or at > least giving a couple examples, shouldn't be unreasonable. Keep in mind > that it's possible/likely the filer will have never filed something like > this before, so the vague guideline as stated simply isn't all that much > help. You want it concrete, make it so. > This is a reasonable request, but I don't have such a list right now. Here are some annotated examples of the sorts of things devrel is interested in, so you can use these as guides: 1. Abusive behavior, IRC. (Recurring abusive behavior) 2. Abusive behavior, email. 3. Abusive/inappropriate responses on normal bug reports. 4. Abusive behavior, forums. (The forum moderators almost always handle this sort of problem pretty quickly.) 5. Other etiquette violation, IRC. (Recurring violation of a #gentoo IRC channel's etiquette policy, not covered by abusive behavior. If you wish to report such a violation, please keep language and cultural differences in mind.) 6. IRC policy violation (abuse of operator status in violation of policy on particular channel). 7. Disruptive behavior, IRC (Well, maybe. An example might be a running feud between two developers where the participants don't mind, but the cumulative effect is to make the channel unusable for others.) 8. QA dispute between developers. (One developer (or user) believes another has violated policy, and they cannot resolve their differences by normal means (discussion, appeal to project lead, etc.)) 9. QA violation, reported by QA. (QA believes developer has seriously violated policy but cannot resolve the issue with the developer directly.) This list is not necessarily complete, nor is everything on the list necessarily appropriate for reporting to devrel. But it should give some idea of the sorts of things that are helpful for briefly explaining why devrel has jurisdiction and to give a clue how the reporter wants the bug to be processed. > Otherwise... unpleasant subject matter, but I'm glad someone's dealing > with it. The rest seems reasonable enough. > > -- > 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 > > -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some LaTeX news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 14 Jan 2006, Alexandre Buisse wrote: Hi, for all of you who have been using latex on gentoo, here are some news on what is currently happening. First of all, we have a new tetex (tetex-3.0_p1). It should have hit the mirrors this morning. This is not an official release from upstream (that would be 3.1) but a snapshot of their development tree that corrects some bugs with the autotools (see bug #113024). If we manage to solve the etex related problems (all the "Fatal error: I'm stymied"), it could be a good candidate for stabilisation. Actually, it installed on a couple of my systems last night. I haven't had a chance to give it much of a workout yet, though. A very exciting package has been added to portage lately, but it's still quite experimental : dev-tex/mpm (only keyworded ~x86 and hard-masked at the moment). It's basically the MikTeX package manager adapted for unix systems. As the texmf tree is always organized in the same way, it can interact with tetex quite nicely. Basically, you tell it which package you want from CTAN and it installs it automatically. It has so far been tested by a few people, including me, and seems to work fine without corrupting anything. However, it needs a lot more testing before even going to ~arch. Please report bugs or success in bug #110494 if you give it a try. Thanks for the information. I use LaTeX quite a bit, and I'll play with mpm on sparc sometime in the next few days. If it works OK, I'll give it a ~sparc keyword unless someone beats me to it. And, last but not least, a LaTeX doc began. It's still a very early draft but any (constructive) criticism and help is most welcome. The discussion happens in bug #118405 and the last draft can be found on my devpage (http://dev.gentoo.org/~nattfodd). Looks good so far. Regards, Alexandre Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (sparc, devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyQiQQa6M3+I///cRAn1ZAKDJUHiEL82h0VaPtG4DPPcWfLJsMACffplD lIMlIDjwJKld2Q6yZFtzVyY= =8Bds -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
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
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: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 4 Mar 2006, MIkey wrote: Stuart Herbert wrote: Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. Amen. I use FEATURES="noinfo noman nodoc" and USE="-doc" on all of my server installs. My only desire is that there would be a way to turn them off more completely - no texinfo, no perl man page generation, etc... I would also like to have them excluded from binary packages. That can't be right can it? You mean, like openoffice-bin, or like the ones you build yourself? I know that I often build on one system, install on several, and when I do that, I really want them to be identical. I think if you have your no-docs-of-any-kind option, you get your wish as to locally built packages, but if you really mean things like openoffice-bin, I doubt that any openoffice user would want it with absolutely no documentation. Confused, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFECcg1Qa6M3+I///cRAisAAKCnE4JMHq+wze8+Ghy6MEUtEyWqYACgqF1e xy3lX0ZeBC6D5GraVIXbM0E= =c9G5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 4 Mar 2006, MIkey wrote: Ferris McCormick wrote: I would also like to have them excluded from binary packages. That can't be right can it? You mean, like openoffice-bin, or like the ones you build yourself? I know that I often build on one system, install on several, and when I do that, I really want them to be identical. I think if you have your no-docs-of-any-kind option, you get your wish as to locally built packages, but if you really mean things like openoffice-bin, I doubt that any openoffice user would want it with absolutely no documentation. Yes, if I say -doc or specify FEATURES="nodoc", I don't want the docs in there, binary package or not. I want the behavior and results to be consistent. I am not talking about things like the internal openoffice help documentation, I am talking about anything that goes into /usr/share/doc, man pages, and info pages. I misinterpreted what you wrote. I thought you meant "physically included in the package," not "installed from a binary package." I just completely read what looks like a reasonable request and turned it into nonsense without thinking about it, I guess. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFECeluQa6M3+I///cRArbCAKChFkOo8JVxW8eFbjh5++Jk387omQCcDZRR sofHhKeCBKhJuG3d60ZtyLo= =XCXt -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 4 Mar 2006, MIkey wrote: Ferris McCormick wrote: I misinterpreted what you wrote. I thought you meant "physically included in the package," not "installed from a binary package." I just completely read what looks like a reasonable request and turned it into nonsense without thinking about it, I guess. I am not so sure you misinterpreted me, because when I specify -doc and emerge -B a package, I don't want docs installed OR in the binary package that is generated. I want the behavior of USE flags to be consistent. If I set -ssl and generate a binary package for apache2, the packaged up libraries should not link with ssl libraries. The same should apply with -doc. That happens now, I believe. The following should all install the same thing: USE='-doc' emergeblah USE='-doc' emerge -b blah USE='-doc' emerge -B blah ; emerge -k blah USE='-doc' emerge blah; quickpkg blah; emerge -C blah; emerge -k blah Assuming all dependencies are satisfied. (The binary package is built from the image which is going to be installed and carries the USE flags with it. If the docs aren't there, they're not there. Or at least, the binary package carries the '-doc' use flag along with it so the docs won't be installed.) What won't install the same is this sequence: USE='doc' emerge -B blah USE='-doc' emerge -k blah 'emerge -k' uses the USE flags the package was built with. Example: Back to ciaranm's original proposal. If I USE='-doc' emerge -B xorg-x11 I am never going to be able to decide I wanted USE='doc' after all and pull the docs from the binary package. Documentation for xorg-x11 is in a separate source file, and with USE='-doc', that file is never even fetched. So, USE='doc' emerge -k xorg-x11 cannot install docs. Concrete example (from a live system): emerge -pkv rubygems [binary R ] dev-ruby/rubygems-0.8.11 USE="-examples" USE='examples' emerge -pkv rubygems [binary R ] dev-ruby/rubygems-0.8.11 USE="-examples" Or am I still missing something? What I would really like is the same capability with info and man pages. Currently the only way to exclude them is use the unsupported, undocumented FEATURES="noman noinfo" hack, which if I am not mistaken does not remove them from binary packages. Try a du -ksh /usr/share/doc /usr/share/man /usr/share/info and you might get an idea of why the feature might be desirable: 132M /usr/share/doc 5.7M/usr/share/info 56M /usr/share/man Most of those are compressed, which means they take even _more_ space in a binary package. It adds up. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFECfz8Qa6M3+I///cRAnqrAKDj5ZhOlKKt5MWnqpEZlReUad8CnwCfQDbu vAQJZ2Lzi8hnOqLMfL8Rc68= =48Q+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 5 Mar 2006, MIkey wrote: Mike Frysinger wrote: Heh heh, same place as FEATURES="noinfo noman nodoc" ;) not really ... those are documented in make.conf -mike I have a nasty habit of always looking at make.conf.example instead of the man page. Plus, er, uh, I used FEATURES="noman" ;) Yeah, thats my story and I'm sticking to it. Regardless, I would rather see noman/nodoc/noinfo implemented in USE flags, so they can be applied package by package, implemented perhaps in something like dodoc/doman/doinfo/dohtml. In some cases I might actually want documentation for specific packages... I hesitate to raise my head again, but why not use FEATURES='-noman' emerge ... (FEATURES='-noman -noinfo -nodoc' USE='doc' emerge ... for that matter.)? I use that sort of thing for, say, FEATURES='-distcc ccache' MAKEOPTS='-j2'emerge ... on some specific occasions, and it does what it looks like it should do. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEC2IcQa6M3+I///cRAqknAKCLiN6lc6CjIJ+O1/0cMZk7epCxUwCeP8jf GXLqlvnzw9c10IK5vtUNnto= =bUOU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 3 Apr 2006, Stuart Herbert wrote: On 4/3/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: i dont see how anyone can be against this (unless you're a terrorist!), so this is on track to be integrated as-is into the dev handbook Etiquette section Great idea! Thanks. Let's go one step further, and also link to it from the Social Contract. Our social contract shouldn't just be between Gentoo and our users. It should be amongst ourselves too. Agreed; if it isn't, it should be. Best regards, Stu -- gentoo-dev@gentoo.org mailing list Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFEMa8iQa6M3+I///cRApdNAKDQdMVanpvYqte2NFBGXCmlUBwOjgCgw9+z tkNPo/cyj4rrP8tDK+T/GIA= =q6Mo -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 3 Apr 2006, Stuart Herbert wrote: On 4/3/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: i dont see how anyone can be against this (unless you're a terrorist!), so this is on track to be integrated as-is into the dev handbook Etiquette section Let's go one step further, and also link to it from the Social Contract. Our social contract shouldn't just be between Gentoo and our users. It should be amongst ourselves too. Best regards, Stu -- gentoo-dev@gentoo.org mailing list I have replied elsewhere that I generally like this and agree with Stuart. Now, there are some details to fill in. Devrel and infra have agreed that when responsibilities overlap, neither group would act unilaterally. Please see http://dev.gentoo.org/~fmccor/devrel/devrel-infra.txt (esp. section II.) So, unless Mike's intent is to repudiate what I believe we agreed to, you would have to read solar's document and the one I just referenced together, so the fifth paragraph needs clarification. As for the proxy comment, as has been noted elsewhere, whenever I or anyone else commit something to the tree, it is very hard for anyone to tell if I am doing it for someone else or not. So, say, it might look unusual when I make a substantative change rather than an arch change for something in dev-ruby, it has happened (at a ruby developer's request). (I'm a sparc/devrel developer, not a package developer for those puzzled by this.) So I am not sure of the proxy comment's practical effect. I still think the intent is good and support it. Regards, - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFEMbe/Qa6M3+I///cRArEWAJ9Yu6xRuDTpvG8oKDAu3zEv0lUeQQCgrf9Y qBPlpULGDpMEguWB85XO+EU= =Mhtu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] xorg-x11 and local (RgbPath) rgb.txt database files [informal survey]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For xorg-x11 (X11R6) users only, If you specify a local rgb database in your xorg.conf RgbPath entry, I'd be interested in hearing about it. Also, why you need it would be interesting and useful information: For example, "My users and I prefer 'jaune' to 'yellow'," "I need more (or different)" color names than rgb.txt supplies," and so on. If this question means anything to you, you may use https://bugs.gentoo.org/show_bug.cgi?id=130003 as background (or comment on the bug, for that matter). If the question doesn't mean anything to you, or if you use the default rgb.txt, no response needed. Thanks, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFEQjq3Qa6M3+I///cRAt2AAKDm9rljAy6nFxqGM58TWqAu0y/MXgCgoC5G sxV0TahcpQhxU6z9SRef2dQ= =Fcm1 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have not read this carefully. There is a lot to work through. At first reading, I like it a lot. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFEbxbHQa6M3+I///cRAo9yAJsEF/hxaLrztTnBlNH6I2ZE/pR5hACghqhY DUyfxAlIDVdWBU70tre3nYg= =tvyX -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Glep 49 (g2boojum's version)
Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement that any alternative package manager support any ebuild which portage supports seems essential, except for a boundary case. What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as well? In a case like this, it seems to me that the ebuild works because of a bug in portage, and there should be no complaint if as a side effect of fixing this bug the ebuild in question quit working. If memory serves me, things like this have indeed happened. I can't recall a specific, however. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Herds suck, fix them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 17 Jun 2006, Carsten Lohrke wrote: On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote: How exactly does one go about maintaining our developers? ;) It's devrel's cursed job. Ask them. :) Carsten Um, whips and chains. But we're nice about it. :) Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFElAsdQa6M3+I///cRAkw9AKCuLkwdVENA8Hy++xBOS76PLGPXywCfW977 N0yvQEPZNYLlpqlau54M18c= =lWhc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: Fw: [gentoo-dev] Gentoo Enterprise 10000 support and developer access
> Date: Sat, 22 Mar 2008 13:33:14 -0400 > From: Mike Spenard <[EMAIL PROTECTED]> > To: gentoo-dev@lists.gentoo.org > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: [gentoo-dev] Gentoo Enterprise 1 support and developer > access > > > Raúl-Ferris, > This past week I made an e10k I own/operate accessible [i.e. the SSP] > to Mark Kettenis the OpenBSD-sparc maintainer. And Mark added > support for the Sun Enterprise 1 (SMP and e10k RTC support). Theo > thought it was very beneficial as a few bugs effecting other > systems were picked up in the process. > > I thought I would extend the opportunity to the Gentoo-sparc team. > > Mike Spenard > - -- > gentoo-dev@lists.gentoo.org mailing list Mike, Thanks for the offer. Currently, we do have access to a system at OSL for sparc development and probably do not need access to yours. However, I am making sure that everyone on the sparc team sees that your system is available in case any individual can use your specific configuration. We ourselves really do very little kernel work and probably cannot use it for that. It is possible, though, that your system can be useful when we find issues which are system-specific, in which case you can expect to hear from us further. I do not know how you use your system or what operating system you usually have running on it. If you happen to run Gentoo/linux on it and wish to become involved in our sparc project, I invite you to read about the Architecture Testing program at http://www.gentoo.org/proj/en/base/sparc/at/index.xml and consider if you are interested in that. Thangs again, and Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer : Markus Duft (mduft)
On Wed, 2008-04-30 at 11:12 -0400, Jim Ramsay wrote: > "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > > Please everybody, give a very warm welcome to mduft. > > Lay on, mduft, > And damn'd be him that first cries, 'Hold, enough!' > > Exeunt, fighting. > Nice. I wish I'd thought of that. :) -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
(I'll Try again, from correct email address) On Thu, 2008-05-01 at 05:30 +, Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. > Just to summarize, for purposes of informing everyone of something I've already requested. Recently we retired 3 developers, the devrel project was not involved as a group except for the lead, and apparently the developers did not know anyone was looking at complaints filed against them. I'd like Council (1) to explain its role in this, if any, (2) explain why it permits such actions in apparent violation of Gentoo's policy of openness, (3) and since there seems to be some confusion (on my part at least) how to interpret Council's role in any appeal IF (I don't really know) Council played a part in the disciplinary action, please amend Council's enabling document GLEP 39 to explain how Council handles appeals and whether or not Council can take or direct disciplinary action in light of this absolute requirement. Since this is a general mailing list and some of you might not know what I'm talking about, this is GLEP 39 and as such it helps define Gentoo policy and procedure. http://www.gentoo.org/proj/en/glep/glep-0039.html > Keep in mind that every GLEP *re*submission to the council for review > must first be sent to the gentoo-dev mailing list 7 days (minimum) > before being submitted as an agenda item which itself occurs 7 days > before the meeting. Simply put, the gentoo-dev mailing list must be > notified at least 14 days before the meeting itself. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Bug wrangling
On Mon, 2008-05-12 at 10:20 +0200, Christian Faulhammer wrote: > Hi, > > please be careful when assigning new bugs. Today I changed several > bugs where the wrong maintainer was used or where the main maintainer > has been forgotten. This only occured since we have no full-time > bug-wrangler anymore. Was anyone successful to contact him, yet? > > V-Li I am told he should be back sometime soon, like today. Apparently someone is in contact with him. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Nominations for council
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think nominations are open. I nominate rane welp zlin I think I've spelt all of them correctly and that all three are are qualified. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhE3DgACgkQQa6M3+I///fA5QCeKT8wwL/+pHhjkh5IJEamQhg3 3M0AoI89cmRHncsEHPArJ219UJrUwT4d =VAHg -END PGP SIGNATURE-
[gentoo-dev] Nominations open for the Gentoo Council 2008/2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll try again. :) I nominate rane welp zlin Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhIIyMACgkQQa6M3+I///fb8wCg3rF3Nxt2FFmkZsxayZcCdMOF Y0QAoLZ8Dp8e1toTjAqL9uqBnOtQK8k5 =gKUy -END PGP SIGNATURE- éí¢^¾X¬¶È Ú(¢¸&j)b b²
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jun 2008 12:44:19 +0200 Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 05-06-2008 02:35:16 -0700, Josh Saddler wrote: > > Now that nominations are officially open, I nominate the current council > > members (again): > > I nominate: > > dertobi123 > fmccor > > OK, I'll accept, if only because I think generally people who are nominated should accept. > -- > Fabian Groffen > Gentoo on a different level > -- > gentoo-dev@lists.gentoo.org mailing list > Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhII+QACgkQQa6M3+I///dZLQCfbst4emnsbarb2ovS4j90XXqj AZUAoJ1P8vQzSeAR4vsEtlMWi1LCRF14 =sOBA -END PGP SIGNATURE- éí¢^¾X¬¶È Ú(¢¸&j)b b²
[gentoo-dev] Spam to see if signature is OK now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhIL8AACgkQQa6M3+I///fT5QCg0w1bPOUu5cfSrvtVxHjAiBQa dPgAn3b6CwChKCzpH8uzuXl/XGz+mHrL =qQD4 -END PGP SIGNATURE-
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
the above and anything else they want to say to the > electorate will have a hard time convincing me that they have the time/ > interest to undertake the duties of a council member. > > I look forward to seeing links to your manifestos on > http://www.gentoo.org/proj/en/council/voting-logs/council-2008- > nominees.xml > > I'll provide a link in the next week or so. Most likely to a link to a text file in d.g.o/~fmccor/ > - -- > Regards, > > Roy Bamford > (NeddySeagoon) a member of > gentoo-ops > forum-mods > treecleaners > trustees > > For the avoidance of doubt, I write as an individual developer and not > on behalf of any project I may be a member of. > -----BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkhIMYQACgkQTE4/y7nJvasByACg24Z2Qw4OPMbLPAGwoRAG/8hG > rswAn3E/B28l95e2rHTbnHX8SKgWfVM1 > =yVuz > -END PGP SIGNATURE- > > -- > gentoo-dev@lists.gentoo.org mailing list > Hope this helps, Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhIlNkACgkQQa6M3+I///eyggCeJFr83dO741dhyqHPDFrOH4Re ERkAoIuTKJBhAPzP0oVhR2X8ldCzeN1U =HFe9 -END PGP SIGNATURE-
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
After having written this, I realized I might be telegraphing a bit too much in places. So take the amplifications for what they are worth. They are more "lawyer like" than my original response, but I don't see how to put them into a manifesto. On Fri, 2008-06-06 at 01:37 +, Ferris McCormick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 05 Jun 2008 19:33:34 +0100 > Roy Bamford <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 2008.06.05 01:00, Łukasz Damentko wrote: > > > Hi guys, > > > > > > Nominations for the Gentoo Council 2008/2009 are open now and will be > > > open for the next two weeks (until 23:59 UTC, 18/06/2008). > > > > Team, > > > > I don't want to nominate anyone who hasn't been nominated already. > > I would like to address all the candidates who have or will accept > > council nominations. > > > > 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider > > it broken) > > > Mostly it's not broken. However, I think the intent of the rule > "If any meeting has less than 50% attendance by council members,..." > is to prevent the council from meeting without a quorum. If at a > meeting they don't have a quorum and thus don't meet, I'd consider that > to be a non-meeting and treat those who did not make it just as "absent" > under normal meeting rules. > And the bit about hearing appeals assumes that devrel initiated the disciplinary action being appealed. I'd make it explicit that Council is not itself a disciplinary body --- resolving conflicts is what devrel is for among other things. > > 2. As one of the first priorities will be setting policy for pending > > appeals what policy do you propose ? > > > Any developer making an appeal would explain why the appeal should be > successful using any information he chooses, then Council would decide > (deny, grant on the merits, grant on procedural grounds, whatever). > I'd also add two new requirements: > 1. Any appeal must be heard and decided within xxx days; > 2. Any Council member who is on record as to the merits of the action > being appealed could not take part in the appeal process unless the > developer making the appeal allows it. Probably this would mean a > discussion between that developer and the Council. > Of course Council members have opinions of devrel actions, but I think > it creates a potential conflict of interest if they broadcast them. Plus a few more: 3. When I say "explains" I mean publicly on IRC; 4. And the explanation is a dialogue --- people may ask questions of each other, request further information, and so on. 5. Procedural grounds refers to failure to follow procedure, not letting the developer appealing know what he's done to merit the discipline, not giving the developer an opportunity to respond, and such like. 6. I don't see much merit in giving devrel a role in the appeal. Whatever they have done should already have been documented. However in any specific appeal, Council should have the option to involve devrel. > > 3. If you are not on the council already, how will you make time for > > the extra work? > > I already have the time, really. Although I am a member of several > projects in Gentoo, right now only Trustees require much time. > > > 4. How do you think the council and trustees can work together to make > > Gentoo better? > > Not just the code base but the cooperative environment we all work > > together in too. > > Disclosure - I have a personal interest in responses as a trustee. > > > > I'm already a trustee, so having a council member who is a trustee is > a start. > Trustees and Council together are responsible for the smooth working > of Gentoo, but with largely complementary areas of authority. So I > think the two groups should begin by looking for places they both can > usefully contribute and work to put cooperation there in place (Code > of Conduct comes to mind because it applies to the entire community > but Council is pretty much limited to developers). Then set out to > put such cooperation in place. > There's a lot of hand-waving in that statement because I don't have > any specific mechanism for carrying it out in mind. > Another idea is to sit down and look at just what Gentoo's business > model is. We know there is one because the Foundation owns things > like trademarks or funds (as it must because you have to have some > sort of legal entity in place to do that). But the Foundation is not > much involved directly in pe
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On Fri, 2008-06-06 at 09:28 +, Duncan wrote: > Ferris McCormick <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, 06 > Jun 2008 01:37:21 +: > > >> 2. As one of the first priorities will be setting policy for pending > >> appeals what policy do you propose ? > > > I'd also add two new requirements: > > 1. Any appeal must be heard and decided within xxx days; > > Not to seem disrespectful, but "Or what?" Or it succeeds. Council may not pocket veto an appeal. > > Seriously, "or the appeal automatically succeeds."? Or, "or the appeal > automatically fails."? Does it matter what the appeal is (the scope of > the question wasn't limited to the current situation, so the answer must > apply in broad scope as well)? > Any appeal. > I'd urge being careful here, because it a similar failure to spell out > the details that triggered what amounted to a bit of a constitutional > crisis, tho the worst now seems past, I believe with the correct decision > being made. (My thanks to all involved.) > > So the "or what" matters, as does the scope, which is why I'm asking > about it. > > -- > 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 Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Nominations open for the Gentoo Council 2008/2009
I also nominate: NeddySeagoon Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 07 Jun 2008 09:45:53 +0200 Tiziano Müller <[EMAIL PROTECTED]> wrote: > Roy Bamford wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 2008.06.05 01:00, ?ukasz Damentko wrote: > >> Hi guys, > >> > >> Nominations for the Gentoo Council 2008/2009 are open now and will be > >> open for the next two weeks (until 23:59 UTC, 18/06/2008). > > > > Team, > > > > I don't want to nominate anyone who hasn't been nominated already. > > I would like to address all the candidates who have or will accept > > council nominations. > > > > 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider > > it broken) > > a) A GLEP 39 is a "proposal" to do/implement something and should not be > used as a way to finally document something. So, if we want to fix it, we > should write down a new GLEP replacing GLEP 39 and then write that > information down where it belongs to: in proj/en/council (and/or the > developer handbook) > > b) Reading GLEP 1 you'll see that there are only two types of > GLEPs: "Standards Track" and "Informational". One is for technical stuff > and the other for organizational, but: "Informational GLEPs do not > necessarily represent a Gentoo Linux community > consensus or recommendation, so users and implementors are free to ignore > Informational GLEPs or follow their advice." > > So we either have to stop using GLEPs for such kind of "rules/definitions" > OR redefine how GLEPs should be used properly for changing organizational > processes. > > We should finally stop doing cosmetic changes or we will forever struggle > with outside people who know our rules better than we and as a result waste > our time and energy and block our processes. > > Cheers, > Tiziano > GLEP 39 is informational in that it describes council+policy. The actual policy was established in 2005 in a vote by the developer community. Thus, changes to the GLEP should be only to clarify actual policy (and I don't know where it is written down. I remember the vote, but don't know who controls the actual policy document). I believe that policy changes would require another vote; GLEP 39 changes should not change policy. At least, that is my recollection and understanding. > > -- > gentoo-dev@lists.gentoo.org mailing list > Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhKs6IACgkQQa6M3+I///cUywCghnDT7JgB9ngb44H90SKK51IX 1FgAoJMjiAu8h5fJArjSSselZ33Xxjd4 =Lq9L -END PGP SIGNATURE-
Re: [gentoo-dev] A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jun 2008 11:12:27 +0200 "Piotr Jaroszyński" <[EMAIL PROTECTED]> wrote: > Hello, > > looks like every nominee wants the council to be more technical so I > have a few technical questions for you: > > 1. GLEP54 > 2. GLEP55 > 3. Most wanted changes in future EAPIs > > [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html > [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html > > -- > Best Regards, > Piotr Jaroszyński > [Error decoding BASE64] Sorry to disappoint you. If you get me on council, I'm going to ask for a recommendation and follow it unless it looks ridiculous. For the GLEPs you mentioned, unless someone came forward otherwise, I'd approve them out of hand. As for future EAPIs, that is not a council matter that I can see. Why on earth can't that be done at the level of those who care? I.e., people who implement package managers or want EAPIs. It seems to me all we want is consistency, and council's job is to put package manager people into a room and tell them not to come out until they agree on something. If I'm a councilor, I really don't care what that is. I'll listen to what you want for future EAPIs, but I don't think it's council's job to decide. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhLqJMACgkQQa6M3+I///frwQCg3SmJMu9K9x3hjpx0jcc0tOBy YpIAn2DS+YeYw016hoebhIyLKtbu80tE =qDAl -END PGP SIGNATURE- ���^�X��� ��(��&j)b�b�
Re: [gentoo-dev] A few questions to our nominees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 8 Jun 2008 09:38:17 + Ferris McCormick <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sun, 8 Jun 2008 11:12:27 +0200 > "Piotr Jaroszyński" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > looks like every nominee wants the council to be more technical so I > > have a few technical questions for you: > > > > 1. GLEP54 > > 2. GLEP55 > > 3. Most wanted changes in future EAPIs > > > > [1] - http://www.gentoo.org/proj/en/glep/glep-0054.html > > [2] - http://www.gentoo.org/proj/en/glep/glep-0055.html > > > > -- > > Best Regards, > > Piotr Jaroszyński > > [Error decoding BASE64] > > Sorry to disappoint you. If you get me on council, I'm going to ask for > a recommendation and follow it unless it looks ridiculous. For the > GLEPs you mentioned, unless someone came forward otherwise, I'd approve > them out of hand. As for future EAPIs, that is not a council matter > that I can see. Why on earth can't that be done at the level of those > who care? I.e., people who implement package managers or want EAPIs. > It seems to me all we want is consistency, and council's job is to put > package manager people into a room and tell them not to come out until > they agree on something. If I'm a councilor, I really don't care what > that is. > > I'll listen to what you want for future EAPIs, but I don't think it's > council's job to decide. > Sorry, I missed something. This is probably a QA matter since they own PMS, I believe. But it still is not a Council matter. It's QA's job to get an agreement on EAPIs if there is a problem. > Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhLslUACgkQQa6M3+I///fHlQCgjjzd35UA3ZzsV2VfVSz2BAo9 yhAAn3JHu/Y1hEcVqo4AVx+1Gwbv3zRI =XM2p -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Thu, 2008-06-19 at 18:28 +0100, Robert Bridge wrote: > On Thu, 19 Jun 2008 12:11:11 +0100 > Roy Marples <[EMAIL PROTECTED]> wrote: > > > On Thursday 19 June 2008 02:43:12 Chris Gianelloni wrote: > > > Nope. What I see as a problem is that the primary author and > > > current de facto maintainer is so much of an asshole that he was > > > forcibly removed from the Gentoo project, which PMS is supposed to > > > be written for, and has ostracized (at least) one of the package > > > manager's development team with his constant not-so-subtle > > > attacks. Quite frankly, I'd prefer see Gentoo take control over > > > the specification that defines the most important single feature of > > > Gentoo and remove the non-Gentoo developers from its development. > > > No offense, but you're not a Gentoo developer any longer and you > > > shouldn't have a say in how *we* manage ourselves. You're more > > > than welcome to contribute code, fork, or whatever the hell you > > > want. This is open source, after all, but that doesn't mean you > > > should be allowed to hold the position of power over Gentoo that > > > you've been granted. > > > > I would like to see Gentoo grow some balls and start banning people > > from -dev and other media used. I don't mean temporary bans, I mean > > for life. > > > > Yes, it's not nice. Yes, Gentoo should be open for all and encourage > > participation from all. However, some people have demonstrated time > > and time again over quite a number of years that they wont change no > > matter what. These people are posionous [1]. > > Slightly ironic for me to suggest this, but... > > It is the gentoo-dev mailing list, restrict posting to gentoo devs > (i.e. only people with a @gentoo.org email address) would make a lot of > sense. > Not really. It's there for general discussion of development matters, not developer matters. Some of the most interesting posts are from non-developers. gentoo-core is restricted. > Rob. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [EMAIL PROTECTED]
On Fri, 2008-06-20 at 07:30 +0100, George Prowse wrote: > Ciaran McCreesh wrote: > > On Thu, 19 Jun 2008 22:48:02 + > > "Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote: > >> Ciaran McCreesh wrote: > >> | On Fri, 20 Jun 2008 00:17:56 +0400 > >> | * have some insane paranoid conviction that Freenode staff are the > >> | ones busy spying on everything they say, whilst conveniently > >> | forgetting to notice that Gentoo's own infra team and current > >> | Council nomination group includes the person who abused root powers > >> | to sniff out lilo's password and give it to the GNAA. > >> > >> Are you ready to back up this claim by presenting some evidence? If > >> not, are you ready to accept the consequence of spreading such FUD? > > > > I'm sure you could ask Freenode and the developer in question for on > > the record statements, if you're interested. > > > I'd be careful, that is potentially libellous. No, for two reasons. No one is named, and you can't libel anonymous. Also if it's true, it's not libel. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
On Tue, 2008-07-01 at 05:30 +, Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. > This is delicate. I have asked for two items on the agenda for the next meeting, but so far they are on mail aliases only. I can post them here, and I want them public. Please advise. > Keep in mind that every GLEP *re*submission to the council for review > must first be sent to the gentoo-dev mailing list 7 days (minimum) > before being submitted as an agenda item which itself occurs 7 days > before the meeting. Simply put, the gentoo-dev mailing list must be > notified at least 14 days before the meeting itself. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: 0-day bump requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 4 Jul 2008 01:16:09 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > Hi fellow developers, > > > it seems I've run into a minor issue with fellow bug wrangler carlo > (who has been putting a lot of work into that, for which we should all > be grateful). > > Carsten has a cut-and-paste message that he posts in comments to > version bump bug reports that he finds have been filed on the day the > software version in question was released/announced. The gist of the > message is that none of or most ebuild developers do not like these > "0-day requests" and that users (and developers) should refrain from > filing them on the same day. Waiting a week would be OK, the message > seems to say. > > Being an ebuild developer myself, I have to say that I do not hold that > stance and that I welcome early version bump requests. Therefore, I > refrain from adding such messages to the bugs that I wrangle and indeed > welcome any bump requests[1]. > > Finding myself in conflict with someone I have come to share a certain > workload with, notably someone who has a few more years of Gentoo > experience, I wonder what the majority of our ebuild developers > actually think. In that spirit, I hope the following questions are > neutral enough for everyone to *not* start a flamewar over this. :) > > > - > 1) How do you feel when you receive an early version bump request? > Speaking only for myself as an arch developer. It depends on the reason. For example, recently there was a day 0 request for a freetype (I believe) stable request because current stable didn't work is some such. That sort of thing is OK. Obviously security bugs require quick processing. New keyword/re-keyword requests are OK (but then of course we don't go stable). Otherwise, we will put the package into the normal cycle whenever it enters the tree. > > 2) If you had your way, would you discourage users from filing early > version bump requests? > > Makes no difference to me, but I am not a package maintainer. I am speaking from an arch point of view. We only ask that the package maintainer make sure it at least seems to work before they bump the version. (It's different when the new version is not compatible with the current version, but that's off topic for this thread, I think. I don't ever want to see that sort of thing.) > - > > I know, it's not a particularly good survey, but I hope the plenty and > diversity of your answers will shed more light on the matter. :) > > > Thank you and kind regards, > JeR > > > [1] In fact I regularly use the opportunity to check on the HOMEPAGE > whether the release was security related, and I assign directly to > security@ when that is the case (CC'ing the package's maintainers) and > perhaps pasting ChangeLog or advisory info in a comment. > -- > gentoo-dev@lists.gentoo.org mailing list > I doubt that this addresses what you are asking, but in case it is useful, Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkht270ACgkQQa6M3+I///edXwCfTPiTZ56Aw9ViJRs8hJTm8DrQ 7g4An1NdsU/hLteSFLmxT47eeWDEGehm =62NW -END PGP SIGNATURE-
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
On Wed, 2008-07-09 at 01:40 -0700, Donnie Berkholz wrote: > On 05:30 Tue 01 Jul , Mike Frysinger wrote: > > If you have something you'd wish for us to chat about, maybe even > > vote on, let us know ! Simply reply to this e-mail for the whole > > Gentoo dev list to see. > > Here's the proposed agenda. Please respond if I forgot something, it's > unclear, or you have another suggestion. As before, since we have an > agenda in advance we won't be holding an open floor. I'll try to clarify my second agenda item on an absolute ban. Also I might edit my private request to make it pure vanilla and send it out, too, so that people may cross check my summary if they wish. If people want that, please respond saying so. 1. Your summary in the agenda is a fair reading of my request. However, I don't think it's realistic to expect a decision within a week because I think instituting a policy and procedure allowing a complete ban forever from Gentoo requires at the least a change to the Code of Conduct and a review cycle for that. 2. I can't spell out exactly what people are thinking of when discussing absolute bans, because I get the sense that different people have different ideas about just what we would mean by that. So I think the first step is for someone who advocates such a procedure needs to spell out exactly what it would be and why we would do it and under whose authority, etc. As probably everyone knows, I am absolutely opposed to any such thing, so I am not the person to do this. 3. So, I don't think we can reach a decision on anything until we are all clear on what we are deciding on. 4. Here's what I think is meant by a complete ban. *These are only my own inferences from reading between the lines and trying to put different comments together in some coherent fashion.* Under some rather unclear conditions, some combination of devrel/userrel/trustees/infra could decide to impose a complete, permanent ban on a member (user or, I suppose developer) of our community. This would have the following effects: a. The person could post to no gentoo mailing list; b. The person could not post to gentoo bugzilla; c. The person could not participate in #gentoo- IRC channels (although this runs into conflict with individual channel policy); d. The person could not contribute to gentoo (hence my corner case of a security fix) except perhaps through a proxy; e. (Perhaps any upstream projects in which the person banned would be notified of the ban??? --- I'm not sure). Right now, I don't know anymore if what I just described is what is being proposed or not. 5. I am told that nothing is forever, and that if whatever problems triggered such a ban were corrected, the ban might be lifted. I note, however, that since the banned person could not participate in Gentoo things, as a practical matter we'd never know if anything was corrected or not. (Except through 3rd parties.) 6. Presumably, all of this would be done in secret and whoever is being hit by such a ban would have no opportunity to respond before the ban's imposition. I suppose there would be a right to appeal to council, assuming council took no part in deciding on the ban. 7. [Argument] I view this as a pretty major change in how Gentoo operates. So someone needs to clarify my inferences in paragraph 4, and then we should think very carefully about it before allowing for any such practice. 8. [Argument] I note that we are likely to institute some form of possible moderation for the gentoo-dev mailing list (presumably based on Code of Conduct violations), and if we do that, it effectively satisfies the intent of any absolute ban, but is not nearly so traumatic to the system. I note that this is a minority view among those who have discussed this. Donnie, I don't know if that clarifies anything or just makes things more confusing. It's the best I can come up with. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: Make developer profiles more difficult to select
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 19 Jul 2008 21:39:04 +0300 Nikos Chantziaras <[EMAIL PROTECTED]> wrote: > Reading around on the net, it amazes me how many people are using > developer profiles for their Gentoo because they think it's for software > developers and don't see that it's for Gentoo developers and not > intended for end users. They know the "Developer" installation profiles > of other distros and think Gentoo's profiles are just the same (on those > distros, selecting a dev profile just means it installs GCC + dev libs + > IDEs by default.) > > Some kind of warning or other mechanism that does selecting this profile > without knowing what you're doing would be a good idea. > Maybe it should be called gentoo-developers or gentoo-developers-only? :) Actually, that's not really meant as a joke. > -- > gentoo-dev@lists.gentoo.org mailing list > Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiCOBcACgkQQa6M3+I///d+dwCeK2WkyRSPDiiLbo+qYTVXT0j/ TNQAoNHUZDcg2WzexGeUoI938AUgx+QT =9Y0b -END PGP SIGNATURE- éí¢^¾X¬¶È Ú(¢¸&j)b b²
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Thu, 2008-07-31 at 23:17 -0700, Donnie Berkholz wrote:
> This is your friendly reminder! Same bat time (typically the 2nd/4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
>
> Keep in mind that every GLEP *re*submission to the council for review
> must first be sent to the gentoo-dev mailing list 7 days (minimum)
> before being submitted as an agenda item which itself occurs 7 days
> before the meeting. Simply put, the gentoo-dev mailing list must be
> notified at least 14 days before the meeting itself.
>
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
Two items, or perhaps two views of the same item:
1. After some of the comments I've received after mentioning what I
think the hold-over item "2) Code of Conduct extent" is, I'm not quite
sure what Council is planning to vote on (the comments seem to conflict,
for example). Is council planning to vote on changes, possible changes
for discussion by the community, or what? If the vote is on the
specific questions Donnie raised, is the intent to implement the outcome
or to make it the official proposal for discussion? Sorry to come
across as somewhat clueless after all the ongoing discussions, but I
guess I really am confused at this point.
I think I'm going to reraise my request for someone if favor of the
proposed changes (which I no longer know quite what are) to put them in
the form of a GLEP so we can all discuss the same things. Whatever the
changes are, they do represent a policy change, and I still think the
community should be able to review the whole thing in complete form
before we just put it in place.
2. Last February, Council determined that for Code of Conduct
enforcement,
"The basic idea is to just promote individual devs responding to
people who are being jerks. Privately, unless things get out of hand."
Where I think "promote" == "get together a core culture of people". But, thus:
"My hope is that with no team of people assigned to doing this stuff, we
can actually build a culture and get more people participating rather
than having "the people who do that stuff" and everyone else."
{both quotes are Donnie's}
At least, that is what I infer from the summary of the February Council
meeting and the emails on the topic.
I am also told currently posted Code of Conduct dated March 15, 2007 is current
and in no need of revision. But I don't see it. Even if we agree that this
informal "core group" may be called proctors, they have no disciplinary
authority because (1) Council expected them to work by replying to inappropriate
email (on gentoo-dev) by requesting the jerk in question to quit being a jerk.
This is a mild form of mailing list moderation, but does not extend to anything
more;
(2) Nor could it, because this group I think is pretty much self selected and
so its
members might not even be known (so far as I know, there are people doing this
today
as called for last February), and so would have no way of getting infra to apply
any sort of suspension. But the Code of Conduct talks of actions by the
proctors
which I think the group as described last February have no capability of
carrying out.
Userrel might have such authority after the last Council meeting, but if so, the
CoC should be updated to mention that.
I believed that Code of Conduct had actually been updated, but everyone tells me
not.
===
Now, here's why my two items might be two sides of the same question. It seems
to me that current Code of Conduct as interpreted last February and perhaps
modified
last Council meeting cannot possibly be stretched to encompass Donnie's
questions from
the 13th of last month. After all, last February the Council made the Code of
Conduct
*milder* than it currently reads, with the intent of rebuilding our culture
gently but
firmly by "training" jerks not to be jerks. I find it very hard to read a
harsh,
user-only policy into that.
If the "extent of CoC enforcement" item is talking about something outside the
CoC or
a major change to the CoC from last February, then all the more reason for
someone to
put it in the form of a GLEP just like any other consequential change.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for August 7
a to have this for Gentoo too. Infra (Shyam Mani) say it isn't > a problem at all to create and maintain it, we in fact already have > something like this pointing at Freenode, it would be just a question > of updating that alias and updating our docs with it. It would > increase our independence from Freenode and make future network > switching much easier should we ever decide it's time to part our ways > with our current IRC service provider. > > The intention behind all three items is to increase our independence > from our IRC service provider. > > Kind regards, > > Lukasz Damentko Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Jeeves IRC replacement now alive - Willikins
Robin, Please for #gentoo-sparc Thanks and regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] best way to use profiles and package.use.mask?
On Tue, 2008-08-12 at 12:00 -0600, Steve Dibb wrote: > Okay, this is something that I've wondered about for a while, but need > to ask -- what is the best way (do we even have a policy) for using > package.use.mask in profiles? > > A couple of specific questions: > > If I need to mask a use flag because of use flag dependencies that won't > work on a particular arch, do I need to contact the arch teams to modify > their package.use.mask profile? If the answer is yes, I can see that as > a huge blocker since I'd have to wait on the arches to do something > before I can even put an ebuild in the tree. I realize this is a > per-arch question depending on how each one might respond, but a common > consensus would be good. > What happens now is that the ebuild gets added, keywords get dropped as needed, and whoever added the new ebuild opens a rekeywording bug. > Are there ever any cases where we could just simply put the use flag as > restricted in the global package.use.mask and then unrestrict them in > the profiles ones if, for example, it only worked on one or a few > arches? Or is the best policy always to mask it on each profile? > Personally, I prefer the first. But then, if a package is not going to work someplace, sparc is often one of those places. Down side comes if perhaps we are actually testing the package out of /usr/local/portage or some such, and suddenly the use flag for it comes up masked. > As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a > dependency (media-video/em8300-libraries) which is only keyworded for > x86, ppc, and amd64. That means I'd have to mask the use flag in alpha, > hppa, ia64, ppc64 and sparc (according to repoman). I could skirt the > issue completely and just run an if statement checking if they are using > any of those three arches, but I'd prefer to do it the right way. And > not piss off any arch teams in the process. > > So I guess my question is, can individual ebuild devs freely edit > package.use.mask files in profiles? > Freely? Of course not. We (the arch developers) need to know about it. :) > Steve > I see what you are after. I don't see a good answer for your specific request that does not usually involve a bug of some sort, asking the arch teams to look at what you have done or what you want to do. There are edge cases, of course. Like, "I've package.use.masked fast-x86 for bigmath-3.3.3 on sparc because it pulls in the fast-x86 package which is a fast math x86 package written in x86 assembler." But we still want to know what you've done and why, although in a case like that, a ChangeLog entry would likely be enough. Speaking for myself and not for all of sparc: If you do what seems best at the time (drop keywords and ask for rekeyword, package.use.mask, use.mask with selective unmasking) and document it, along with just asking on IRC when there is doubt, you won't go far wrong. We might scream at you, but we do that to package developers all the time anyway. Default now seems to be to drop keywords and open bugs requesting rekeywording, and that seems to work fine. But unnecessary in edge cases like the one I made up above (and yes, there are some like that). And if you know ahead of time you have something like this coming up, as I mentioned before, ask on IRC if you think of it before playing with profiles. I didn't answer your question. Mostly, I guess, do what seems right and let us know what you did. The best way to do that is through a bug usually. You might not find us on IRC when you need us, and we probably won't read your mail. :) Sorry for not helping, Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Resignation
No, not from Gentoo. After some thought, for personal reasons I resign from devrel. It's been enjoyable, and all my best to the devrel team. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Remove global USE flag tetex
On Wed, 3 Sep 2008 01:46:22 +0200 Christian Faulhammer <[EMAIL PROTECTED]> wrote: > Hi, > > there should be no more packages in the tree that have USE=tetex, so > this global USE flag can be removed. Any opinions? > > V-Li > > -- > Christian Faulhammer, Gentoo Lisp project > http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode > > http://www.faulhammer.org/> Hooray! Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-11 at 17:26 +, Duncan wrote: > Jeroen Roovers <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 11 > Nov 2008 17:24:50 +0100: > > > Words > > like "production", "critical" and "important" can be applied as easily > > to the state of a company's or nation's system as to a single person's. > > Yes, but it's a relative thing. They obviously do what they can with the > resources they have (are willing to dedicate). We do the same. A user's > single system will absolutely be important to him, no doubt about it, but > if he doesn't believe it worth "superhuman" feats or prioritizing to > ensure it's safety, neither should we. I think I understand what you mean here, but it's not what you wrote as best as I can tell. As a developer, I believe it is my responsibility to work a bit harder just so that the users don't have to resort to '"superhuman" feats' to keep their systems running. I do agree that no matter what we provide, all users (including ourselves) will have to expend some effort to take advantage of it. > No, we don't go around > purposefully breaking things, but both he and we have limits to our > resources and certain priorities in their allocation, and if he's not > placing undue priority on the safety of his machine, why is it even a > question if we will? The presumption should be actions within the bounds > of rational reality and prioritization of resources for both users and > their distribution, us. No more, no less. > > IOW, I'd have agreed if the point was that it's a machine that's useful > to the user and that he doesn't want broken, and we should behave > accordingly, but the triple emphasis of important, production, critical, > seemed a bit undue for the lengths to which an ordinary user goes or the > priority he reveals by his own actions. And if his actions reveal a > SERIOUS priority in the area, than he's already covered by definition. > That's all I was saying. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On Tue, 2008-11-11 at 11:18 +0100, Jose Luis Rivero wrote: > Richard Freeman wrote: > > Jose Luis Rivero wrote: > >> I would prefer to analyze the causes of the slacker arch (manpower, > >> hardware, etc) and if we are not able to solve the problem by any way > >> (asking for new devs, buying hardware, etc) go for mark it as > >> experimental and drop all stable keywords. > > > > How is that better? Instead of dropping one stable package you'd end up > > dropping all of them. A user could accept ~arch and get the same > > behavior without any need to mark every other package in the tree > > unstable. > > Accept ~arch for the random package which has lost the stable keyword a > random day? And next week .. which is going to be the next? The key is > the concept 'stable' and what you hope of it. > > A long/middle-term solution for arches with very few resources instead > of generating problems to users seems a much better approach to me. > > > An arch could put a note to that effect in their installation > > handbook. The user could then choose between a very narrow core of > > stable packages or a wider universe of experimental ones. > > Mixing software branches is very easy in the Gentoo world but it has > some problems. Are you going to install in your stable (production, > critial, important,...) system a combination of packages not tested > before? Because the arch teams or the maintainers are not going to test > every posible combination of core stable + universe of experimental > packages. This is why branches exists. > > > I guess the question is whether package maintainers should be forced to > > maintain packages that are outdated by a significant period of time. > > Suppose something breaks a package that is 3 versions behind stable on > > all archs but one (where it is the current stable). Should the package > > maintainer be required to fix it, rather than just delete it? > > Maintainer has done all he can do, this means: that is broken, this > version fix the problem, go for it. Maintainer's job finishes here, now > it's the problem of your favorite arch team. > > > I suspect > > that the maintainer would be more likely to just leave it broken, which > > doesn't exactly leave things better-off for the end users. > > It's a different approach (maybe with the same bad results) but > different anyway. Leave the bug there, point the user to the bug and > maybe you can gain a new dev or an arch tester. > > While the proposal made here is to throw random keyword problems to > users by policy (which in the case of amd64 some months ago would have > created a complete disaster). > > > I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise > > discretion on removing stable versions of these packages. However, for > > some obscure utility that next-to-nobody uses, does it really hurt to > > move from stable back to unstable if the arch maintainers can't keep up? > > Special cases and special plans are allowed, what we are discussing here > is a general and accepted policy. > > > I guess it comes down to the driving issues. How big a problem are > > stale packages (with the recent movement of a few platforms to > > experimental, is this an already-solved problem?)? How big of a problem > > do arch teams see keeping up with 30-days as (or maybe 60/90)? What are > > the practical (rather than theoretical) ramifications? > > An interesting discussion. Ask our council to listen all parts: > maintainers, current arch teams, the experience of mips, etc. and try to > make a good choice. > > Thanks Richard. > > -- > Jose Luis Rivero <[EMAIL PROTECTED]> > Gentoo/Alpha Gentoo/Do > Very interesting discussion. Let me take a more or less random post and toss in a slight variation. As you might know, I am an arch maintainer (sparc) and I don't think we are a "slacker architecture." However, I have placed an indefinite hold on a stabalization request from the bug-that-must-not-be-named, because in my opinion this package given the current state of everything should not go stable on sparc (more QA issues than functional ones). How, I wonder, would the variations here handle such a situation? I don't think this situation is unique because arch developers are sometimes going to have a different concept of "stable" than the package developers do. If this does not make sense, is off topic, or irrelevant feel free to ignore it. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] An official Gentoo wiki
On Tue, 11 Nov 2008 18:45:32 -0500 Mark Loeser <[EMAIL PROTECTED]> wrote: > So, gentoo-wiki.com went down for a awhile and took something away from > our users something that is useful. Its back now, but I think we should > consider having our own official wiki that our users can contribute to. > We already have something very similar to this on the forums, and this > would just give the correct tool to put their documentation on. > > I already know some people are going to hate this idea and say that the > documentation could be wrong, etc, so lets look at how others have > handled this situation. It seems that Ubuntu has their own official > documentation section and a community section where users can contribute > to. We can put a nice big warning saying that the user documentation > may have some errors, and that any such errors should not be directed at > the maintainers of the package or the GDP. > > What are others feelings on this? What issues do you see with having a > wiki? Do you see anyway to resolve the issue you see with us having a > wiki? > I'm for it. I think the positives --- more communications paths, community building, providing something our users want --- outweigh the negatives (entries might be incorrect or irrelevant or whatever). I think it's understood that contributions might contain errors, but the can be corrected. I don't know about Ubuntu's community section, but I do find Wikipedia very useful even though I know it might be wrong. :) > -- > Mark Loeser > email - halcy0n AT gentoo DOT org > email - mark AT halcy0n DOT com > web - http://www.halcy0n.com Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] app-admin/eselect needs YOUR help
On Mon, 2008-12-08 at 12:56 -0800, Alec Warner wrote: > On Mon, Dec 8, 2008 at 9:49 AM, Wulf C. Krueger <[EMAIL PROTECTED]> wrote: > > On Monday, 08. December 2008 17:37:42 Donnie Berkholz wrote: > >> Open and public debate about the right way to do things does take > >> longer, and it's something you certainly participate in quite > >> frequently so I'm surprised to hear you badmouth it when it comes to > >> your own ideas. > > > > It's not about Ciaran's (or anyone's ideas). We openly and publicly discuss > > such things in Exherbo, too. Not endlessly, though, but we get to an actual > > decision in a much shorter timeframe. > > > > Of course, Ciaran plays along the Gentoo way of either discussing things > > till a) people are sufficiently annoyed about the length of the thread to > > stop reading it at all (the normal procedure), b) the council decides to > > postpone the decision to the next meeting during which it gets postponed to > > the next meeting (and so on) or c) it's being decided that it's not needed > > (only to discover half a year later that an issue has to be worked around > > again because the real solution was treated in the way of a) or b)). :-) > > > > So this is not badmouthing but dealing with the facts of Gentoo. > > s/Gentoo/Any 'large' organization with little or no management/ > > it turns out this is a problem in a number of other organizations; > hopefully Gentoo will get better at addressing them. > > -Alec > Interesting (and valid) point. Perhaps this argues for more (or more active) mamagement. > > > > Best regards, Wulf > Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 2009-01-20 at 21:04 +0200, Petteri Räty wrote:
> Many times upstream Java projects don't include build.xml files or
> proper build systems so we include build.xml files in $FILESDIR. In case
> upstream some day adds one we usually use cp -i to detect if upstream
> adds this file in new versions. If devs do their job properly, this will
> never show to users. On #gentoo-dev at least grobian and darkside did
> not like this and proposed using test and die instead. If we think that
> cp -i is not acceptable, this should be made a function to avoid code
> duplication in my opinion. Here's a suggestion:
>
> function cp-no-replace() {
> debug-print-function ${FUNCNAME} $*
>
> [[ ${#} != 2 ]] && die "${FUNCNAME} takes two arguments"
> [[ -e ${2} ]] && die "die target exists"
>
> cp "${1}" "${2}" || die "cp failed"
> }
>
> So do you think:
> a) cp -i is fine
Fine with me
> b) this function should be added to eutils
I don't like this one ---
[[ ${#} != 2 ]] && die "${FUNCNAME} takes two arguments"
[[ -e ${2} ]] && die "die target exists"
How does the user recover from that? I would become irate if a build
died without giving some useful indication the problem.
> c) keep it restricted to java eclasses
> d) something else
>
> Regards,
> Petteri
Regards,
Ferris
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 2009-01-20 at 21:37 +0200, Petteri Räty wrote:
> Ferris McCormick wrote:
> > On Tue, 2009-01-20 at 21:04 +0200, Petteri Räty wrote:
> >> Many times upstream Java projects don't include build.xml files or
> >> proper build systems so we include build.xml files in $FILESDIR. In case
> >> upstream some day adds one we usually use cp -i to detect if upstream
> >> adds this file in new versions. If devs do their job properly, this will
> >> never show to users. On #gentoo-dev at least grobian and darkside did
> >> not like this and proposed using test and die instead. If we think that
> >> cp -i is not acceptable, this should be made a function to avoid code
> >> duplication in my opinion. Here's a suggestion:
> >>
> >> function cp-no-replace() {
> >>debug-print-function ${FUNCNAME} $*
> >>
> >>[[ ${#} != 2 ]] && die "${FUNCNAME} takes two arguments"
> >>[[ -e ${2} ]] && die "die target exists"
> >>
> >>cp "${1}" "${2}" || die "cp failed"
> >> }
> >>
> >> So do you think:
> >> a) cp -i is fine
> >
> > Fine with me
> >
> >> b) this function should be added to eutils
> >
> > I don't like this one ---
> > [[ ${#} != 2 ]] && die "${FUNCNAME} takes two arguments"
> > [[ -e ${2} ]] && die "die target exists"
> >
> > How does the user recover from that? I would become irate if a build
> > died without giving some useful indication the problem.
> >
>
> You did not understand the issue if you are fine with a) but then make
> this statement. a) would surely be even more confusing to the user.
>
> Regards,
> Petteri
I think I understand the issue. My point is that
die "die target exists"
gives no clue whatsoever as to what to do or where the problem is and
strikes me as something that should never appear in a proper build. If
that's the preferred solution, at least indicate that the ebuild has not
caught up with upstream and that the user is not at fault.
'cp -i' will at least ask a question, and I find that marginally better
--- it's confusing, but at least it says something. But it seems to me
that if we hit this case, no one (including the package owner) knows
which .xml file to use, so stopping the build makes sense, but do it
with some message that explains exactly what is going on.
I do not intend to respond further to this thread.
Regards,
Ferris
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 20 Jan 2009 23:50:47 +0100
Jan Kundrát wrote:
> Ferris McCormick wrote:
> > 'cp -i' will at least ask a question, and I find that marginally better
> > --- it's confusing, but at least it says something. But it seems to me
> > that if we hit this case, no one (including the package owner) knows
> > which .xml file to use, so stopping the build makes sense, but do it
> > with some message that explains exactly what is going on.
>
> The problem is that the whole build won't *abort*, but rather become
> interactive.
>
> I for one think that having it die (in the unlikely case that s
> developer made a mistake) is better than letting it hang indefinitely
> (in the unlikely case that a developer made a mistake) :).
That's what I meant by "stopping the build". My concern is that when
we do stop the build, we do it with some useful error message and make
it clear that the user did not screw up and so should do something to
fix it. ("die file exists" looks to me like an attempt to ask the user
to fix something, not an ebuild problem.)
As I think about it, I am not sure how this could happen. It would
either be an ebuild that the package owner never tried or a change in
the source file. And why wouldn't a change in the source file cause an
immediate termination because the length would suddenly be wrong? And
if the now-upstream-supplied build.xml file is different from the one
the developer put together, wouldn't you probably want a revision bump
at that point?
> Think about
> insane users setting up cronjobs and what not...
>
> Cheers,
> -jkt
>
> --
> cd /local/pub && more beer > /dev/mouth
>
Clearly, I misspoke when I said I'd not respond further. :)
Regards,
Ferris
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: PGP signature
[gentoo-dev] Fw: Invitación a Congreso de Software Libre y Tecnología Libre Republica Dominicana
I'm passing this on to gentoo-dev because that should reach anyone who
might be interested in this. I don't know if the Dominican Republic is
convenient for anyone to reach, but this might be of interest to
someone.
Regards,
Ferris
Begin forwarded message:
Date: Mon, 26 Jan 2009 20:26:15 -0400
From: Socrates Piña
To: trust...@gentoo.org
Subject: Fwd: Invitación a Congreso de Software Libre y Tecnología
Libre Republica Dominicana
Señores
Fundacion Gentoo
La comunidad seguidora de la filosofia del software libre, en Republica
Dominicana, esta organizando un Congreso sobre ; " Software libre -
educacion y conocimiento libre.", dedicados a toda la nacion con el
aupicio de las universidades Dominicana.
Este congreso contara con la participacion de lideres mundiales del
software y conocimiento libre y esperamos representacion de: Europa,
Sur America, America, etc en el mismo. y de toda la juventud
universitaria dominicana.
A los organizadores de este evento, nos gustaria poder contar con su
colaboracion y participacion en el mismo. Por ellos le invitamos a
participar con un stand, donde puedan exponer sus productos y desarrollo
tecnologicos usando software libre. Como es conocido en el mundo del
software libre, ustedes ya tienen equipos a la ventas con sistema
operativos libres a nivel de pc y ademas con sus grandes servidores.
Es esta una gran oportunidad, para poder demostrar a la comunidad de
usuario de software libre, la forma eficiente en que nuestro sistema
operativo corre en su hardware y de llegar a nuestra comunidad.
http://elnuevodiario.com.do/app/article.aspx?id=136186
la direccion adjunta es sobre la publicacion periodistica de la
realizacion del evento que sera en el mes de septiembre del 2009, del
14 al 17 y esperamos tener una pronta repuesta.
Atentamente,
Prof. Dionisio Grullón Heredia Licdo.
Socrates Piña Calderón
Organizador
Organizador
--
Licdo. Sócrates A. De js. Piña Calderón
Abogado - Notario
Telfs: (809)532-5479
(809)481-4912
--
Licdo. Sócrates A. De js. Piña Calderón
Abogado - Notario
Telfs: (809)532-5479
(809)481-4912
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
SeñoresFundacion Gentoo
La comunidad seguidora de
la filosofia del software libre, en Republica Dominicana, esta
organizando un Congreso sobre ; " Software libre - educacion y
conocimiento libre.", dedicados a toda la nacion con el aupicio
de las universidades Dominicana.
Este congreso
contara con la participacion de lideres mundiales del software y
conocimiento libre y esperamos representacion de: Europa, Sur
America, America, etc en el mismo. y de toda la juventud
universitaria dominicana.
A los
organizadores de este evento, nos gustaria poder contar con su
colaboracion y participacion en el mismo. Por ellos le invitamos a
participar con un stand, donde puedan exponer sus productos y
desarrollo tecnologicos usando software libre. Como es conocido en el
mundo del software libre, ustedes ya tienen equipos a la ventas con
sistema operativos libres a nivel de pc y ademas con sus grandes
servidores.
Es esta una gran
oportunidad, para poder demostrar a la comunidad de usuario de
software libre, la forma eficiente en que nuestro sistema operativo
corre en su hardware y de llegar a nuestra
comunidad.http://elnuevodiario.com.do/app/article.aspx?id=136186la
direccion adjunta es sobre la publicacion periodistica de la
realizacion del evento que sera en el mes de septiembre del 2009, del
14 al 17 y esperamos tener una pronta repuesta.
Atentamente,
Prof. Dionisio Grullón
Heredia Licdo. Socrates Piña Calderón
Organizador Organizador
-- Licdo. Sócrates A. De js. Piña CalderónAbogado - NotarioTelfs: (809)532-5479 (809)481-4912
-- Licdo. Sócrates A. De js. Piña CalderónAbogado - NotarioTelfs: (809)532-5479 (809)481-4912
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote: > On Mon, 23 Feb 2009 16:15:25 -0600 > Ryan Hill wrote: > > Can we ban eclasses from setting EAPI? Is there any case where it > > would be sane? > > It's already banned from a QA perspective, but from a package manager > perspective people have done it in the past and possibly still do do > it, and the spec doesn't forbid it. > For what it's worth, no eclass in the gentoo-x86/eclass tree sets EAPI. I don't know about anyplace else. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty wrote: > Let's try something new. I would like to get opinions from as many > people as possible about GLEP 55 and alternatives listed here in order > to get some idea what the general developer pool thinks. Everyone is > only allowed to post a single reply to this thread in order to make it > easy to read through. The existing thread should be used for actual > discussion about the GLEP and the alternatives. This should be a useful > experiment to see if we can control ourselves :) > > My notes so far: > > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down > > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage This is GLEP-55 I think, and it is my preference. It seems to solve the problem that the glep sets out to solve and has no effect on current portage.I don't claim that it's beautiful or perfect, but I have not seen a better alternative, either. It also has going for it the fact that some number of people have already thought through it and Piotr went to the effort of writing it up as a proposal, so it has had more thought put into it than alternatives. I do not find the arguments against it persuasive, so I'd say do this and be done with it. We can argue forever for better alternatives, but I don't see that we are getting very far with that approach. Just my opinion, of course. > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage This one's OK with me, too, if people prefer it. > > 3) EAPI in locked down place in the ebuild I generally dislike this sort of thing, and I think it puts more of a strain of the ebuild developers. But then, I'm not an package developer, so my opinion with respect to this is not worth much. I'd just rather see the EAPI visible in the file name than have to read the ebuild to find it, and I guess the overhead argument is that it's easier on portage not to have to do that, too. > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) I don't see why this is better than the glep 55 proposal??? > b) new subdirectory like ebuilds/ Yuch. > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait > > Regards, > Petteri > Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] truecrypt licensing - bug #241650
On Sat, 28 Feb 2009 09:34:12 +1100 Daniel Black wrote: > > I've run out of interest to chase down the answer to the range of issues here. > > Can someone with a few hours look trough all the info and see if truecrypt > license has improved to a situation where it is not putting the gentoo- > foundation or gentoo user's at risk. > > If you could provide a fully cited reply on the bug report. > > Next step? Gentoo Foundation lawyers? > > Sorry for the lack of interest especially to all those who want to use > truecrypt in the time being. > > Daniel Black > I'll look at it for the trustees in a bit. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop
On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote: > Hi everyone, > > with EAPI 3 confusion about what is in which EAPI may increase, > although appendix E of the PMS is quite helpful here. Anyway, > something handy to put on your desk is my little EAPI leaflet which > gives you all important (in my eyes) information in one leaf. Have a > look at http://v-li.de/temp/eapi_cheatsheet.pdf>, print it, fold > it and tell me if you like or not (and especially what exactly). > > V-Li I like it. It's useful to me, at least, and I like having this information available where I can find it in case I need it. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages
On Sat, 04 Apr 2009 16:16:29 +0200 Ehret Stefan wrote: > Timothy Redaelli wrote: > > On Saturday 04 April 2009 13:05:04 Ehret Stefan wrote: > >> Hello > >> > >> I would ask if I can maintainer following packages for > >> the gentoo-amd64 arch. > >> > >> app-crypt/truecrypt > > What about bug #241650? > > > the license seems to be a problem > but what is with the other packages? > I don't think the truecrypt license is a problem if we treat the package as in my Comment 11. There are/have been a few other packages where we require each user to fetch the source individually, and I think that is the main issue here, too. Each user must be aware of the license because of some restrictions on repackaging or redistribution. We do not distribute the package at all --- we provide a means to build it and install it (when we require the user to fetch the source). At one time, at least, the sun java distribution was like this, and as I said, I think there are others. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Retiring
On Mon, 4 May 2009 04:34:20 -0400 Markos Chandras wrote: > On Monday 04 May 2009 00:26:13 Peter Faraday Weller wrote: > > Hi, > > > > I've enjoyed my time with Gentoo, mostly... But these days I've just got > > too demotivated to work on it. I might have stayed if Ken69267 posted me > > some Lifesavers, but he didn't. :( > > > > On a more serious note, the problem seems to be the complete lack of > > management in the required places, Gentoo is fast becoming > >[..] > >I might consider coming back. > > > Indeed Gentoo has several problems. But we should stay together and try to > deal with them. I 've been around as a dev for 3 months and I think 4-5 devs > retired since then because of all the 'Gentoo anarchy' etc. So please stay > and > help us all solve those issues. I am pretty sure that you are not the only > one > who's having those thoughts. I've been a developer a bit over 5 years. We know the problems and are working to fix them. > -- > Markos Chandras (hwoarang) > Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] > Web: http://hwoarang.silverarrow.org Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Retiring
On Sun, 3 May 2009 18:51:59 -0400 Duncan <1i5t5.dun...@cox.net> wrote: > Peter Faraday Weller posted > 1241385973.4028.67.ca...@localhost.localdomain, excerpted below, on Sun, > 03 May 2009 22:26:13 +0100: > > > On a more serious note, the problem seems to be the complete lack of > > management in the required places, Gentoo is fast becoming (or more > > likely, already is) an anarchic organisation, where it's becoming > > nigh-on impossible to keep track of things. > > > > I see a number of issues with Gentoo these days. The lack of a proper > > leadership body. Lack of people working together in unison. The tree > > needs to be sorted out: we have >16000 packages, and 200-250 developers, > > not all of which are ebuild developers) - We're still using CVS, we do > > *not* have the manpower to keep all the packages updated properly using > > a centralised VCS. If these issues were fixed, I don't know/care how > > they do get fixed, but if they were, I might consider coming back. > > FWIW, from my perspective, Gentoo has turned the corner, we've hit the > low point (which I'd put at when the foundation dissolved due to malaise) > and things are beginning to improve now. Certainly there's a lot of work > remaining to be done and nobody's perfect, but I really do see positive > changes this last year or so. > For what it's worth (probably not much) I think Foundation is functioning now. At least, we are legal again, have bylaws, and a real bank account. > The council is actually somewhat functional now again, no more multi-hour > meetings that get little if anything accomplished. Gentoo worked thru > the foundation and council crises. I don't do IRC so can't evaluate it, > but certainly, the lists have gotten rather more professional the last > while -- no more severe personal attacks, and when it starts heading that > way, often both sides get warnings to "stop it" and people do (tho this > of course doesn't mean there's not disagreements, only that they're kept > to something approaching a reasonable professional level). > > Yes, Gentoo is still using CVS, but there are moves toward something > else, with GIT seemingly the lead candidate. While I don't see it > getting to that point in the remaining bit of the current council term, I > hope that it's a major item on the agenda for the next council to deal > with. The overlay structure seems to be quite active and is continuing > toward better overall integration, with issues like overlay and eclass > priority and sharing being worked out. > > Now Gentoo does seem to be at that "magic" 250-ish person mid-size > organizational cap, has been there for some time, and hasn't seemed to > get past it. OTOH, few organizations do tend to get past that, Debian > being the commonly mentioned FLOSS community exception, so Gentoo isn't > alone in that regard. In fact, there's many organizations that would > LOVE to be dealing with that problem as long as Gentoo has been. Maybe > we'll ultimately get past it, maybe we won't and we'll just have to learn > to manage at the 250-ish size we are. > > Perhaps the biggest mark of improvement for me personally has been that > (as I recently hinted in a post to the docs list) I'm actually thinking > about becoming a dev again. For some months, I had lost the motivation > and reasons I might wish to do so, but now it's back. I'm certainly > grateful for the folks that stuck around thru the bottom, and yes, that > IS a marked improvement I'm glad to see. =:^) > > So anyway, we seem to disagree on what's happening with Gentoo, but I > really do see improvement, and think it's a shame to have people leaving > for the lack of it, just as things from my perspective seem to be turning > around. But, regardless of whether you choose to stay or go, and that's > of course a decision you must make (recognizing that people do sometimes > need a time away, ideally to return refreshed and revitalized, ready to > take on new challenges), you did say you may be back if you see that some > of these issues have been addressed. Based on that, if indeed the > changes I am beginning to see continue, plan on that return, 'cause those > changes are coming. =:^) > > -- > 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 > > Regards, Probably should not have responded, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
On Fri, 2009-05-08 at 12:45 +, Duncan wrote: > Markos Chandras posted > 200905081342.17562.hwoar...@gentoo.org, excerpted below, on Fri, 08 May > 2009 13:42:13 +0300: > > > On Friday 08 May 2009 12:19:28 Duncan wrote: > >> Duncan <1i5t5.dun...@cox.net> posted pan.2009.05.06.17.25...@cox.net, > >>[..] If a potential recruit isn't interested in IRC, > >> Gentoo isn't interested in them as developers." > >> > >> Which, I suppose, is good to know, agree or not. > > > Ok now you are overreacting. Joining IRC 2 times in your life ( just > > for the review/recruit process ) is not that hard. > > > > If it's trivial enough that it's overreaction to refuse to join IRC twice > in one's life (which it should be noted, to my knowledge anyway, no one > has actually refused), then certainly, by that same mark of triviality, > it's overreaction to require it, as well. Otherwise, if it wasn't simply > triviality, it wouldn't be overreaction, but misreaction. > > But no matter, the practical fact of the matter is that for someone who > would otherwise not do IRC, it's just one more hurdle in the process. > Whether it's useful or not, trivial or vital, no longer matters, it's > defined by the gatekeepers as a requirement, therefore, by said > definition, it is a requirement. > Well, you could always do it over the phone. :) > It's good to know the requirements, including this one. Which is what I > was asking in the original post, is it or isn't it. Apparently, it is, > and anyone intending to become a developer can now deal with it as such. > -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries - SPARC team summary
We are an architecture team, so except for one developer (bluebird) who is actively working on true multilib support (64-bit userland), we are mostly reactive to bug reports for security, testing, and keywording. Currently we have enough developers to pretty much keep up with demand. However, note the following: 1. We need arch testers. We use them to help with evaluating keyword requests and as a breeding ground for new developers. However, because of this all of our arch testers have become developers and we need to refresh the pool. 2. Although we currently are keeping up with requests, the work load is heavy enough that we face (in my opinion) a real risk of developer burnout. Thus, I would say that we are understaffed, although we have one or two candidates in process. I'd prefer to have about three more developers as well as arch testers as mentioned above. So, short term, we are in reasonable shape. Longer term, we need to recruit. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Gentoo Support Everywhere
On Tue, 19 May 2009 22:40:44 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Jesús Guerrero posted > f7f0028fed7284065d82b976e721ec3a.squir...@jesgue.homelinux.org, excerpted > below, on Tue, 19 May 2009 23:57:38 +0200: > > > I don't know what the problem is with the forum thread, but it's there, > > I swear :) > > Have you double-checked for a typo? I can't see the thread either, > getting a does not exist error, not the unauthorized or locked or > whatever error I'd expect if it were that, so I expect it's a typo. > > Here's the link as originally posted. Please double-check. Or, as > someone else suggested, tell us how to navigate there (which forum, > subject, date posted for thread origin, author, etc). I'd have tried > that if I knew where to look, but there's not enough info in the post as- > is to do so. > > http://forums.gentoo.org/viewtopic-t-762914.html > It's there for me if I should see Gentoo subforum in LinuxQuestions.org and a poll. > -- > 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 > > Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sat, 23 May 2009 18:14:57 -0500 Andrew Gaffney wrote: > On 05/23/2009 05:56 PM, Mounir Lamouri wrote: > > William Hubbs wrote: > >> [snip] > >> My question for the group is, how do you feel about speech software > >> being on our minimal cd as well as our live cd? > > I agree, it should be in our minimal and live CD's. There is no reason > > to consider blind persons out of the minimal CD. > > The real issue here is the size. If these additional packages plus all of the > alsa modules add 20MB to the minimal CD, it's just not worth it. It's not > "minimal" anymore. > > -- > Andrew Gaffney > http://dev.gentoo.org/~agaffney/ > Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering > Lead > If the 20MB is a real problem, I think the alternative is to have two versions of the "minimal CD". Otherwise it seems to me that Gentoo is discriminating against people who cannot see the screen, and I would consider that to be very tacky at best. Someone (rdalek1967) said the problem was an extra 2.5 hours time for download over dialup. If that is correct, we are looking at 12.5 hours instead of 10 hours (about 25% increase, but 10 hours is a long time, and I don't know that 12.5 hours is subjectively that much longer). So, to answer William's original question, one way or another we should provide a minimal CD with the speech software on it in my opinion. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sat, 23 May 2009 20:12:17 -0500 Dale wrote: > Ferris McCormick wrote: > > > > If the 20MB is a real problem, I think the alternative is to have two > > versions of the "minimal CD". Otherwise it seems to me that Gentoo is > > discriminating against people who cannot see the screen, and I would > > consider that to be very tacky at best. > > > > Someone (rdalek1967) said the problem was an extra 2.5 hours time for > > download over dialup. If that is correct, we are looking at 12.5 hours > > instead of 10 hours (about 25% increase, but 10 hours is a long time, > > and I don't know that 12.5 hours is subjectively that much longer). > > > > So, to answer William's original question, one way or another we should > > provide a minimal CD with the speech software on it in my opinion. > > > > Regards, > > Ferris > > > > -- > > Ferris McCormick (P44646, MI) > > Developer, Gentoo Linux (Sparc, Userrel, Trustees) > > > > One problem I will mention but in most cases wouldn't matter. Most > dial-up ISPs have connect time limits. AT&T for example is 12 hours, my > current ISP is 10 but some are as little as 4 hours. When that limit is > reached, it disconnects. This happens even if there is data flowing. > > If, this is a big if here, a person has one of these and cannot resume > the download, this could become a issue even if they have a long connect > time like AT&T. I use Kget to download huge files or CDs since it has a > resume feature. However, are the tools on the CD, wget I guess, resumable? > wget claims it is: The example in the man page is === wget -c ftp://sunsite.doc.ic.ac.uk/ls-lR.Z If there is a file named ls-lR.Z in the current directory, Wget will assume that it is the first portion of the remote file, and will ask the server to continue the retrieval from an offset equal to the length of the local file. ==== > I do think this is a good idea even if it is a separate CD to download. > Also something to remember when making the stage tarballs I guess. > > Dale > > :-) :-) > Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for May 28
On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> This is your friendly reminder! Same bat time (typically the 2nd & 4th
> Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
>
> For more info on the Gentoo Council, feel free to browse our homepage:
> http://www.gentoo.org/proj/en/council/
>
>
> Following is the preliminary meeting agenda. First we'll have to fill
> the empty spot. After a short upgrade on EAPI-3 implementation we will
> discuss the removal of old eclasses, followed by our old friend GLEP 55.
> If we still have time we can dive into the topic of general EAPI
> development.
>
Because Piotr recently amended GLEP55 to provide some further
clarification and justification as well as to present a few alternatives
addressing some objections people have expressed, it seems to me that
the GLEP55 discussion should now go something like this:
1. Approve the concept in principle (I think Piotr's examples
sufficiently show the need for something along the lines set out in the
revised GLEP);
2. Choose one of the proposed solutions. For what it's worth, I favor
the new extension (package.ebuild --> package.eb), and then I think
something like ${PN}-${PVR}.eapi-${EAPI}.eb (or equivalent) is probably
best. Here, ${PVR} is perhaps in a new version format.
a. No introduced overhead;
b. Current PMs will not even see it;
c. I think there is an advantage for the users and developers to be
able to see the required eapi immediately without having to read all
the .eb (or .ebuild if you choose .ebuild-) files.
3. Approve the GLEP.
I would do the first quickly in order to cut off all the continual noise
on gentoo-dev@, and I really think the revised GLEP makes the case for
it well enough. After that, it should no longer be a religious issue,
and I optimistically would not expect step 2 to take long at all.
I note that the .eapi-${EAPI} part could well be optional, in which case
GLEP54 falls naturally into the new scheme as something like
${PN}-${PVR}-scm.eb
>
> Approval/voting of new council member replacing Donnie Berkholz
> ---
>
> Unfortunately Donnie resigned as a member of the council (for
> details please read his mail on the g-council ml). Next in line
> are ulm and ssuominen.
>
>
> EAPI 3: Short discussion of the progress
>
>
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.
>
>
> Removing old eclasses
> -
>
> Goal: Decide whether developers are allowed to remove eclasses. Problem:
> Upgrading using portage with a version before 2.1.4 will fail since portage
> always used eclasses from the tree instead of the ones from environment.bz2,
> even though the environment fail has been generated. Portage 2.1.4 got stabled
> over a year ago.
>
>
> Handling EAPI versioning in a forwards-compatible way
> -
>
> Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate
> to solve the problem. Decide which one should be chosen.
>
>
> Define EAPI development/deployment cycles
> -
>
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.
>
>
> Cheers,
> Tiziano
Regards,
Ferris
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council Reminder for May 28
On Wed, 2009-05-27 at 12:46 +, Ferris McCormick wrote:
> On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote:
> > This is your friendly reminder! Same bat time (typically the 2nd & 4th
> > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
> > irc.freenode.net) !
> >
> > If you have something you'd wish for us to chat about, maybe even vote
> > on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> > list to see.
> >
> > For more info on the Gentoo Council, feel free to browse our homepage:
> > http://www.gentoo.org/proj/en/council/
> >
> >
> > Following is the preliminary meeting agenda. First we'll have to fill
> > the empty spot. After a short upgrade on EAPI-3 implementation we will
> > discuss the removal of old eclasses, followed by our old friend GLEP 55.
> > If we still have time we can dive into the topic of general EAPI
> > development.
> >
>
> Because Piotr recently amended GLEP55 to provide some further
> clarification and justification as well as to present a few alternatives
> addressing some objections people have expressed, it seems to me that
> the GLEP55 discussion should now go something like this:
>
> 1. Approve the concept in principle (I think Piotr's examples
> sufficiently show the need for something along the lines set out in the
> revised GLEP);
>
--- SNIP ---
I did not intend to set off another religious war with this. I was
merely expressing my own opinion in response to the request from
Council. But it seems every time GLEP55 is mentioned, there is a
cascade of emotional responses, but I don't see anything in GLEP55 worth
any sort of emotional response, so consider this directed at council.
If anyone has technical issues with it, please either make them as such
and leave out the personal attacks.
1. For some reason, there were comments about the writing style used in
GLEP55. Personally, I find it clear enough, and would expect that it
would be revised once Council settles on whether to adopt the proposed
solution or one of its alternatives. (That's why it's marked as a
draft.) In my opinion, as it stands it clearly shows the necessity for
it or its equivalent (one of the alternatives it mentions);
2. I said that no matter what we do, I think we need a new extension;
3. Personally, I prefer .eb (with eapi defined elsewhere)
to .ebuild-, but I view that as more a matter of taste than a
major technical matter;
4. Personally, I prefer ${PN}-${PVR}.eapi-.eb (or a syntactic
equivalent); again, that is a matter of taste and performance;
5. As an alternative, I have no problems with ${PN}-${PVR}.eb and using
#!eapi as the first line of the .eb[uild] file. In that case, I
suppose you could even follow through and source a program called
'eapi', but that's a PM implementation issue outside the scope of the
GLEP. The argument against this is performance hit, I guess, and on
that I am not qualified to comment.
6. My remarks about -scm were merely meant to show that once you
introduce the .eb extension, you can implement GLEP54 transparently in
whatever manner excites you.
As I said at the beginning, these are my personal preferences addressed
to Council in response to their request. If others have preferences
which differ, please take them up with me (I am open to persuasion), and
please leave the emotion out of it. But I think GLEP55 adequately makes
the case for it or one of the alternatives it mentions, so don't bother
arguing with me on that matter. It's Council you need to convince, not
me.
Regards,
Ferris
--
Ferris McCormick (P44646, MI)
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I nominate: ssuominen armin76 Perhaps others later. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I knew I wasn't done. I also nominate: arfrever calchan -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Mon, 01 Jun 2009 22:29:25 +0200 Tiziano Müller wrote: > The people I'd like to nominate: > > - dertobi123 ... for his solid comments, experience, common sense, > reliability > - halcy0n ... even though he had to resign early I hope he finds time > again to run for council, I really enjoy working together with him and I > appreciate his common sense > - betelgeuse ... technically skilled and experienced > - fmccor ... not sure whether possible or not since member of the > trustees. But his latest comments showed experience in organizational > tasks and that's what we need. > Thank you very much for the nomination. But as you guessed, as a trustee I am not allowed to serve on council (our bylaws prohibit it). Thus, if I ran and somehow were elected, I'd have to decline or resign as a trustee. Thus I must decline the nomination, although again I appreciate the confidence you show in me. > Probably some more later on... > > > > > -- > Tiziano Müller > Gentoo Linux Developer, Council Member > 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 Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re:[gentoo-dev] GLEP 55 Version 2
O > > Date: Sat, 06 Jun 2009 23:31:47 +0100 > From: Roy Bamford > To: gentoo-dev@lists.gentoo.org > Subject: [gentoo-dev] GLEP 55 Version 2 > > > - -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ladies and Gentlemen, > > I've spent some time reading all of this years emails on GLEP55 and > added a few lines to version 1.5 which is the last offical version. > > The HTML version (not with the GLEP style sheet) is at > http://xrl.us/bevrnb (my devspace) > Its not ready to go to council as it still needs additional content > which I don't have the background to contribuite. My role in this > version of GLEP 55 has been interpretation and editorial. > Very small point. There is a difference between "EAPI in the file name extension" and just "EAPI in the file name". I think the intent here is the latter, but it speaks of them interchangeably it seems. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2009 Council Elections
On Fri, 2009-06-26 at 14:46 +0200, Ben de Groot wrote: > Wulf C. Krueger wrote: > > I think it would be in the best interest of both Exherbo and Gentoo to > > elect > > [...] to the Gentoo Council. > > I would think the only thing that matters is the best interest of > Gentoo. This is after all the _Gentoo_ Council we're speaking of, not a > body that is concerned with non-Gentoo matters. > > > All of them [...] would be ideal candidates to > > get the best of both distros and deepen a cooperation and common > > understanding > > between both. > > In my opinion it is in the best interest of Gentoo at this point to > ignore Exherbo and to silence those people involved with Exherbo that > have been so divisive and generated so much conflict in Gentoo channels. I think this works only if Gentoo can exist in a vacuum. And in my opinion it can't. An exchange of ideas among projects is good, and for Gentoo I suppose the council is the official driver. To me, that implies that council ignore other projects like Exherbo only to the detriment of Gentoo. (I believe we already have dual developers for Gentoo/Exherbo, but I haven't bothered to verify.) > > > This strengthening bridge of understanding can be seen in dev- > > zero's move to appoint ciaranm as his proxy for today's council meeting. > > To appoint as proxy for a council meeting someone who has been booted > from Gentoo is a clear lapse of judgement, and would in my eyes > disqualify the involved council member from functioning in that position. > > > While the other candidates certainly have great merits, they tend to only > > see > > one side and concentrate too much on Gentoo alone. > > I would hope so. The people we elect to the council should concentrate > on Gentoo, otherwise they'd have a conflict of interest. Conflict of interest? How so. And like it or not, as best as I can tell GLEP39 is the ruling document for council, and it does not require council members or proxies to be gentoo developers. It might be reasonable to require they be members of a gentoo project, but as someone (Denis?) explained to me, Gentoo project members need not be developers. Anyone with something useful to contribute should be able to, but only developers should have commit access (actually, the trustees can request limited commit access to any Foundation trustee or officer, I believe). > > Cheers, > Ben Flames not required, Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2009 Council Elections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 28 Jun 2009 16:40:00 +0100 Roy Bamford wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2009.06.28 10:00, Tiziano Müller wrote: > > Am Freitag, den 26.06.2009, 07:15 -0600 schrieb Denis Dupeyron: > > > On Fri, Jun 26, 2009 at 6:46 AM, Ben de Groot > > wrote: > > > > To appoint as proxy for a council meeting someone who has been > > booted > > > > from Gentoo is a clear lapse of judgement, and would in my eyes > > > > disqualify the involved council member from functioning in that > > position. > > > > > > As Petteri noted it's not obvious that GLEP39 disallows choosing a > > > non-dev as proxy for a council meeting. I haven't talked to > > Tiziano, > > > and I don't know what he had in mind when he chose ciaranm as his > > > proxy, but I'd be ready to believe part of it was that he wanted to > > > experiment. > > Well, it was surely not an experiment to see whether someone must be > > a > > dev or not to be a proxy. Based on GLEP 39 it was fairly clear to me > > this must not be the case and I at least expected the council to > > accept > > him (or any other non-dev) at least for that meeting. > > > [snip] > > -- > > Tiziano Müller > > Gentoo Linux Developer, Council Member > > 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 > > > > Its my opinion that the concept of proxies in council meetings is > fatally flawed. > > 1. The brief (if any) that the proxy is given by the council member > being proxied is never made public. > This is a problem. Any time a council member requires a proxy, that should be published immediately (including who the proxy is). Not possible for things coming up at the last minute, of course. > 2. Its never clear if the proxy is voting as instructed by the council > member or as they see fit at the time. > > What if an entire meeting and therefore any votes were staffed by > entirely by non gentoo developer proxies? > Unlikely, but perfectly possible under GLEP39. Would Gentoo feel bound > by decisions that such a meeting reached? > Currently, yes. > Oh. Don't talk about 'common sense' GLEP39 does not mention it, so it > doesn't count ... and its much rarer than you may think. > It's worse than that. I think 'common sense' is subjective and thus not a useful method of interpretation. Even if one disagrees with that statement, 'common sense' is certainly cultural (do you suppose common sense in N. Korea is the same as common sense in S. Korea? I don't think so at all.). So, 'common sense' for Gentoo still cannot be all that useful a method of interpretation, because Gentoo most certainly is multi-cultural. > Lastly, as a trustee and partly legally responsible for decisions made > on behalf of Gentoo, I am uneasy with the concept of non developers > making those decisions. Now reread my 'what if' above with that > liability in mind. > It's not that bad. as long as council meets every two weeks, any decision can be undone within 2 weeks (and council can always hold a special session. Although under your 'what if' scenario, we have a council which does not take its responsibilities very seriously.) > Note: Other trustees may have a different view of the world > I'm sure we all have different views of the world. But I generally agree with what you have written here, I think. > - -- > Regards, > > Roy Bamford > (NeddySeagoon) a member of > gentoo-ops > forum-mods > treecleaners > trustees > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.12 (GNU/Linux) > > iEYEARECAAYFAkpHjtYACgkQTE4/y7nJvavn9gCgt5tw0IaT8GRdh2w0nY+RskZF > H2YAoMgphYWUOp4bVMl8TWp0Qy1nTzjI > =aR8L > -END PGP SIGNATURE- > > Regards, Ferris - -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkpH60gACgkQQa6M3+I///eSvgCeMx/4WsoLHkIRv7DuH5iRl1/z H4AAoIaOejm13uYxbNcqesyJSKcIh8Ms =Fm7s -END PGP SIGNATURE-
Re: [gentoo-dev] 2009 Council Elections
On Sun, 2009-06-28 at 23:53 +0100, Roy Bamford wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2009.06.28 23:14, Ferris McCormick wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Sun, 28 Jun 2009 16:40:00 +0100 > > Roy Bamford wrote: > > > [snip] > > > > What if an entire meeting and therefore any votes were staffed by > > > entirely by non gentoo developer proxies? > > > Unlikely, but perfectly possible under GLEP39. Would Gentoo feel > > > bound > > > by decisions that such a meeting reached? > > > > > > > Currently, yes. > > > > > Oh. Don't talk about 'common sense' GLEP39 does not mention it, so > > it > > > doesn't count ... and its much rarer than you may think. > > > > > It's worse than that. I think 'common sense' is subjective and thus > > not a useful method of interpretation. Even if one disagrees with > > that > > statement, 'common sense' is certainly cultural (do you suppose > > common > > sense in N. Korea is the same as common sense in S. Korea? I don't > > think so at all.). So, 'common sense' for Gentoo still cannot be all > > that useful a method of interpretation, because Gentoo most certainly > > is multi-cultural. > > > > > Lastly, as a trustee and partly legally responsible for decisions > > > made on behalf of Gentoo, I am uneasy with the concept of non > > > developers making those decisions. Now reread my 'what if' above > > > with that liability in mind. > > > > > It's not that bad. as long as council meets every two weeks, any > > decision can be undone within 2 weeks (and council can always hold a > > special session. Although under your 'what if' scenario, we have a > > council which does not take its responsibilities very seriously.) > > > Note: Other trustees may have a different view of the world > > > > > I'm sure we all have different views of the world. But I generally > > agree with what you have written here, I think. > > You agree that common sense can't be used and admit that a corner case > exists that would in effect have the trustees pointing out to the > council that they had made an error of judgement and need to reverse a > decision that the last meeting made. I would prefer never to have to go > there. > I meant that the council can reverse itself. I did not intend to imply any trustee action --- I intended to imply that council should be able to see when they had made an error of judgment. > I do not agree that an all proxy council meeting shows that the council > does not take its responsibilities very seriously, rather that real > life has hit everyone at the same time and they have appointed > proxies. GLEP39 does not even set a limit on the maximum number of > council members who may be proxied at any single meeting. Fair enough. But I don't think such a meeting should ever happen. Surely, council can reschedule a meeting if they see this coming up. :) > As I have already said, I'm against the idea of proxies altogether. > We should amend glep39 to remove proxies and ensure that council > members are drawn from the developer community. Of course, that > does not eliminate the possibility of the trustees pointing out to the > council that they need to reverse a decision but it does ensure that > decisions are made only by council members who are Gentoo developers. > > - -- > Regards, > > Roy Bamford > (NeddySeagoon) a member of > gentoo-ops > forum-mods > treecleaners > trustees > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.12 (GNU/Linux) > > iEYEARECAAYFAkpH9GAACgkQTE4/y7nJvavFPwCguehKyVF6Ep294VWSHB14Dlq/ > mKIAmwWe9bHlEHwYayljnsisUW8p3VsK > =Npgw > -END PGP SIGNATURE- > > Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2009 Council Elections
On Sun, 2009-06-28 at 18:12 -0500, Dale wrote: > Roy Bamford wrote: > > > > > > You agree that common sense can't be used and admit that a corner case > > exists that would in effect have the trustees pointing out to the > > council that they had made an error of judgement and need to reverse a > > decision that the last meeting made. I would prefer never to have to go > > there. > > > > I do not agree that an all proxy council meeting shows that the council > > does not take its responsibilities very seriously, rather that real > > life has hit everyone at the same time and they have appointed > > proxies. GLEP39 does not even set a limit on the maximum number of > > council members who may be proxied at any single meeting. > > > > As I have already said, I'm against the idea of proxies altogether. > > We should amend glep39 to remove proxies and ensure that council > > members are drawn from the developer community. Of course, that > > does not eliminate the possibility of the trustees pointing out to the > > council that they need to reverse a decision but it does ensure that > > decisions are made only by council members who are Gentoo developers. > > > > I'm just picking a random message so no fingers being pointed here. > > As a long time Gentoo user, I have to ask. Why is that EVERYONE on the > council must be there or have someone there to represent them? Would > Gentoo come to a end if one person or even two people were not present? > All that's required is a quorum (4 out of 7) to hold a meeting. > I do agree that if a proxy is going to be used, they should be a > developer. If it is not that way now, it should be changed. I been > using Gentoo for years and wouldn't even consider serving as a proxy. I > would certainly not want to be a tie breaker on a vote. > > As a American that sees his own country's government getting out of > control, never count on common sense. Elected people rarely have any. > If they do during the election, it disappears after taking their > position. I think the vast majority of people here have seen that over > the years. > > My $0.02 worth. > > Dale > > :-) :-) Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
back to monthly is to allow those who > are council members in Gentoo to accomplish things other than the > council only. We all have personal lives and we all have our respective > roles we play outside of the council. Another note on meetings. The time > they are held currently don't fit well with my work schedule. > > I'm not subscribed directly to the gentoo-dev mailing list anymore > outside of post-only. And I don't plan to re-subscribe. I do browse > the archives regularly however. If there is some topic that should > be brought to my attention please point it out to me directly on irc > or CC: me. > > Thank you all and I will try not to let you down. Unless you were one of > the ones who wanted to me lose. Then sorry, but I'm going to have fun > disappointing you, by doing what is best for Gentoo. > > If you have any ideas on how you think the council should function or > reform itself. Please start a new thread or email those who think will > listen to those ideas. I'm open for some real change as long as it's > for the the positive. > Thank you. > So lets have some damn fun again !...@#$ > Thanks. > > Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] What is a devrel bug?
Unfortunately, the audience for this note most likely comprises people
who will not see it, but perhaps it will be useful anyway. However,
it's been a while since I've sent a long, rambling note, so here we
go
Once or twice a week, devrel ((Gentoo) Developer Relations) is assigned
a new bug of the form "I updated sci-calculators/units and it now claims
that 1 light year = 4 mm." While this would be a bug, it is not one
devrel can do anything about: As the name suggests, devrel is concerned
with people, not with packages, and devrel does not address problems
like a misbehaving "units" package. When we get such a report, we have
to notice we have an inappropriate bug, then reassign it. This serves
only to annoy us and to delay a resolution for the reporter. Please do
not assign software bugs to devrel.
That said, now that I have your attention, I'll continue a bit with some
suggestions describing what a good devrel bug might be. Devrel bugs are
concerned generally with recruiting developers, retiring developers, and
conflicts between developers. I am focusing on the last of these.
A few months ago I floated an RFC (attached, and at
http://dev.gentoo.org/~fmccor/devrel/DevrelBug.rfc.txt ) outlining some
thoughts on what information is useful for helping devrel sort out a bug
in which one developer is complaining about some other developer's
behavior and is requesting some sort of devrel intervention. The RFC
was not met with hostility, so I am sending it on to this mailing list
for feedback and suggestions.
Please note that the RFC refers to devrel policy, and that the policy is
undergoing revision. However, this does not affect the RFC; it affects
only what the RFC is referring to.
Although it is not emphasised in the RFC, I should add that when you
have such a complaint, it really helps everybody (including you) if you
try to resolve it by other means before filing a bug. In case you do
not remember, we have an ombudsman group ([EMAIL PROTECTED]) within
devrel whose charter is just that: help to mediate a solution before
escalating the problem to a level where you probably don't want it. I
note in passing that actually most devrel members will help resolve such
problems if you ask them (in case you have a favorite devrel member
whose style you are comfortable with), but if you do that, be prepared
for a referral to the ombudsman or working with that particular devrel
member's own eccentricities (e.g., if you ask me, be prepared for very
long ("may I have 5 minutes please?") discussions on IRC; others prefer
to work with email, etc.).
If you are still with me, thanks for your attention.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
THOUGHTS ON EFFECTIVE DEVREL PERSONNEL BUGS
== = == =
I. BACKGROUND
A bug reporting some developer's inappropriate behavior is similar to a
bug reporting some package's inappropriate behavior. And for devrel to
process such a personnel bug effectively and correctly, we need as much
context information as posible, just as the package maintainer needs as much
information as possible to process a failure report.
("fmccor is a disrespectful and incompetent developer" is as hard to do much
with as is "gcc is broken because it won't compile any of my programs".)
However, now that I have had time to gain some experience reviewing
devrel personnel bugs, I can say that this background information is sometimes
missing. Because of this, we (devrel) can miss the point of the report,
misclassify it, underreact (leading to "devrel never does anything"), or
overreact (leading to "devrel is just looking for reasons to hammer me").
This is frustrating, it slows the process, and it works to no one's benefit.
Consequently, here are some thoughts about information to include in a
bug reporting a misbehaving developer.
II. CONTENT
Generally, conform to the analogy to a product bug, or consider the form
of a legal brief for that matter. In some rational order (not fixed, but
perhaps depending on the bug), some or all of the following information can be
useful.
A. Brief (one or two sentence) summary of what the bug is about. If
possible, use the Bugzilla Summary field for this.
B. "Jurisdiction" --- why this is something for devrel to consider (policy
violation or whatever). This is a categorization of the report, not an
argument why it is valid. (This could be handled by a predefined set of
reasons by an existing Bugzilla field similar to "Component," but currently
it is not.)
C. What happened --- what specifically you are reporting. This is a
recounting of the incident(s) triggering the report. It should include
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 21:49 +0200, Danny van Dyk wrote: > Am Donnerstag, 10. August 2006 18:51 schrieb Grant Goodyear: > > Olivier Crete wrote: [Thu Aug 10 2006, 11:42:14AM CDT] > > > > > On Thu, 2006-10-08 at 10:57 -0500, Grant Goodyear wrote: > > > I volunteer (again).. What's the status on the search for voting > > > software ? > > > > Well, fmccor has suggested STV[1], so the current plan is to use > > "countify" to assemble the usual master ballot, and then write some > > sort of glue script that will take the master ballot and transform > > it into whatever STV needs. Of course, the glue bit still needs to > > be written. > Hm, i see a problem here. IIRC STV expects one line of input per ballot, > which lists all candidates sperated by spaces. Now, per votifiy, > developers can put more than one developer per line, if they deem them > to be equally competent. Isn't that incompatible behaviour? > Yes, but if we use STV (and there are issues with it if Condorcet is a requirement, because Condorcet is really designed to pick one winner, and it takes some extra work to get a ranking), I have a tiny ruby script which can take any number of raw ballots and convert them into one (internal form) STV .blt file. (The "equally competent" part might be another problem with STV, but I have to go back and look at it carefully to verify that.) So the "glue" is rather easy; problem is the specific balloting method. STV supports several protocols for selecting some number of winners from a list of candidates, but Condorcet is not among them, because Condorcet is really a "pick single winner" method. (By the way, if the ballots from council2005 are still around, and if someone can make them anonymous (convert names to something like C1, C2, etc.), I can take them and show what results STV would give, if you'd like a controlled test.) Anyone having better information than I have, please correct my mistakes here. > Danny > -- > Danny van Dyk <[EMAIL PROTECTED]> > Gentoo/AMD64 Project, Gentoo Scientific Project Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 21:11 +0100, Ciaran McCreesh wrote: > On Thu, 10 Aug 2006 20:03:26 +0000 Ferris McCormick <[EMAIL PROTECTED]> > wrote: > | So the "glue" is rather easy; problem is the specific balloting > | method. STV supports several protocols for selecting some number of > | winners from a list of candidates, but Condorcet is not among them, > | because Condorcet is really a "pick single winner" method. > > All you need to do is delete the single winner from the election and > repeat the process. > True. I was hoping no one would notice, however, because that gets tedious (although once you have the ballots, it can be automated to a large extent). At some point, we should re-examine policy and run some controls to see if a voting method more closely designed for what we are actually doing might be more appropriate. In the middle of a voting cycle is probably not the right time for that, though, no matter what makes things easiest for me. > -- > Ciaran McCreesh > Mail: ciaran dot mccreesh at blueyonder.co.uk > > Thanks, I guess :), Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Aug 2006, Matti Bickel wrote: Thomas Cort <[EMAIL PROTECTED]> wrote: Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Unless this causes problems for people, I'd like to be able to find it. As you see from my signature, I'm extrapolating from sparc here, but on sparc, at least, the specs and configuration of a failing system (or of a system which cannot be made to fail) is sometimes highly relevant. Having this sort of information can't hurt and might help, so I'd ask please provide it someplace if convenient. Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. Yes. Well, if you say everything is good, I just don't read it. I sometimes compromise on bugs and give a two or three line indication of just which system(s) I am reporting on. If people want more information, they can ask me or go to a summary page sparc maintains --- all my systems are described there. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFE28DyQa6M3+I///cRAqWRAKCSzbmYM8G16DzXuqdUHbYgVnivsQCgyVqS mO5HEmm6oc3yrqfX0IfrMug= =T6kP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Council polls now open
On Thu, 2006-08-10 at 20:24 +, Ferris McCormick wrote: > On Thu, 2006-08-10 at 21:11 +0100, Ciaran McCreesh wrote: > > On Thu, 10 Aug 2006 20:03:26 +0000 Ferris McCormick <[EMAIL PROTECTED]> > > wrote: > > | So the "glue" is rather easy; problem is the specific balloting > > | method. STV supports several protocols for selecting some number of > > | winners from a list of candidates, but Condorcet is not among them, > > | because Condorcet is really a "pick single winner" method. > > > > All you need to do is delete the single winner from the election and > > repeat the process. > > > > True. I was hoping no one would notice, however, because that gets > tedious (although once you have the ballots, it can be automated to a > large extent). At some point, we should re-examine policy and run some > controls to see if a voting method more closely designed for what we are > actually doing might be more appropriate. > Thanks to a pointer from Jan Kundrát, I have been able to build a master STV ballot from last year's council ballots. I had previously failed to note the "Eliminate candidates..." option to STV. But having noticing it, I am able to follow Ciaran's suggestion and run repeated Condorcet cycles over last year's ballot until 7 members are selected. Running STV in this manner selects the same council as we did elect. Total effort --- perhaps 15 minutes work for a new election (I have scripts which will build a master ballot from a collection of individual ballots, and from that the effort is minimal --- say, 60 seconds total if you are slow.) So, my "tedious" comment is someplace between misleading and wrong. I note in passing that NO voting method designed to select a set of several winners at once for this sort of election chooses quite the same winners as repeated application of Condorcet does. The deterministic one do agree with each other, however, on a slightly different set of winners. At some point after this year's election we should follow up on this. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, 2006-08-24 at 09:50 +0100, Stuart Herbert wrote: > Hi Donnie, > Lots of interesting material in this thread, and I haven't come close to processing it all. I am briefly responding to two of Stuart's points just to try to cut off further attempts to recall history. For those of you who want controversy, I'm afraid I'm going to disappoint you, because I am just going to say "yes, I was there and you have it right." :) == Lots of things snipped === > > Around the same time, more cries of "Democracy!" and "Eliminate the > > cabal!" forced developer relations (devrel) to come up with a huge, > > bureaucratic, court-like system for disciplining pretty much the same > > group of people again. > > That's not how I remember it. The court-like system was a direct > consequence to the way that Ciaran's first suspension was handled. > Plenty of folks felt that the way it was done left a very bad taste in > the mouth, and the system that followed was an attempt to address > those genuine problems. > This is correct. > > Everyone treated it like a world of extremes of > > good and evil, where democracy is absolutely good and purity, and > > anything other than that is evil. This added bureaucracy has essentially > > rendered this side of devrel powerless, meaningless and useless. > > I'm not sure how you can justify that statement. To the best of my > knowledge, that system has only been tested in full the once - when > Brian was suspended from the project and Ciaran was expelled. > This is also correct. The procedure turned out to be very hard to implement in practice, and I accept responsibility for some of the difficulties. However, we (devrel) did use it successfully with results as Stuart remembers. Since then, we have examined the conflict resolution policy pretty carefully, and policy is under revision. I do not believe the revised policy is posted yet, but if we ever need to use such a process again, it should move fairly but more quickly. > Best regards, > Stu > -- > PS: Isn't it fascinating how different folks can live through the same > events, but end up with different perspectives on it? :) > Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] using -j1 with distcc?
On Wed, 2006-09-13 at 07:52 -0700, Brian Harring wrote:
> On Wed, Sep 13, 2006 at 10:34:52AM -0400, Aron Griffis wrote:
> > From bind-9.3.2-r4.ebuild:
> >
> > # idea from dev-libs/cyrus-sasl
> > if has distcc ${FEATURES}; then
> > einfo "You have \"distcc\" enabled"
> > einfo "build with MAKEOPTS=\"-j1\""
> > jobs="-j1"
> > else
> > einfo "build with MAKEOPTS=${MAKEOPTS}"
> > jobs=""
> > fi
> >
> > emake ${jobs} || die "failed to compile bind"
> >
> > I think this is bogus. If building with distcc reveals a parallel
> > build issue, then the issue exists with or without distcc, it just
> > seems to happen less often without it. We've been down this road
> > before, maybe people have forgotten?
> >
> > bind-9.3.2-r4.ebuild failed to build for me on dual ia64. Building
> > with -j1 works.
> >
> > Unless somebody can explain how this is valid, I'll go ahead and fix
> > the bind ebuilds (where "fix" means "use -j1 unconditionally since the
> > Makefiles aren't parallel safe").
>
> Similar trickery in app-office/openoffice, although they enable -jN if
> distcc is enabled, else -j1 ...
>
> Always wondered how that was valid, just avoid OO compiles enough it
> wasn't something I ever got around to looking into :)
> ~harring
I don't see how it can be valid, especially ferringb's example.
Enabling distcc doesn't mean the build will distribute; only that the
possibility is there. If you happen to build when the other system(s)
is(are) unavailable for some reason, you get everything on the host, so
for ferringb, e.g., this would mean -jN on one system.
As for Aron's case, I agree with him.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Changes in Developer Relations and log of devrel meeting
On Wed, 2006-10-04 at 15:39 +0100, Ciaran McCreesh wrote: > On Wed, 04 Oct 2006 07:12:56 -0700 Josh Saddler <[EMAIL PROTECTED]> > wrote: > | > Uh, read again. You missed the point. I'm not talking about the > | > logged meetings here. I'm talking about the goings on in a certain > | > private IRC channel. > | > | You're just pissy because you weren't invited to the party. > > Naah. As anyone in devrel will tell you, someone forwards me complete > logs of the private devrel IRC channel, all the email sent to the alias > and spycam footage of their orgies. > > Seriously though, devrel keeping things private probably isn't a good > idea even if they're not using said private things to plot behind > people's backs any more. Given that they've done it in the past, it > only lends credibility to people who're claiming that devrel are out to > get them for personal reasons... > A very few discussions must be private: Consider that except for some documentation and policy, our only "product" is developers and the interactions among them, really. Now, if we were of one mind, there would be no problem, but we are not --- we are individuals with individual approaches and philosophies (even the log which triggered this thread might give some indications of that). Like it or not, this means that some discussions can include references to people which usually are not intended (the references; we can't speak to the history of the people), but in public might be injurious. Obviously I am not going to elaborate, but you can probably imagine situations which can set off such discussions. Now, that said, we (devrel) agree that we do too much in private, and believe it or not, we try to avoid it (I think the log contains some mention of this, too). So with the one (small, actually) exception outlined at length above, I think devrel pretty much agrees with ciaranm's observation; I believe it is our (informal) policy to work in public with -private as the exception. This doesn't mean we always observe said "policy", but we are aware of the issues. For example, I refer you to ribosome's observation in the log at 20:57 and kloeri's followup at 20:57 -- 58. I should emphasize that I am speaking as an individual member of devrel, I am giving my own spin on things, and I do NOT speak here for devrel as a whole. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Gentoo Commitfests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Oct 2006, Mike Doty wrote: --[PinePGP]--[begin]-- Just a random thought that popped into my head: We could have a commit fest where everyone who wants to compete kicks in some small amount of money(say $5) maybe the foundation kicks in a little something too. Then the person with the highest amount of commits at the end of some time period(say 8 hours) gets the money, or perhaps it's split 75%/25% between the top 2. I think this is a fun way to build some team spirit. Thoughts? I'm all for it. -- === Mike Doty kingtaco -at- gentoo.org Gentoo/AMD64 Strategic Lead Gentoo Council Gentoo Developer Relations Gentoo Recruitment Lead Gentoo Infrastructure GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === --[PinePGP]--- gpg: Signature made Fri 20 Oct 2006 08:00:23 PM UTC using RSA key ID 19F4AE05 gpg: Good signature from "Mike Doty <[EMAIL PROTECTED]>" gpg: aka "Mike Doty <[EMAIL PROTECTED]>" gpg: aka "Mike Doty <[EMAIL PROTECTED]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 --[PinePGP]--------[end]-- Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFFOYEzQa6M3+I///cRAiOnAJ4pBTXJEPQZYlu8FYksT9qkj2j9TgCgs7y7 wNyZmtxh3YDYYrf4KyK6rr0= =ONFU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Gentoo Commitfests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Oct 2006, Donnie Berkholz wrote: Ciaran McCreesh wrote: On Fri, 20 Oct 2006 15:00:26 -0500 Mike Doty <[EMAIL PROTECTED]> wrote: | I think this is a fun way to build some team spirit. I think it's a fun way to ruin QA by encouraging people to commit broken stuff. How exactly does it do that? Thanks, Donnie I thought I responded to rour mail, but it seems not to have gottten through. I like youru idea. Let's try it. Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFFOdc4Qa6M3+I///cRAoB3AKDJ64gpsEFVE4cR6G8doltuNAurUACeLAW3 Js2/WbXBQGq+0Lm8pcazQfY= =Bj3s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Gentoo Commitfests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 23 Oct 2006, Simon Stelling wrote: Alec Warner wrote: Haha, there are times when you need to realize that it's just joking around, versus an actual flamefest ;) This makes Gentoo look very unprofessional. It even makes us look like we're having fun. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list That's a joke, right? If we aren't having fun, we should go do something else, I would think. We don't look unprofessional; we look like people. Sorry for raining on your parade; I have some sort of flu and am passing it on. Regards, Feerris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFFPLoWQa6M3+I///cRAvvjAKDIyT38RAEnSSr63gFUoIhojwZ7AwCfYZ7R rv1pV9NSNHQ52Jmf4OIlnCk= =dcN3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Gentoo Commitfests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I spelled my name wrong. Bad keyboard, but that's tacky. Apologies, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFFPL6YQa6M3+I///cRAjDOAJ9YA2paFRxZuKtn/jaCABwGcN31ggCgzCa1 lE6LVIPKs5T8dPvl6QiXjow= =aK2g -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Only you can prevent broken portage trees
On Mon, 2006-10-30 at 00:28 -0800, Robin H. Johnson wrote: > On Sun, Oct 29, 2006 at 07:49:22PM -0700, Jason Wever wrote: > > Please triple check what you want to commit and verify that you don't do > > any of the following (which are punishable by death): > > > > 1) remove the last ebuild that is keyworded for a given arch, especially > >when resulting in broken dependencies. > > > > 2) remove the last stable ebuild for an architecture > > > > 3) remove the last testing ebuild for an architecture when there is no > >stable ebuild available after the removal > > To generalize on Francesco's email, how long should developers wait for > minority arches to mark stuff stable, after a security bug, and then a > reminder more than 4 months later? 5 months of no response from the > arches says something is wrong on their side. > I might be mistaken, but I believe sparc responds pretty quickly to security bugs, either by taking the requested action or by explaining why the requested action is impossible (i.e., build problems). > I think that usage statistics might point out that there are nobody even > using these specific ebuilds that are proposed for removal. > Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Only you can prevent broken portage trees
On Tue, 2006-10-31 at 18:23 +0100, Jakub Moc wrote: > Ciaran McCreesh napsal(a): > > On Tue, 31 Oct 2006 11:57:37 -0500 Alec Warner <[EMAIL PROTECTED]> > > wrote: > > | I picked a random e-mail to reply to. I don't maintain that many > > | packages (maybe 10 or so?). But if I have a bug (particularly a sec > > | bug as in this case) and you haven't stablized it after five months > > | then I'll probably just nuke the ebuild and drop your keywords > > > > Which is dumb. There's no harm to be had in just leaving the ebuild > > there. > > Accumulating broken old vulnerable and unsupported junk in tree for the > sole sake of arches that noone cares about enough to keyword something > newer for months harms everyone who uses rsync, wastes disk space for > users, wastes disk space on mirrors, makes CVS and portage slower, > wastes maintainers time... No harm? Nonsense. > > Well, there's a bit more to it than "noone cares about". Biggest problem I have seen (although seldom) is when the "fixed" version is broken for us. In such cases, we will note the problem on the bug, but obviously will not keyword the "fixed" version, and we need the old version until the package maintainer corrects the problem. Thus, we have no control over any 5 month, 6 month, forever rule. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
[gentoo-dev] xelatex --- Can't load fontspec (no [EMAIL PROTECTED])
Josh,
As you recall, I discussed problems with \use{fontspec} in xelatex
with you earlier. I am copying gettoo-dev@ on the off chance other
people are playing with xelatex, too. People who have no idea what I am
talking about might as well stop reading now.
The difficulty is that fontspec in one instance uses
[EMAIL PROTECTED], and it's trying to decide between AAT and ICU.
Unfortunately, [EMAIL PROTECTED] is not defined anywhere. The solution
is to use [EMAIL PROTECTED] instead and to always use ICU. The little patch I
have attached does that.
With this change to fontspec.sty, under xelatex
\use{fontspec}
loads the style file as expected, and commands like
\setromanfont[BoldFont=""Charis SIL"" Bold,ItalicFont=""Charis SIL""
Italic]{""Charis SIL""}
work the way they are supposed to. (And yes, you do need the double ""
because otherwise, xelatex stops scanning at the space and tries to load
Charis (not "Charis SIL").)
Hope this is of interest,
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
--- texmf/tex/xelatex/fontspec/fontspec.sty- 2006-11-01 20:22:18.0 +
+++ texmf/tex/xelatex/fontspec/fontspec.sty 2006-11-03 14:20:18.0 +
@@ -500,8 +500,12 @@
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED],#1}\fi
[EMAIL PROTECTED]@family{scfeat:[EMAIL PROTECTED] #1 [EMAIL PROTECTED]
[EMAIL PROTECTED],ICU}{%
- [EMAIL PROTECTED]@suffix/#1}%
[EMAIL PROTECTED],ICU}{%
+% [EMAIL PROTECTED]@suffix/#1}%
+% [EMAIL PROTECTED]"[EMAIL PROTECTED]@suffix" at [EMAIL PROTECTED] pt
+% [EMAIL PROTECTED]@[EMAIL PROTECTED]@long +rend:#1}}
[EMAIL PROTECTED]
+ [EMAIL PROTECTED]@suffix/ICU}%
[EMAIL PROTECTED]"[EMAIL PROTECTED]@suffix" at [EMAIL PROTECTED] pt
[EMAIL PROTECTED]@[EMAIL PROTECTED]@long +rend:#1}}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Packages for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 01 Jan 2007 10:51:56 -0500 Seemant Kulleen <[EMAIL PROTECTED]> wrote: > Betelgeuse, > > I'll take sqlite if you and I can co-maintain it. > > Thanks, > -- > Seemant Kulleen > Developer, Gentoo Linux > > -- > gentoo-dev@gentoo.org mailing list I can also help with sqlite if no one else can (i.e., I can help Seemant with it). - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFFmW6wQa6M3+I///cRAo0PAJ9rXuaSog/hypExHgNCEvWvnw1iiACfRAtb yb8TPvRNkDfP6Sa3gdn5+ho= =6wif -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gentoo-dev vs lkml?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Mar 2007 17:30:32 -0500 Steev Klimaszewski <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > >> Personally I understand why flameeyes took that to bugzilla; how else > >> could he say he'd gone thru the appropriate channels? Devrel (a > >> group, not an individual) weren't set up to respond quickly as others > >> have informed us all. > > > > Case in point: you need to distinguish between flameeyes leaving (again) > > as a publicity stunt because his attempt to blackmail devrel failed and > > flameeyes' stated reason for leaving... > > > > > It was an ultimatum. He goes or I go, it was not blackmail. FFS, can > we please stop calling it blackmail? As I recall, flameeyes made the statement to kloeri, and kloeri called it blackmail. Whatever you call it, in business, issuing such an ultimatum is one of the quickest ways to become unemployed. > -- > gentoo-dev@gentoo.org mailing list Regards, - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFF+HzzQa6M3+I///cRAgbrAKDegV4ZTzktAo3xspKdFZtXv4NWgwCgnWHc 0JtrXM0K3jT7G10qqWTrGYI= =ciKo -END PGP SIGNATURE- éí¢^¾§¶(® X§X¬
Re: [gentoo-dev] Re: gentoo-dev vs lkml?
On Thu, 2007-03-15 at 00:35 +, George Prowse wrote: > Ferris McCormick wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wed, 14 Mar 2007 17:30:32 -0500 > > Steev Klimaszewski <[EMAIL PROTECTED]> wrote: > > > > > >> Ciaran McCreesh wrote: > >> > >> > >>>> Personally I understand why flameeyes took that to bugzilla; how else > >>>> could he say he'd gone thru the appropriate channels? Devrel (a > >>>> group, not an individual) weren't set up to respond quickly as others > >>>> have informed us all. > >>>> > >>> Case in point: you need to distinguish between flameeyes leaving (again) > >>> as a publicity stunt because his attempt to blackmail devrel failed and > >>> flameeyes' stated reason for leaving... > >>> > >>> > >> > >> > >> It was an ultimatum. He goes or I go, it was not blackmail. FFS, can > >> we please stop calling it blackmail? > >> > > > > As I recall, flameeyes made the statement to kloeri, and kloeri called > > it blackmail. Whatever you call it, in business, issuing such an > > ultimatum is one of the quickest ways to become unemployed. > So you'd rather let one of the best employees go rather than chastise a > worker who is leaving soon? Thats just cutting off your nose to spite > your face. > You misunderstand. The analogy is that I walk into my boss's office and say "Fire Joe or I'm gone", in which case I can expect to be gone one way or the other. > It's good to see it has only taken 3 or is it 4 or 5 devs to leave > before anyone thinks about doing something. > > George -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gentoo-dev vs lkml?
On Thu, 2007-03-15 at 14:44 +, George Prowse wrote: > Ferris McCormick wrote: > > > >>>> > >>> As I recall, flameeyes made the statement to kloeri, and kloeri called > >>> it blackmail. Whatever you call it, in business, issuing such an > >>> ultimatum is one of the quickest ways to become unemployed. > >>> > >> So you'd rather let one of the best employees go rather than chastise a > >> worker who is leaving soon? Thats just cutting off your nose to spite > >> your face. > >> > >> > > > > You misunderstand. The analogy is that I walk into my boss's office and > > say "Fire Joe or I'm gone", in which case I can expect to be gone one > > way or the other. > Joe was leaving anyway. Ask Joe to leave soon which saves every single > problem. Joe just does what he was going to do, you get what you want > and the company keeps on running smoothly. The company then has the > choice of making it known to you that it will not be tolerated in the > future. > Whether or not Joe is leaving or not is irrelevant to how to treat my conduct. Apparently in this case I did not know Joe was leaving, and it is never (well, hardly ever) acceptable to make such demands. "Joe goes or I go" says something about me, not about Joe. And what it says (if nothing else) is that I am a problem employee who considers himself to be indispensable. We (or anyone else) just can't "ask Joe to leave soon" because someone doesn't like him. In my example, I am the problem, not Joe --- I set it up that way. Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-core] Tears of unfathomable sorrow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Apr 2007, Alec Warner wrote: Much to the joy of many I am now retiring from Gentoo. I've already done most of the work (sorry to burden you kloeri I think just the tree-bits are left). Many will wonder why; but this has been a while in coming. I don't get along with many like I used to and in many cases I don't find myself agreeing with the direction of things. Those who know me know I always bitched about how I didn't do enough for Gentoo and that too is a reason for leaving. I expect to still file patches for portage and I expect to hang out in gentoo-dev-help on irc and I expect to mentor for this years summer of code. For TreeCleaners I'm sorry that this is out of the blue; I hope you guys continue to nuke broken crap from the tree. For everyone who still loves working in their little window in gentoo, for all the devs that only read core and not -dev, for all the devs who made gentoo what it was when I started; thanks. It was a fun ride. As you know, I really wish you wouldn't do this. But if you must, best of luck. I respect you and enjoy working with you. -Alec -- [EMAIL PROTECTED] mailing list Regards, - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGF54eQa6M3+I///cRAnnyAJoCc6GDKmT1OzOf/qdEIBIoKCpzQgCgtl2Y qCFW0a7Qw2ye+Mp0ha2YBv4= =Czyo -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New metastructure proposal
On Fri, 2007-04-13 at 19:26 +0530, Andrew Cowie wrote: > On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote: > > as everyone probably noticed, there is a current atmosphere of sinking ship, > > with quite a lot of people leaving and many agreeing that gentoo is no fun > > working on anymore. Before it's too late, I'd like to propose a big > > reformation > > A well considered and thoughtful message. Reinvigorating communities is > hard, and I hope the rest of the Gentoo developer community will find > inspiration from the gentle encouragement to be positive, even if it > turns out the specific ideas aren't the direction you want to go. > > For all that the original poster got hammered about the stage4 thing, as > a long time Gentoo advocate I must admit that the constant stream of > negativity connected with so many developers getting upset and leaving > in a relatively short period of time is vaguely unsettling. It's good to > see other developers noting that they are happy - it balances things. > OK, I'm a happy developer. > One of the hallmarks of Gentoo has been whole tree co-ordination and the > fact that developers are able to cover for each other is really rather > cool. Regardless of any structural changes you might make, this > characteristic co-ordination and co-operation is what has made Gentoo an > impressive distribution and so I hope you manage to maintain this spirit > in the years to come. > > AfC > Bangalore > Thanks for the kind words; positive posts are always welcome. :) I believe it is very much our intent to "maintain this spirit [of co-operation]". Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
On Fri, 2007-04-13 at 12:17 -0700, Daniel Ostrow wrote: > > > > > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > > > > helpful for an awful lot of Gentoo developers. > > > > > > except that you back the tree into a corner that it cannot come out of > > > > Huh? Not at all. If a package can't use its test suite, the ebuild can > > set RESTRICT=test. > > > > > > Please refrain from that kind of comment. It doesn't help anyone. > > > > > > the answer is the same: talk to the QA team to get the tree into a > > > state where having src_test enabled by default is feasible and then > > > the QA team can change the profile > > > > That isn't going to happen any time soon. There are too many changes > > and the impact of turning it on is too high. A gradual migration via > > EAPI is much safer and much more useful. > > > > > enforcing via spec is the wrong way to go here ... spec is for > > > defining how the ebuilds work, not for forcing policy down peoples > > > throats > > > > And whether or not src_test is called is part of how ebuilds work. > > Policy is whether or not src_test is required to do something in all > > situations, or whether it can be RESTRICTed out as necessary. > > > > First off...wow...long time since I've been active...so if anyone wants > to discount my comments based on that alone feel free. I'm trying to get > back in the game and I think a few e-mails as participation might be > best...hopefully you'll actually see me online soon. > > Now on to the real topic at hand. For src_test I see things this way. > Welcome back to the real (Gentoo, that is) world. :) Good summary of the situation, I think (although I've snipped it since everyone's read it once.) --- snip --- > Just my 2 cents... > > --Dan Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Resignation
On Tue, 2007-04-17 at 07:43 +0200, Luca Barbato wrote: > Jakub Moc wrote: > > So Since devrel has been so kind and suspended me, based on our > > brand new CoC, I don't feel any need to stay on this project any more. > > I'm therefore resigning from this project. > > While there are situations in which you are right about complaining, the > form of some of your complaints isn't exactly nice many times. The 2 > weeks pause probably had been meant to just have you think about this issue. > > > I'm pretty sure it will be actually no loss for Gentoo, since those > > folks that contributed to my retirement far outweigh the benefit I > > could ever possibly be to this project. > > Nobody is perfect, complaints about conduct can be issued in a simpler > and saner way... > > Since I consider your work precious I'd like to see you back after those > 2 weeks. Please try to think about how to improve instead on how unfair > this treatment had been. > Jakub, Luca is exactly right here. The suspension is meant to be a cooling off period, not a message that says "please resign". So please, both for yourself and for Gentoo, reconsider your resignation and use the two weeks to cool off, relax, or whatever. I believe your work is most important, and I'd hate to lose it over this rather small matter. If you wish, please contact me privately. I'll discuss anything you like. > lu > > -- > > Luca Barbato > > Gentoo/linux Gentoo/PPC > http://dev.gentoo.org/~lu_zero > Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
