Re: [gentoo-dev] Mailing list moderation and community openness

[Eray Aslan]

On Tue, Mar 20, 2018 at 10:28:48AM -0500, Matthew Thode wrote:
> While I personally do no agree with mailing list moderation infra has
> been tasked with moving forward on it.

You can always resign from infra.

That was a somewhat tongue-in-cheek comment but not wholly.  You cant
cop out by saying it was an order from council.  I understand if you
dont but do consider it.  Fight the good fight.

-- 
Eray

Re: [gentoo-dev] Mailing list moderation and community openness

[Paweł Hajdan , Jr .]

On 20/03/2018 05:17, Michael Palimaka wrote:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
> 
> 1: https://bugs.gentoo.org/650964

This is a controversial topic which continues to be rehashed.

I think it'd be good for people opposing it (I share at least some of
your concern) to make sure they read the following resources and suggest
the best means to keep our community a nice place.





Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Herb Miller Jr .]

On 03/20/2018 07:50 PM, Benda Xu wrote:
> Hello Herb,
>
> "Herb Miller Jr."  writes:
>
>> When I did my homework on creating nodejs ebuilds (not nodejs itself
>> but packages written in node), it seems the topic has come up a few
>> times in the past but the time commitment and general disorganization
>> of upstream has scared off any serious attempts at packaging.
>>
>> Seeing as there has been interest in nodejs packages, and in the end
>> we could be talking 400-600+ packages, would it be possible to create
>> dev-libs/nodejs category? I would be happy to write and proxy-maintain
>> ebuilds for a large number of them to get things in motion. I've
>> already opened pull request #7427 [1] for chalk and its
>> dependencies. I'm aiming to build up to all the dependencies needed
>> for Visual Studio Code OSS.
>>
>> [1]:https://github.com/gentoo/gentoo/pull/7427
> Your effort will be much appreciated.  I support your plan.
>
> Should the category be dev-js intead?  To me, node.js is but an
> implementation of javascript runtime.
>
>
> BTW, for the 400-500 packages, are you going to create them with a
> generator script?
>
> Cheers,
> Benda
>
>
Hopefully by the time it gets to that many I won't be the only one
creating/maintaining them. If I am, then yes, some kind of automation
would be the only sane way to keep up. I figure I'll face that challenge
when I get there. As I'm writing them I am seeing a general skeleton
forming that most of them fit into.


Herb Miller Jr.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[M. J. Everitt]

On 21/03/18 01:27, Kent Fredric wrote:
> On Tue, 20 Mar 2018 14:48:29 -0400
> Michael Orlitzky  wrote:
>
>> There's a real technical problem hidden in there. Since npm
>> (recursively!) bundles every dependency, nobody worries about
>> compatibility in their JS packages. You'll quickly find yourself stuck.
> Honestly, I expected at some point we'd reach for slotting and normalization,
> and recursive trees of symlinks
>
> eg: 
>   /usr/lib/nodejs///lib/  -> 
> /usr/lib/nodejs//
>
> Or something like that.
>
> So you'd wind up with
>
>   /usr/lib/nodejs/foo/1.0/lib/bar  -> /usr/lib/nodejs/bar/1.0
>   /usr/lib/nodejs/foo/1.0/lib/baz  -> /usr/lib/nodejs/baz/2.0
> /usr/lib/nodejs/bar/1.0/lib/baz  -> /usr/lib/nodejs/baz/1.0
> /usr/lib/nodejs/baz/1.0/...
> /usr/lib/nodejs/baz/2.0/...
>
> Or something like that. But I imagine constructing such a thing a
> rather painful exercise.
>
 Said the voice of bitter experience ... *eg* :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Kent Fredric]

On Tue, 20 Mar 2018 14:48:29 -0400
Michael Orlitzky  wrote:

> There's a real technical problem hidden in there. Since npm
> (recursively!) bundles every dependency, nobody worries about
> compatibility in their JS packages. You'll quickly find yourself stuck.

Honestly, I expected at some point we'd reach for slotting and normalization,
and recursive trees of symlinks

