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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [gentoo-dev] Fwd: understanding gentoo

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

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

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

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

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

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

bitcoincore.eclass: Mark @DEAD for removal No consumers left in Gentoo ebuild repository.

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

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

[gentoo-dev] Fwd: understanding gentoo

-- 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

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

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

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

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"

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

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

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

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

[gentoo-dev] IPFS source mirror

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?

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

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

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

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

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). >> >>

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

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

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

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

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

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

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

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

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

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

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

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

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

# Brian Evans

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

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"

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

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

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

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

[gentoo-dev] Mailing list moderation and community openness

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

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

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

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

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

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

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

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

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. > > *

[gentoo-dev] About making mastersync redundant

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

[gentoo-dev] understanding gentoo

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