Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Sat, Dec 09, 2017 at 08:13:18PM -0500, Rich Freeman wrote: > On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell wrote: > > > > Other developers are required to subscribe to -dev, and are > > expected to follow it so they stay informed. > > Developers are not required to subscribe to -dev. > > > If they missed something covered on the list, they are directed to the > > archives and (usually) laughed at. > > Correct. While nobody is required to follow the lists, acting out of > ignorance usually doesn't impress others. Devs are expected to be > adults and figure out what they need to follow based on what they > intend to contribute to. -core and -dev-announce are the only > required subscriptions. > > > > > Great things coming from Gentoo "leadership" here. What will you do when > > mgorny starts targeting developers and pitching tantrums over them, too? > > You act as if this was the only reason that comrel took action. In > the cases of appeals I've seen I've yet to see a case where there > wasn't something else going on behind the scene that wasn't reasonably > severe when they've taken action. I can't vouch for their reasons in > this case as I'm not privy to them, and I imagine they're not going to > be made public. Well, let's consider the order of events here: 1. wltjr and others appear on the ML 2. Drama 3. mgorny suggests some change in structure to avoid dealing with said people. 4. more drama 5. mgorny publicly insults comrel, accusing them of doing nothing 6. mgorny publishes formal plan to reform our mailing lists 7. more drama 8. comrel bans wltjr 9. mgorny's plan is put on Council agenda 10. comrel *mails to let everyone know wltjr was banned*, despite prior claims of valuing privacy and secrecy 11. you are here This looks awfully clear to me. I'm pointing out behavior that looks a lot like one person twisting the social structure to suit their desires. This concerns me because our community will be damaged by his plan, and it is only the first step. In the second step, he will turn against developers as well. But not you and his other buddies. Just the ones *he* thinks are a problem. > > > This is precisely why we have unmotivated developers > > and a bevy of unmaintained packages; nobody wants to contribute to a > > distro that treats its users (and developers) so poorly. > > Go ahead and cite the list of people who have been banned in the last > decade. You won't run out of fingers on one hand. Some might cry > about it for months, but good luck finding another distro that hasn't > banned twice as many in the same span of years. > > And keep in mind that failing to take action isn't without > consequences. When somebody is harassing somebody else (and sometimes > more than one other) you don't really get a choice about whether > somebody is going to end up leaving, whether of their own accord or > not. That is a situation I've seen happen more than once around here > behind the scenes. Again, I have no specific knowledge about this > particular comrel action - I'm talking about situations I've seen in > the past. I'm not focused on the ban, or whether it was deserved. That's a separate subject. I'm pointing out behaviors that damage our image, our credibility, and morale. I'm calling out unequal enforcement and favoritism; these are things that you won't find in any records, because the existence of such records would damn those culpable. The fact that comrel has never acted against mgorny strongly indicates that they do not care about the way he treats others. He is kept because of his technical skill. Others do not get this convenience; we are accountable for the code *and* the words that we write. You're blind if you don't see this. > > > A distro should never bend its entire social structure to protect the > > feelings of one surly developer (or his/her entourage), > > Certainly, and that works both ways. > > > but naturally > > since every council member is friends with mgorny and comrel is afraid > > to take any action against him, they'll make exceptions to established > > procedures and ignore any complaints about the way he treats others. > > Considering that he won a significantly contested election to Council, > I suspect that more people around here approve of mgorny than just the > members of the council. And I can certainly vouch that not all > council members are necessarily fans of some of his actions, though I > suspect that his technical contributions are praised by just about all > (rightly, IMO). > > I've yet to see a discussion between Council members where people were > strongly playing favorites the way you imply. I'm not criticizing any code he's written. I do not have the same background, nor the same open schedule needed to reach that level of skill yet. This isn't a thread about code review. The fact you're trying to change the subject isn't helping you. Can we suddenly ignore it when someone's an asshole as long as they com
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Sat, Dec 9, 2017 at 7:29 PM, Daniel Campbell wrote: > > Other developers are required to subscribe to -dev, and are > expected to follow it so they stay informed. Developers are not required to subscribe to -dev. > If they missed something covered on the list, they are directed to the > archives and (usually) laughed at. Correct. While nobody is required to follow the lists, acting out of ignorance usually doesn't impress others. Devs are expected to be adults and figure out what they need to follow based on what they intend to contribute to. -core and -dev-announce are the only required subscriptions. > > Great things coming from Gentoo "leadership" here. What will you do when > mgorny starts targeting developers and pitching tantrums over them, too? You act as if this was the only reason that comrel took action. In the cases of appeals I've seen I've yet to see a case where there wasn't something else going on behind the scene that wasn't reasonably severe when they've taken action. I can't vouch for their reasons in this case as I'm not privy to them, and I imagine they're not going to be made public. > This is precisely why we have unmotivated developers > and a bevy of unmaintained packages; nobody wants to contribute to a > distro that treats its users (and developers) so poorly. Go ahead and cite the list of people who have been banned in the last decade. You won't run out of fingers on one hand. Some might cry about it for months, but good luck finding another distro that hasn't banned twice as many in the same span of years. And keep in mind that failing to take action isn't without consequences. When somebody is harassing somebody else (and sometimes more than one other) you don't really get a choice about whether somebody is going to end up leaving, whether of their own accord or not. That is a situation I've seen happen more than once around here behind the scenes. Again, I have no specific knowledge about this particular comrel action - I'm talking about situations I've seen in the past. > A distro should never bend its entire social structure to protect the > feelings of one surly developer (or his/her entourage), Certainly, and that works both ways. > but naturally > since every council member is friends with mgorny and comrel is afraid > to take any action against him, they'll make exceptions to established > procedures and ignore any complaints about the way he treats others. Considering that he won a significantly contested election to Council, I suspect that more people around here approve of mgorny than just the members of the council. And I can certainly vouch that not all council members are necessarily fans of some of his actions, though I suspect that his technical contributions are praised by just about all (rightly, IMO). I've yet to see a discussion between Council members where people were strongly playing favorites the way you imply. > Unfortunately, GLEP 39 does not have a section on recalling or > impeachment... This whole debate has been going on for over a year, and there has been an election in the interim. Do you really think that a majority of developers somehow missed the hundreds of posts on -dev the last time this debate happened? I'm not sure why you think a recall would succeed even if one were possible. Besides, the council hasn't even made any decisions here. This matter was never appealed to the council, so it seems a bit silly to hold them accountable. > This whole situation highlights why the Council has no > business sticking its head into non-technical matters. It's clearly not > up to the task. It's no surprise, since technical skill does not > guarantee or even imply social skill. (or vice-versa) Dealing with social issues is a major part of the Council's purpose, per GLEP 39. I don't think the developers were blind to this in the last election, especially considering all the fiasco this was causing in the months leading up to the election. And again, this particular issue was never appealed to the Council. I'm not sure where else you would see something like this appealed. The Trustees have struggled with simply filing the tax returns. If you don't think that somebody can have both technical and social skills, I'm not sure why you think that somebody could have both financial/legal and social skills. > Would you have done anything different if it were me or some > other developer who was proposing this change? What change are you proposing? > It wouldn't have made it to the Council agenda if he didn't write it, > period. Everyone else would've been told to suck it up and deal with it. This is silly. Go ahead and find a single example of ANYTHING submitted by ANYBODY for the Council agenda which didn't make it onto the agenda in the last five years. I can't vouch for how things worked a decade ago but the process is basically that if somebody replies to the call for agenda items, it goes on the agenda. That doe
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote: > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson Jr.: > > > > The day everyone wanted has come, after this message. I will > > unsubscribe not to return. You all won in 2008, and again in 2017. > > Though this time I will not be back. I tried more than most anyone else > > would for a very long time. Gentoo wins I lose, I am fine with that. > > > > Please do not contact me off list in IRC or at all. I am done with the > > Gentoo community! > > > Independent of whether William now unsubscribed or not, he's now enjoying a > lengthy (1 year until review) vacation from all Gentoo communication channels. > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer (council, perl, libreoffice) So, mgorny threatened to leave if something wasn't done, right? I saw the IRC conversation about unsubscribing from gentoo-dev, as well. IRC is not private, for the record. Other developers are required to subscribe to -dev, and are expected to follow it so they stay informed. If they missed something covered on the list, they are directed to the archives and (usually) laughed at. I see no reason for this expectation to be waived for any single developer. Do I get a free pass if I don't like what someone says? It's not enough to let wltjr leave on his own; you had to create a ban and add a smug, tongue-in-cheek mail to it to maintain the image of doing something. Quite hypocritical of comrel's attitude of secrecy to suddenly announce a ban. It seems to me that secrecy is only adopted when it suits those who stand to benefit from it. Great things coming from Gentoo "leadership" here. What will you do when mgorny starts targeting developers and pitching tantrums over them, too? Are we going to stratify developership further, too? It seems rather clear to me that a few individuals see themselves as the owners of this distro and bend it to suit their whims, using bureacracy to obscure their actions and motivations, segment the community, and block those less experienced. This is precisely why we have unmotivated developers and a bevy of unmaintained packages; nobody wants to contribute to a distro that treats its users (and developers) so poorly. A distro should never bend its entire social structure to protect the feelings of one surly developer (or his/her entourage), but naturally since every council member is friends with mgorny and comrel is afraid to take any action against him, they'll make exceptions to established procedures and ignore any complaints about the way he treats others. Software cannot fix wetware. Plenty of developers get to deal with mgorny's aggressive and insulting tone, yet nothing happens. Gee... I wonder why. Maybe because the upper parts of Gentoo are riddled with cronyism. "Rules for thee, not for me." It's clear to anyone with eyeballs that there is preferential treatment and inconsistent enforcement of rules in this community, and the people in a position to fix it, won't, because they in fact benefit from this. Unfortunately, GLEP 39 does not have a section on recalling or impeachment... This whole situation highlights why the Council has no business sticking its head into non-technical matters. It's clearly not up to the task. It's no surprise, since technical skill does not guarantee or even imply social skill. (or vice-versa) I'm tired of people beating around the bush and the facile attempts of tact: why do you give special treatment to certain members of this community? Would you have done anything different if it were me or some other developer who was proposing this change? It wouldn't have made it to the Council agenda if he didn't write it, period. Everyone else would've been told to suck it up and deal with it. And knowing how the Council is, in a few days we'll all get to deal with the churn of mailing lists to protect one person's ego. Sad. ~zlg -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] amd64 17.1 profiles ready for testing
Le 09/12/17 à 22:00, Michał Górny a écrit : > W dniu sob, 09.12.2017 o godzinie 21∶47 +0100, użytkownik Xavier Miller > napisał: >> >> Tool doesn't work with no-multilib profiles: > > Are you using the old version? Version 2 was fixed to support no- > multilib, and you certainly should update the package to the newest > version (3) before using it. Version 3 is OK, I didn't resync portage before emerging it ;) Migration in progress. Xavier. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] amd64 17.1 profiles ready for testing
On 12/09/2017 04:00 PM, Michał Górny wrote:
>
> rm -r /lib.{old,new} /usr/lib.{old,new}
>
It probably won't hurt anything, but that should be run in BASH.
Re: [gentoo-dev] amd64 17.1 profiles ready for testing
W dniu sob, 09.12.2017 o godzinie 21∶47 +0100, użytkownik Xavier Miller
napisał:
>
> Le 09/12/17 à 11:26, Michał Górny a écrit :
> > Hi, everyone.
> >
> > I've pushed a commented out set of 17.1 profiles for amd64 that feature
> > the long-overdue SYMLINK_LIB=no setup. I'd really appreciate some real
> > testing.
> >
> > Warning: there is a slight risk of breaking your system, in particular
> > multilib libraries and/or programs.
> >
> >
> > To switch to the new profiles (from 13.0 or 17.0):
> >
> > emerge -1v app-portage/unsymlink-lib
> > unsymlink-lib --analyze
>
> Hi,
>
> Tool doesn't work with no-multilib profiles:
Are you using the old version? Version 2 was fixed to support no-
multilib, and you certainly should update the package to the newest
version (3) before using it.
>
> # unsymlink-lib --migrate
> /lib32 & /lib -> /lib.new ...
> cp: impossible d'évaluer '/lib32/.': no such file or directory
> Non-successful return from cp: 1
>
> And I cannot do --finish or --rollback.
>
> What can I do?
rm -r /lib.{old,new} /usr/lib.{old,new}
--
Best regards,
Michał Górny
Re: [gentoo-dev] amd64 17.1 profiles ready for testing
Le 09/12/17 à 11:26, Michał Górny a écrit : > Hi, everyone. > > I've pushed a commented out set of 17.1 profiles for amd64 that feature > the long-overdue SYMLINK_LIB=no setup. I'd really appreciate some real > testing. > > Warning: there is a slight risk of breaking your system, in particular > multilib libraries and/or programs. > > > To switch to the new profiles (from 13.0 or 17.0): > > emerge -1v app-portage/unsymlink-lib > unsymlink-lib --analyze Hi, Tool doesn't work with no-multilib profiles: # unsymlink-lib --migrate /lib32 & /lib -> /lib.new ... cp: impossible d'évaluer '/lib32/.': no such file or directory Non-successful return from cp: 1 And I cannot do --finish or --rollback. What can I do? Kind regards, Xavier Miller. signature.asc Description: OpenPGP digital signature
[gentoo-dev] amd64 17.1 profiles ready for testing
Hi, everyone. I've pushed a commented out set of 17.1 profiles for amd64 that feature the long-overdue SYMLINK_LIB=no setup. I'd really appreciate some real testing. Warning: there is a slight risk of breaking your system, in particular multilib libraries and/or programs. To switch to the new profiles (from 13.0 or 17.0): emerge -1v app-portage/unsymlink-lib unsymlink-lib --analyze Check the output for any suspicious entries, then follow the instructions it prints. Once all is done, you can either uncomment the masked profile entries or set profile manually, e.g.: eselect profile set --force default/linux/amd64/17.1/desktop (--force is needed since the profile is commented out) If migrating from 13.0, the notes from 17.0 migration apply as well. Detailed migration guide 1. Sync and upgrade your system to avoid rebuild issues. 2. Install app-portage/unsymlink-lib. 3. Run 'unsymlink-lib --analyze' and verify the results. [at this point: do not call emerge or modify /usr manually] 4. Make a backup unless you're brave and/or the other thing. 5. Run 'unsymlink-lib --migrate'. 6. Reboot your system and see if it still boots, possibly test if important programs work. Also check if emerge starts but don't install anything. If your system is now broken, you can do 'unsymlink-lib --rollback' to return to step 3. 7. Run 'unsymlink-lib --finish'. [at this point you can start using emerge again] 8. Rebuild gcc. If you're switching from 13.0, also binutils & glibc according to that news item. 9. If you're using a multilib profile, rebuild 32-bit packages. Alternatively, if you're switching from 13.0 you can try the full-tree rebuild. 10. Once all 32-bit libraries are rebuilt, the PM should just remove /lib32 and /usr/lib32 symlinks. If it doesn't, remove them manually. -- Best regards, Michał Górny