eg: 
/usr/lib/nodejs///lib/  -> 
/usr/lib/nodejs//

Or something like that.

So you'd wind up with

/usr/lib/nodejs/foo/1.0/lib/bar  -> /usr/lib/nodejs/bar/1.0
/usr/lib/nodejs/foo/1.0/lib/baz  -> /usr/lib/nodejs/baz/2.0
/usr/lib/nodejs/bar/1.0/lib/baz  -> /usr/lib/nodejs/baz/1.0
/usr/lib/nodejs/baz/1.0/...
/usr/lib/nodejs/baz/2.0/...

Or something like that. But I imagine constructing such a thing a
rather painful exercise.



 


pgp2r11X0fk7L.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: FYI: Mastersync is down

[Alec Warner]

On Tue, Mar 20, 2018 at 5:32 PM, Alec Warner  wrote:

> Disk maintenance is ongoing from now for +2h while we swap disks.
>
> Because I'm pessimistic, I expect funny business during the swap; so
> maintenance may extend further out.
>
> If all goes well, the disks in the new hardware should be a good fit and
> master-rsync should return to service after the maintenance.
>

The maintenance is complete and we have dipper-disks-in-blackcap-chassis.

As expected there were *significant* shenanigans. However they were
overcome and the box is back online.

We will monitor for the next 48 hours for problems and resolve the
maintenance notice if we don't observe any regressions.

-A


>
> -A
>
> On Mon, Mar 19, 2018 at 9:13 PM, Alec Warner  wrote:
>
>> This is just an FYI: https://infra-status.gentoo.org/
>>
>> Hoping to have this fixed in a couple of days. In the meantime you may
>> see missing snapshots (for emerge webrsync) and no rsync propagation.
>>
>> -A
>>
>
>

Re: [gentoo-dev] Mailing list moderation and community openness

[Rich Freeman]

On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu  wrote:
> William Hubbs  writes:
>
>> I do feel that this decision reflects badly on us as a community and
>> should be reversed immediately. The proper way to deal with people who
>> have bad behavior is to deal with them individually and not put a
>> restriction on the community that is not necessary.
>
> I agree with William.  Dealing with individuals makes more sense.
>
> It boils down to an attitude of assuming outsiders are good (blacklist
> to ML) or bad (whitelist to ML) by default.

Actually, I think it is more of a technical constraint.  It is
basically impossible to blacklist somebody on a mailing list, since
all they need to do is roll up a new email address.

I can think of various arguments for whitelisting or not whitelisting,
but it seems silly to blacklist.

-- 
Rich

Re: [gentoo-dev] Fwd: understanding gentoo

[Benda Xu]

Abhishek,

Abhishek Kumar  writes:

> -- Forwarded message --
> From: Abhishek Kumar 
> Date: Tue, Mar 20, 2018 at 12:48 PM
> Subject: understanding gentoo
> To: gentoo-dev@lists.gentoo.org
>
> Hi Everyone
>
> I want to know the code that belongs to news items after updating port
> tree.Explain its implementation also.
>
> Thank You

If you are aiming for summer of code, move your question to
gentoo-soc@l.g.o.  If you are interested in the internals of portage,
read the code first and ask on gentoo-portage@l.g.o.

I don't think anyone will explain its implementation to you unless you
do the study and show your competence first.  Your behavior of
re-posting the same message is considered rude.

Yours,
Benda

Re: [gentoo-dev] Mailing list moderation and community openness

[Benda Xu]

William Hubbs  writes:

> I do feel that this decision reflects badly on us as a community and
> should be reversed immediately. The proper way to deal with people who
> have bad behavior is to deal with them individually and not put a
> restriction on the community that is not necessary.

I agree with William.  Dealing with individuals makes more sense.

It boils down to an attitude of assuming outsiders are good (blacklist
to ML) or bad (whitelist to ML) by default.

Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Benda Xu]

Hello Herb,

"Herb Miller Jr."  writes:

