Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
On Thu, 2009-07-09 at 22:50 -0400, Andrew D Kirch wrote: Ciaran McCreesh wrote: trelane ciaranm: I want Paludis to fail. It's unhealthy (or at least the loudest and most visible of it's devs are) for Gentoo. trelane lets be VERY clear on that point. So long as Paludis, and the culture it creates are unhealthy for Gentoo I want it to fail. trelane ciaranm: that's put in a manner that seems to be a somewhat knee-jerk reaction. It should be clear that opposing you and everything you do was an initiative I started only after careful consideration. Ciaran, you are killing Gentoo. You wrote a demonstrably error prone GLEP 39, then tried to exploit it to ram through GLEP 55, and you got caught. You've created a huge amount of red tape, needless bickering argument, and have utterly hamstrung every council ever convened. Ciaran, you will not be doing this again. Actually, GLEP39 was written by Grant and Ciaran, and it was voted on by the entire developer community (I don't recall in which order these happened, but certainly it was not Ciaran who approved it). --- snip --- I am wearing my userrel hat here. I don't see anything here that contributes to the discussion --- it looks like a personal attack and a threat to me. As Jorge stated a day or so ago, please stop this now. You may consider this to be a final warning. Andrew D Kirch Funtoo.org PS: Ciaran, Thank you for comparing me to Rush Limbaugh, I consider it a compliment. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org 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?
. 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) fmc...@gentoo.org 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 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 neddyseag...@gentoo.org 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) fmc...@gentoo.org 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) fmc...@gentoo.org 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 neddyseag...@gentoo.org 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 Grootyng...@gentoo.org 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) fmc...@gentoo.org 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 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re:[gentoo-dev] GLEP 55 Version 2
O Date: Sat, 06 Jun 2009 23:31:47 +0100 From: Roy Bamford neddyseag...@gentoo.org 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) fmc...@gentoo.org 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) fmc...@gentoo.org 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) fmc...@gentoo.org 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 dev-z...@gentoo.org 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
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-eapi, but I view that as more a matter of taste than a
major technical matter;
4. Personally, I prefer ${PN}-${PVR}.eapi-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 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) fmc...@gentoo.org
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 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-EAPI) 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) fmc...@gentoo.org
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sat, 23 May 2009 18:14:57 -0500 Andrew Gaffney agaff...@gentoo.org 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) fmc...@gentoo.org 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 rdalek1...@gmail.com 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) fmc...@gentoo.org 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. ATT 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 ATT. 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
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) fmc...@gentoo.org 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 hwoar...@gentoo.org 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. Sigh. My intent was to put it to bed. 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Retiring
On Mon, 4 May 2009 04:34:20 -0400 Markos Chandras hwoar...@gentoo.org 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) fmc...@gentoo.org 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 w...@gentoo.org 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Packages
On Sat, 04 Apr 2009 16:16:29 +0200 Ehret Stefan eh...@planetpurple.net 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) fmc...@gentoo.org 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 dragonhe...@gentoo.org 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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@gentoo.org 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-eapi - 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) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - 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) new extension 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) fmc...@gentoo.org 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 socratespi...@gmail.com 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) fmc...@gentoo.org 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] 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) fmc...@gentoo.org
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) fmc...@gentoo.org
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 j...@gentoo.org 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) fmc...@gentoo.org 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] 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] 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 URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ Hooray! Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
[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] 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] 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] 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
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
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] 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 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] [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] 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] 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] 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] 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 performing technical guidance, say (although I can think of cases where it might be). I personally think it makes sense to look at bringing the two closer together to look more like a traditional business (although this is perhaps a minority view). For our continued health I think we have to work toward this goal. This is badly stated. Perhaps it would help if I mentioned that in my view, Gentoo exists for its community, not just for the developers. 5. Tell us a little about yourself - the skills and experience you can bring to the council
[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
[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²
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
- 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-
[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-
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
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] 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: 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] Re: [gentoo-core] Keywords policy
(Probably off topic? I think Richard said something he didn't intend.) On Tue, 2008-03-11 at 11:24 -0400, Richard Freeman wrote: Alec Warner wrote: On 3/10/08, Ryan Hill [EMAIL PROTECTED] wrote: You're still not getting this. The KDE team did not _want_ these ebuilds keyworded. That's why they _weren't_ keyworded. That's why there was no bug filed, saying hey we dropped these keywords because they _did not want_ you to add them back yet. When the ebuilds were of sufficient quality that they could be tested, then a bug is filed, the ebuilds are tested, and then re-keyworded. Right, but you did not make your want known, so how is Jer to know? I don't really want to get into the specifics of this situation but wanted to raise a question of policy. My understanding is that arch teams shouldn't keyword anything without the OK of the maintainer - usually in the form of a STABLEREQ bug. When I get stable requests from users I don't act on them until I hear from the maintainer for this reason. Um, not really --- this is too broad. Some packages are not keyworded because no one has ever tried them. We occasionally get keyword requests of the form Please add ~sparc keyword to because I've been using it and it works fine in response to which we do add the keyword if it does work. No maintainer action involved, because the maintainer apparently doesn't know if the package works on sparc or not anyway. A STABLEREQ is a different matter, masked packages are a different matter, but not just keywording. --- snip --- 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] Operations lead --- armin76
Another attempt. I don't seem to get to gentoo-dev@ Patience, please. === All, It is my pleasure to announce that after some arm twisting, Raúl Porcel (armin76) has accepted the previously open position of sparc Operations Manager. This is no real change since that's what he's been doing for us anyway. A note to those of you wanting to give nice sparc systems to someone who can use them, Raúl is in the market. Just keep in mind that Raúl is in Barcelona, Spain before you make him an offer. The CC to gentoo-pr and to anant is for GMN and for whatever else PR uses this sort of inforation for --- if that's the wrong way to contact GWN, please let me know. Please join me in congratulating Raúl on his now-official position in the sparc project. As I said above, I can't really say new position since this is already what he's doing for us. Thanks and regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel) signature.asc Description: This is a digitally signed message part
[gentoo-dev] rgb file specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is random musing based based on perhaps my own problems. I need a local color.file to see well what I have going on, and current xorg ignores that. Thus, at every build, there is in oscolor.c a constant I must change from 1 to 0. This is frustrating, especially since the fix is completely trivial on a USE or configure flag. As best as I can tell, xorg people have ignored my request, although it it is real. I am asking if anyone cares if one can give a local rgb file or not, or if I am stuck with fixing every update so that it will take mine so that I can see it. Perhaps no one cares but me. Well, so be it, but it slows down xorg-server testing (or upgrading) for me because I have to keep changing that file by hand. I'm really tired of fixing this trivial thing by hand. Regards, - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel, Userrel) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHkjbaQa6M3+I///cRAm3NAJ4oWcvMcAYSn+MxAg+RBNiRAC6+AACghTHr QvlQV65GYVva2FHttZmnyQU= =HzFW -END PGP SIGNATURE- éí¢^¾X¬¶È Ú(¢¸j)b b²
Re: [gentoo-dev] Projects and subproject status
For sparc: 1. Are we fine? Qualified yes. We are understaffed and at some point burn out is going to catch up with us. At the moment we seem to be keeping up, largely because of the superhuman efforts of Raúl Porcel (armin76). Also because of his and agaffney's efforts, we are on track for release. We have a couple open lead positions which I would like to fill, but I guess that won't happen until I spend some time on it. See the sparc project pages if you are interested in joining a fun, dynamic project. :) 2. What are we going to do? - Recruit, I hope. Especially AT's on path leading to developer status. - Otherwise, pretty much what we are doing. As an architecture project, our primary goal is to keep sparc as current and stable as possible, and I believe we are working to do just that. Regards, Ferris (sparc lead) -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
On Wed, 2008-01-09 at 11:51 -0800, Chris Gianelloni wrote: On Wed, 2008-01-09 at 14:00 +, Ferris McCormick wrote: they get to devrel because you ensured there would be no one to catch them --- you are the one who wanted to kill off the proctors, after all. ...and the finger-pointing starts... Bravo! I never have been able to figure out what the hell I did to you to make you feel like you need to personally attack me every step of the way, but I'm not putting up with it, anymore. I'm adding Developer Relations to this email and will be filing a formal complaint against you. Have a good day. To the extent you see this as a personal attack, I apologize. I never intended it as such. I was only recalling your email from 5 June which reads: On Tue, 2007-06-05 at 21:52 +0100, Ciaran McCreesh wrote: On Tue, 05 Jun 2007 21:44:23 +0100 Roy Bamford [EMAIL PROTECTED] wrote: For that reason alone, it should normally be avoided in international forums such as are provided by Gentoo. Why yes! Gentoo needs to be one hundred percent serious and entirely not fun. Anyone saying anything remotely amusing needs to be shut down by the proctors immediately. Please keep up the good work. I really have to agree with you. The proctors have completely lost their way. They are ineffective. They tend to compound the problems they were created to stop. They are slow. They have not prevented anything, which was the reason for their creation. Rather, what they *have* done is stifle conversation, piss off people, get in the way of Developer Relations reports, and otherwise making developers feel like they don't want to participate in our official discussion channels. What do I think needs to be done? The proctors project needs to go away. It simply wasn't implemented in the way the Council had hoped and has proven to be more harmful than the original problems to morale and inter-developer trust. While the individual members might be doing what they think is best and trying their best, they've failed at the goals of improving our communications channels. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation = From this I inferred you were the one who wanted to kill off the proctors. I am not attacking you: I am saying there is no way to catch CoC violations because the mechanism for that was the proctors, we don't have any proctors, and it seems to me (The proctors project needs to go away) that you were instrumental in that. If any of this is incorrect, I'll retract it, but I am trying to be factually correct and what I have is the above email. As for filing a devrel complaint, do so if you must. But as you know, policy strongly suggests you should talk to me first so we can figure out where the miscommunication is. We also might discuss why you chose to hang an attack on devrel onto my rather innocuous musings. Sorry for any confusion, Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Item for 10 Jan 2008 Council meeting
As always, I'd like a status report on Code of Conduct, with three questions in mind: 1) Do we have an implementation schedule? ; 2) Have we identified some warm bodies for it?; 3) Most devrel requests seem really to relate to CoC violations. Would you like us to bounce those to the CoC people, process them using CoC rules, or keep doing what we are doing now (generally, close them with a note explaining why or mediate them)? (I'm talking about the He's being rude/sarcastic/disrespectful sorts of things which really need to be processed immediately and merit a warning or brief suspension if anything.) Thanks, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer: Justin Bronder (jsbronder)
On Fri, 2007-11-16 at 14:40 +0200, Petteri Räty wrote: It's my usual please to announce a new ebuild monkey. Justin hails from Brighton, Massachusetts. His educational background should provide a good theoretical approach to all the future flames on gentoo-dev: I'm pretty much self taught computer wise as I went to the University of Maine in order to get my Master's in Mathematics where I focused on abstract algebra and number theory, I liked the challenges of discovering proofs, and pretty much ignored any real applications. Please give him the normal welcome. Regards, Petteri Justin, welcome. Perhaps you ran into the Banach-Tarski paradox, at least, so that you know how to make mountains out of molehills. (Necessary for any good flame war.) Sorry about that. Other mathematicians always welcome. :) PS. Uncle Seemant told me he was mentoring him so that he could himself retire at some point so now it's time to start persuading him to stay again :) Regards and welcome, 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] New eclass: emul-linux-x86.eclass
On Wed, 2007-11-14 at 14:53 +0100, Torsten Rehn wrote:
On Wednesday 14 November 2007 14:21, you wrote:
But why is it standard to quote other assignments like in DESCRIPTION and
HOMEPAGE then?
When assigning literal values as in DESCRIPTION and HOMEPAGE, you have to
quote. ${WORKDIR} is quoted on its assignment and therefore does not have to
be quoted when assigning its value to another variable (${S}) by reference.
Note, however, that for example in /usr/lib/portage/bin/ebuild.sh, it's
always quoted (except once, which looks like an oversight). Example:
ebuild.sh:1081: if [ ${PORTAGE_BUILDDIR}/.tested -nt ${WORKDIR} ];
then
or
ebuild.sh:1090: cd ${WORKDIR}
(The line that looks like an oversight is:
ebuild.sh:1019: if [[ ${PORTAGE_BUILDDIR}/.compiled -nt ${WORKDIR} ]] ;
then
)
[EMAIL PROTECTED] cat test.sh
#!/bin/bash
TEXT=A B
Q=${TEXT}
echo ${TEXT}
FAIL=DONT TRYTHISATHOME
[EMAIL PROTECTED] ./test.sh
A B
./test.sh: line 5: TRYTHISATHOME: command not found
--
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: USE flag transition: tetex and latex
On Wed, 2007-11-07 at 09:13 +0100, Alexis Ballier wrote: Hi, Yes, we should introduce tex, latex and kpathsea USE flags. Anyone? +1 for latex kpathsea. How/when do we start ? :) I'd say start moving useflags on a per package basis, making them local for now. Once there are enough, let us move to a global one. Once this is finished, let us deprecate the tetex useflag. +0.5 for tex: it's a good idea, but I dont know about any package using only tex and not latex (and where it would be optional). Perhaps I'm wrong there. I don't think documentation using texinfo.tex (the documentation that comes in .texi files) uses latex --- I believe that texinfo.tex uses just plain tex. Alexis. 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] jmbsvicetto is now Sparc AT Subproject Lead
All, I'm pleased to announce that Jorge Manual B S Vicetto [EMAIL PROTECTED] has taken the lead of the Sparc AT (Architecture Testers) subproject. As you know, Jorge has been a member of the Sparc AT subproject from its beginning, and he was willing to become its lead when I begged him to do so. Please give him the usual Gentoo words of encouragement for which we are so well known. My thanks to Jorge, and to all, 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] Monthly Gentoo Council Reminder for October
On Mon, 2007-10-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. Two topics: The first substantive, the second procedural. Substantive --- It is not clear whether or not Gentoo currently has a Code of Conduct or even if the Council wishes it to. As you know, we do have a draft of one, at least, but it is not complete. Now, that in itself is not a problem because a final Code requires an iterative process based on experience and feedback. If we start with a final Code of Conduct, it will be wrong and subject to revision anyway. What are not clear are (1) whether the Code of Conduct is in effect; (2) if so, how we enforce it. Code of Conduct explicitly calls out a Proctors group as its executive arm, but previous Council disbanded the proctors. So as it stands, if we are serious about a Code of Conduct, we have to resurrect the proctors or some equivalent enforcement mechanism. If we are not serious about having a Code of Conduct, I'd like Council to explain why not. (As an aside, I will mention that devrel does receive complaints on occasion which would properly fall under the Code of Conduct and proctor control --- either because any policy violation complained of falls under the Code of Conduct better than under a devrel problem, or because it is a user/developer issue, or because by the time it gets to us it's stale, or You might get the idea.) Anyway, Code of Conduct status needs clarification and action. I can go on with this at length, but perhaps this reply is not the place for it. Procedural -- The election for this Council and its aftermath shows that we are not sure how to handle a situation in which it appears a candidate will not be able to serve if elected. As a more extreme example than the one we faced this time, suppose a candidate resigns or is suspended. I am still not sure, for example, who are actually Council members right now. 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/ Flames to someplace else, please. Otherwise, as always, comments, corrections, additions, etc. welcome. 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] Additions to the Gentoo Sparc architecture project.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sparc wishes to announce the following additions to the Gentoo Sparc project: 1. armin76 (Raúl Porcel) has joined the sparc developers working primarily on security matters; 2. bluebird (Friediech Oslage) has joined sparc as an AT (Architecture Tester); 3. ezod (Aaron Mavrinac) has joined sparc as an AT. Congratulations and thanks to all of you. Everyone else, please help welcome these three new members to our project. Thanks and regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG/9rRQa6M3+I///cRAqA1AKDRGyruYuEimQg+eelv03RZZw2UfACgmSdV H4FScOCI3w9T+r8bkEbWH6A= =xvhP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Sep 2007 13:42:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: On 16:11 Wed 26 Sep , Mike Frysinger wrote: On Wednesday 26 September 2007, Christian Faulhammer wrote: Joe Peterson [EMAIL PROTECTED]: Thanks for the tip. I added failed to install genlop (via dobin) - not sure if there is a standard way to do this, as it seems many ebuilds just do dobin failed, and some do failed to install It is mainly to localise which die command caused the halt. So I know of no standard. if there is just one call to die in a function, then i usually dont bother ... but if there are multiple ones (possibly nested), then it can easily save time Cardoe was just telling me that die messages are not that useful or time-saving because portage posts the line number of the failure already. That prompts the question, should we get rid of die messages? Thanks, Donnie No. They might contain useful information. Just the line number of the failure is just frustrating: You don't really necessarily know what went wrong, and you have to go read the ebuild to find out. Users might not appreciate that. -- [EMAIL PROTECTED] mailing list Regards, - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+sspQa6M3+I///cRAr1QAJ9e1rGHNFBavGgR7pIxr1Xzaw12GgCg4lAK k5/iP9fH0kcmYlBdjTKcYrY= =BEej -END PGP SIGNATURE- éí¢^¾§¶(® X§X¬
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Sep 2007 17:42:01 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ferris McCormick wrote: On Wed, 26 Sep 2007 13:42:08 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: On 16:11 Wed 26 Sep , Mike Frysinger wrote: On Wednesday 26 September 2007, Christian Faulhammer wrote: Joe Peterson [EMAIL PROTECTED]: Thanks for the tip. I added failed to install genlop (via dobin) - not sure if there is a standard way to do this, as it seems many ebuilds just do dobin failed, and some do failed to install It is mainly to localise which die command caused the halt. So I know of no standard. if there is just one call to die in a function, then i usually dont bother ... but if there are multiple ones (possibly nested), then it can easily save time Cardoe was just telling me that die messages are not that useful or time-saving because portage posts the line number of the failure already. That prompts the question, should we get rid of die messages? Thanks, Donnie No. They might contain useful information. Just the line number of the failure is just frustrating: You don't really necessarily know what went wrong, and you have to go read the ebuild to find out. Users might not appreciate that. -- [EMAIL PROTECTED] mailing list Regards, die dobin failed or something equally vague and pointless is no less or more frustrating or informative then a line number. And arguably if there's multiple statements that contain die dobin failed in an ebuild it can set you on the wrong path and is equally and if not more frustrating. Well, I was talking about useful die messages of course. 'die dobin failed' is the same as no die message at all. Whoever wrote 'dobin ... || die dobin failed' certainly knows more than that. 'die dobin failed' of course might as well be omitted, but better, it seems to me, is to make it same something intelligent. -- [EMAIL PROTECTED] mailing list - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+ttGQa6M3+I///cRAjFwAKDeMoVxlrBaZG2t98ZTzfCMuWtdEACfUZ1I NivmnTpQL+eztQB3BOVs3CA= =pVt8 -END PGP SIGNATURE-
[gentoo-dev] New sparc Arch Tester --- tcunha
I am pleased to announce that Tiago Conha (tcunha) has joined the sparc project as an architecture tester. Tiago is already an AT for amd64, so now two architectures will keep him busy. Don't look for him on the sparc/at page --- we have just started using ATs so that page does not exist yet. We will be doing one in the next 2 or 3 days. It will look familiar, because we plan to plagiarize amd64's subproject web pages with minimal editing: Change amd64 to sparc and provide correct names for sparc. Regards, -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
[gentoo-dev] trustee nomination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I understand there are problems getting enough people to run just to fill the required slots. If that's the case, in order to get enough candidates, I'll nominate myself (and accept). Hope this helps, Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGr7dXQa6M3+I///cRAmMJAJ0Vt5XiAMEaJ0Ed9WpqFkdYccTIggCeIOpP Memd/8PUIdIbpiKArdszHP8= =MHIF -END PGP SIGNATURE-
Re: [gentoo-dev] council and proctors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jul 2007 17:08:31 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: On Sun, Jul 15, 2007 at 05:11:56PM +0200, Timothy Redaelli wrote: I have always thought that proctors/COC is useless, I vote to remove it. Proctors have already been removed in the last council meeting. As far the CoC is concerned, i'm not sure what the current status is and if anyone is supposed to enforce it atm (devrel? userrel?). I am sure not devrel. That's one reason we had proctors to begin with. Council, I guess. cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) Wernfried, regards, - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGm/1pQa6M3+I///cRAhHkAJ9Ooi4ey+bsAg9cONKbA+PxJryC3ACfZ4xz oYJUpkqvVBy4nF3LcbVKOV8= =mLhy -END PGP SIGNATURE-
Re: [gentoo-dev] ML changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 13 Jul 2007 20:13:53 -0400 Seemant Kulleen [EMAIL PROTECTED] wrote: So I should cut it, but I'm leaving it so you see what I'm responding to. Seemant, thanks. On Fri, 2007-07-13 at 10:33 -0700, Chris Gianelloni wrote: *sigh* It seems impossible to have any sort of discussion with you (unless one is in agreement with you, of course, and then one is clear headed) without eliciting a *sigh* -- I don't think it's particularly the healthiest way to have one. If you simply don't like disagreement, then please be clear about that. Why is it that everyone always assumes everything the Council does is out to get Ciaran rather than something we see as a good global solution to our current problems? Well, it would be great if the council can clearly outline what exactly our current problems are. Maybe if you presented those problems and then presented the proposed solutions to them, things would be easier to understand? Here's a little hint for all of you conspiracy theorists out there. If all we wanted was to get rid of Ciaran, we'd just have a fucking vote to get rid of Ciaran and make all of this *SO* much simpler on ourselves. This is again a disparaging and unhealthy way to have a discussion. I'm going to request that if you will respond to my notes, please do so with some modicum of civility and respect. If you find yourself unable to do so, then please do not respond to me at all. We're trying to solve the problem of people, *ALL* people, treating each other like complete crap on our lists. The problem has been an issue of discipline. We've simply got too many people who are too scared to take any actions to resolve these problems. Why do you think Developer Relations has all of these procedures and policies for retiring developers? Is it because we need all of that to determine if someone has crossed the line? No. It's because we have a large number of developers (or possibly even just a very vocal minority) who complain about every single damn thing anyone ever does and it has been much simpler to make up these ridiculous guidelines and rules to follow in an attempt to curb the dissenters than it is to just deal with them. Well, your own method of responding to my note is a good example of treating others like crap. How do we solve that? The problem with moderation is that nobody censors speech with which they agree, but quick to censor that with which they don't. So, here we have an example of one of the possible problems that you alluded to earlier: a vocal minority unable to pick its battles, and which engages in endless nitpicking. Why not just have the fucking vote to get rid of [them] and make all of this *SO* much simpler on ourselves then? Why should the vast majority of people on this list have to pay for what is, evidently, a minority? If, on the other hand, it's not a minority, then doesn't that indicate that the issue is on a deeper level? And if so, wouldn't it be more prudent to try and solve that one, instead? I say drop the rules to something simple that makes sense, boot the troublemakers, and ignore the dissenters. I'll gladly help anyone make up any procmail recipes they need to filter their mail. Let's get back to developing and leave the politics to Obama and Hillary. This is a little worrisome, you know. Perhaps you didn't mean this set of statements to sound as all-encompassing as all that. Isn't dissent and disagreement the result of differing points of view, which could actually benefit Gentoo? My thought is this: everyone should try and evaluate their own behaviour on this list, and the method in which they treat others. If each of us actually thought about the effects of our attitudes, this discussion might well be moot. Thanks, Seemant Regards, - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGmSCmQa6M3+I///cRAkgdAJ9iEiEccwXHhpobT30s7k8CTvf8JACdGMgd 1flKq6L+B4LhqrMnx9Zveic= =qIVf -END PGP SIGNATURE-
Re: [gentoo-dev] gentoo-dev-announce list
On Thu, 2007-06-21 at 20:02 -0700, Daniel Ostrow wrote: On Thu, 2007-06-21 at 14:09 -0700, Donnie Berkholz wrote: Hi all, I'm back for my yearly posting about creating a gentoo-dev-announce list [1]. Fedora recently created a fedora-devel-announce list with a great description of how it works, what's posted to it, etc [2], which got me excited about making this happen in Gentoo. Last time the issue came up, numerous people supported it, but nobody followed through to get the list created. This time, I'm going to file a bug to the infra team to make it happen. What's this mean for you? If you want to ignore -dev, you can just subscribe to -dev-announce. But you will lose your ability to participate in discussions leading toward decisions. If you have an announcement relevant to development, post it to both -dev and -dev-announce. Replies will go only to -dev. Can I get an 'AMEN'! Sure --- AMEN I like it. ++ ++ ++ some more ... oh and ++ --Dan -- 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: [RFC]: gentoo-politics ML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 12 Jun 2007 23:10:32 +0200 Benjamin Judas [EMAIL PROTECTED] wrote: Am Dienstag, den 12.06.2007, 20:46 +0100 schrieb Stephen Bennett: On Tue, 12 Jun 2007 21:00:55 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: On Mon, Jun 11, 2007 at 02:35:42PM +0200, Alexander Gabert wrote: You left the project and it's your choice to continue working with it and on it. Nonono, you got it all wrong. He didn't leave, he was fired [1]. Which means that he left, just that it wasn't his decision. Did you have anything resembling a point to make? ...which means that he has a documented history of trolling not only on mailinglists but also in irc-channels; not only against developers but also against volunteering users. Is this going anywhere useful? It certainly has the potential of generating quite a bit of heat with no content associated with it, and it is becoming disturbingly close to personal attacks. I don't think that that would be appropriate on #gentoo-anything, and I suggest taking some care before going further down this particular path. Thanks, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGbyWgQa6M3+I///cRAvYrAJ9lsCY2tPbVBF7vBYP5oBLXWok2EwCgyQce J0kMYIy7B52Yb4SkNechRIU= =afTM -END PGP SIGNATURE- éí¢^¾§¶(® X§X¬
Re: [gentoo-dev] Increasing contributions and interest via personal project aggregation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 09 May 2007 19:42:18 -0400 Daniel Drake [EMAIL PROTECTED] wrote: Donnie Berkholz wrote: I'm sure I'm not the only one with a number of projects I'll never get to, but I'd really like them to happen anyway. I suggest we create some sort of page that aggregates all of these personal projects together, so anyone can browse through them and look for stuff that sounds fun. I'd definitely throw in a few if there were some central place. Daniel And I. I like the idea. -- [EMAIL PROTECTED] 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) iD8DBQFGQmKwQa6M3+I///cRAqJsAJ4nuKxbqQ7tPhxQQM76BtK6V0a/NACfVfC/ MHSud02EDyJEscbu9HIsDC4= =QB+Z -END PGP SIGNATURE-
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 6 May 2007 16:29:22 -0400 Dan Meltzer [EMAIL PROTECTED] wrote: On Sunday 06 May 2007 4:22:44 pm Ciaran McCreesh wrote: On Sun, 6 May 2007 16:13:56 -0400 Dan Meltzer [EMAIL PROTECTED] wrote: So you want users to have to explicitly acknowledge all ewarn notices? Now *that*'s a way of making the system useless by overusing it. Err, warn notices are supposed to be important warnings. If they are not it sounds like a good job for QA. That's a completely different degree of importance. Sounds like its the right degree of importants for deprecated things upstream to me. Dan, Ciaran, Perhaps I'll come across as a spoil sport here, but is there any chance you could take your conversation to IRC (or to whatever)? It would go faster, and if you can reach some common level of agreement, then you can usefully post that to this list. -- [EMAIL PROTECTED] 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) iD8DBQFGPkM9Qa6M3+I///cRAi1mAKCjjlYDckKoENeGFLjLkaWwH1ynFQCgkOq/ +WdqXmqhJpbiuFFgEJQeSyI= =zykl -END PGP SIGNATURE- éí¢^¾§¶(® X§X¬
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thu, 2007-05-03 at 13:11 +0200, Matthias Langer wrote: ok, agreed, this is a valid point. so i would suggest, that maintainers of games where this argument applies, come to special agreements with the arch teams - or just file bugreports like this: although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like to have it stable real soon, as upstream has changed the network protocol. i have x86 and amd64 hardware available, and can confirm, that the game works nice there; so, if no one objects, i'm gonna mark lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like to have a shiny sparc keyword, but have no hardware to test. so it would be highly appreciated if someone from the sparc team can give the game a try. I can't speak for all of sparc, of course, but generally we try to accommodate requests when the package developers explain the situation. In a case like Eternal Lands, it might turn out that the best solution would be always to keep it as ~sparc, but that would have the same effect in practice as a stable keyword, because anyone playing the game on sparc would know what was going on (I would think). The key here is the bug report, and at that point the friendly sparc developers would work with you. :) but committing straight to stable on arches where the package wasn't even tested is an absolute no-do for me. DISCLAIMER: I've not read the bug mentioned as I've lost the email with it's number so I may just be talking out of my ass. no, in fact you are the first one that comes up with a valid argument, why games sometimes should go to stable almost immediately. sad, but true... 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] Re: Re: Re: Resignation
This thread is not going anywhere useful, and does not belong on -dev. There was a request to move it to gentoo-devrel if there was any need to continue it. Please do that. Me, I don't see that there's much new ground to cover at this point. 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] 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
Re: [gentoo-dev] Resignation
On Tue, 2007-04-17 at 09:04 -0500, Jeffrey Gardner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. It was recently said that if you had been the 20th or 30th person to get sanctioned, you could have just relaxed and enjoyed the vacation time. But since the CoC is fairly new, and you're the first one (that I can remember) to get suspended, it stings more than it should. Anyway, what I'm trying to say is don't take it so hard...it's not that big a deal. Small correction, just for accuracy's sake: Suspension is under devrel policy, not CoC. Otherwise, I fully agree with your last sentence. - -- Jeffrey Gardner Gentoo Developer Public PGP Key ID: 4A5D8F23 hkp://pgpkeys.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJNP3iR2KxEpdjyMRAuDcAKCYrMSWKW3vejLMGZzzQXcPVF2K4gCfcu8r 9F5Ub7g+aWGm1fD2riE5nwM= =bOk8 -END PGP SIGNATURE- 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] [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: snip 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. /snip 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
[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] 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: snip 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... snip 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
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: snip 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... snip 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] 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
[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] 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
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] 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] 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] 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] 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] 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] 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] 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 + 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
[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 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
