[19:00:31] !proj council [19:00:32] (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh [19:00:37] -*- slyfox is here [19:00:38] + mrueg [19:00:41] meeting time! [19:00:48] 0. roll call [19:00:49] :) [19:00:51] -*- K_F here [19:00:54] -*- dilfridge here [19:00:54] -*- slyfox here [19:00:55] -*- WilliamH here [19:00:57] -*- mgorny here [19:01:06] -*- ulm here [19:01:36] mrueg: [19:01:39] ok let's give mrueg a moment to turn up [19:02:35] I sent him a text [19:02:47] to have it mentioned during the meeting logs, as requested by tamiko , mrueg is the assigned proxy for this meeting [19:02:59] jo [19:03:01] o/ [19:03:08] excellent [19:03:11] was on the phone, I'm here [19:03:13] soo... [19:03:22] 1. Lack of enough package maintainers [19:03:28] https://archives.gentoo.org/gentoo-project/message/4771bc564060b7ab1f64d5c094105493 [19:03:36] is there anything we can do? [19:03:49] who brought the crystal ball today? [19:03:51] Well, its certainly not a voting action, but it is always interesting to discuss a bit [19:03:51] recruitment drive? [19:03:54] Not really, it is up to devs to recruite more people. [19:03:56] The resources availble to Gentoo is defined by (i) amount of time spent on the project and the level of knowledge from existing developers (ii) efficiency in processes (iii) Attracting new developers with knowledge to contribute to the project (either as developers or proxied). Now, (iii), requires an active userbase, which agains requires a precense to get known, e.g at various conferences. [19:04:06] recruit [19:04:32] this might be related to the other problem [19:04:33] of those, having a properly working community, resulting in wanting to spend more time, c.f. (i) is the less costly , if every existing dev increases 5% it is much higher than number of new recruits [19:04:34] let's give this 10min brainstorming and then go on [19:04:34] maybe we can have a proxy and get some maintainers on funtoo side? [19:04:50] kill some of the negative energy towards gentoo [19:04:52] with a good QA check? Then I can advertise the option to funtoo people [19:04:53] Yes, devs shoud spend less time fighting in public media and help users (and other devs) more :) [19:05:00] drobbins: possible, but not sure how much it helps [19:05:24] the proxy maints are already doing such stuff, the bottleneck is people again... [19:05:46] is there a list of outdated catpkgs? [19:05:48] yep, proxy-maint would use any help it can get [19:05:51] do we have any recruiter backlog? [19:06:16] AFAIK recruiting is going quite smoothly for competent candidates [19:06:19] slyfox: my impression is it is better than ever in that department [19:06:22] slyfox: no [19:06:28] https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email1=recruiters&emailassigned_to1=1&emailtype1=substring&list_id=3763516&query_format=advanced [19:06:28] hard to generate interest in maintaining catpkgs if we are not clear what those catpkgs are [19:06:38] the bug list is very short [19:06:54] https://www.akhuettel.de/gentoo-bugs/ < you need to scroll down [19:06:55] drobbins: there's a lot of maintainer-needed@ [19:07:02] hmm [19:07:09] ^ was just going to suggest that [19:07:24] https://qa-reports.gentoo.org/output/maintainer-needed.html [19:07:40] literally only KDE is fine [19:07:46] every other project is understaffed [19:07:49] I would suggest a first step of differentiating between 'important' non-maintained catpkgs and 'misc' ones [19:08:03] when resources are tight, gotta prioritze the important ones and focus on those [19:08:03] K_F: need to filter that by open bugs [19:08:23] if a package is working then m-n isn't a big problem [19:08:35] ulm: maybe, maybe not.. some of them might have glaring security holes but nobody is looking at it, and a poor user walks into the trap [19:08:53] ulm: so without a maintainer, should at the very elast consider dropping to ~arch [19:09:10] but that is somewhat parallel discussion, so not something for today [19:09:18] actually that's an interesting point, but different issue [19:09:27] m-n -> not stable ? [19:09:38] dilfridge: lets put that up for discussion at next meeting [19:09:42] K_F: if there is a known security hole then there should be a bug open for it [19:09:42] yep [19:09:58] from time to time i'm spending the time to enlarge that list by killing dead projects [19:09:58] at some point lastriting is also an option [19:09:58] if we have less packages to maintain, we can focus better on those we do maintain [19:10:29] yeah [19:10:29] yes, I'm proposing drop to testing since there has been some pushback on that historically [19:10:32] I agree on the principle [19:10:40] sorry, had a huge lag [19:11:04] about recruitment drive [19:11:10] we could start at fosdem [19:11:37] for a start, by preventing non-developer non-contributors from pretending to be important people in gentoo? [19:11:45] hehe [19:11:51] mgorny: I'll bring name tags [19:12:08] dilfridge: right, precense at conferences are important, imho, for gentoo to be considered part of the "major" distros to consider altogether [19:12:11] i think it's a bit of chicken-and-egg problem [19:12:16] to get new people in some occasional blog noise about gentoo is constantly recruiting might help [19:12:17] and having a professional representation at such conferences.. [19:12:22] we have less people, gentoo becomes worse [19:12:32] gentoo becomes worse, we have less candidates and less incentive to do things [19:12:32] as for FOSDEM, I'm very happy to receive input on the flyer we're creating for this year's stand [19:12:33] I think there are general actions that can be taken to get new maintainers.... we all know those. Recruitment, etc. [19:12:36] well, we also need to figure out what is cool about gentoo that we want to emphasize [19:12:39] yes, flyer! [19:12:58] I am more interested in specific actions to address critical ebuilds in need of maintainership [19:12:59] but thats more for #gentoo-fosdem and #gentoo-pr [19:13:04] yes [19:13:05] but I am not sure if that is a different topic [19:13:35] most of the times some dev is taking mercy on really critical ebuilds [19:13:39] i think to some degree candidates don't really know what to do in gentoo [19:13:50] unless noone knows what is critical (see sgml) [19:13:53] i've seen a lot of potential candidates try to find some niche to work on [19:13:59] but most of the time those weren't ebuilds [19:14:05] how hard would it to be to maintain a list of critical ebuilds that need maintainers? or does such a list exist? [19:14:20] drobbins: I don't know of a list myself. [19:14:22] this would provide some focus [19:14:32] maybe a first step is to figure out how to create one? [19:15:01] if we really did have a package considered critical without maintainer, simply a list isn't sufficient, that would recruite a pro-active approach to getting people to take over it [19:15:09] i have some graphviz-based dependency graphing in gpyutils [19:15:13] drobbins: the problem, as I see it is, what is "critical"? [19:15:23] drobbins: other than anything in @system [19:15:26] but it'd need some work to apply to this [19:15:39] WilliamH: here is my idea [19:15:46] a cute little script, grabs catpkgs on a user's system [19:15:52] sends them to gentoo [19:16:09] we can then get a count of most popular catpkgs [19:16:17] then we have another db of last commit of each catpkg [19:16:26] that sounds like gentoostats, and it isn't really interesting on a number of reasons, privacy part of it, but mainly critical isn't a popularity contest [19:16:28] then correlate -- viola, automatic list of where to focus [19:16:38] it's a starting point [19:16:45] you'd likely have fringe users running that script, but someone with 1000 servers would never do it [19:16:51] drobbins: i think we're getting too deep into details now [19:16:54] ok [19:17:00] please leave this until after the meeting [19:17:00] right [19:17:03] That does sound like something gentoo-stats could do, but no one seems interested in picking that up for some reason. [19:17:06] so you know from the start that you get biased results, with very little value [19:17:15] I think we should postpone this and send it to the lists for general discussion [19:17:21] agreed [19:17:21] any last words? [19:17:31] WilliamH: potentially interested in helping. I have lots of experiencing pulling stuff out of portage and putting them in db. [19:17:40] right. [19:17:44] next topic [19:17:54] 2. Update of GLEP 42 [19:17:55] dilfridge: instead of general discussion a working group might be the better idea [19:18:03] drobbins: ping me post the meeting and i'll give you a quick run of problems with gentoostats [19:18:09] mgorny: will do [19:18:15] https://archives.gentoo.org/gentoo-dev/message/6f070b64892d2e351bd51b2ffa1dc64e [19:18:22] https://gitweb.gentoo.org/data/glep.git/log/?h=glep42-update [19:18:36] do we need any discussion here? [19:18:46] -*- dilfridge doesnt think so [19:18:51] not from my point of view, thanks for the update, it is technical in nature [19:19:09] rationale is in the message [19:19:22] -*- WilliamH is reading [19:19:37] infra approved™ [19:19:44] main point is dropping detached sigs, because it is covered by tree signing now [19:20:10] ulm: the only comment I made during my readthrough is whether that should involve a metadata requires on 74, but I dropped it :) [19:20:32] so let's vote on the glep42 update as presented in the e-mail(s) [19:20:41] K_F: that's outside the scope of 42 [19:20:48] -*- dilfridge yes [19:20:50] it's covered by 74 [19:20:53] -*- mgorny yes [19:20:53] -*- K_F yes [19:20:54] -*- ulm yes [19:20:58] -*- WilliamH yes [19:20:58] -*- slyfox yes [19:21:04] mrueg: ? [19:21:22] yes [19:21:31] ok approved unanimously [19:21:34] next topic [19:21:42] 3. Final review of GLEP 74 [19:21:51] https://archives.gentoo.org/gentoo-project/message/7d189934e371842fc799ba1eead3d01f [19:21:58] https://www.gentoo.org/glep/glep-0074.html [19:22:22] i've pushed gemato 9.2 today, and it adds repo.postsync.d that verifies the signatures [19:22:28] mgorny: afaik this is already implemented and running on the infra side? [19:22:35] so we have it implemented on both ends now [19:22:40] mgorny: nice! [19:22:46] did security@ have any feedback? postivie/negative? [19:22:47] mgorny: thanks for your work on that [19:22:59] will this be implemented in the PM itself as well at some point? [19:22:59] slyfox: no [19:23:08] slyfox: not that i know of. or at least i didn't see anything explicitly marked as 'security' [19:23:10] *sigh*, assuming OK then :) [19:23:14] also 99.4% of distfiles have blake2b by today [19:23:19] --> robbat2-alt (~androirc@199.119.235.216) hat #gentoo-council betreten [19:23:21] mrueg: hope so [19:23:30] only 377 left, mostly fetch restricted stuff [19:23:33] slyfox: well, given I'm the one mostly involved on that front, the comments have gotten already, including no compression on top manifest [19:24:03] (that was already incorporated after last meeting) [19:24:14] iow, i think we can mark it Final now [19:24:15] time to vote then? [19:24:24] works for me [19:24:27] my opinion on this is that GLEP 74 is trying to solve a problem that outside the scope of the package manager [19:24:46] please vote: final approval of glep74 as linked [19:24:49] verification of tree has to be part of PM to ensure it is consistent across [19:24:52] -*- K_F yes [19:24:54] -*- dilfridge yes [19:24:54] -*- slyfox yes [19:24:55] -*- mgorny yes [19:24:56] yes [19:25:02] -*- ulm yes [19:25:22] -*- WilliamH yes [19:25:30] excellent, unanimous [19:25:38] next topic [19:25:39] my non-vote: you're all idiots :) [19:25:43] (I'm here just in time, but expect to loose signal again) [19:25:47] *** Modus #gentoo-council +m by dilfridge [19:25:50] drobbins: acknowledged :) [19:25:53] <-* ulm hat drobbins aus dem Chat #gentoo-council geworfen (Kicked by ulm) [19:26:07] ulm: why? [19:26:10] --> drobbins (~drobbins@funtoo/bdfl/drobbins) hat #gentoo-council betreten [19:26:28] I don't really believe that was necessary [19:26:33] -*- WilliamH agrees [19:26:57] but it is within the chair's right to put +m [19:27:08] drobbins: if you have any useful comment, you can proxy it through me [19:27:11] let's move on [19:27:27] the next topic is going to take hours ;-) [19:27:41] ulm: I'm saying this so it will be in the log. your action, kicking drobbins was inappropriate. [19:27:41] 4. Restricting gentoo-dev/-project posting [19:27:52] https://archives.gentoo.org/gentoo-dev/message/6e7cc13cd850be7dbd86376d3a197a16 [19:28:07] WilliamH: I'm not suffering to be insulted here [19:28:08] i guess it's not the time for debate but for decision [19:28:24] as i've said, i think we should split it into smaller sub-topics [19:28:28] if doing a straw vote, I'm against a split [19:28:34] right... I think about every argument for the lists has already been made [19:28:40] for a start, ulm has suggested we may benefit from gentoo-council list for agendas [19:28:47] mgorny: how would you suggest splitting it? [19:28:55] right now they kinda end up mixed with random discussions [19:28:58] mgorny: I have retracted this [19:29:14] -*- dilfridge is for g-dev restricted and used for all official business, g-project unchanged (as originally intended) [19:29:28] <-- jlec (~jlec@gentoo/developer/jlec) hat das Netzwerk verlassen (Quit: Leaving.) [19:29:29] splitting the lists up even more isn't the right thing to do [19:29:43] I tend to agree with ulm about splitting the lists. [19:29:53] *** Modus #gentoo-council +v robbat2-alt by dilfridge [19:29:54] i'd agree with dilfridge, split & merge [19:29:56] there are too many as it is. :-) [19:30:04] stop the weird topic split between -dev and -project which most of the people are getting wrong anyway [19:30:12] make -dev developer-to-developer, and -project developer-to-user [19:30:26] not sure if that'll be easy to organize though [19:30:39] comment from robbat2-alt [19:30:40] 19:29 My comment: i strongly oppose the further split, but do welcome proactive [19:30:40] mgorny: how is -project then different from -user? [19:30:43] moderation (not reactive) after a switch to mailman [19:30:45] 19:29 And all people, incl devs should be told if they are too inflammatory [19:30:51] mgorny: there's nothing stopping devs from being on -user. [19:31:00] I'm taking that in a infra point of view, in particular noting the requirement for a new infrastructure for mailing lists [19:31:04] as a first step we could move follow-ups to council agenda to -dev [19:31:25] WilliamH: i think -user should be more on topic for helping users with problems, not deciding how gentoo works [19:32:41] -*- ulm notes that there already is a past council decision that -dev should be moderated [19:32:56] my basis is that discussion, and discussions allowing a broad take on things, with general acceptance of input, is the best way to get good end results [19:33:02] but I see the problem with implementing it [19:33:10] if we don't agree, it is all fine as long as we accept eachothers opinions [19:33:19] ok here's a suggestion on how to proceed: A) do we want to add/reactivate any new lists? yes/no, B) should -dev be for devs+selected posting only? yes/no, C) where should official business go? dev/new list [19:33:21] and most forms of censorships have a tendency to result in group think [19:33:28] i think we may proactively approve moderation as a tool for comrel [19:33:42] it might be an option to introduce a gentoo-core-public [19:34:02] i.e. let comrel enforce moderation (when it's technically supported) when things go out of control [19:34:14] dilfridge: (A) and (B) are likely fine, (C) seems to exclude -project as it is today for council etc [19:34:18] ether on specific people or on the ml in general [19:34:48] or on new subscribers [19:34:50] K_F: well, it's actually a decision tree, and the further down you go the more it depends on previous votes [19:35:03] dilfridge: nothing in C depends on A or B [19:35:39] maybe we should start with something simpler [19:35:56] 'do we want a public mailing list with posting restricted to devs (+ voiced contributors)'? [19:36:06] mgorny: well, someone would have to do the moderation, yes, but I'm not so happy about comrel (which brings us back to the plan to revive the proctors, WIP) [19:36:20] mgorny: sounds good [19:36:21] theoretically, agenda items of technical nature should be discussed in -dev already now, but follow-up to -project normally leads to them being discussed there [19:36:31] mgorny: who's managing access for voiced contributors? [19:36:33] and -project was never intended for that [19:36:33] dilfridge: you avoid that issue if it is proactive approval [19:36:48] dilfridge: it'd actually be similar to +v in #gentoo-dev [19:36:53] -*- NeddySeagoon supports revive proctors as long as it 100% council support [19:36:59] mrueg: any active developer can vouch for someone [19:37:07] I have no problem with reviving the proctors. [19:37:09] what is proctors? [19:37:16] mgorny: and what is the concequences if said person gets kicked out? [19:37:21] or, if more than one vouced by a dev [19:37:22] slyfox: basically moderators for the mailing lists. [19:37:25] aha [19:37:27] mgorny: yeah but who does the account managment? infra? [19:37:33] the proctors were a short-lived team that was tasked with enforcing the code of conduct [19:37:42] slyfox: ^ [19:37:48] mrueg: yep, either infra or if we develop some automated way [19:37:56] unfortunately the first ones to misbehave were council members, thus shortlived [19:38:06] K_F: we keep bugs to track that [19:38:16] much like editbugs [19:38:31] so if someone is given posting access, there's a bug for that [19:38:31] mgorny: I agree that is a fair anology [19:38:33] that sounds reasonable [19:38:35] if comrel bans him, it's on bug [19:38:40] The proctors moderated a council memeber. Council didn't like it [19:39:30] moderation has generally one, very important problem: what do to if one mail is aggressive but also carries valuable info? [19:39:51] it has more issues than that, the most important one is defining what is agressive [19:39:51] if you deny it, you lose the info [19:39:57] if you accept it, people have easy way around moderation [19:40:06] (storms ahead, flightcrew announced my in-flight internet might cut out) [19:40:09] mgorny: email the poster. Dropping mail on the floor won't work [19:40:14] Ask the person to rewrite it [19:40:21] robbat2-alt: ++ [19:40:23] assuming he will [19:40:24] robbat2-alt++ [19:40:27] Have a trashcan of visible rejected mail? [19:40:36] yeah, that might be an option [19:40:38] mgorny: if he won't, the email doesn't get posted. [19:40:39] With why it was denied [19:40:54] mgorny: Its the posters choice. Moderation needs to be interactive. [19:41:07] wfm [19:41:24] but as K_F said, we also need to decide what needs to be moderated [19:41:26] maybe we can tackle it differently? Have an open mailing list, but every gentoo dev has the possibility to request someone to vouch for X if there is abusive behaviour. if the person doesn't find someone that vouches for her or him, the person will loose write access [19:41:31] I wouldn't be fan of trashcan , it can open a whole different can of worms [19:41:55] I think we're debating hypothetical issues. [19:41:57] but given it's bilateral, i suppose it could help people improve [19:42:06] dilfridge: it won't be hypotethical if implemented [19:42:20] well [19:42:23] dilfridge: and it consists of things that should be a clear meaning on before imposing any measures [19:42:29] then we solve the problems as they come [19:42:32] otherwise it _will_ result in issues down the road [19:42:35] i believe if we enforce moderation, then we should also moderate off-topics [19:42:43] dilfridge: I'm not a big fan of kicking the can down the road [19:42:48] mgorny: Anfthing off topic needs to be moderated. We probably need to (re)define /topics so its clear to posters [19:42:49] that's better than debating for ages and not coming to any conclusion [19:42:56] right [19:42:57] we've seen the disagreements with the current discussions that has prompted this action [19:43:07] personally I don't find the postings to be in violation of the gentoo CoC [19:43:13] and now we get to the point where we maybe see that moderation is not really easy [19:43:19] so [19:43:24] I actually like the editbugs model [19:43:38] ulm: yes, I'm for that one as well [19:43:40] to cut this short, I suggest we vote on the wording by mgorny, 'do we want a public mailing list with posting restricted to devs (+ voiced contributors)' [19:43:44] and users could be tracked in analogy to bug 236218 [19:43:47] ulm: https://bugs.gentoo.org/236218 "all users with editbugs privileges"; Gentoo Infrastructure, Bugzilla; IN_P; betelgeuse:bugzilla [19:43:51] no retroactive moderation, but dev+approved users for -dev is all good [19:44:00] (to clarify the fundamental issue first) [19:44:00] where any dev can approve users c.f editbugs smodel [19:44:14] K_F: please don't apply a specific mailing list yet [19:44:29] vote: 'do we want a public mailing list with posting restricted to devs (+ voiced contributors)' [19:44:42] -*- slyfox no [19:44:46] -*- K_F yes [19:44:51] -*- dilfridge yes [19:44:53] -*- mgorny yes [19:44:56] -*- mrueg yes [19:45:14] -*- ulm yes (under the condition that it will be -dev) [19:45:23] -*- K_F adds same condition as ulm [19:45:33] ok [19:45:38] -*- WilliamH not a new mailing list [19:45:46] K_F: it's a majority without that anyway [19:45:49] motion passed in any case [19:45:51] -*- WilliamH no [19:46:03] <-- robbat2-alt (~androirc@199.119.235.216) hat das Netzwerk verlassen (Ping timeout: 255 seconds) [19:46:08] then the next question would be "do we want this to be gentoo-dev"? [19:46:15] so, if we apply this to -dev, what would be the criteria between -dev and -project? [19:46:41] mgorny: project is free to subscribe to without voiced approval [19:46:41] -dev is for developer discussion, that always was its description [19:46:54] it would be nice to avoid cross-posting every second topic [19:46:54] People that can't post to -dev post to -project [19:47:04] NeddySeagoon: exactly [19:47:14] e.g. devs discuss X in -dev, user wants to add something, he posts same topic to -project [19:47:20] mgorny: I agree on avoiding cross-posing, but that is a matter of defining where things should go [19:47:23] ulm: and devs won't read -project. [19:47:26] Currently -project has the following description: "For the discussion of non-technical matters in Gentoo" [19:47:39] NeddySeagoon: I'd disagree with that, I read it to begin with.. [19:47:41] I suggest we clarify, all official business (including council stuff etc) goes to -dev [19:48:03] dilfridge: that is likely further down after we have established how -dev looks [19:48:04] K_F: i didn't know it even exists before i was nominated for council [19:48:06] NeddySeagoon: I read it too (again) [19:48:35] K_F: Well, we are not all going to agree ... I don't have a problem agreeing to disagree [19:48:39] maybe we should define how users should reply if they want to get involved in something discussed in -dev [19:48:58] mgorny: they would have to be able to post to -dev [19:48:59] mgorny: likely if they aren't pre-approved, they should find a dev to proxy them [19:49:00] i.e. whether they should just mail -project, or proxy via dev, or file a bug, or... [19:49:22] Its getting messy [19:49:24] bug would be different channel, so only causing same split as -project [19:49:28] mgorny: they would have to be able to post to -dev so that what they say gets included in the thread on -dev. [19:49:44] WilliamH: developer can proxy their message, or vouch for them [19:49:50] mgorny: Otherwise you will have a lot of broken threads. [19:49:50] so they would either need to find a dev to sponsor them, and get +v (equiv) , or the dev to proxy the specific message [19:49:54] well, technically they can reply to poster [19:50:07] and the poster can decide to proxy it or voice them [19:50:20] mgorny: right, but I don't think we should limit it to that specifically [19:50:26] we would also need a transition phase for existing user subscriptions to -dev [19:50:35] (i've actually seen users reply to me when they weren't subscribed to -dev) [19:50:38] like one or two months [19:50:58] ulm: that sounds like it's going to incite some drama [19:51:14] mgorny: why that? [19:51:20] people still will be able to subscribe and read -dev without hassle, right? [19:51:25] slyfox: yes [19:51:44] ulm: i'm afraid some people will find it more convenient to complain for those two months than request voice [19:51:45] Maybe not. It may get posters foucused, so it s not actually required [19:52:08] mgorny: does the current mailing list software allow for read-only users? [19:52:14] and do we really need it, tbh? i think current posters shouldn't have a major problem requesting dev to vouch for them [19:52:30] mgorny: the alternative is that they won't have voice for some time, which I think is worse [19:52:30] mgorny: and how much work is it to flip that bit for infra? [19:52:33] K_F: yes [19:52:40] again: why not the other way around? blacklist people if others complain about their behaviour and they don't find anyone that vouches for them [19:52:42] K_F: we have ACLs [19:53:08] mgorny: maybe s/transition phase/delay between announcement and implementation/ [19:53:10] mrueg: what if people resub with new address over and over again? [19:53:23] I'm actually for a clean slate in that case, every non-@gentoo addresse would immediately be read-only, and they can start finding a sponsoring dev, but only after we have established the protocol for other devs to request it (similar to editbugs) [19:53:31] blacklisting doesnt work [19:53:37] mgorny: that's ban evasion and should be handled by comrel [19:53:37] not for what is planned [19:53:41] i agree with K_F [19:53:44] with a 1-2 week max implementation [19:53:50] yep [19:53:55] i'd say it's like this [19:53:56] -*- dilfridge too [19:53:57] you read the list [19:54:09] you want to reply, you can't -> you ask someone to proxy it or vouch for you [19:54:14] I tend to agree with mrueg [19:54:31] generally the cleanest way i see it, people start posting via proxies and proxies eventually +v them when they see they behave [19:54:45] --> jlec (~jlec@gentoo/developer/jlec) hat #gentoo-council betreten [19:54:45] *** Modus #gentoo-council +v jlec by ChanServ [19:54:46] if we have a whitelist, this will make it only more difficult for contributors to start with gentoo [19:55:04] mgorny: not really [19:55:08] ehrm, mrueg [19:55:14] How do other distros handle this? [19:55:22] mrueg: truth is, most of contributors don't start gentoo with -dev [19:55:25] e.g. in Debian, are all of the lists open? [19:55:26] mrueg: they can contribute through b.g.o and proxied maintainers [19:55:38] most of people start with bugzilla, github etc. [19:55:45] mrueg: or any other mailing list than -dev [19:55:56] Proxying makes all +v modorators [19:56:17] K_F, mgorny: all I'm saying is you're adding more steps than necessary [19:56:19] NeddySeagoon: more like distributed moderation [19:56:23] ok so this discussion already intrinsically assumes that -dev is going to be the restricted list [19:56:25] NeddySeagoon: technically true, it just makes it more difficult to identify non-devs [19:56:57] so we need to get back to the question, how do we describe the topics [19:57:20] IF messages afe forwarded to the list, headers will still be there [19:57:24] for one, i still believe council matters should be discussed on -project, it involves the whole community [19:57:52] "dev - gentoo developer discussion, project - issues pertaining to gentoo, technical or otherwise" ?! [19:57:59] even devs not wanting to follow that daily for some reason, can use it for specific purposes [19:58:04] K_F: then we lose the entire advantage again [19:58:05] to be honest, i don't see a point in having one list restricted without the other [19:58:06] --> Chewi (~chewi@gentoo/developer/chewi) hat #gentoo-council betreten [19:58:06] *** Modus #gentoo-council +v Chewi by ChanServ [19:58:12] dilfridge: we really do not [19:58:23] <-- jlec (~jlec@gentoo/developer/jlec) hat das Netzwerk verlassen (Client Quit) [19:58:23] dilfridge: they wouldn't need to follow it daily [19:58:28] otherwise we just move the problem instead of solving it [19:58:42] agenda item would link discussion on on project, so at least a week (generally) to comment on issues [19:58:49] mgorny: Thats what the -dev -project split did [19:58:57] K_F: this sounds like getting back to the point of letting users believe in lies about gentoo because nobody is there to deny them [19:59:11] well, there's no reason why things cannot be discussed on -project too... [19:59:20] mgorny: I'm not sure of characterising some of the opinions as lies is generally fruitful [19:59:32] +1 [19:59:42] dilfridge: split disussion doesn't benefit anyone [19:59:50] i'd say we either go for both restricted, or just kill -project and focus on one restricted list [19:59:52] it is well-known that facts have a distinct left-wing bias. [20:00:16] yes, it's going to hurt for a while but people'll get used to that and things will settle down in month or two [20:00:23] There is no requirement for opinions to have any basis in fact [20:00:26] when we don't move council traffic to the restricted list then the whole proposal doesn't make much sense [20:00:35] ulm++ [20:00:47] NeddySeagoon: ++ [20:01:23] ok [20:01:23] if we restrict -project too then there would be no need for the split between -dev and -project, in the first place [20:01:27] ulm: it gives developers room for discussion , but council matters affect the whole community [20:01:39] ulm: and it is easy for a dev to ignore -project except for agenda-relevant discussions [20:01:48] ulm: well, technically we could split between technical and non-technical matters [20:02:08] mgorny: that's what we have now. [20:02:18]