> When I did my homework on creating nodejs ebuilds (not nodejs itself
> but packages written in node), it seems the topic has come up a few
> times in the past but the time commitment and general disorganization
> of upstream has scared off any serious attempts at packaging.
>
> Seeing as there has been interest in nodejs packages, and in the end
> we could be talking 400-600+ packages, would it be possible to create
> dev-libs/nodejs category? I would be happy to write and proxy-maintain
> ebuilds for a large number of them to get things in motion. I've
> already opened pull request #7427 [1] for chalk and its
> dependencies. I'm aiming to build up to all the dependencies needed
> for Visual Studio Code OSS.
>
> [1]:https://github.com/gentoo/gentoo/pull/7427

Your effort will be much appreciated.  I support your plan.

Should the category be dev-js intead?  To me, node.js is but an
implementation of javascript runtime.


BTW, for the 400-500 packages, are you going to create them with a
generator script?

Cheers,
Benda

[gentoo-dev] Last-rites: bitcoincore.eclass

[Andreas Sturmlechner]

bitcoincore.eclass: Mark @DEAD for removal

No consumers left in Gentoo ebuild repository.

Re: [gentoo-dev] Re: FYI: Mastersync is down

[Aaron Bauman]

On Tue, Mar 20, 2018 at 05:32:23PM -0400, Alec Warner wrote:
> Disk maintenance is ongoing from now for +2h while we swap disks.
> 
> Because I'm pessimistic, I expect funny business during the swap; so
> maintenance may extend further out.
> 
> If all goes well, the disks in the new hardware should be a good fit and
> master-rsync should return to service after the maintenance.
> 
> -A

Thank you for your dedicated work, Alec :)


signature.asc
Description: Digital signature

[gentoo-dev] Fwd: understanding gentoo

[Abhishek Kumar]

-- Forwarded message --
From: Abhishek Kumar 
Date: Tue, Mar 20, 2018 at 12:48 PM
Subject: understanding gentoo
To: gentoo-dev@lists.gentoo.org


Hi Everyone
I want to know the code that belongs to news items after updating port
tree.Explain its implementation also.

Thank You

[gentoo-dev] Re: FYI: Mastersync is down

[Alec Warner]

Disk maintenance is ongoing from now for +2h while we swap disks.

Because I'm pessimistic, I expect funny business during the swap; so
maintenance may extend further out.

If all goes well, the disks in the new hardware should be a good fit and
master-rsync should return to service after the maintenance.

-A

On Mon, Mar 19, 2018 at 9:13 PM, Alec Warner  wrote:

> This is just an FYI: https://infra-status.gentoo.org/
>
> Hoping to have this fixed in a couple of days. In the meantime you may see
> missing snapshots (for emerge webrsync) and no rsync propagation.
>
> -A
>

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Michael Orlitzky]

On 03/20/2018 04:14 PM, Herb Miller Jr. wrote:
> That is scary. I hadn't noticed there are node_modules directories under
> many node modules and that npm list outputs different versions of the
> same dependency. To help me better understand the situation, when you
> see this happen does "bar-1.0" normally depend on "baz-1.0" because...
> 
> A) There is some huge technical hurdle in upgrading to "baz-2.0"?
> B) I was too lazy or didn't care to upgrade to "baz-2.0"?
> C) My package.json is outdated?
> 
> If A, can you point me to a good example I can take a look at?

It's usually B or C, but I hit several cases where there was a real
incompatibility. When I opened Github issues, I got a lot of WONTFIX
responses telling me that I have to use npm.

No particular examples come to mind, though -- this was about 2.5 years ago.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Herb Miller Jr .]

On 03/20/2018 02:48 PM, Michael Orlitzky wrote:
> On 03/20/2018 07:50 AM, Herb Miller Jr. wrote:
>> When I did my homework on creating nodejs ebuilds (not nodejs itself but
>> packages written in node), it seems the topic has come up a few times in
>> the past but the time commitment and general disorganization of upstream
>> has scared off any serious attempts at packaging.
> There's a real technical problem hidden in there. Since npm
> (recursively!) bundles every dependency, nobody worries about
> compatibility in their JS packages. You'll quickly find yourself stuck.
>
> For example, if you want to package an end-user application "foo", it
> might depend on libraries "bar-1.0" and "baz-2.0". But then "bar-1.0"
> itself depends on "baz-1.0". What do you do? Slot everything? How do you
> make NodeJS look in the right place? You're going to need a plan,
> because this situation is not at all uncommon.
>
That is scary. I hadn't noticed there are node_modules directories under
many node modules and that npm list outputs different versions of the
same dependency. To help me better understand the situation, when you
see this happen does "bar-1.0" normally depend on "baz-1.0" because...

A) There is some huge technical hurdle in upgrading to "baz-2.0"?
B) I was too lazy or didn't care to upgrade to "baz-2.0"?
C) My package.json is outdated?

If A, can you point me to a good example I can take a look at? If it's
normally B or C, I have no problem making lots of upstream pull
requests. It's just Javascript. Though I understand that's not a true
solution in the long-run and has burnout written all over it. I'll have
to give the problem much more thought.


Herb Miller Jr.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Herb Miller Jr .]

Indeed I did. Thank you for pointing that out. It had been a long night.


Herb Miller Jr.


On 03/20/2018 02:34 PM, Michał Górny wrote:
> W dniu wto, 20.03.2018 o godzinie 07∶50 -0400, użytkownik Herb Miller
> Jr. napisał:
>> When I did my homework on creating nodejs ebuilds (not nodejs itself but
>> packages written in node), it seems the topic has come up a few times in
>> the past but the time commitment and general disorganization of upstream
>> has scared off any serious attempts at packaging.
>>
>> Seeing as there has been interest in nodejs packages, and in the end we
>> could be talking 400-600+ packages, would it be possible to create
>> dev-libs/nodejs category? I would be happy to write and proxy-maintain
>> ebuilds for a large number of them to get things in motion. I've already
>> opened pull request #7427 [1] for chalk and its dependencies. I'm aiming
>> to build up to all the dependencies needed for Visual Studio Code OSS.
> I think you meant 'dev-nodejs'.
>
>> [1]:https://github.com/gentoo/gentoo/pull/7427
>>
>> 
>> Herb Miller Jr.
>>

[gentoo-dev] IPFS source mirror

[Stephen Christie]

Has there been any investigation of IPFS or a similar distributed object store 
for as an optional source mirror? That would let anyone be a partial mirror of 
the sources they keep, and spread bandwidth across the network.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Michael Orlitzky]

On 03/20/2018 07:50 AM, Herb Miller Jr. wrote:
> When I did my homework on creating nodejs ebuilds (not nodejs itself but
> packages written in node), it seems the topic has come up a few times in
> the past but the time commitment and general disorganization of upstream
> has scared off any serious attempts at packaging.

There's a real technical problem hidden in there. Since npm
(recursively!) bundles every dependency, nobody worries about
compatibility in their JS packages. You'll quickly find yourself stuck.

For example, if you want to package an end-user application "foo", it
might depend on libraries "bar-1.0" and "baz-2.0". But then "bar-1.0"
itself depends on "baz-1.0". What do you do? Slot everything? How do you
make NodeJS look in the right place? You're going to need a plan,
because this situation is not at all uncommon.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Michał Górny]

W dniu wto, 20.03.2018 o godzinie 07∶50 -0400, użytkownik Herb Miller
Jr. napisał:
> When I did my homework on creating nodejs ebuilds (not nodejs itself but
> packages written in node), it seems the topic has come up a few times in
> the past but the time commitment and general disorganization of upstream
> has scared off any serious attempts at packaging.
> 
> Seeing as there has been interest in nodejs packages, and in the end we
> could be talking 400-600+ packages, would it be possible to create
> dev-libs/nodejs category? I would be happy to write and proxy-maintain
> ebuilds for a large number of them to get things in motion. I've already
> opened pull request #7427 [1] for chalk and its dependencies. I'm aiming
> to build up to all the dependencies needed for Visual Studio Code OSS.

I think you meant 'dev-nodejs'.

> 
> [1]:https://github.com/gentoo/gentoo/pull/7427
> 
> 
> Herb Miller Jr.
> 

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Mailing list moderation and community openness

[Kristian Fiskerstrand]

On 03/20/2018 04:28 PM, Matthew Thode wrote:
> On 18-03-20 23:17:52, Michael Palimaka wrote:
>> I see that in bug #650964[1] Council is pushing forward again with
>> implementing user whitelisting on this mailing list (ie. anyone that is
>> not "approved" will have their mail rejected).
>>
>> Could someone please explain how this doesn't directly contradict the
>> core tenets of an open and inclusive community?
>>
>> 1: https://bugs.gentoo.org/650964
>>
> While I personally do no agree with mailing list moderation infra has
> been tasked with moving forward on it.  In that vein, this is what we
> are proposing.
> 
> Install and configure mailman3/hyperkitty/postorius once they all
> support python3.  Specifically we wish to use docker-mailman for this so
> we can easilly redeploy this on diferent machines as needed.
> 
> mailman3 gives us two good things, it has support for moderation (for
> better or worse) and it handles senders using dmarc.
> 
> There are still some issues with it infra side (archiving will still
> have to use the old system) and moving mailing lists is going to be fun,
> but them the breaks.

Switching to mailman might have some good merits on its own, but as I
understand it it isn't necessary for the proposal at hand, that can be
solved using access control lists in mlmmj-process?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] things becoming better and better

[Toralf Förster]

On 03/19/2018 08:07 PM, M. J. Everitt wrote:
> Hopefully, moving forward there will be less
> human effort required to extend and maintain the tree of packages on
> which we depend, and together with QA, huge strides forward are being
> made to achieve this end.

Indeed,

automation of QA and other checks is a big step towards to have the tree
in a good shape.

(BTW I like the funny name "croaker" in IRC) - and IMO a lot of
improvement was made in that area.

-- 
Toralf
PGP 23217DA7 9B888F45




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-project] Re: [gentoo-dev] Mailing list moderation and community openness

[Rich Freeman]

On Tue, Mar 20, 2018 at 9:41 AM, Gregory Woodbury  wrote:
> On gentoo-dev list: k_f
> points out that this should have been talked about during previous
> discussion periods...
>
> It was discussed "to death" over and over, and many argued against it
> till they were blue in the face.

Indeed, it will probably still be discussed over and over up until the
point where those who disagree are either unable to post on the lists,
or told that it is off-topic and will result in them losing access to
post on the lists.

Seriously, everything that has been said today in this thread was said
in the last thread on this topic.  The whole reason we have GLEP 39 is
that there are simply topics that not everybody will agree on...

-- 
Rich

Re: [gentoo-dev] Mailing list moderation and community openness

[William Hubbs]

On Tue, Mar 20, 2018 at 04:44:26PM +0100, Alexander Berntsen wrote:
> On 20/03/18 13:17, Michael Palimaka wrote:
> > Could someone please explain how this doesn't directly contradict the
> > core tenets of an open and inclusive community?
> It's fairly simple to produce a justification of the decision. I can
> think of several ways of doing so. One is through an appeal to some
> notion of community health improvement from impeding toxic contributors.
> In this strategy, the argument would be something pertaining to how
> allowing these toxic posters free rein on the mailing list would
> contradict the core tenet of an open and inclusive community. There are
> several more ways to rationalise the decision.
> 
> But you won't buy into either of those purported vindications of this
> decision. (I won't either.) So don't bother requesting them. Another
> aimless (and thus endless) back and forth in Jackal language isn't
> likely to achieve anything worthwhile beyond what the initial exchange
> achieved.

As the council member who voted against this decision, I am going to
express my opinion, even though it will be unpopular with the majority of
the council and probably others as well.

I do feel that this decision reflects badly on us as a community and
should be reversed immediately. The proper way to deal with people who
have bad behavior is to deal with them individually and not put a
restriction on the community that is not necessary.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[Pengcheng Xu]

I can understand the need to reduce meaningless spams on the dev list,
but seems like general rejection of posts from non-developers would
distract the idea of this being an open mailing list: a list that one can’t
post to effectively decays to something like a bulletin board, and obviously
the developing process shouldn’t be kept in a showcase, which would greatly
discourage people who are not part of the dev team, yet still wanting to
get involved in the discussing, maybe even decision-making.

Pengcheng Xu
i...@jsteward.moe



> H30/03/20 20:17、Michael Palimaka のメール:
> 
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
> 
> 1: https://bugs.gentoo.org/650964
> 



signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Mailing list moderation and community openness

[Alexander Berntsen]

On 20/03/18 13:17, Michael Palimaka wrote:
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
It's fairly simple to produce a justification of the decision. I can
think of several ways of doing so. One is through an appeal to some
notion of community health improvement from impeding toxic contributors.
In this strategy, the argument would be something pertaining to how
allowing these toxic posters free rein on the mailing list would
contradict the core tenet of an open and inclusive community. There are
several more ways to rationalise the decision.

But you won't buy into either of those purported vindications of this
decision. (I won't either.) So don't bother requesting them. Another
aimless (and thus endless) back and forth in Jackal language isn't
likely to achieve anything worthwhile beyond what the initial exchange
achieved.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[Matthew Thode]

On 18-03-20 23:17:52, Michael Palimaka wrote:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
> 
> 1: https://bugs.gentoo.org/650964
> 

While I personally do no agree with mailing list moderation infra has
been tasked with moving forward on it.  In that vein, this is what we
are proposing.

Install and configure mailman3/hyperkitty/postorius once they all
support python3.  Specifically we wish to use docker-mailman for this so
we can easilly redeploy this on diferent machines as needed.

mailman3 gives us two good things, it has support for moderation (for
better or worse) and it handles senders using dmarc.

There are still some issues with it infra side (archiving will still
have to use the old system) and moving mailing lists is going to be fun,
but them the breaks.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: several dev-php/PEAR-* packages (Mar 2018)

[Brian Evans]

# Brian Evans 

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[Gregory Woodbury]

On gentoo-dev list: k_f
points out that this should have been talked about during previous
discussion periods...

It was discussed "to death" over and over, and many argued against it
till they were blue in the face.
Their concerns were ignored, and Gentoo lost a lot more of the "Free
and Open" reputation it theoretically
prides itself on.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Mailing list moderation and community openness

[Lars Wendler]

On Tue, 20 Mar 2018 23:17:52 +1100 Michael Palimaka wrote:

>I see that in bug #650964[1] Council is pushing forward again with
>implementing user whitelisting on this mailing list (ie. anyone that is
>not "approved" will have their mail rejected).
>
>Could someone please explain how this doesn't directly contradict the
>core tenets of an open and inclusive community?
>
>1: https://bugs.gentoo.org/650964
>

+1

This is ridiculous and council should be ashamed of this decision.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp8dhy4aanHN.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Mailing list moderation and community openness

[Kristian Fiskerstrand]

On 03/20/2018 01:17 PM, Michael Palimaka wrote:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
> 
> 1: https://bugs.gentoo.org/650964
> 

The correct place to have pointed this out would have been during the
previous ML discussions, and in particular ahead of either of the two
council meetings on the matter where it was clearly put on the agenda.
The bug in question is just a technical matter of implementing a final
decision.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Mailing list moderation and community openness

[Michael Palimaka]

I see that in bug #650964[1] Council is pushing forward again with
implementing user whitelisting on this mailing list (ie. anyone that is
not "approved" will have their mail rejected).

Could someone please explain how this doesn't directly contradict the
core tenets of an open and inclusive community?

1: https://bugs.gentoo.org/650964

[gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[Herb Miller Jr.]

When I did my homework on creating nodejs ebuilds (not nodejs itself but
packages written in node), it seems the topic has come up a few times in
the past but the time commitment and general disorganization of upstream
has scared off any serious attempts at packaging.

Seeing as there has been interest in nodejs packages, and in the end we
could be talking 400-600+ packages, would it be possible to create
dev-libs/nodejs category? I would be happy to write and proxy-maintain
ebuilds for a large number of them to get things in motion. I've already
opened pull request #7427 [1] for chalk and its dependencies. I'm aiming
to build up to all the dependencies needed for Visual Studio Code OSS.

[1]:https://github.com/gentoo/gentoo/pull/7427


Herb Miller Jr.

[gentoo-dev] make boehm-gc USE flag global

[grozin]

There are 4 packages with the USE flag boehm-gc:

dev-embedded/sdcc
gnustep-base/libobjc2
media-gfx/asymptote
net-libs/onion

plus 3 packages with the USE flag gc having the same meaning:

sci-mathematics/flint
sys-apps/nix
www-client/elinks

I think it would be reasonable to rename the flag gc to boehm-gc in these 
3 packages, and make boehm-gc global. The description can be something 
like


Enable garbage collection using dev-libs/boehm-gc

Andrey

Re: [gentoo-dev] bug queue size over time

[James Le Cuirot]

On Mon, 19 Mar 2018 22:05:16 -0700
"Paweł Hajdan, Jr."  wrote:

> On 19/03/2018 21:33, Alec Warner wrote:
> > I'd avoid the REST API here. If you want this data; I'd consider
> > filing a bug. Infra can do stuff like run nightly reports for this
> > information and hang them off of endpoints you can access.
>
> Would it only collect data going forward, or does this method also
> support historical backfill?

We used to have graphs for Java bugs from data that was collected over
time but that all broke when the categories were reorganised. I recall
it was possible to set these up through the web interface but I've
totally forgotten how.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Kristian Fiskerstrand]

On 01/09/2018 10:20 PM, Andreas K. Huettel wrote:
> During the last Gentoo council meeting, the decision was made to implement 
> changes to the gentoo-dev mailing list [1].
> 
> These changes affect only the gentoo-dev mailing list, and will come into 
> effect on 23 January 2018.
> 
> * Subscribing to the list and receiving list mail remains as it is now.
> * Posting to the list will only be possible to Gentoo developers and
>   whitelisted additional participants.
> * Whitelisting requires that one developer vouches for you. We intend this
>   to be as unbureaucratic as possible.
> * Obviously, repeated off-topic posting as well as behaviour against the
>   Code of Conduct [2] will lead to revocation of the posting permission.
> 
> If, as a non-developer, you want to participate in a discussion on 
> gentoo-dev, 
> - either reply directly to the author of a list mail and ask him/her to 
> forward your message,
> - or ask any Gentoo developer of your choice to get you whitelisted.
> 
> If, as a developer, you want to have someone whitelisted, please comment on 
> bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching 
> for a contributor you are expected to keep an eye on their activity.
> 
> [1] https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt
> [2] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct
> [3] https://bugs.gentoo.org/644070  (alias g-dev-whitelist)
> 

This was not put in effect on 23 January 2018, however I have now
requested infra to put it in place in [bug 650964]. Users wishing
posting permissions are encouraged to find a mentor and register in [bug
644070]

References:
[bug 650964] https://bugs.gentoo.org/650964
[bug 644070] https://bugs.gentoo.org/644070
-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] About making mastersync redundant

[Fabian Groffen]

Hi,

I know infra is working on fixing this, so they better focus on that for
now.  Thank you to infra for doing all the work!

When this is resolved, perhaps we should have a discussion on how to
make this service redundant?  Currently the prefix rsync generation is
redundant (== 2 generators) so I'm interested to discuss and see if that
would be feasible for gx86 too.

Fabian

On 19-03-2018 21:13:37 -0400, Alec Warner wrote:
> This is just an FYI: [1]https://infra-status.gentoo.org/
> 
> Hoping to have this fixed in a couple of days. In the meantime you may see
> missing snapshots (for emerge webrsync) and no rsync propagation.
> 
> -A
> 
> 
> 
>  References:
>1. https://infra-status.gentoo.org/
> 
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8: 
-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: PGP signature

[gentoo-dev] understanding gentoo

[Abhishek Kumar]

Hi Everyone
I want to know the code that belongs to news items after updating port 
tree.Explain its implementation also.

Thank You