2019-03-07 16:59:26 <_ikke_> Any opinion about this PR? https://github.com/alpinelinux/aports/pull/6569. Ideally it would get added to docs.a.o, but as it's not online yet, ncopa felt it could be added to aports for the time being. 2019-03-07 17:04:40 I think this is fine as-is 2019-03-07 17:04:53 docs.a.o should primarily focus on alpine-specific things 2019-03-07 17:04:56 this is more about github 2019-03-07 17:05:07 if/when we move to our own platform (e.g gitlab) it might make more sense to include into docs.a.o 2019-03-07 17:06:07 Any news reg theme? 2019-03-07 17:06:26 still nothing :/ 2019-03-07 17:06:36 at this point I'm assuming I'll have to write it on my own (or get help from someone else) 2019-03-07 17:06:48 alpine theme @ docs.a.o? 2019-03-07 17:06:52 I'll give the guy one more poke once editing's over being kind of like "ok, time's up, whatcha got, we're ready to publish" 2019-03-07 17:07:10 danieli: antora theme, yes; if you look at the current site you might notice funny things like "Product A" and "Service B" 2019-03-07 17:08:37 <_ikke_> SpaceToast: alright 2019-03-11 09:20:53 i looked over the install handbook. nice work! 2019-03-11 09:21:09 there are a few places where it mentions bugs in setup-alpine scripts 2019-03-11 09:21:26 i would like to fix those 2019-03-11 13:33:32 ncopa: alright, do tell me when each is dealt with, and I'll test in a VM :) 2019-03-14 10:29:36 hi 2019-03-14 10:30:09 hi 2019-03-14 10:30:17 i wonder how we could improve this message https://github.com/alpinelinux/aports/blob/master/.github/stale.yml 2019-03-14 10:30:40 kind of docs i guess :) 2019-03-14 10:31:57 what i like to include, a note about rebase master so its up to date and CI will work correctly. 2019-03-14 10:32:12 and update it so ppl will feel less offended 2019-03-14 10:32:57 now we see things like: hey this is my valuable contribution and you want to close it without even reviewing it properly! 2019-03-14 10:36:59 and maybe find a balance between what to put in the message and what to offload to some file in git ie: stale.md or contributors.md or similar. 2019-03-14 12:31:41 suggestion for stale.md: http://tpaste.us/mZvv 2019-03-14 12:35:10 <_ikke_> attemtp -> attempt 2019-03-14 12:58:46 <_ikke_> ncopa: I like the tone of that message 2019-03-14 13:02:06 looks good :) it should go into the developer docs for sure 2019-03-14 13:07:43 it's the response the stale bot posts on issues 2019-03-14 13:08:01 it'll need a little refactoring to fit into dev docs, but I don't see why not 2019-03-14 13:17:25 i think the stale bot is only a temporary solution 2019-03-14 13:29:17 I think having something to mark truly abandoned PRs as such is a good idea, we just need to make it smarter somehow :) 2019-03-14 13:29:39 (or perhaps have a deadline for PR processing that makes that unnecessary) 2019-03-14 13:30:43 exactly, but i dont think its wise to spend too much time on github atm. 2019-03-14 13:30:55 lets do that when we have something local 2019-03-14 13:31:04 Ideally, whatever we use could be portable, yeah. 2019-03-14 13:32:20 i think the contributor guidelines can be defined already, so when the time comes we know what to do. 2019-03-14 13:32:55 any progress on implementing SIGs/teams at all? 2019-03-14 13:33:05 I'd rather finish the user docs first, and ncopa wants baselayout and setup-* fixed before then 2019-03-14 13:33:14 danieli: hasn't even been mentioned afaik :/ 2019-03-14 13:33:20 I'm gonna rewrite SpaceToast's suggestion and poke at the mailing list again 2019-03-14 13:33:37 Wanna pass it through me on the way? :) 2019-03-14 13:33:44 of course 2019-03-14 13:33:48 ^^ 2019-03-14 13:33:48 I'll bounce it off you 2019-03-14 13:33:55 awilfox had a suggestion too a year ago (or two) 2019-03-14 13:34:13 sorry for not being responsive :-/ 2019-03-14 13:34:24 You're busy, we all get that 2019-03-14 13:34:30 org struct has to be looked at, not sure ncopa has time now... 2019-03-14 13:34:35 But that's just the thing, the suggestions are here to improve it :D 2019-03-14 13:34:39 we all seem too busy 2019-03-14 13:34:43 and i think the proper fix for me not being responsive is to go ahead with this 2019-03-14 13:34:50 exactly 2019-03-14 13:35:28 we're too busy running with the bicycle by our side that we dont have time to stop and jump up on the bicycle 2019-03-14 13:36:47 +1 2019-03-14 13:39:56 do we have a good example of SIGs? how others structure/deal with it? 2019-03-14 13:40:13 My proposal is based on Gentoo 2019-03-14 13:40:28 (ncopa and I both technically originate from it as is) 2019-03-14 13:40:38 I've modified it a bit to increase flexibility and separation 2019-03-14 13:40:39 like https://wiki.gentoo.org/wiki/Project:Portage/Membership ? 2019-03-14 13:40:45 As that's the specific issues we're running into 2019-03-14 13:41:14 clandmeter: not quite, that's just the portage project 2019-03-14 13:41:23 My "teams" are the Gentoo projects, basically 2019-03-14 13:41:37 Each team figures out how they want to organize themselves internally 2019-03-14 13:41:45 (Besides overall structure) 2019-03-14 13:42:04 The base structure does come from the portage team though 2019-03-14 13:44:39 When I get to $dayjob office I could link you my proposal I'd you'd like 2019-03-14 14:15:45 Actually, danieli - now that a go-ahead was given, perhaps we should try and draft the final document (rather than a proposal with lots of details left our for discussion)? 2019-03-14 14:15:58 s/our/out/ 2019-03-14 14:16:16 a go-ahead was given? 2019-03-14 14:16:24 where? 2019-03-14 14:16:46 "and i think the proper fix for me not being responsive is to go ahead with this" 2019-03-14 14:17:18 I don't see that as a green signal to just go ahead with it, more of a remark 2019-03-14 14:17:36 Maybe I didn't really read it thoroughly 2019-03-14 14:17:40 Or misunderstand 2019-03-14 14:17:55 But the sentiment certainly seems that everyone is too busy to discuss/review 2019-03-14 14:18:05 So trying to draft a version with all the details makes sense anyway 2019-03-14 14:18:13 +1 2019-03-14 14:18:16 that I agree with 2019-03-14 14:18:45 i think ncopa means just go ahead with it. make a proposal/draft and lets discus. 2019-03-14 14:18:56 How does taking 1-2h out of Sunday to discuss it in here (since I'll be the one documenting it, at the end of the day) and make a fully featured draft? 2019-03-14 14:19:07 a draft has already been posted to the ML but received no response 2019-03-14 14:19:19 Anyone present can chime in on the process, and then we can ask for final approval 2019-03-14 14:20:04 we have a meeting channel with a meeting bot. 2019-03-14 14:20:11 Oh, we do? 2019-03-14 14:20:23 you will never guess the channel name 2019-03-14 14:20:34 #alpine-meeting ? :) 2019-03-14 14:20:35 iirc it requires a key? not sure 2019-03-14 14:20:43 +s 2019-03-14 14:20:44 haven't looked at it in some time 2019-03-14 14:20:47 its open 2019-03-14 14:20:47 Aha 2019-03-14 14:20:49 all right 2019-03-14 14:20:55 What bot does it run? 2019-03-14 14:21:01 sopel 2019-03-14 14:21:09 iirc 2019-03-14 14:21:09 I'll look it up in a bit 2019-03-14 14:21:24 afaik it's this https://wiki.debian.org/MeetBot 2019-03-14 14:21:25 supybot plugin 2019-03-14 14:21:38 <_ikke_> nope, sopel 2019-03-14 14:21:44 aha 2019-03-14 14:22:03 <_ikke_> supybot seems to be not really maintained / deprecated 2019-03-14 14:22:13 So how about meeting in there on March 17 14:00 GMT for the purposes of making a final draft of the team proposal? 2019-03-14 14:22:21 (that would be 10 am my time) 2019-03-14 14:22:28 <_ikke_> What weekday is that? 2019-03-14 14:22:32 Sunday 2019-03-14 14:22:36 sunday, by the looks of it 2019-03-14 14:22:44 <_ikke_> Would work for me 2019-03-14 14:22:46 I'm going to be busy every day for 7 days except Sunday :/ 2019-03-14 14:22:58 <_ikke_> I can chair the meeting again 2019-03-14 14:23:05 I can try and make time during work / other things but I'm sure you'll agree it's suboptimal 2019-03-14 14:23:08 Sounds good :) 2019-03-14 14:23:15 <_ikke_> I just need some kind of agenda 2019-03-14 14:23:31 the draft could work like an agenda? 2019-03-14 14:23:49 The goal will be to discuss and formulate a final draft of the team proposal, to be presented to ncopa and the core development team for approval 2019-03-14 14:23:51 btw, i would check with ncopa 2019-03-14 14:23:58 not sure he has time on sundays 2019-03-14 14:24:17 im not sure ill be around. but i think you can manage without me. 2019-03-14 14:25:34 He gets the final vote anyway, so worst case scenario is a delay that's be equivalent to the scheduling delay 2019-03-14 14:25:36 Imo 2019-03-14 14:50:08 _ikke_: took a look through the bot's docs, I'll draft an agenda for you - expect a link in ~10ish hours (I'll need to get out of work, get home, and write it :) ) 2019-03-14 15:11:47 SpaceToast: have a look at this too: http://lists.alpinelinux.org/alpine-devel/5811.html 2019-03-14 15:12:10 im looking for the email where you sent your org proposal. did you send it as email? 2019-03-14 15:12:47 ncopa: http://lists.alpinelinux.org/alpine-devel/6458.html 2019-03-14 15:14:42 took a look - looks like an even looser variation, with fewer details 2019-03-14 15:14:52 (but the idea seems relatively similar, though some of the reasoning is different) 2019-03-14 15:43:20 ah, i was looking at the subject 2019-03-14 15:43:21 thanks 2019-03-15 00:16:34 _ikke_: here's my agenda draft: https://brpaste.xyz/y4fTUg?asciidoc 2019-03-15 00:16:41 (proposed, at least :) ) 2019-03-15 16:25:50 <_ikke_> SpaceToast: thanks 2019-03-15 16:26:29 feel free to change whatever, it's mostly a rough outline of what (as far as I can tell) needs to happen 2019-03-15 16:26:39 <_ikke_> yes, sure thing 2019-03-17 00:58:01 ncopa: first set in the attempts to get setup-alpine fixed... https://github.com/alpinelinux/aports/pull/6716 + https://github.com/alpinelinux/alpine-conf/pull/21 2019-03-17 14:03:49 <_ikke_> Meeting is starting about teams and organization, please join #alpine-meetings if you are interested 2019-03-17 18:02:28 alright, I think I have a first draft ready, just need to populate team membership lists 2019-03-17 18:02:31 _ikke_, danieli? 2019-03-17 18:02:56 right now I'm doing pure Name, Nick, Email cells; but it's ok to have some missing (at least until further notice) 2019-03-17 18:14:28 SpaceToast: where exactly are you publishing the list? 2019-03-17 18:14:59 lists* 2019-03-17 18:15:01 danieli: it'll be going into the developer documentation section 2019-03-17 18:15:13 so something like docs.a.o/developer-handbook/edge/teams.adoc 2019-03-17 18:15:20 well .html once compiled 2019-03-17 18:15:29 right, docs.a.o 2019-03-17 18:18:11 SpaceToast: also, what what exact data do you want for it? 2019-03-17 18:18:14 define 'name' 2019-03-17 18:19:16 First Name + Surname ;) 2019-03-17 18:19:27 I thought we decided not to publish that? 2019-03-17 18:19:44 we decided that it's ok to have it be missing, in cases where people do not want it published 2019-03-17 18:19:54 all right 2019-03-17 18:19:58 people can ask for removal I guess 2019-03-17 18:20:01 but for outsiders to work with us it's important to have it where possible 2019-03-17 18:20:08 agreed 2019-03-17 18:20:12 well, ideally we ask people if they're ok with having it published 2019-03-17 18:20:25 so if there's *any* doubt, just tell me to not include it and I'll put N/A 2019-03-17 18:20:32 with a TODO to resolve all N/As 2019-03-17 18:20:41 also, nickname or username? 2019-03-17 18:20:43 (as well as a gentle "also please confirm you're active and involved") 2019-03-17 18:20:52 I really think the difference is moot 2019-03-17 18:20:59 I can't speak for other people, unfortunately 2019-03-17 18:21:01 "user-chosen identifier" :) 2019-03-17 18:21:22 https://i.imgur.com/1XCgG8b.png this is for core devs 2019-03-17 18:21:30 I'm writing it into CSV 2019-03-17 18:21:43 if you could, write in asciidoc format 2019-03-17 18:21:48 let me give you a quick preview 2019-03-17 18:21:49 I don't know asciidoc format 2019-03-17 18:21:54 it's quite simple 2019-03-17 18:22:13 https://i.imgur.com/YcNYRCS.png 2019-03-17 18:22:18 what I have for infrastructure right now 2019-03-17 18:22:31 there's only one more entry for infra 2019-03-17 18:22:48 also re: nicks I'm defaulting to irc nick, I think, since that's where people are likely to use that 2019-03-17 18:22:56 | Kevin Daudt | _ikke_ | kdaudt@alpinelinux.org 2019-03-17 18:22:57 there's also github, but that should (usually) be quite similar 2019-03-17 18:23:02 aha :) 2019-03-17 18:27:44 ok, got everything so far 2019-03-17 18:27:52 I'm almost done 2019-03-17 18:27:59 did you do it too? 2019-03-17 18:28:04 I think core devs names/email should be published regardless, since they have the most responsibility 2019-03-17 18:28:25 for developers (packaging team) I'll go by whether or not their nick has parts of their name in it 2019-03-17 18:28:26 <_ikke_> I don't think any core devs atm have issues with that 2019-03-17 18:28:44 (e.g for Shiz I'll N/A the Name) 2019-03-17 18:29:06 here's everything except the "developers" section https://hastebin.com/dajoyenife 2019-03-17 18:29:07 almost done 2019-03-17 18:29:23 oh, yeah I'd done that already, oops :) 2019-03-17 18:29:29 is there IRC log of today #alpine-meetbot session? 2019-03-17 18:29:33 <_ikke_> mps: yes 2019-03-17 18:29:35 check that the emails are correct and all 2019-03-17 18:29:37 <_ikke_> check #alpine-meetings 2019-03-17 18:29:42 don't bother aligning btw, I have :Sort on my (n)vim 2019-03-17 18:29:44 <_ikke_> the link in the topic also contains a log 2019-03-17 18:29:51 <_ikke_> (a link to log) 2019-03-17 18:30:31 so security is going to be mostly empty, and we're just missing packaging (developers) 2019-03-17 18:30:59 _ikke_: thanks, I planned to lurk but was on short travel at the time 2019-03-17 18:31:09 also, I'm going by pure alphabetical order re: team leads 2019-03-17 18:31:11 because I realized 2019-03-17 18:31:23 outsiders don't care if they're talking to a team lead or "just" a member - they just want someone able to act 2019-03-17 18:31:30 and if you're looking for a lead specifically, bold should be enough 2019-03-17 18:32:05 while having pure alphabetical order means lookup is faster 2019-03-17 18:32:29 https://hastebin.com/oheqavezuh not ordered alphabetically 2019-03-17 18:32:50 also, I don't think it matters too much, I'm in favor of having the team lead at the top for clarity anyway 2019-03-17 18:33:14 that hastebin is core -> infra -> 'developers' (packaging) 2019-03-17 18:33:28 just ripped right off the intra wiki 2019-03-17 18:34:01 mhm 2019-03-17 18:35:31 for a lot of these, their nicks often contain parts of their name, as well as their emails 2019-03-17 18:35:36 so I can't imagine they're against that being available 2019-03-17 18:35:53 shiz being the main exception 2019-03-17 18:36:45 I'll avoid giving Roberto's surname, since that's also notably missing 2019-03-17 18:36:49 (but ask later) 2019-03-17 18:37:19 his full name is registered at bugs.a.o for example 2019-03-17 18:37:24 i doubt he minds 2019-03-17 18:37:49 ah, alright 2019-03-17 18:38:06 that should do it then 2019-03-17 18:38:41 relevant section(s): https://brpaste.xyz/nxRHXw?lang=asciidoc 2019-03-17 18:38:43 look good? 2019-03-17 18:39:18 ha 2019-03-17 18:39:24 asciidoc doesn't like .space gTLD? 2019-03-17 18:39:41 it's asciidoctor (the implementation) 2019-03-17 18:39:44 I already filed a bug :) 2019-03-17 18:39:52 but yeah, I suspect that's what's going on 2019-03-17 18:39:59 it recognizes links, but not emails 2019-03-17 18:40:05 I think link-wise it just goes by https?:// 2019-03-17 18:40:43 nobody uses gopher:// anymore so no worries 2019-03-17 18:41:01 also, looks okay to me 2019-03-17 18:41:14 would prefer the team lead at the top but that's it 2019-03-17 18:42:23 I think the advantage of being fully alphabetical is worth it, but would be willing to change if more people insist 2019-03-17 18:42:30 but alright! that's good :D 2019-03-17 18:42:39 let me get this set up, push, and show off, then 2019-03-17 18:42:58 I don't insist, don't worry 2019-03-17 18:44:50 <_ikke_> I doesn't matter that much to me either 2019-03-17 18:47:11 heh, our compiler is being stubborn again 2019-03-17 18:47:25 do either of you have access to whatever hosts the builder for docs.a.o? 2019-03-17 18:47:34 it needs its cache cleaned and to be ran by hand :( 2019-03-17 18:47:37 I don't have access to much, _ikke_ probably does 2019-03-17 18:47:39 it didn't pick up the new component, looks like 2019-03-17 18:47:48 (ran it on laptop, works fine here) 2019-03-17 18:48:11 I'd rather it be available so I can simply link it to ncopa for approval tomorrow 2019-03-17 18:48:17 <_ikke_> Not sure what is building it 2019-03-17 18:48:39 it's based on mqtt, from what clandmeter told me 2019-03-17 18:48:52 the binary itself should be somewhere like ~/.yarn/bin/antora 2019-03-17 18:48:53 <_ikke_> There is a docs container 2019-03-17 18:49:02 most likely that one 2019-03-17 18:49:07 that sounds like that'd be it 2019-03-17 18:49:17 and it's not in netbox, darn it 2019-03-17 18:49:36 <_ikke_> danieli: yeah, was looking there, will add it 2019-03-17 18:50:01 <_ikke_> Does not have a static IP either 2019-03-17 18:50:42 <_ikke_> mqtt-exec is stopped 2019-03-17 18:51:05 that... probably would do it 2019-03-17 18:51:13 did it crash or something? 2019-03-17 18:51:16 maybe it crashed because the two pushes (to separate repositories) are interdependent 2019-03-17 18:51:35 then again, it shouldn't have crashed with how I did it... hmm 2019-03-17 18:53:06 <_ikke_> SpaceToast: I ran the command manually (it completed instantly) 2019-03-17 18:53:08 <_ikke_> can you check? 2019-03-17 18:53:28 _ikke_: looks good! 2019-03-17 18:53:33 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/index.html :D 2019-03-17 18:53:54 <_ikke_> Oh, I ran it in a way nothing would happen anyway :P 2019-03-17 18:54:07 <_ikke_> But I guess it ran when I started mqtt-exec 2019-03-17 18:56:08 <_ikke_> "they may not have zero team leads." 2019-03-17 18:56:26 its probably not added to a runlevel? 2019-03-17 18:56:49 <_ikke_> clandmeter: it is, it was just marked as "stopped" 2019-03-17 18:56:51 has the container been restarted? 2019-03-17 18:56:52 <_ikke_> not even crashed 2019-03-17 18:56:54 odd 2019-03-17 18:57:16 <_ikke_> it does seem to use supervisor 2019-03-17 18:57:27 it has been rebooted 2019-03-17 18:57:35 are you sure its in a runlevel? 2019-03-17 18:57:41 hey clandmeter :) 2019-03-17 18:57:48 hi 2019-03-17 18:57:51 <_ikke_> unlevel: default 2019-03-17 18:57:53 <_ikke_> networking 2019-03-17 18:57:55 <_ikke_> darkhttpd 2019-03-17 18:57:57 <_ikke_> sshd 2019-03-17 18:57:59 <_ikke_> mqtt-exec 2019-03-17 18:58:01 <_ikke_> crond 2019-03-17 18:58:03 <_ikke_> I did not change that 2019-03-17 18:58:13 what happens when you reboot the container? 2019-03-17 18:58:37 <_ikke_> It's started 2019-03-17 18:58:45 it has been working before, just since the reboot it stopped i guess 2019-03-17 19:00:12 <_ikke_> SpaceToast: The weight of the bold parts seems to be very low 2019-03-17 19:00:16 <_ikke_> hardly noticable 2019-03-17 19:00:22 that's a theme thing 2019-03-17 19:00:25 we have to write our own anyways 2019-03-17 19:00:32 I'll try and remember it 2019-03-17 19:00:33 I'll get onto that tonight 2019-03-17 19:00:38 oh, cool, thanks :D 2019-03-17 19:00:56 I'll just clone, edit, and hand you a patch 2019-03-17 19:01:00 for most purposes though, the difference between a team lead and member is mostly organizational - they get to add new members and get to vote on other stuff 2019-03-17 19:01:43 it's... not quite as simple as that, antora theming is done a bit differently; default UI is here: https://gitlab.com/antora/antora-ui-default 2019-03-17 19:01:50 you may also notice strange artifacts like the menu 2019-03-17 19:02:03 (what's Product B?) - so we really do need to make one basically from scratch 2019-03-17 19:02:20 gotcha. I'll have a look 2019-03-17 19:02:33 there was someone that was supposed to be working on it, but at this point I suspect they haven't done anything, so I would start on it once user-handbook is otherwise ready for deployment 2019-03-17 19:02:38 let me see if they have docs... 2019-03-17 19:03:07 https://docs.antora.org/antora-ui-default/set-up-project/ there we are 2019-03-17 19:03:09 that and what follows 2019-03-18 09:52:26 SpaceToast: around? 2019-03-18 10:30:39 danieli: im ok with copying data from wiki.alpin.pw, but please be careful cause maybe some is private. 2019-03-18 10:30:46 clandmeter: I am aware 2019-03-18 10:30:51 i like to keep that wiki alive for internal infos 2019-03-18 10:31:15 yeah no, I'm not going to blindly leak info from there 2019-03-18 10:31:46 SpaceToast: im not a core dev anymore? ;-) 2019-03-18 10:32:05 looks like she missed one 2019-03-18 10:32:09 er, they* 2019-03-18 11:32:16 moin \o 2019-03-18 11:32:37 I suppose I did, it's a quick fix though :) 2019-03-18 11:33:24 though as with ncopa, ideally more things should be removed from core over time (both responsibilities and people), we mostly codified the status quo yesterday 2019-03-18 11:33:33 and she is correct, lol 2019-03-18 11:34:35 pushed 2019-03-18 11:35:21 clandmeter: notably, it looks like mqtt has died again (I noticed it yesterday before falling asleep, but just now it failed to refresh again 2019-03-18 11:35:54 mqtt-exec [ started 16:37:18 (0) ] 2019-03-18 11:36:42 it is running, dont know why its not updating. 2019-03-18 11:36:49 i can check it in a bit 2019-03-18 11:37:01 sure, no worries 2019-03-18 11:37:14 you won't appear in the core list until you figure it out, after all ;) 2019-03-18 11:37:39 omg, ill do it right now. 2019-03-18 11:38:31 :) 2019-03-18 11:38:32 we need to make the initd configurable to have a logfile instead of only dev.null 2019-03-18 11:39:14 I can try and poke that next time I have some time off 2019-03-18 11:39:14 first i need to scream a few times against ruby gems now. 2019-03-18 11:39:24 . . . so maybe thursday? :/ 2019-03-18 11:40:06 to fix ruby gems i will need a another century 2019-03-18 11:47:56 SpaceToast: i changed the logfile and restarted the service 2019-03-18 11:48:06 not sure whats going on, but next push i could know more. 2019-03-18 11:48:14 ok 2019-03-18 11:48:20 in the meanwhile, could you do a by-hand rebuild? 2019-03-18 11:48:26 its uptodate 2019-03-18 11:48:28 i think 2019-03-18 11:48:30 i see myself now 2019-03-18 11:48:33 ah, now it is :) 2019-03-18 11:48:36 but incorrect email address 2019-03-18 11:48:37 clandmeter: to easy you burden about ruby gems I agree with you :) it's a mess, didn't know untill I started to work with them 2019-03-18 11:48:50 can you update it to alpinelinux.org? 2019-03-18 11:48:55 then ill check what it does 2019-03-18 11:49:10 oh, I see 2019-03-18 11:49:22 I couldn't find any references to it on my first go-around 2019-03-18 11:49:54 pushed 2019-03-18 11:50:45 no responce 2019-03-18 11:50:56 i think it has issues with reading from mqtt 2019-03-18 11:51:11 perhaps the new git repo isn't generating signals, despite being inside docs/? 2019-03-18 11:51:15 I'm not sure how those are being done 2019-03-18 11:51:29 is the repo n ew? 2019-03-18 11:51:32 yes 2019-03-18 11:51:46 it's a separate module 2019-03-18 11:51:49 https://git.alpinelinux.org/docs/developer-handbook/ 2019-03-18 11:53:12 that should fit the scope 2019-03-18 11:53:39 ah found it 2019-03-18 11:56:25 <_ikke_> ACTION hangs in suspension 2019-03-18 11:56:51 the script doesnt support mutliple repos 2019-03-18 12:03:04 i think its ok now, so lets way and see on next push 2019-03-18 14:41:49 hi ppl 2019-03-18 14:42:03 <_ikke_> ncopa: o/ 2019-03-18 14:42:07 sorry for not showing up at the meeting yesterday 2019-03-18 14:42:13 <_ikke_> No problem 2019-03-18 14:42:14 good work everyone! 2019-03-18 14:42:30 i guess this is a good place to ask questions? 2019-03-18 14:43:00 what is the reasoning for allowing more than one team lead? 2019-03-18 15:32:08 Team leads aren't necessarily a super special position - the main difference is that they can add new members and get to vote 2019-03-18 15:32:21 But a team not having a lead is a potential problem 2019-03-18 15:37:23 (since it means no new members can be added, nor can anyone leave, at least not officially) 2019-03-18 15:37:49 So, as per usual, the reasoning is that it allows multiple advantages, and has no disadvantages 2019-03-18 17:21:23 what i am slightly worried about is if both team leads think "that will the other team lead take care of" 2019-03-18 17:21:55 also what may happen if team leads disagree 2019-03-18 17:24:01 i think it may make sense to also have the policy for leaving a team and dissolving a team in place at the same time 2019-03-18 17:24:07 or at least a plan for it 2019-03-18 17:24:39 so we dont end up with a situation where its super easy to create new team but impossible to take it down 2019-03-18 17:58:41 That's the thing, team leads don't "take care" of anything 2019-03-18 17:58:58 The ONLY difference between a team lead and a team member is that team leads have a vote and can add new members 2019-03-18 17:59:03 There is no other difference 2019-03-18 17:59:15 If you're a team member you're fully instated and can take care of things yourself 2019-03-18 18:08:11 ok 2019-03-18 18:48:08 Re: dissolution, since teams cannot have zero leads, if the last lead leaves and no one is jumping to take their place, I think it can dissolve (same as 0 members) 2019-03-18 18:48:22 Can't codify that right now though, work is being very busy :) 2019-03-18 18:49:53 understood. no stress. 2019-03-18 18:50:15 anything regarding teams that is blocking on me now? 2019-03-18 18:51:50 <_ikke_> I guess the final decission? 2019-03-18 18:53:45 was there an email sent about that or similar? may be good to have such thing on the record 2019-03-18 18:54:41 <_ikke_> No, there hasn't 2019-03-18 18:55:02 <_ikke_> Would be a good idea indeed 2019-03-18 19:07:33 _ikke_: could you send a link to the meeting results and the new page to the ML? :) 2019-03-18 19:07:56 And ncopa can then officially reply with final decision (or request changes) 2019-03-18 19:08:17 <_ikke_> https://meetbot.alpinelinux.org/meetbot/meetings/%23alpine-meetings/2019-03-17-14%3A03_Teams-and-Organization.html 2019-03-18 19:08:21 <_ikke_> those are the notes 2019-03-18 19:09:21 <_ikke_> Do you mean this https://lists.alpinelinux.org/ ? 2019-03-18 19:12:38 No, I mean beta.docs.a.o/dev-hand/index.html 2019-03-18 19:12:49 (aka the resulting document, even if not fully amended yet) 2019-03-18 19:14:15 <_ikke_> SpaceToast: Ah, sorry, I read your question wrong 2019-03-18 19:16:40 i think it may make sense to send the meetboot summary to the alpine-devel mailing list too 2019-03-18 19:17:14 <_ikke_> yes, that was my plan 2019-03-18 19:23:35 That is indeed what I meant to suggest :) 2019-03-18 19:31:23 i also wonder if it makes sense to split the "packaging" team or aports team 2019-03-18 19:31:46 currently its only "core" devs that has git push access to main and stable branches 2019-03-18 19:31:52 <_ikke_> ncopa: Was wondering that myself 2019-03-18 19:32:02 and long list of more people who have access to community and testing 2019-03-18 19:33:04 i also dont want be alone when deciding who gets git push access to main 2019-03-18 19:33:58 <_ikke_> Mailing list post sent 2019-03-18 19:34:13 <_ikke_> hence multiple team leads? 2019-03-18 19:50:24 Yup 2019-03-18 19:58:57 ncopa: also, ideally we would populate the security team, and take you off of a couple (if you're leading every team, it isn't exactly accomplishing our goal 1, is it?) 2019-03-18 19:59:16 I believe danieli volunteered to lead the security team, but it's up to you before everything is all confirmed etc 2019-03-18 20:07:09 also, we probably need write down the policies how to get @alpinelinux.org email addr 2019-03-18 20:07:21 who gets it, etc 2019-03-18 20:07:48 You tell me :) 2019-03-18 20:07:56 Also the same for @alpine cloaks 2019-03-18 20:08:20 ^ 2019-03-18 20:08:43 i'd prioritize figuring out emails over cloaks at the moment though 2019-03-18 20:08:48 ok, lets deal with one thing at the time 2019-03-18 20:13:05 +1 2019-03-18 20:13:32 I mention them since they should probably be treated the same 2019-03-18 20:13:45 At least in terms of accessibility 2019-03-20 18:12:16 it doesn't look like anyone has any comments on the team stuff in the ML (it's been ~3+ days) 2019-03-20 18:12:43 ncopa: perhaps respond to it affirmatively and we can start implementing? (with the obvious first thing being asking leads to clean up membership list, and figuring out security team membership) 2019-03-20 18:13:00 (note: I would have suggested this earlier, but my $dayjob sprint is ending today, in ~4h :) ) 2019-03-20 18:14:35 hi 2019-03-20 18:14:48 heya :) 2019-03-20 18:15:01 too bad about pingu btw, might have to write something up with pyroute2 now 2019-03-20 18:16:04 unless you want take over it 2019-03-20 18:16:20 i would love to work on pingu, it was one of the more fun projects 2019-03-20 18:16:33 I took a quick look, and I'm not sure how to implement the fix I have in mind :( 2019-03-20 18:16:47 but 1) i dont use it myself anymore, 2) i should rather spend my time on other things 2019-03-20 18:16:51 basically, for each WAN, the table is filled with routes that have something to do with that WAN 2019-03-20 18:17:07 what SHOULD be happening instead is that for each WAN, the table should be filled with all routes, minus routes that have to do with other tracked WANs 2019-03-20 18:17:22 this avoids breaking loopback NAT, while keeping wan address pinning 2019-03-20 18:17:59 right, i think that makes sense 2019-03-20 18:17:59 but the way you're handling it (right now) is you only pass the gw in question to the function that does the filtering 2019-03-20 18:18:16 while it would need the list of all gws, as well as the index of the one being handled 2019-03-20 18:18:20 and that seems a bit involved 2019-03-20 18:19:18 i dont think i have mental energy for looking at the code now... 2019-03-20 18:19:33 yeah, don't worry :) 2019-03-20 18:19:44 it's your project, and you have the full right to not work on it 2019-03-20 18:20:01 this made me a bit sad: https://github.com/alpinelinux/aports/pull/5717#issuecomment-474686094 2019-03-20 18:20:02 any ideas re: ML/teams? 2019-03-20 18:20:22 yes, im gonna search for the email re ML/teams 2019-03-20 18:20:29 im afraid of opening my inbox 2019-03-20 18:20:43 im sure it will give me bad concience :) 2019-03-20 18:21:32 owch~ 2019-03-20 18:22:09 message ID is 20190318193346.GA18235@alpha, if that helps 2019-03-20 18:22:32 and yeah, that post seems sad to me too, and is one of the things I'd ideally like to improve with all of this 2019-03-20 18:26:00 yes, i know 2019-03-20 18:31:03 ncopa: if I knew for this url it will save me time 2019-03-20 18:31:27 <_ikke_> what url? 2019-03-20 18:31:49 above, ncopa just posted here 2019-03-20 18:32:06 https://github.com/alpinelinux/aports/pull/5717#issuecomment-474686094 2019-03-20 18:32:49 <_ikke_> Don't follow your safe time comment related to that post 2019-03-20 18:35:01 I worked alone to upgrade llvm, clang, lld, lldb and in same time there is a people who works in paralel on the same thing 2019-03-20 18:35:46 <_ikke_> ah ok 2019-03-20 18:37:16 but I don't complain, I'm happy if they take maintainership, I will have time for things which interest me more 2019-03-20 18:54:55 regarding the teams org, think the current defacto is: http://lists.alpinelinux.org/alpine-devel/6025.html 2019-03-20 18:55:18 and this: http://lists.alpinelinux.org/alpine-devel/6024.html 2019-03-20 18:58:45 <_ikke_> Has that ever been used? 2019-03-20 18:59:07 <_ikke_> There are some people with developer status I guess 2019-03-20 19:05:14 yes 2019-03-20 19:05:54 we sort of use it when adding new people with git push access 2019-03-20 19:06:07 <_ikke_> ok 2019-03-20 19:06:31 and we have followed it in at least one case where we considered kick one out 2019-03-20 19:06:36 <_ikke_> nod 2019-03-20 19:06:48 two times there have been given warning according that doc 2019-03-20 19:07:31 i think it would be good to have the "how to kick out a misbehaving team member" procedure in place 2019-03-20 19:19:29 current doc (on docs.a.o) simply says that team leads can remove misbehaving team members 2019-03-20 19:19:51 internal organization is left up to the teams to decide upon - do we want this to be stricter? 2019-03-20 19:21:59 <_ikke_> Should one person be able to kick someone out? 2019-03-20 19:22:25 yes, because the people with that power are nominated (and de-nominated) through a vote (of all other such people) 2019-03-20 19:22:54 if a lead kicks someone out without proper justification, they can be voted out and the person re-invited, in the worst of scenarios 2019-03-20 19:23:12 (as all additions/removals have to be recorded in the public docs) 2019-03-20 19:23:53 of course, each team is allowed to internally organize their own procedures to kicking someone out 2019-03-20 19:33:21 SpaceToast: let me as outsider to that doesn't sound justified to allow one person to kick someone before some triage 2019-03-20 19:34:26 s/to that/to note that/ 2019-03-20 19:38:04 mps: well, the status quo listed is someone wants X out, they post on the ML, and then a single person (member, not lead) of the core team decides if it should be done or not 2019-03-20 19:38:27 I think team matters should stay local to the team, and think that a lead of a given team is likely a better resource than a member of core, on average 2019-03-20 19:38:35 but we can definitely discuss this, of course :) 2019-03-20 19:39:37 I think team matters should stay in team, but have seen bad things where leader have absolute rights 2019-03-20 19:39:38 (the core member handles looking at supporters and otherwise, mind you, and then a vote is supposed to happen) 2019-03-20 19:39:48 this is why there is not a single leader 2019-03-20 19:39:53 I'm starting to think "team lead" is the wrong term 2019-03-20 19:39:58 did you read the docs page mps? 2019-03-20 19:40:24 yes, but must admit, not thoroughly 2019-03-20 19:40:40 a "team lead" (of which there may and should be multiple) has two privileges above members: 2019-03-20 19:40:49 1. they get to vote; 2. they can add and remove members 2019-03-20 19:41:02 to become a team lead, all other team leads must vote you in (across all teams) 2019-03-20 19:41:12 so it's not really a "leader" thing - more of an administrator 2019-03-20 19:41:22 ok, ok, you don't have to repeat that here, I read this 2019-03-20 19:41:53 sorry if I misunderstood 2019-03-20 19:42:12 so it's not like they're leading team decisions internally ( they could be, but that's up to the team ) 2019-03-20 19:42:23 perhaps we should codify that all team leads of a given team should vote on removals? 2019-03-20 19:42:27 but giving one person, whoever it is, full rights to kick someone is not good idea, imho 2019-03-20 19:42:48 (if there's only one lead, then they get to do it, but we expect multiple leads as things expand) 2019-03-20 19:44:13 yes, someone, be it person or team, have to do 'dirty work', but ime, other members of team should have right to express their opinion 2019-03-20 19:45:20 perhaps 2019-03-20 19:45:30 the linked status quo reads like a popularity contest, to me, to be honest 2019-03-20 19:46:40 eh, agree. but why we talk about things which will never happen, I hope :) 2019-03-20 19:46:57 procedures exist to remove uncertainty 2019-03-20 19:47:06 (and thus minimize interrupts) 2019-03-20 19:47:23 I'm not sure if it's a good idea for the entire team to vote on it 2019-03-20 19:48:09 as teams get bigger that would become pretty expensive (time-wise) to do, and descend 2019-03-20 19:48:24 I'm fine with having all of that team's leads vote on it, though 2019-03-20 19:48:47 (which would mean single-person power if there's only one team lead, but that would be in the early days of any given team, and that kind of flexibility may be useful under those circumstances) 2019-03-20 19:48:59 e.g consider current team listings - there are (I'm told) lots of inactive people there 2019-03-20 19:48:59 voting is issue which are not resolved for millennia, so it is hard to tell what is right 2019-03-20 19:49:16 imagine having to ask all of them (including the afk ones) if it's ok to remove someone (that has also been afk) 2019-03-20 19:49:57 since right now said teams only have ncopa as a lead, with the leads-only system we get higher agility at first, and more consistency once there are more leads (and thus the team is bigger) 2019-03-20 19:50:03 so I think that might be an appropriate approach 2019-03-20 19:51:01 I'm not against your proposal, and as you noted it could/should be discussed, and I'm outsider so you can safely ignore my words 2019-03-20 19:51:25 hey, you might consider joining at some point :) 2019-03-20 19:51:27 mps: i think you have valid concerns 2019-03-20 19:51:41 anyone and everyone should be able to chime in, before everything's finalized (and set in concrete (not quite in stone)) 2019-03-20 19:52:05 what i worry about is misbehaving "team leads" (or whatever we end up calling it) 2019-03-20 19:52:21 team leads have to be voted in by all other team leads 2019-03-20 19:52:31 and any team lead may be voted out by all other team leads, in case of misbehavior 2019-03-20 19:52:33 <_ikke_> I think what's important is that it's abundantly clear that it's not something that should be used lightly 2019-03-20 19:52:43 _ikke_: that makes sense 2019-03-20 19:52:44 <_ikke_> s/it's/it should be 2019-03-20 19:53:15 i really like the idea that the teams can organize themselves 2019-03-20 19:53:18 I noticed in some teams that misbehaving persons tends to rise up faster than well behaving, to note some of my observation 2019-03-20 19:54:27 I still have a hope that all issue could be resolved by 'common sense', or I'm idealist 2019-03-20 19:54:32 also, when a conflict happen and emotions are involved, its very very nice to have a written procedure how to move forward 2019-03-20 19:54:46 a written procedure that everyone else has agreed on earlier 2019-03-20 19:54:54 terms of beeing a member 2019-03-20 19:55:07 that is good idea 2019-03-20 19:55:21 become a member you agree on the CoC 2019-03-20 19:55:24 but without CoC 2019-03-20 19:55:34 so you dont later can say "i dont agree with the CoC" 2019-03-20 19:56:52 also if a "team lead" abuses his power, who/how should the team members report it? 2019-03-20 19:57:15 I understand your intention with CoC, but I still believe that the developors are 'grown' persons, exception are there but could be solved without strong rules 2019-03-20 19:57:41 sorry, have to go out, see you later 2019-03-20 19:57:52 there are people who are super nice with people above them but really horrible to people who they feel are under them 2019-03-20 20:17:27 ncopa: I think team members should tell any other team lead of their choice, who will then bring it up in alpine-meetings or similar 2019-03-20 20:17:45 I'm horrible towards everyone equally :) 2019-03-20 20:18:50 mps: you can't rise in this team structure, the only "higher" position than member is lead, and that involves all the leads voting on it together 2019-03-20 20:47:45 i sort of want avoid "everyone needs to meet and we vote or nothings happens" 2019-03-20 20:47:57 because from experience people often dont care 2019-03-20 20:48:00 yes, that's why the team-internal stuff should be handled internally 2019-03-20 20:48:07 and dont respond 2019-03-20 20:48:12 also, I suppose the "everyone" is optional - the vote is between everyone that shows up 2019-03-20 20:48:22 but even for the team lead coordination 2019-03-20 20:48:29 adding/removing team leads 2019-03-20 20:48:50 yes... I personally see attending those things as a part of the responsibilities you take when you become a lead 2019-03-20 20:48:54 so perhaps that should be documented? 2019-03-20 20:49:28 what I currently do is i ask is if someone at the core team have objection to add a new member 2019-03-20 20:49:55 most respond with "no objection". its easy for them 2019-03-20 20:50:02 and then we have a 2 week limit 2019-03-20 20:50:26 so i f not enough people have responded within 2 weeks, i can go ahead 2019-03-20 20:50:29 2 weeks sounds like a pretty long time 2019-03-20 20:50:45 well, you can be on vacation or be sick or whatever 2019-03-20 20:50:54 I also think being a lead implies a certain level of activity and availability (one that can be temporarily paused by notice in advance) 2019-03-20 20:51:12 right 2019-03-20 20:51:14 after all, if you can't be there, why do you have a vote to begin with 2019-03-20 20:51:25 so we may want document what is expected 2019-03-20 20:51:29 yes, that makes sense 2019-03-20 20:51:43 <_ikke_> There is the problem of timezones 2019-03-20 20:51:48 <_ikke_> and working schedules 2019-03-20 20:52:09 you're telling *me* that? ;) 2019-03-20 20:52:15 yes and i think important decisions shouldnt be rushed 2019-03-20 20:52:35 I suppose the mass votes are to add/remove leads, which is indeed significant 2019-03-20 20:52:46 2 weeks does sound like overkill though, and I'm quite impatient 2019-03-20 20:52:59 perhaps 1 week? (to guarantee hitting a weekend) 2019-03-20 20:53:34 but the idea is that there is a limit 2019-03-20 20:54:04 well, I originally envisioned a full on meetbot meeting (so a ~30 minute vote) 2019-03-20 20:54:14 but synchronizing everyone is hard, especially if we actively expect everyone to be present 2019-03-20 20:55:17 perhaps we don't hard define a limit, just that there should be one 2019-03-20 20:55:35 (that way it can be much lower as we bootstrap everything, and grow to 1-2 weeks as the dust settles and membership gets higher) 2019-03-20 20:55:39 i think we can start with the one we currently have 2019-03-20 20:55:46 and then change it 2019-03-20 20:55:52 hmm 2019-03-20 20:56:03 i mean, we dont need spend time on 1 day, 2 weeks discussion right now 2019-03-20 20:56:15 ok, in that sense I suppose it's fine 2019-03-20 20:56:27 but I do think 2 weeks is far too high with the current set of leads 2019-03-20 20:56:31 the more important thing is that each team can decide things for them selves 2019-03-20 20:56:49 and making the set of leads higher would then have a 2 week RTT 2019-03-20 20:56:57 yes, that's already mostly documented 2019-03-20 20:57:28 just needs some spucing up 2019-03-20 20:57:35 (the glossary, and the organization of the pre-list stuff) 2019-03-20 20:57:37 also, as it works now, the 2 week limit is if not enough responds 2019-03-20 20:57:48 aha 2019-03-20 20:58:04 so you can still ping each for a response if its urgent 2019-03-20 20:58:28 its not that you must wait 2 weeks 2019-03-20 21:00:49 ok, no problem for bootstrap then 2019-03-20 21:01:04 so let me go over the changes to make so far: 2019-03-20 21:01:21 1. be specific about members being removed (team organizes internally, we recommend a 2/3 majority vote between all leads) 2019-03-20 21:01:51 2. be specific about adding/removing team leads (50% majority across all team leads in the project, established time limit) 2019-03-20 21:02:13 3. specify what is expected of a team lead (being there and active, notifying people in advance if they're planning to be away) 2019-03-20 21:02:45 4. define developer (any team member, on any team, including "nontechnical" members, who shall not be differentiated (teams organize that internally)) 2019-03-20 21:02:50 does that sound complete? 2019-03-20 21:09:30 yes i think so 2019-03-20 21:10:57 again, thank you very much for helping with this 2019-03-20 21:11:47 and thanks for being persistant and patient :) 2019-03-20 21:32:23 ¯\_(ツ)_/¯ 2019-03-20 21:32:29 it's gonna make my (and many others') jobs easier :) 2019-03-20 21:32:45 so this is purely self interested, don't take it the wrong way or anything ;) 2019-03-20 21:32:58 certainly wouldn't want people to think I'm a good person or anything, then they start expecting unreasonable things~ 2019-03-21 01:46:31 alright, I did my best to rework the pre-listing part to be more clear, complete, and include/cover all of the above 2019-03-21 01:47:23 I'm going to lose consciousness for a while now, so if there's any feedback, please try to not ping me until at least 12h from now (9:47pm EST), but please do so afterwards :) 2019-03-21 01:47:39 for reference, still on https://beta.docs.alpinelinux.org/developer-handbook/0.1a/ 2019-03-21 21:48:54 ddevault: out of curiosity - does lists.sr.ht support access controls? 2019-03-21 21:49:27 just a minimal implementation 2019-03-21 21:49:43 if you're interested in that (like ACLs) I can probably put it together this week 2019-03-21 21:49:57 to be more specific, I can see potential use-cases for read-only lists (only approved accounts can post, anyone can subscribe), write-only lists (anyone can send, only approved accounts can read) and fully private lists (only approved accounts can do anything) 2019-03-21 21:50:09 for example, write-only lists may be useful for CVE reporting 2019-03-21 21:50:21 these are all supported, but without ACLs 2019-03-21 21:50:30 so you can't add people to your authorized users list 2019-03-21 21:50:44 hmm, how is it handled then? 2019-03-21 21:51:05 read-only would be useful for a -docs ML (so only devs can post "hey, modify docs on X", but anyone can see the changes to the overall project) 2019-03-21 21:51:11 you can configure permissions for non-subscribers, subscribers, and account holders separately 2019-03-21 21:51:21 the list owner is assumed to have all permissions 2019-03-21 21:51:36 is it possible to turn off subscriptions? 2019-03-21 21:51:48 yes, but only by also turning off the ability to browse 2019-03-21 21:51:57 that seems reasonable, thanks :) 2019-03-21 21:52:02 reason being that users who can browse the web archives but not subscribe could just scrape it and it'd be effectively the same 2019-03-21 21:52:10 yeah 2019-03-21 21:52:25 in that case, I think I'd be alright switching to lists.sr.ht (whatever my support is worth, anyway) 2019-03-21 21:53:00 I'll see about adding per-user ACLs tomorrow 2019-03-21 21:53:02 I should have time 2019-03-21 21:53:02 though having full ACLs might be a nice-to-have at some point to make management easier on the infra 2019-03-21 21:53:05 nice :) 2019-03-21 21:53:48 my immediate priorities are (1) RISC-V stuff I've been putting off, which I mostly sorted today, (2) kicking off the Python overhaul in aports, (3) adding APIs & webhooks to more *.sr.ht services 2019-03-21 21:54:09 alpine's slot can be repurposed if necessary :) 2019-03-21 21:54:17 speaking of, meta.sr.ht can act as an oauth provider, right? 2019-03-21 21:54:20 yes 2019-03-21 21:54:21 (that's what I recall, at least) 2019-03-21 21:54:28 ok good, just making sure 2019-03-21 21:54:59 I think that's a really redeeming bit for it (it makes no sense to just have it sitting there just for the MLs, but if, say, we switched to gitlab and could just use the existing ML accounts on there, that'd be quite nice) 2019-03-21 21:55:22 why switch to gitlab when you could switch to git.sr.ht ;D 2019-03-21 21:55:27 but yeah, in theory that'd work 2019-03-21 21:56:50 gitlab keeps coming up :) obviously meta.sr.ht is no problem if we use git.sr.ht, but it being a capable oauth provider means we aren't locked into the set 2019-03-21 21:57:24 gitlab has a pretty sizable advantage in that the interface and feature set is mostly familiar to a lot of github-transitioning users 2019-03-25 10:22:12 SpaceToast: I think the current teams list is not accurate. I think we should give you read access to our current gitolite config 2019-03-25 10:29:08 SpaceToast: prspkt and misery have access to testing and community repos 2019-03-25 11:42:38 <_ikke_> ncopa: PR for updating stalebot message: https://github.com/alpinelinux/aports/pull/6831 2019-03-25 11:46:54 _ikke_: personally i think the stale bot is rude against contributors 2019-03-25 11:47:32 the send patch, we dont have capacity to review, and suddenly a bot threaten to close it due to inactivity 2019-03-25 11:48:26 i also think its not enough to simply comment, to get it untagged. you need to rebase it 2019-03-25 11:49:01 ah, yes, you fix that part 2019-03-25 11:50:09 so i think the message should have different tnoe 2019-03-25 11:50:11 tone* 2019-03-25 11:50:55 "sorry, we are overloaded. in desperation we have hired this brainless bot. its not your fault. to help us please rebase" 2019-03-25 11:51:49 <_ikke_> ncopa: Yes, I agree that the stalebot is not friendly 2019-03-25 11:51:53 but that is my humble opinion 2019-03-25 11:52:03 <_ikke_> No, you are totally right 2019-03-25 11:52:09 <_ikke_> In an idea situation we would not need it 2019-03-25 11:52:26 i think we should be friendly, and i think we should require our bots to be friendly 2019-03-25 11:52:32 yes, i understand why we need it 2019-03-25 11:52:50 <_ikke_> ncopa: Hence the PR, so we can improve the message with eachother 2019-03-25 11:52:54 but imho we should communicate why we need the stupid bot to the contributors 2019-03-25 11:52:59 got you 2019-03-25 11:53:12 i'll leave a comment there 2019-03-25 14:42:44 i gave the docs team read access to the gitolite config 2019-03-25 14:44:33 I'll correct the listings (for the bits I can find) and poke here once I think everything's up to date (at least that's visible from there) 2019-03-25 14:45:57 where does the teams re-org block now? 2019-03-25 14:46:33 mostly approval (whether yours or everyone else's) 2019-03-25 14:47:14 if everyone's happy with the current state of the doc, we can mostly just go (correcting listings can happen even afterwards, though they'll likely happen within the next few hours) 2019-03-25 14:47:33 note: I renamed team leads to team admins due to the prevalent confusion (in case you haven't re-read it) 2019-03-25 14:58:27 who will get alpinelinux.org email address? team admins only? some of the members too? or all members? 2019-03-25 14:58:46 we should probably doc the policy for that too 2019-03-25 14:59:24 I would lean towards all members, since admins aren't supposed to be *too* much above in technicality 2019-03-25 14:59:33 but it's possible some teams wouldn't need anything of the sort 2019-03-25 14:59:38 maybe any team member may request one? 2019-03-25 15:05:35 the thing i am worried about is that as soon as you get an @alpinelinux.org email, you speak as an official representative for alpine project 2019-03-25 15:05:57 which comes with some responsibility 2019-03-25 15:07:46 yes, but being a team member does mean officially working on the project as well 2019-03-25 15:08:08 which is why I'm suggesting that any team member may *request* it 2019-03-25 15:08:17 the request can be denied, assuming a reason is given :) 2019-03-25 15:08:28 i have to say, i see ncopa's concern, but i agree with SpaceToast 2019-03-25 15:09:04 and the core team can be responsible for the administrative task of granting (or denying) applications of that sort 2019-03-25 15:09:18 *if* someone abuses it, it will have to be dealt with 2019-03-25 15:09:42 an option would be to reserve @alpinelinux.org emails for team leads and core devs only 2019-03-25 15:09:57 I think abusing an official email should be treated like abusing the access you have to the project (same as with push access), and thus treated similarly 2019-03-25 15:10:24 danieli: btw, "team lead" has been renamed to "team admin", due to the confusion most people seemed to have 2019-03-25 15:10:35 hopefully this helps people figure out the intent 2019-03-25 15:10:37 SpaceToast: fair enough, will keep that in mind 2019-03-25 15:10:47 i did not know that people decided to rename it 2019-03-25 15:10:51 you can always read the latest (pushed) status if you want :) 2019-03-25 15:11:07 I decided to rename it, because I think only one person of everyone here really managed to "get" it on the first try 2019-03-25 15:11:16 (I believe it was _ikke_, if I'm not mistaken?) 2019-03-25 15:11:18 lets do this: dont give anyone email address til we have established some use guidelines and have them documented 2019-03-25 15:11:26 of course 2019-03-25 15:11:30 duly noted 2019-03-25 15:12:03 so when I go over the team listing I'll add some TODOs to that effect 2019-03-25 15:12:15 the docs may be something like "use with care. make sure people understand what is your personal opinion and what is alpine linuxes as project" 2019-03-25 15:12:26 good 2019-03-25 15:13:23 is there anything else that needs to be addressed? 2019-03-25 15:19:07 i'd like to reduce the core team a bit 2019-03-25 15:19:17 but i guess thats something we can deal with internally 2019-03-25 15:19:35 yes 2019-03-25 15:19:51 whenever you have a new team member, or are removing someone, or are making a change that should be documented, please do drop it in here 2019-03-25 15:20:14 I'll add it to my notes if I can't deal with it immediately, or just go ahead and make the changes (my policy with things I can do right now that take 5 minutes or less) 2019-03-25 15:20:44 i was also thinking what to do with inactive members 2019-03-25 15:20:50 or team admins 2019-03-25 15:21:11 I think we should specify a period of inactivity (something like 4 months) 2019-03-25 15:21:25 if no one's seen a member (including admins) for that long, they should be gently poked (ideally with a stick ;) ) 2019-03-25 15:21:31 if there's no reaction, they get removed 2019-03-25 15:21:43 (if there is a reaction, the result should depend on the reaction, of course) 2019-03-25 15:22:00 "you are expected to be present for meetings and voting sessions." 2019-03-25 15:22:08 precisely 2019-03-25 15:22:25 ncopa: I'm also noticing that there's a loose "acfdev" team present as well - should that be defined? 2019-03-25 15:22:47 i dont think thats needed 2019-03-25 15:23:14 and speaking of acf - is it actively maintained? 2019-03-25 15:23:19 its basically only tdtrask that does acf 2019-03-25 15:23:30 i think he still maintains it to some degree 2019-03-25 15:23:33 (I didn't add a user-handbook section for "Working with ACF" since I'm not familiar with it (yet)) 2019-03-25 15:23:42 would have to ask, then 2019-03-25 15:23:50 but i dont know if we want keep it as an official alpine project 2019-03-25 15:24:00 it could be a separate project 2019-03-25 15:24:05 to keep things simpler 2019-03-25 15:24:14 ok 2019-03-25 15:27:09 im just trying to think of the effective change with implementing this 2019-03-25 15:27:40 currently, to add new members its the core team that votes 2019-03-25 15:28:01 they will lose that power with this change 2019-03-25 15:28:32 core team can no longer decide if we should and a new team with a new team admin 2019-03-25 15:28:40 instead its the team admins that has to vote on that 2019-03-25 15:29:37 same with expulsion. core team can no longer expel misbehaving people. instead it is a vote among team admins? 2019-03-25 15:32:28 yes 2019-03-25 15:32:45 this is mostly because the core team is a bit conflated - it's both an administrative team and the team that manages main/ 2019-03-25 15:33:42 so core team will be the packagers that maintains main and stable basically 2019-03-25 15:33:51 yes 2019-03-25 15:34:00 but the admin power is moved over to the team admins 2019-03-25 15:34:07 for team management stuff, yes 2019-03-25 15:34:15 core is also the decisionmaking point other project-related things 2019-03-25 15:34:19 (e.g who gets emails?) 2019-03-25 15:34:47 right. i guess that is where things are a bit fuzzy 2019-03-25 15:34:56 where goes the limit 2019-03-25 15:35:09 <_ikke_> things like public dns and managing assets? 2019-03-25 15:35:16 I'd say that's still core 2019-03-25 15:35:30 well not everyone in core has access to all that 2019-03-25 15:35:42 team admins manage things internal to their team, and the team organizational structure (adding/removing teams/members) 2019-03-25 15:35:52 so i guess thats something that we will have to clarify and doc 2019-03-25 15:35:58 who owns what 2019-03-25 15:35:59 everything else is still decided by core (and often implemented by infra) 2019-03-25 15:36:02 yea 2019-03-25 15:36:09 i think i get it now 2019-03-25 15:36:38 the only thing team admins take over is team membership for now 2019-03-25 15:36:45 power to decide who is in and who is out 2019-03-25 15:37:06 yes 2019-03-25 15:37:15 and what happens inside their team (alongside all the members) 2019-03-25 15:37:28 which is the most important thing 2019-03-25 15:37:34 ok. thanks 2019-03-25 15:37:39 imo it's just a natural side effect of letting teams manage themselves 2019-03-25 15:37:49 im formulating an email for the current core team 2019-03-25 15:37:53 aha 2019-03-25 15:38:07 having to ask someone outside the team to add a member to the team breaks the "soft decentralization" we're going for 2019-03-25 15:38:16 all of the official alpine resources remain in the core team 2019-03-25 15:38:44 ideally, I'd like to separate out maintainership of main/ out and leave core as purely administrative, but we need more members to do that first, just on my long-term "to suggest" list 2019-03-25 15:39:09 yes i think we need to do that 2019-03-25 15:39:20 but lets do this in babysteps 2019-03-25 15:39:31 yeah, as I said, in the long-term suggestion list 2019-03-25 15:40:20 i just want to make sure that i do this correctly, so nobody later complains and say we had no right to do this change 2019-03-25 15:40:36 I know :) 2019-03-25 15:42:04 <_ikke_> Do you expect to completely separate core from maintaining main/stable releases? 2019-03-25 15:43:02 maybe 2019-03-25 15:43:13 i think yes 2019-03-25 15:43:41 because, there are people who can contribute with maintaining main and stable, but does not need to be involved in the admin work 2019-03-25 15:43:43 would make sense 2019-03-25 15:43:57 or does not need to meet up and vote for stuff they dont care about 2019-03-25 15:45:56 <_ikke_> RIght, but a lot of core members will probably still remain involved with that I guess 2019-03-25 15:47:22 that's not a problem, you can be on multiple teams at once (for a plain example, see ncopa ;) ) 2019-03-25 15:47:36 but yeah, that's the idea 2019-03-25 15:48:45 so this doc completely replaces: https://lists.alpinelinux.org/alpine-devel/6024.html and https://lists.alpinelinux.org/alpine-devel/6025.html? 2019-03-25 15:49:14 yes 2019-03-25 15:49:32 (so if anything is missing in that regard, it should be brought up, but I think we did that last time) 2019-03-25 15:56:28 based on gitolite access, ikke shouldn't be in core - is that right? 2019-03-25 15:58:04 same for nangel 2019-03-25 16:00:22 further, do we know the email or name for tdtrask ckampka and rdutra 2019-03-25 16:00:28 (going over group by group) 2019-03-25 16:00:54 ehm, I vote for _ikke_ to be in core. ok, my vote doesn't count I know, but anyway :) 2019-03-25 16:01:04 :) 2019-03-25 16:01:06 well, I initially put him in core! 2019-03-25 16:01:14 but he's not on the gitolite list for that 2019-03-25 16:01:24 (and it seems quite awkward to me, as-is now ^^;;) 2019-03-25 16:01:29 because we didnt trust him with git push to main yet 2019-03-25 16:01:31 yes 2019-03-25 16:01:37 ah, ok 2019-03-25 16:01:38 its awkward as it is 2019-03-25 16:01:49 and we are in the process of cleaning this up :) 2019-03-25 16:01:55 indeed we are :) 2019-03-25 16:03:20 ok, so, for core: 1. nangel: keep or remove; 2. add tdtrask; 3. add ckampka; 4. add rdutra 2019-03-25 16:03:36 for 2-4: do we know their more common nicks, and emails and/or names? 2019-03-25 16:08:15 shoulndn't core members have full names? It looks strange to me that core members 'hides' behind nicks, although I know that is not something which can be judged easily 2019-03-25 16:08:42 this is kind of a transitional period 2019-03-25 16:08:48 full names = real names 2019-03-25 16:08:50 prior to now, no one expected to have to share their name when signing up 2019-03-25 16:09:06 + there ARE some legitimate edge cases in which one may not wish to share it 2019-03-25 16:09:16 but that would be why 2019-03-25 16:09:34 nangel = Nathan Angelacos 2019-03-25 16:09:40 tdtrask = Ted Trask 2019-03-25 16:09:49 let me check the spelling of the others 2019-03-25 16:10:08 yes, but nangel is not in the core listing in gitolite - he is in infra and acf 2019-03-25 16:10:17 but according to the infra team, he has no business being there 2019-03-25 16:10:23 Christian Kampka 2019-03-25 16:10:26 but right now I'm just going over core - do we keep nangel on there? 2019-03-25 16:10:47 let me check if he is in the mailing list 2019-03-25 16:10:56 i just sent a mail asking for vote 2019-03-25 16:12:47 keep nangel for now 2019-03-25 16:13:31 we need seprate admin and tech core teams 2019-03-25 16:14:01 both nangel and _ikke_ are effectively in "admin core" but not in "tech core" currently 2019-03-25 16:14:07 the technical vs non-technical user distinction is supposed to be team-internal 2019-03-25 16:14:20 so I guess the real issue is that we're using gitolite as a source of truth right now :) 2019-03-25 16:14:27 <_ikke_> I use _ikke_ here becuase that's what I used on irc before I joined alpine 2019-03-25 16:14:28 so ok, I'll only consider users that should be *added* 2019-03-25 16:14:37 gitolite tells who have git push access to what 2019-03-25 16:14:39 <_ikke_> But everywhere else I'm kdaudt 2019-03-25 16:14:42 yeah 2019-03-25 16:14:51 _ikke_: yes, I figured that out 2019-03-25 16:15:19 similarly, I figured out that rnalrd is larena 2019-03-25 16:15:41 so ok, we still have rdutra's name, and emails for all 3 members 2019-03-25 16:15:53 Roberto Oliveira 2019-03-25 16:16:25 <_ikke_> ncopa: Ted is btw not on the internal wiki 2019-03-25 16:16:34 yes, my current listing is from there 2019-03-25 16:16:47 so all 3 of those should be missing 2019-03-25 16:16:59 do we have emails for all 3 of those? 2019-03-25 16:17:06 yes i have them 2019-03-25 16:17:17 im searching for rdutras email currently 2019-03-25 16:17:22 he used to have an ibm email 2019-03-25 16:17:23 ok 2019-03-25 16:17:46 <_ikke_> It's in the internal wiki 2019-03-25 16:18:06 oh, he's marked as in packaging 2019-03-25 16:18:09 interesting 2019-03-25 16:18:26 i found this: Roberto Oliveira 2019-03-25 16:18:31 not sure thats the one he wants to use 2019-03-25 16:18:46 i gave himan alpine address i think 2019-03-25 16:18:50 that's the one I have 2019-03-25 16:18:51 oh, he may have alpine 2019-03-25 16:19:01 not so long ago 2019-03-25 16:19:06 i remember he asked for alpinelinux.org email address 2019-03-25 16:19:45 i added him as i just mentioned 2019-03-25 16:19:59 Christian Kampka 2019-03-25 16:20:25 tdtrask has only been doing acf i think 2019-03-25 16:20:54 i think i gave him git push access to he could push directly without asking me 2019-03-25 16:20:56 ok, so we can avoid adding him into core (even if he has push to main/) 2019-03-25 16:21:01 yes 2019-03-25 16:21:08 ok, so so far 2019-03-25 16:21:17 I added rdutra and ckampka into core 2019-03-25 16:21:36 SpaceToast: btw, if i see typos in current docs, should i mention it or just let you solve it later? 2019-03-25 16:21:53 <_ikke_> I don't think they are core 2019-03-25 16:22:13 clandmeter: if at all possible, send in patch (brpaste.xyz/raw/xxx) 2019-03-25 16:22:17 otherwise, you can mention it here 2019-03-25 16:22:26 np 2019-03-25 16:22:44 _ikke_: they're in @alpinedev, which has RW+ to aports, including main/ 2019-03-25 16:22:51 which is kind of the definition of core 2019-03-25 16:24:22 ncopa: rgdoliveira@alpinelinux.org 2019-03-25 16:24:47 ah, thanks 2019-03-25 16:24:49 better use that 2019-03-25 16:25:04 just did :) 2019-03-25 16:26:25 i think the list is kind of out dated. there are some ppl with an alpine address i havent seen contrib in years 2019-03-25 16:27:07 yeah, we're trying to clean all of that up - for instance it looks like there's not been a policy on inactive members so far 2019-03-25 16:29:03 exactly, we need one :) 2019-03-25 16:29:38 I'm proposing 4 months timeout for members (after which questions are asked, and depending on what happens they may be removed) 2019-03-25 16:30:06 for admins, perhaps 4 months, or 5 consecutive missed meetings and/or similar? 2019-03-25 16:32:16 is that period based on something? 2019-03-25 16:32:53 it's exactly double what gentoo uses 2019-03-25 16:33:06 (officially, unofficially it's closer to 120 days) 2019-03-25 16:33:21 we've not had a policy before, so being more lax initially seems like a good idea 2019-03-25 16:33:34 it can always be changed in the future 2019-03-25 16:44:20 sounds good to me 2019-03-25 16:53:01 +1 2019-03-25 16:56:49 ok, so for infra 2019-03-25 16:57:28 clandmeter: currently, I have you, _ikke_ and danieli on the infra team; gitolite suggests fcolista, nangel and rnalrd should be in there too 2019-03-25 16:57:35 can you clarify? :) 2019-03-25 16:57:47 its just the three of us 2019-03-25 16:57:52 ok 2019-03-25 16:58:25 maybe we should incoude kunku 2019-03-25 16:58:43 he was neither mentioned, nor in git 2019-03-25 16:58:47 nangel manages email iirc 2019-03-25 16:58:47 kunkku 2019-03-25 16:58:50 if you come up with a definitive answer, do tell me :) 2019-03-25 16:59:07 he is not really a member, but he does manage the vpn 2019-03-25 16:59:15 so i guess that makes him part of infra :) 2019-03-25 16:59:32 he is part of current core afaik 2019-03-25 16:59:46 yes, but the whole point is to separate things out, atm 2019-03-25 16:59:56 simply having everyone be on every team kind of defeats the purpose 2019-03-25 17:00:15 (which is going to be quite the mess when I get to packaging - do I just add everyone in core into that pile?) 2019-03-25 17:05:20 No just the ones that contribute I guess 2019-03-25 17:05:35 Contribute in code 2019-03-25 17:05:54 still quite messy :/ 2019-03-25 17:06:28 I think the issue is in the main/others distinction 2019-03-25 17:06:38 for example, we recently had a python package move from main/ to community/ 2019-03-25 17:06:43 the implications get kind of weird 2019-03-25 17:07:47 That's what good docs can help us with 2019-03-25 17:08:28 well the status quo is that everything is mixed 2019-03-25 17:08:32 documenting that doesn't really work 2019-03-25 17:08:49 (and again, doesn't help the issue we're trying to solve) 2019-03-25 17:09:52 the idea with "community" repo was to have a less strict repo, that we dont support for as long time as we do with main 2019-03-25 17:10:04 and at the same time make it easier to get more people help maintain it 2019-03-25 17:10:49 well the issue isn't really with the packaging team (or the community repo) 2019-03-25 17:10:55 but that the core team is main/ only 2019-03-25 17:11:06 and stable branches 2019-03-25 17:11:10 so we either have to add everyone that works on main/ *and* other stuff into packaging, 2019-03-25 17:11:26 or we have to say "core also can touch other packages" 2019-03-25 17:11:40 and neither of these solutions seems satisfactory, since we're creeping back into everything being mixed up 2019-03-25 17:12:06 everything is currently beeing mixed up 2019-03-25 17:12:19 yes, and we're trying to fix/improve that 2019-03-25 17:12:46 i think the simplest short time solution is to say that "core can also touch other packages" 2019-03-25 17:12:55 ok 2019-03-25 17:13:11 so we add that to the list of stuff to remove from core later :/ 2019-03-25 17:13:13 which means core is a subset of "packages" 2019-03-25 17:13:47 they sort of need to be connected 2019-03-25 17:14:10 I added `NOTE: The core team may also do everything the packaging team may do during the (currently unlimited) transitional period.` 2019-03-25 17:14:16 if you upgrade a lib in main, that breaks ABI, you need rebuild lots of stuff 2019-03-25 17:14:34 also in community and testing 2019-03-25 17:14:40 well, what would ideally happen is that packaging would be entirely separate and handle all the repos 2019-03-25 17:14:54 including main? 2019-03-25 17:14:57 and the "more loose" things be handled through PRs (which would be a major responsibility of that team) 2019-03-25 17:15:01 yes 2019-03-25 17:15:07 and stable branches would be releng 2019-03-25 17:15:17 but that may be unrealistic in the near future 2019-03-25 17:15:54 i think the packaging team needs to be splitted up 2019-03-25 17:16:13 separate team that deals with python for example 2019-03-25 17:16:30 subsets are allowed 2019-03-25 17:16:31 yeah 2019-03-25 17:16:46 we even had a section on that in the meeting 2019-03-25 17:16:56 which also means we could have a "stable" team 2019-03-25 17:17:01 e.g if two teams with overlapping scopes want to do a thing, the team that's more specific wins out 2019-03-25 17:17:10 but for now we decided not to do any of that due to lack of members 2019-03-25 17:17:22 I really think "stable" can be happened by releng, once we have that 2019-03-25 17:19:07 i think we currently have a huge "packaging" team, where "core" is a subset, a small "infra" team and tiny new teams like docs and security 2019-03-25 17:19:36 we operate on different definitions of huge :) but yes, packaging is quite big right now 2019-03-25 17:19:41 (relatively speaking) 2019-03-25 17:19:46 relatively huge 2019-03-25 17:19:48 yes 2019-03-25 17:20:14 but we also have huge amounts of PRs incoming 2019-03-25 17:20:28 and it's technically packaging and core's job to handle them (since core has to handle any PRs that have to do with main/) 2019-03-25 17:20:46 yes 2019-03-25 17:21:22 but yes, I think having language-specific teams is a good idea (one everyone agreed on, it's just the timing that was disputed) 2019-03-25 17:21:33 yes 2019-03-25 17:21:37 and I think the catch-all packaging team should be able to work with main/ as well, so they can handle PRs 2019-03-25 17:21:52 but baby steps is the approach we're taking, with the current problem being how to handle it now 2019-03-25 17:21:54 hopefully we have enough people to staff teams like security, documentation, releng 2019-03-25 17:22:28 imo we need to change just enough to get the system bootstrapped 2019-03-25 17:22:34 at which point we can go around and have people make new teams 2019-03-25 17:22:34 yup 2019-03-25 17:22:46 (e.g ddevault could get accepted into packaging, and then suggest the creation of the python team) 2019-03-25 17:23:05 it's just that the core: main/ and packaging: others separation is making bootstrapping harder 2019-03-25 17:23:33 i think packaging team may be a good "entrypoint" to join any other team (thinking long term) 2019-03-25 17:23:45 because its difficult to doc something you have no experience with 2019-03-25 17:24:29 and its probably no good idea to let a releng member decide how to make releases if he/she has no clue how the packaging works 2019-03-25 17:25:22 it may also be valuable for infra people to maintain packages they use themselves 2019-03-25 17:25:32 hmm, that's fair 2019-03-25 17:26:50 i think letting the core team be a subset of packaging team may be a good step forward 2019-03-25 17:27:20 makes it easier to do stuff like move from main to community and the other way around 2019-03-25 17:27:45 instead of having a handover from one team to another 2019-03-25 17:27:51 this means that we must allow for "nesting" 2019-03-25 17:28:01 which is basically an entirely new thing 2019-03-25 17:28:41 would it be easier to bootstrap this thing if we simply added all the core team members to "packaging"? 2019-03-25 17:29:58 that's the other solution I mentioned, yeah 2019-03-25 17:29:58 i think it still have value, because even if im both part of "main" and "community" group, i can let my focus be on "main" 2019-03-25 17:30:18 because i know there are plenty other that can help out with community and testing 2019-03-25 17:30:24 both of the solutions make me feel a bad taste in my mouth though 2019-03-25 17:30:29 because we're treating the symptoms 2019-03-25 17:30:29 :) 2019-03-25 17:30:47 so how would you like it to work? 2019-03-25 17:31:03 I would like packaging to be a catch-all for *all* packages (including main) 2019-03-25 17:31:21 releng (or core, since core is the catch-all for non-handled things) to handle stable branches (since that's not quite the same) 2019-03-25 17:31:36 then, we can have more specific subsets 2019-03-25 17:31:41 that will override packaging 2019-03-25 17:31:52 (this would apply to core, but also python in the future, for example) 2019-03-25 17:32:06 so we give everyone currently with access to community and testing repos also access to main? 2019-03-25 17:32:10 but not stable branches 2019-03-25 17:32:18 yes 2019-03-25 17:32:25 and then core keeps its "main/" bit 2019-03-25 17:32:34 so if there's a clash between packaging and core, core wins out, since it's more specifc 2019-03-25 17:33:04 anyone that wants to touch packages "in general" has to then join package 2019-03-25 17:33:21 while core can be focused on main (and similarly, python can be focused on python packages only) 2019-03-25 17:34:30 hmmm 2019-03-25 17:34:49 basically, more specific teams have to be pure subsets of the more generic ones 2019-03-25 17:35:14 the issue here seems to be that the generic team (packaging) does not fully encompass the team that handles main/ (whether that be core, or something else if it gets moved) 2019-03-25 17:36:26 I agree that all teams should be a subset of packaging 2019-03-25 17:36:33 all package-related teams* 2019-03-25 17:36:38 because packaging is an essential skill & good litmus test 2019-03-25 17:36:49 and yeah, I agree that packaging may be a good entry-point 2019-03-25 17:37:01 encompass? not english native speaking 2019-03-25 17:37:04 (not a necessary one) 2019-03-25 17:37:08 ncopa: envelop is a synonym 2019-03-25 17:37:17 don't agree with all package-related teams* 2019-03-25 17:37:23 I meant all teams 2019-03-25 17:37:32 let's say we get a marketing team 2019-03-25 17:37:42 or accounting team 2019-03-25 17:37:42 why should the marketing team go through packaging? 2019-03-25 17:37:47 yes, exactly 2019-03-25 17:37:48 how about all technical teams 2019-03-25 17:37:50 or lawyer team 2019-03-25 17:38:09 in any case we cannot have that as a hard limit 2019-03-25 17:38:14 similarly, you shouldn't need to maintain, say, testing/skim for a year to handle infrastructure 2019-03-25 17:38:17 also, a prevailing sentiment is that do the right thing always wins 2019-03-25 17:38:29 I'm not in favor of writing down all of the rules and running everything by the book 2019-03-25 17:38:45 you have it the other way around 2019-03-25 17:39:00 the book is there to make running things easier (e.g remove uncertainty) 2019-03-25 17:39:08 not to decide how to run things, necessarily 2019-03-25 17:39:18 obviously we should empower the legal team to do their job, even if the documented team structure doesn't allow for it 2019-03-25 17:39:37 yeah, I just don't think packaging needs to be the root of all 2019-03-25 17:39:46 and if we dont follow the written book, how and who decides when to follow it and when not to follow it? 2019-03-25 17:39:53 you 2019-03-25 17:39:58 guided by consensus 2019-03-25 17:40:04 and trust 2019-03-25 17:40:16 consensus takes a long time to get :) 2019-03-25 17:40:23 that's what trust is for 2019-03-25 17:40:28 basically, the book accelerates things by saying "X is ok" 2019-03-25 17:40:29 so we write that down too? and then we selectivly follow that too? 2019-03-25 17:40:31 :) 2019-03-25 17:40:36 so everything that falls into X is done faster 2019-03-25 17:40:44 put people in a position to make decisions, and trust them 2019-03-25 17:40:49 then let them make those decisions 2019-03-25 17:41:00 roughly, yes, that's the idea 2019-03-25 17:41:10 https://www.youtube.com/watch?v=jl0hMfqNQ-g 2019-03-25 17:41:19 the issue you get is that if the book is contradictory (e.g "so is Y ok?") - whenever that comes up, that slows things down (even with trust in place) 2019-03-25 17:41:29 so we want to maximize "X is ok", and minimize "so is Y ok?" 2019-03-25 17:41:39 gotcha 2019-03-25 17:41:41 further, we also want to allow people to be focused on their specific island 2019-03-25 17:41:48 e.g right now ncopa basically does "everything" 2019-03-25 17:41:55 which slows us down 2019-03-25 17:41:59 the reason for teams being the way they are is so you have a specific scope that you "work on" 2019-03-25 17:42:01 im the bottle neck 2019-03-25 17:42:06 and you don't have to worry about things outside that scope 2019-03-25 17:42:16 for example, in #alpine-devel, andypost asked ncopa to fix a builder 2019-03-25 17:42:18 I mean, fixing that problem is as easy as giving more people ncopa's powers (in whole or in part) 2019-03-25 17:42:21 that should be the infra team's job 2019-03-25 17:42:33 assuming you have people you can trust with those responsibilities 2019-03-25 17:42:34 ah, but then you have to communicate that to other members, and the outside world 2019-03-25 17:42:37 it needn't be formal 2019-03-25 17:42:47 and then you need to be able to scale that as the project gets bigger 2019-03-25 17:42:50 that could be as easy as updating the list of people on the wiki 2019-03-25 17:42:51 that's what the formality is there for 2019-03-25 17:43:02 many projects scale far further than where alpine is without formal process 2019-03-25 17:43:10 may be putting the horse before the lede here 2019-03-25 17:43:20 if you look at every large project out there... 2019-03-25 17:43:31 you may notice they have something significantly more formal than our proposal here :) 2019-03-25 17:43:39 we already had the meeting on this and figured these details out though 2019-03-25 17:43:48 so I'd rather get back on topic 2019-03-25 17:43:51 alright, I'll leave it in your capable hands 2019-03-25 17:44:00 ddevault: just trust me, eh? ;) 2019-03-25 17:44:20 but, most significantly - I agree that "doing the right thing" should have priority 2019-03-25 17:44:28 my goal here is to do the right thing, and make doing the right thing easier 2019-03-25 17:44:44 and I see the strange separation between core and packaging as a barrier to that 2019-03-25 17:44:54 SpaceToast: i want go back to the main vs community+testing problem and core vs packaging 2019-03-25 17:45:00 yes 2019-03-25 17:45:10 what you suggested will not work 2019-03-25 17:45:18 i will explain 2019-03-25 17:45:38 and i mean "releng" included 2019-03-25 17:46:17 if we separate out stable branches for releng team 2019-03-25 17:46:36 and give everyone in "packaging" access to "main" 2019-03-25 17:47:17 what will happen is that people will push stuff there without thinking of consequences because its someone elses job to deal with the consequences 2019-03-25 17:47:46 this is handled by the specificity clause, though 2019-03-25 17:47:52 let's swap this out for a moment 2019-03-25 17:48:02 forget about core, pretend we're talking about python 2019-03-25 17:48:11 packaging team has access to all packages, including python packages 2019-03-25 17:48:16 but they know the python team exists 2019-03-25 17:48:37 if the packaging team takes some python stuff and massively reworks them, that would be them doing the wrong thing, and they should be told off as a result, right? 2019-03-25 17:49:00 python team would be understandably upset, because while knowing that they python team exists, packaging (the generic team) messed something up without consulting them 2019-03-25 17:49:21 right 2019-03-25 17:49:26 similarly, because the packaging team knows the core team exists, they should be careful with touching anything in main/ without consulting core 2019-03-25 17:49:39 and if they do mess something up, the perpetrator should be told off - they failed to do some of the most basic groundwork 2019-03-25 17:50:04 however, it's entirely possible that someone in packaging (but not core) maintains a package in main/ - they should still be able to update it in the master branch 2019-03-25 17:50:34 so I don't think your concern is necessarily justified, we just need to be *very* clear that more specific teams override the more generic ones 2019-03-25 17:50:57 and that if you're touching something that's under the purview of a more specific team, you should at least try to ask them 2019-03-25 17:51:37 i am worried about people move stuff to main without understanding/caring about the consequenses 2019-03-25 17:51:38 (and let's be more technically specific - I think packaging team should have access to the master branch - the entirety of master; releng (or core) should have access to all branches, but should be expected to only cherry-pick from master) 2019-03-25 17:51:53 yes, but if they do that without asking/consulting, they are abusing their powers 2019-03-25 17:52:02 that would be a reason to potentially remove them, even, imo 2019-03-25 17:52:07 they just need to understand that 2019-03-25 17:52:20 (which, at that point, is a documentation problem, rather than an organizational one) 2019-03-25 17:52:29 i see your point 2019-03-25 17:52:42 we need to trust them enough 2019-03-25 17:52:45 to not mess up 2019-03-25 17:52:47 (I can even make that the specific example used; "for example, if a packaging member moves something into main/ without consulting core, that would be abuse of powers") 2019-03-25 17:52:57 yes, you *need* to trust members of teams 2019-03-25 17:53:05 if you do not trust a team member, they should not be a team member 2019-03-25 17:53:09 - you don't trust them 2019-03-25 17:53:15 that is the very foundation 2019-03-25 17:53:37 trust is a required component for decentralization 2019-03-25 17:53:44 (as ddevault was saying) 2019-03-25 17:54:06 i need to go soon and i will think about it ti ltomorrow 2019-03-25 17:54:07 the question is "how much trust"; in this case "if you mess up badly enough, we no longer trust you, bye" 2019-03-25 17:54:11 ok 2019-03-25 17:54:23 what i would like to see 2019-03-25 17:54:32 I'll add the above section (without touching listings for now) so you can see an example implementation 2019-03-25 17:54:36 is that if you take maintainership of a package, in main 2019-03-25 17:54:56 you also maintain it in stable branches 2019-03-25 17:55:07 so you make sure you get sec fixes in there 2019-03-25 17:55:09 ok, I'll think about that 2019-03-25 17:55:34 if you mess up, and push something to main that you later get problem with, you will also feel that pain 2019-03-25 17:55:40 so you learn to not do it again 2019-03-25 17:55:49 makes sense 2019-03-25 17:55:55 that way your problems aren't inherited by someone other than you 2019-03-25 17:56:09 exactly 2019-03-25 17:56:29 also, we need a big packaging team 2019-03-25 17:56:35 and we need expand it quick 2019-03-25 17:56:41 yes, since it's the generic encompassing one 2019-03-25 17:56:56 we can later siphon people out into more specific teams, but that'd take some time 2019-03-25 17:56:56 but trust is not a thing that can grow quick 2019-03-25 17:57:16 you cannot gain trust quick 2019-03-25 17:57:26 it takes time to trust someone 2019-03-25 17:57:30 and it needs to take time 2019-03-25 17:57:32 that's what "known contributor" stuff is for 2019-03-25 17:57:37 you start by sending patches 2019-03-25 17:57:41 once you have enough trust 2019-03-25 17:57:45 you are added to the team 2019-03-25 17:58:03 (if you want to be on, of course) 2019-03-25 17:58:10 you can't even try to join before contributing in some way 2019-03-25 17:58:20 so we made the difference with community and main, because we needed bigger trust to the people in main 2019-03-25 17:58:27 because it has 2 years consequence 2019-03-25 17:58:30 for maintenance 2019-03-25 17:58:47 and there have been lots of fly-by people 2019-03-25 17:58:56 come quick, contribute alot 2019-03-25 17:59:00 and then disapear 2019-03-25 17:59:14 yeah, that's kind of the idea of the contribution part 2019-03-25 17:59:18 you have to demonstrate staying power 2019-03-25 17:59:23 *before* you're allowed to join the team 2019-03-25 17:59:44 this does mean that it'll take some time to make the packaging team grow, but it'll be sustainable growth (+ known contributor stuff will help a lot) 2019-03-25 17:59:58 with the community repo, the consequence of a messup is only 6months 2019-03-25 18:00:03 we only maintain that for 6 months 2019-03-25 18:00:19 so its not that serious if someone messes up there 2019-03-25 18:00:34 which means we dont need as much trust, and the entry bar is lower 2019-03-25 18:00:47 meaning its easier to add more people there quicker 2019-03-25 18:01:29 I understand, but the reality is that it didn't quite end up working out that way 2019-03-25 18:01:42 i need to go now 2019-03-25 18:01:45 \o 2019-03-25 18:01:51 and i wil think of what you said 2019-03-25 18:02:07 hopefully it is enough to tell people to no touch "main" 2019-03-25 18:02:12 most people are responsible 2019-03-25 18:02:26 not to touch "anything handled by a more specific team without at least asking that team"* :) 2019-03-25 18:02:37 and if you do do it, that's abuse of power and you *could* be reprimanded or even removed 2019-03-25 18:03:13 but im also afraid of not touching anything without asking first 2019-03-25 18:03:18 because that would also slow us down 2019-03-25 18:03:26 anything *that is handled by a more specific team* 2019-03-25 18:03:35 so, a generic packager touching python things, for example 2019-03-25 18:03:41 or a generic packager touching main/ 2019-03-25 18:03:51 if it's in community/ (for example), and not handled by any more specific team, go ahead! 2019-03-25 18:03:55 that's *your* region 2019-03-25 18:03:55 for example, if id need to ask the listed maintainer for every update or every change i do, things would be dog slow 2019-03-25 18:04:25 maintainers are not necessarily team members, and team members are intended to work together, so that's not how that should play out 2019-03-25 18:04:34 ok gotta go now. see you tomorrow 2019-03-25 19:08:04 kunkku: hi 2019-03-25 19:08:18 We were talking about teams 2019-03-25 19:08:46 I wondered if you are part of infra 2019-03-25 19:11:02 If you considered yourself as part even. :) 2019-03-25 19:26:03 at least I hang on the IRC channel :) 2019-03-25 19:42:37 :) 2019-03-25 19:43:07 SpaceToast: is that enough? :) 2019-03-25 19:43:30 ¯\_(ツ)_/¯ 2019-03-25 19:43:36 I'll add you in just in case :) 2019-03-25 19:47:38 <_ikke_> clandmeter: re stale message, apparently ncopa prefers just a single message that the bot posts 2019-03-25 19:53:45 _ikke_: i dont understand what you mean? 2019-03-25 19:54:25 <_ikke_> https://github.com/alpinelinux/aports/pull/6831#issuecomment-476167583 2019-03-25 19:55:02 that doesnt make sense :) 2019-03-25 19:55:33 it was his idea to have it in a seperate file 2019-03-25 20:09:55 _ikke_: if you can shorten it and make it more friendly please do. 2019-03-25 20:10:15 <_ikke_> trying to 2019-03-26 06:37:49 this new governance document is highly flawed 2019-03-26 06:38:36 amongst other things, it: 2019-03-26 06:38:54 - entrusts too much power to team administrators (team members must be able to vote) 2019-03-26 06:43:34 - enables teams to do whatever they want instead of forcing all teams to play by the same democratic rules 2019-03-26 06:43:57 - fails to define how the project as a whole may override a decision made by a team or by core 2019-03-26 06:44:28 - fails to protect project members from unfair mob-based expulsion 2019-03-26 06:52:04 - fails to define how to even update the policy document in the future 2019-03-26 06:52:12 - fails to define how votes are taken 2019-03-26 06:52:27 - fails to define how to raise an issue for a team or entire project to vote on 2019-03-26 06:52:41 and so i am forced to not support it 2019-03-26 06:55:33 additionally, i believe that having core decide on whether or not the document is ratified is inappropriate and not concordant with interim policy 2019-03-26 09:15:37 morning 2019-03-26 09:17:25 <_ikke_> morning 2019-03-26 10:20:33 oh, kaniini leave :( 2019-03-26 14:26:39 morning! isn't it fun when you're woken up by your boss calling you during vacation time? 2019-03-26 14:27:00 <_ikke_> love it 2019-03-26 14:28:38 looking at the criticisms above... won't be pinging (as I'm aware they wish to leave), but the discussion is obviously open for everyone 2019-03-26 14:28:58 "entrusts too much power to team administrators (team members must be able to vote)" + "fails to protect project members from unfair mob-based expulsion" -> these two seem contradictory to me 2019-03-26 14:29:47 i think kaniini's worries are valid 2019-03-26 14:30:01 the whole idea of having team admins is that being allowed to vote (control the direction of the project) requires more trust (from everyone involved, thus the other team admins) than being able to push 2019-03-26 14:30:16 if we decide that all members may vote, there is straight up no reason to have team admins 2019-03-26 14:30:26 but then we're instantly vulnerable to mob-based expulsion 2019-03-26 14:30:52 it seems like the first part complains about the solution to the second, and that seems .. strange 2019-03-26 14:31:28 "enables teams to do whatever they want instead of forcing all teams to play by the same democratic rules" - the goal is to get the project from various points As to point Bs; voting on absolutely everything, for example, will be even slower than the status quo 2019-03-26 14:31:35 ultimately, there needs to be some breaking point 2019-03-26 14:32:05 "teams may internally organize themselves" seems like a pretty natural one - if someone doesn't like how the team is functioning, they can leave it, or ask an admin of a different team to open a discussion 2019-03-26 14:32:23 (this is called "communicating with others", and it looks like it'll be mentioned a few more times) 2019-03-26 14:32:45 "fails to define how to even update the policy document in the future" + "fails to define how votes are taken" - is it the document's job to define common terms? 2019-03-26 14:32:47 I mean we can do it 2019-03-26 14:32:56 I just don't really see a specific reason *to* do it 2019-03-26 14:33:12 do we have a major problem where people don't know what a vote is? 2019-03-26 14:33:28 does the old document (the one we're trying to rework now) have a clause on how to modify it? 2019-03-26 14:33:49 then again, that last part isn't there, and that may be the source of "i believe that having core decide on whether or not the document is ratified is inappropriate and not concordant with interim policy" 2019-03-26 14:34:20 so perhaps writing in how to update it (majority vote of admins + a meeting discussing direction perhaps?) may be needed 2019-03-26 14:34:39 finally, "fails to define how to raise an issue for a team or entire project to vote on" - please refer back to "communicating with others" 2019-03-26 14:35:14 oh, looks like I missed "fails to define how the project as a whole may override a decision made by a team or by core" 2019-03-26 14:35:24 this one is a bit confusing to me 2019-03-26 14:35:33 the project *IS* the sum of its members, and thus the sum of its teams 2019-03-26 14:36:04 why should the dlang and lua teams get to override the decision of the python team regarding a python package if they team up, for example? 2019-03-26 14:36:33 "by core" is more appropriate; but I think it's rooted in the fact that core right now is in a weird state, that we want to get it out of 2019-03-26 14:36:43 where it's kind of "catch-all" for all the things that were missed 2019-03-26 14:36:53 to give an example 2019-03-26 14:37:25 sometimes we need parallel version of a package 2019-03-26 14:37:41 eg lua5.2 + lua5.3 and python2 + python3 2019-03-26 14:38:04 may be for a transit period or maybe needs to be permanent 2019-03-26 14:38:29 what happens with "lua" package and "python" package? 2019-03-26 14:38:56 well, as-is, the lua or the python team decides; and if they don't exist, the packaging team does 2019-03-26 14:39:10 if a given team has a specific opinion, they can talk to the teams in question and suggest it 2019-03-26 14:39:24 should `apk add lua` be current old stable or should it be latest version 2019-03-26 14:39:35 I'd imagine it depends on a case-by-case basis 2019-03-26 14:40:12 arch linux has traditionally let the "unversioned" package be the last version 2019-03-26 14:40:24 <_ikke_> which imho makes sense 2019-03-26 14:40:28 personally, I generally agree with that approach 2019-03-26 14:40:32 while fedora has tended to do the opposite 2019-03-26 14:40:47 however, I also personally don't care much about releases besides latest and edge 2019-03-26 14:41:03 still, I don't see how "the project as a whole" would come out and make decisions on this 2019-03-26 14:41:34 well the thing is that it may make sense to handle those cases in a similar way 2019-03-26 14:41:52 ok, so packaging can propose to have a policy in the documentation 2019-03-26 14:41:53 <_ikke_> You do want some kind of consistency 2019-03-26 14:41:57 so there is some consistency over the alpine project 2019-03-26 14:42:07 this isn't "overriding", this is proposing rules; imo very different things 2019-03-26 14:42:11 so if there are some group that has strong opinion one way 2019-03-26 14:42:19 and other group strong opinion other way 2019-03-26 14:42:28 the whoe thing may end up in a big mess 2019-03-26 14:42:38 but yes, anyone can come in, ask that we have a new policy (a *general* policy) we then have a meeting (and/or vote) regarding it 2019-03-26 14:42:45 and the policy gets added to docs and implemented 2019-03-26 14:43:00 I really don't see this as "overriding" anything, rather normal procedure 2019-03-26 14:43:08 (and has nothing to do with teams :) ) 2019-03-26 14:44:20 so someone has power to come up with a policy for the project as a whole, that overrides whatever a team may come up with 2019-03-26 14:44:27 same with tabs vs spaces in APKBUILDs 2019-03-26 14:44:46 well, same story with team admins and voting, I would imagine 2019-03-26 14:45:00 lets say python team prefers spaces and lua team prefers tabs 2019-03-26 14:45:24 the project is the sum of its members, various admins are members trusted with the ability to vote, thus admins effectively represent their teams within the larger project scope 2019-03-26 14:45:30 so someone needs the power to say: "we will use tabs. end of discussion" (or spaces) 2019-03-26 14:45:41 so in choosing project policy, I'm guessing that can be voted on 2019-03-26 14:45:50 in the case of tabs vs spaces, this is an *existing* policy 2019-03-26 14:45:59 that I should add to the docs at some point 2019-03-26 14:46:24 those were simple examples 2019-03-26 14:46:49 but what if it is more sensitive matters, such as, how do expel a team member 2019-03-26 14:47:12 if the entire project needs to do it... 2019-03-26 14:47:24 pretty sure removal of members is covered, though 2019-03-26 14:49:29 "fails to define how the project as a whole may override a decision made by a team or by core" 2019-03-26 14:50:05 so if python team decides that we should use spaces in stead of tabs in all APKBUILD which includes python stuff 2019-03-26 14:50:19 they are wrong, because that goes against the project's policies 2019-03-26 14:50:23 how can the "project as a whole" override that 2019-03-26 14:50:48 you're imagining a scenario where people stubbornly ignore rules and abuse their power 2019-03-26 14:50:54 you remind them that there IS already a policy 2019-03-26 14:51:33 if someone won't follow a policy, that's like someone breaking the law (aka breaking social contract) 2019-03-26 14:52:00 so in such an extreme and unlikely case, you could, for example, remove their push access until they calm down 2019-03-26 14:52:05 i think that is what need to write down. exactly how do we protect our selves against someone who ignore rules and abuse power 2019-03-26 14:52:28 anyone that abuses power is subject for removal, as per the ways to remove members 2019-03-26 14:52:34 yes, its the extreme cases i think we should cover 2019-03-26 14:52:39 if all the members are doing it, you go through all the admins, at which point the team is dissolved 2019-03-26 14:52:55 like an "emergency" plan 2019-03-26 14:53:05 if the unthinkable actually happens 2019-03-26 14:53:09 which we hope it does not 2019-03-26 14:53:12 well, what would you like included above what there already is? 2019-03-26 14:53:20 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/#_removing_an_administrator - current contents 2019-03-26 14:56:07 just, going by what there is now, it'd seem repetitive, imo "only remove admins in case of emergency [...] in case of emergency, remove admins" 2019-03-26 14:57:42 another comment i got was that there are no reference to the code of conduct 2019-03-26 14:59:30 i will think about what i'd like to include and i will try come up with some more specific suggestions how to deal with the cornercases 2019-03-26 15:00:28 ok, I'll add "acting in accordance with the Code of Conduct" into the "what's expected part 2019-03-26 15:07:34 I had a hope that will not hear words 'code of conduct' in Alpine. sorry couldn't resist to write my opinion about this 2019-03-26 15:08:36 <_ikke_> mps: It had already come up 2019-03-26 15:08:38 <_ikke_> last year or so 2019-03-26 15:09:37 eh, so I was happy till now because my ignorance about it :) 2019-03-26 15:09:47 i have long hoped a CoC would not be necessary, that it should be common sense how to behave and treat others 2019-03-26 15:10:34 yeah, I'm strong believer in common sense 2019-03-26 15:10:49 but experience has shown that its needed 2019-03-26 15:12:05 I suspect that CoC will solve the problem, if common sense cannot 2019-03-26 15:13:00 SpaceToast: just so you know, the core devs were all positive on your proposal, with the exception of kaniini 2019-03-26 15:13:07 I think most of us have 'CoC' ingrained in us without strictly written ones 2019-03-26 15:13:32 ncopa: ok, so we just have the above (actually actionable) issues to iron out, and we should be mostly good then :) 2019-03-26 15:13:50 mps: the written CoC is for those who hasn't 2019-03-26 15:14:00 I like that way of looking at it 2019-03-26 15:14:22 I certainly found it a bit strange, but enforcement seems to be going in that direction, which means no side-effects 2019-03-26 15:18:07 personally, I think Alpine have to have 'benevolent dictator' and some number of lieutenants 2019-03-26 15:18:59 that's the status quo, mps, more or less 2019-03-26 15:19:09 and as you can tell, it doesn't work out very well 2019-03-26 15:19:30 <_ikke_> I don't think there are leadership issue per se 2019-03-26 15:19:53 it's mostly workflow-related problems, but that style of governance makes it hard to not have the workflow be as it is 2019-03-26 15:19:55 imo 2019-03-26 15:20:00 it is obvious that changes are needed, but maybe evolutionary changes and not revolutionary 2019-03-26 15:20:05 <_ikke_> It's more like people need to be empowered to continue without having to rely on ncopa 2019-03-26 15:20:22 <_ikke_> So more a matter of delegation 2019-03-26 15:20:50 _ikke_: yeah, something like that 2019-03-26 15:21:06 it is about to define some sort of organization structure 2019-03-26 15:21:12 so i dont become bottleneck 2019-03-26 15:21:16 which i am 2019-03-26 15:21:22 <_ikke_> Yes, but that's a means to a goal, not a goal itself 2019-03-26 15:21:41 good point 2019-03-26 15:22:27 successful project need a strong leader and leader should have power to decide in conflicts and to delegate power to other 2019-03-26 15:23:44 with soft leader project leads to 'well' chaotic end 2019-03-26 15:24:35 alpine project is currently going towards a chaotic end :) 2019-03-26 15:24:57 and teams by it's nature are in some kind of contention most of time 2019-03-26 15:25:05 <_ikke_> Hence trying to define teams, in order to be able to delegate work and decissions 2019-03-26 15:26:01 i need to attend a meeting now 2019-03-26 15:26:21 and then i will have to update libssh2 in all stable branches 2019-03-26 15:26:29 i think the recent secfix broke things 2019-03-26 15:26:37 ncopa: I see current crisis as a chance to find solution solution which will be good for Alpine and not to use 'ready-made' solution 2019-03-26 15:27:18 bbl 2019-03-26 15:27:28 I find your suggestion that my proposal, that's been talked over, with multiple parties contributing, and has greatly evolved as a result is a "cookie cutter" policy to be quite insulting. 2019-03-26 15:28:02 SpaceToast: sorry 2019-03-26 15:28:04 <_ikke_> I suspect mps's reaction was regarding CoC, but they can clarify 2019-03-26 15:28:06 not you ncopa 2019-03-26 15:28:24 SpaceToast: sorry if you understand it this way, it is not my intention 2019-03-26 15:28:46 you suggested finding a solution that will be good for alpine, as opposed to something "ready-made" 2019-03-26 15:29:06 this solution has been talked over and modified extensively to fit alpine better, based on the desired of people within alpine 2019-03-26 15:29:26 I'd say that qualifies as "good for alpine", given said process; and does not qualify as "ready-made", eh? ;) 2019-03-26 15:29:32 by 'ready-made' I didn't have your work in mind, sorry again if it sounds like that 2019-03-26 15:29:36 ok 2019-03-26 15:29:58 if you mean the CoC, it may make sense to rewrite it, but I believe that can be done at a later point 2019-03-26 15:30:06 right now we're already trying to get one big thing through :) 2019-03-26 15:30:16 I see that you worked hard to find something which you think will work 2019-03-26 15:31:43 my observation are more 'a general' from experience which I have with some other projects 2019-03-26 15:33:30 ok, now I can see that you are definitely talking about the CoC 2019-03-26 15:33:33 at the end, I don't mind, whatever happens if it works I will be happy and I wouldn't like that my opinion deteriorate you all in any way 2019-03-26 15:33:54 for reference, here's our current one: https://alpinelinux.org/community/code-of-conduct.html 2019-03-26 15:34:44 I also wrote my own, some time ago (as an amusing response to the thing you're referring to, I think), here: https://github.com/5paceToast/CoC 2019-03-26 15:34:55 I read it earlier, but forgot about it, now I see it again 2019-03-26 15:36:27 CoC as it is now is not bad, only I have fear to not go to some kind of 'political correctness' rules 2019-03-26 15:37:25 my notes are more of the autonomy of teams, because that I mentioned 'benevolent dictator' 2019-03-26 15:39:25 ok, I will cease now from this discussion, whatever you decide I'm fine with it till Alpine is good for me. And I'm ready to help where I can 2019-03-26 16:32:40 SpaceToast: I don't know if this helps, but I do appreciate your effort in this topic. 2019-03-26 17:04:07 is there a wiki page or email thread somewhere which documents the proposed new governance model and/or summarizes the discussion so far? 2019-03-26 17:05:34 there's the meeting notes you were linked before, the developer docs page (current status), the git log for it, and logs of this channel (most of the conversations here were about that for the last week or two) 2019-03-26 17:05:52 thanks 2019-03-26 17:06:14 do you think it might be useful at some point to regroup on the ML? 2019-03-26 17:06:35 IRC isn't a great medium for non-real-time communication 2019-03-26 17:07:10 the issue is the sheer volume of things being discussed, the approach so far has been to occasionally post summaries of updates to the ML 2019-03-26 17:07:14 but I've not really kept up with that 2019-03-26 17:07:20 (I think _ikke_ and ncopa were doing that) 2019-03-26 17:07:21 I only mention it because I saw earlier you were welcoming anyone's thoughts, and I might have some, but the investment in getting caught up is steep 2019-03-26 17:07:39 you're telling me? ;) 2019-03-26 17:07:50 ? 2019-03-26 17:09:15 trying to get this done has taken quite a bit of my time and non-insignificant amounts of effort ^^;; 2019-03-26 17:09:19 investment is indeed quite steep 2019-03-26 17:09:24 ah, yes 2019-03-26 17:09:34 it's the right thing to do :tm: though, which is why I've been wading through 2019-03-26 17:10:42 <_ikke_> SpaceToast: thank you for that effort 2019-03-26 17:11:01 no worries, if I didn't feel like it was worth it, I wouldn't be doing it, now would I? :) 2019-03-26 17:11:20 <_ikke_> Doesn't mean we can't thank you for it :) 2019-03-26 17:11:23 aye, thanks for your hard work, and everyone else's as well 2019-03-26 17:12:53 what were some of the catalysts that kicked off this effort? 2019-03-26 17:13:01 I showed up. 2019-03-26 17:13:04 in other words, what are some specific problems that the new model ought to solve? 2019-03-26 17:13:07 ah 2019-03-26 17:13:16 there are a few issues right now 2019-03-26 17:13:26 the first is that most of everything has to go through a very few people 2019-03-26 17:13:39 ncopa in particular, but also clandmeter (e.g re: infra stuff) 2019-03-26 17:13:54 as a result, they do "a bit of everything" (inefficient), and getting things done can take forever 2019-03-26 17:14:01 and, of course, it means they're horribly overworke 2019-03-26 17:14:28 (one example symptom is the "patches come to alpine to die a slow death" thing) 2019-03-26 17:14:41 the solution is to compartmentalize efforts - if you're doing X Team stuff, you don't worry about any other details 2019-03-26 17:14:53 (less context switching = more effective; having more people you could ask = less bottlenecking) 2019-03-26 17:15:21 the project is also slowly starting to grow, so it's important to have some sort of process to get people into positions where they can get things done without asking *anyone*, once they're sufficiently trusted 2019-03-26 17:15:42 finally, other projects are reaching out to us and want to work with us, but this is hard to organize since (to the outside), we look like a chaotic mess, with no clear contact points 2019-03-26 17:15:56 (that last one is best seen in the email chain that kicked this off, something regarding a joint-distro security effort) 2019-03-26 17:18:45 would you agree with this summary of the problems? https://paste.sr.ht/~sircmpwn/089d949942ba5af35dda80af7b0cc35e15f8112d 2019-03-26 17:19:28 I'd add a point 4 regarding context switching being prevalent due to lack of focus 2019-03-26 17:19:37 a lot of people severely underestimate how severe that can get 2019-03-26 17:19:48 (and, well, in the current case, it's quite extreme) 2019-03-26 17:20:06 that seems like a result of problem 1 2019-03-26 17:20:12 that is, 2019-03-26 17:20:26 not quite, if you simply increase the amount of people that make (*) decisions, that problem will remain 2019-03-26 17:20:28 overworked contributors are forced into context-switching and have no time to specialize because they have too many tasks 2019-03-26 17:20:39 hm, I see what you mean 2019-03-26 17:20:42 It's definitely related, but separate 2019-03-26 17:20:55 otherwise yes, seems accurate 2019-03-26 17:21:30 https://paste.sr.ht/~sircmpwn/077de606d0215e300078ba2584c878c69c0176a0 2019-03-26 17:21:45 yes, that seems complete to me 2019-03-26 17:22:06 is there a writeup of the proposed solution that we can compare to these goals? 2019-03-26 17:22:08 the way of fixing that ends up being simple: tiered trust gauge (contributor -> known contributor -> real developer -> voting rights), compartmentalization of tasks based on groups, groups are independent (decentralization) to avoid bottlenecking usually associated with hierarchical structures 2019-03-26 17:22:22 here is the current state of the proposal: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/ 2019-03-26 17:22:24 as it stood this morning, at least 2019-03-26 17:22:47 the overall story is, once everyone is happy with the document, it gets one more touchup and becomes the new status quo, from what I can tell 2019-03-26 17:22:56 thanks 2019-03-26 17:23:00 I'll read over this 2019-03-26 17:23:18 no worries, and thanks for any feedback :) 2019-03-26 17:32:39 let's number k_niini's points in the order they were presented 2019-03-26 17:33:40 regarding #2, I think that this can be addressed (perhaps in parallel with 6), by establishing some conventinos for documenting team-specific policies 2019-03-26 17:33:46 conventions, rather 2019-03-26 17:33:57 <_ikke_> I like conventino's better :P 2019-03-26 17:34:18 such policies would be the home of matters such as spaces versus tabs in aports, which would be the domain of the core team 2019-03-26 17:34:32 each packaging team, e.g. python, inherits all of the policies of core, since they operate within aports 2019-03-26 17:34:48 we ideally want to strip core of various functions over time 2019-03-26 17:35:02 s/core/packaging/ 2019-03-26 17:35:03 I think things like "spaces versus tabs in aports" should be a projectwide policy thing 2019-03-26 17:35:16 (aka documented in non-team-specific documentation sections) 2019-03-26 17:35:38 as was discussed earlier :) 2019-03-26 17:35:49 aye, I read through the IRC logs for today at least 2019-03-26 17:35:52 just offering a different take 2019-03-26 17:35:54 <_ikke_> In the end, what would be the responsibility of the core team? 2019-03-26 17:36:11 <_ikke_> If you strip too much, there is nothing left :) 2019-03-26 17:36:15 ideally, the core team should be purely administrative 2019-03-26 17:36:23 I think there ought to be a (small) team to which all unknowns fall 2019-03-26 17:36:29 that too, yes 2019-03-26 17:36:30 to resolve disputes between other teams 2019-03-26 17:36:33 kind of how everyone respects ncopa's opinion because of the history he has with the project 2019-03-26 17:36:36 or clarify things in no man's land 2019-03-26 17:36:44 that would become the core team's domain, effectively 2019-03-26 17:36:49 (again - minimizing bottlenecks) 2019-03-26 17:36:54 but that's quite a ways off 2019-03-26 17:37:01 <_ikke_> I think core should also decide the general direction of alpine? 2019-03-26 17:37:11 imo that should be the collection of team admins 2019-03-26 17:37:17 another function of this team should be to address k_niini's point #1 2019-03-26 17:37:32 a team member who has a disagreement with their team's admin should appeal to the core team for an administrative decision 2019-03-26 17:37:34 e.g why should core decide what direction we should go legally, if we have a legal team? 2019-03-26 17:37:37 and trust the core team to exercise their best judgement 2019-03-26 17:37:58 sounds good to me, under what I have now you'd appeal to any team admin (not just core) and have them discuss that 2019-03-26 17:38:08 <_ikke_> SpaceToast: because the would also be most 'liable' for the results? 2019-03-26 17:38:27 but this is not a strict rule, but rather an inference from the base role of the core team 2019-03-26 17:38:29 is that really the case? 2019-03-26 17:38:36 <_ikke_> SpaceToast: not sure 2019-03-26 17:38:55 basically, the core team is responsible for everything, but trusts other teams with some subset of its responsibilities 2019-03-26 17:38:59 ddevault: the idea is that "team admin" is the highest level of trust attainable (and the list of current admins decide to allow/disallow others in those ranks) 2019-03-26 17:39:11 in the event that the team loses that trust, it's up to the core team to settle it 2019-03-26 17:39:17 you're describing the status quo, but I think we want to be more decentralized 2019-03-26 17:39:45 the project is, ultimately, the sum of its members, and I think project direction *should* be decided by the list of the most trusted members 2019-03-26 17:39:51 I think there's a risk of replacing trust with bueracracy in that appraoch 2019-03-26 17:39:56 approach, damn 2019-03-26 17:40:08 <_ikke_> To my feeling that should be done gradually though, not in one instance 2019-03-26 17:40:14 I also want to avoid design by committee 2019-03-26 17:40:22 yes, right now core continuing to handle the project direction is fine 2019-03-26 17:40:24 I trust individuals more than I trust groups of individuals 2019-03-26 17:40:56 I agree with that, but imo the listing in core and the listing of all team admins should be of similar size 2019-03-26 17:41:04 (at least based on current core size) 2019-03-26 17:41:21 it might grow as the project grows, but if the project grows that much we'll badly need all parts of the project to be accounted for in decisions 2019-03-26 17:41:31 -> having every "component" of the project be represented becomes important 2019-03-26 17:43:41 also, "the core team is responsible for everything" - that's kind of a large chunk of what we're trying to avoid, isn't it? :) 2019-03-26 17:45:09 well, I don't think that having that goal and fixing these problems are mutually exclusive 2019-03-26 17:45:22 I think about it as formalized delegation 2019-03-26 17:45:58 well, that's the case for overlapping teams (e.g packaging -> python) 2019-03-26 17:46:10 I just don't think our venn diagram needs anything that encompasses everything 2019-03-26 17:46:33 core can be a catch-all, but imo that should be the exception ("oh, we have nothing here"), rather than the rule (in that case) 2019-03-26 17:46:50 something I'm worried about is rules hacking 2019-03-26 17:47:11 if we don't establish an ultimate authority composed of a small number of very trusted people 2019-03-26 17:47:15 I worry that the system can be taken advantage of 2019-03-26 17:47:22 that's the idea of team admins, though 2019-03-26 17:47:29 well, two things 2019-03-26 17:47:32 you can ONLY become an admin if ALL other admins agree to take you in 2019-03-26 17:47:36 (well, a 2/3 majority) 2019-03-26 17:47:43 and abuse of admin powers -> removal 2019-03-26 17:47:45 consider the python team 2019-03-26 17:47:56 <_ikke_> How do we prevent having to compromise in everything to reach consensus? 2019-03-26 17:47:57 and admins need to represent their team, which is why you must have 1+ 2019-03-26 17:48:08 I see no reason why "needs a person with the level of responsibility and trust given to an admin" ought to be a blocker for establishing a python team 2019-03-26 17:48:09 <_ikke_> (I guess what ddevault refers to as design by comittee) 2019-03-26 17:48:28 because the python team must be represented within the project 2019-03-26 17:48:41 no, the python team must be represented within the packaging team 2019-03-26 17:48:53 in that case, you can join the packaging team and make an unofficial team 2019-03-26 17:49:00 so no #alpine-python, no python-specific ML 2019-03-26 17:49:10 why deny those resources to groups that need them? 2019-03-26 17:49:19 they're not denied, just get an admin :) 2019-03-26 17:49:20 it seems pretty arbitrary 2019-03-26 17:49:27 but the bar for getting an admin is very high 2019-03-26 17:49:42 the bar for getting admin is trust 2019-03-26 17:49:43 <_ikke_> But you also don't want to splinter everything 2019-03-26 17:49:47 it's important to quickly empower motivated people with the ability to get things done 2019-03-26 17:49:49 whether that's high or not depends, imo 2019-03-26 17:50:00 yes, you can start getting things done by just being part of the "parent" tam 2019-03-26 17:50:02 (e.g packaging) 2019-03-26 17:50:05 trivial things like an IRC channel or a mailing list, which are just a few bytes in a server's RAM somewhere, should be easily obtainable 2019-03-26 17:50:17 <_ikke_> It's not about resources 2019-03-26 17:50:30 <_ikke_> It's also about preventing creating islands 2019-03-26 17:50:33 if there's an official #alpine-python channel, that means that that channel officially represents the project 2019-03-26 17:50:49 and thus *has* to be represented within the project, and the project *must* have communication channels inside 2019-03-26 17:50:50 that's contrary to the decentralized goal 2019-03-26 17:50:52 yes, what _ikke_ said 2019-03-26 17:51:09 not quite, it's an enforcement of federated style decentralization 2019-03-26 17:51:22 consider activitypub, without the ability to block out other instances 2019-03-26 17:51:28 that's roughly the goal/idea 2019-03-26 17:51:42 I can stand up a new activitypub instance and start federating with people without any of their input 2019-03-26 17:51:44 you may be handling your own affairs, but you're still *part of alpine* 2019-03-26 17:52:41 to start up a new activitypub instance, you have to get an instance first, perhaps the comparison isn't perfect, but that process would involve having an official team 2019-03-26 17:52:53 (because if it's official, it represents alpine, and should be represented within alpine) 2019-03-26 17:52:59 consider this: I could gather some motivated people, join ##alpine-python, and we could work on improving the state of python in alpine, all autonomously, right now (hypothetically) 2019-03-26 17:53:06 yes 2019-03-26 17:53:12 we could prepare patches to aports and shoot them off to the ML 2019-03-26 17:53:16 yup 2019-03-26 17:53:24 but that will not make you an official part of alpine 2019-03-26 17:53:26 and they'd still be bound by the policies of aports (e.g. tabs) 2019-03-26 17:53:35 nope, you could break them 2019-03-26 17:53:41 that'd just mean that your patches won't be accepted 2019-03-26 17:53:44 but this would be an effective and quick way to improve python support in alpine 2019-03-26 17:54:01 yes, such "task" oriented teams work well in the short term 2019-03-26 17:54:06 in the long term, the patch process becomes burdensome 2019-03-26 17:54:14 but if you want collective access, you have to be part of the project 2019-03-26 17:54:18 <_ikke_> But they could still communicate via #alpine-devel so that everyone can follow what is happening 2019-03-26 17:54:19 and if you're part of the project [...] 2019-03-26 17:54:27 <_ikke_> Unless the traffic is very high and distracting 2019-03-26 17:54:37 ACTION thinks of alpine-mips-patches 2019-03-26 17:54:39 <_ikke_> That's exactly what some of us have done 2019-03-26 17:55:01 <_ikke_> ncopa could chime in with some suggestions / things to think about 2019-03-26 17:55:06 yeah 2019-03-26 17:55:07 I think I see how this could fit into the proposed model 2019-03-26 17:55:17 I'll just pay attention and whine if it's going in a direction which won't support that 2019-03-26 17:55:31 ddevault: basically, your "unofficial team" would be under the (undocumented) "known contributor" thing 2019-03-26 17:55:43 undocumented because it'd just describe human psychology, which is out of scope 2019-03-26 17:55:45 <_ikke_> The only thing I would argue about is not automatic / per definition seperation of communication channels per team 2019-03-26 17:55:50 <_ikke_> s/not/no 2019-03-26 17:55:59 _ikke_: yeah, you don't have to get them, you can request them :) 2019-03-26 17:56:16 though, if there was a clear need for a mailng list to organize the work (or any other resources, like builder time, which can be justified for that purpose) 2019-03-26 17:56:17 the idea is that if you're a known, regular contributor, it's meant to be a lot easier to join (any) official team 2019-03-26 17:56:39 I don't think beuracracy (how the fuck do you spell that word) should stand in the way of giving people the resources they need to be productive 2019-03-26 17:56:44 if you're part of the project, you have to deal with everything related, including being represented within the federation 2019-03-26 17:56:50 if you're not part of the project, make your own :D 2019-03-26 17:57:07 you spell it as the french "desk" (bureau) + "cracy" (common suffix) 2019-03-26 17:57:14 bureaucracy 2019-03-26 17:57:20 thanks 2019-03-26 17:57:24 doesn't help :P 2019-03-26 17:57:27 <_ikke_> haha 2019-03-26 17:57:36 (cracy being from the greek "rule" suffix) 2019-03-26 17:57:40 so basically "desk rule" 2019-03-26 17:58:11 ideally, I'd like to have a minimal amount of bureaucracy and make the level of trust needed for admin a bit lower; but that doesn't work 2019-03-26 17:58:17 because SOME PEOPLE out there are not very nice people 2019-03-26 17:58:31 and that's the same rough reason as to why any official team has to be represented (and communicable) 2019-03-26 17:58:41 I think the level of trust for an admin should be *higher* 2019-03-26 17:58:50 but the responsibilities which are exclusively trusted to them should be fewer 2019-03-26 17:59:00 how much fewer can you go? 2019-03-26 17:59:02 <_ikke_> hence s/team lead/team admin/ 2019-03-26 17:59:06 yes 2019-03-26 17:59:08 responsibilities right now: 2019-03-26 17:59:11 ideally no more than 2-4 2019-03-26 17:59:14 1. participate in project-wide meetings/voting 2019-03-26 17:59:20 2. adding/removing in-team members 2019-03-26 17:59:22 that's *it* 2019-03-26 17:59:34 then where's the dispute resolution? 2019-03-26 17:59:45 3 is implied by 1: be the contact point for the rest of the project 2019-03-26 17:59:54 dispute resolution is done in the abovementioned meetings 2019-03-26 18:00:05 basically, when I look at the core team 2019-03-26 18:00:07 (or, if there's already a project-wide policy, the meeting is more about "why we should have an exception") 2019-03-26 18:00:08 that list is alarmingly long 2019-03-26 18:00:18 <_ikke_> The list of what? 2019-03-26 18:00:19 yes, that is because the status quo is mixed 2019-03-26 18:00:22 list of people 2019-03-26 18:00:26 everyone does everything 2019-03-26 18:00:31 and the "everything" in question is "core" 2019-03-26 18:00:39 that's the very problem we're trying to solve 2019-03-26 18:00:52 obtaining a consensus on a difficult issue among that large of a group of people will be nearly impossible 2019-03-26 18:00:56 <_ikke_> In my case it's because I like to be able to do different things 2019-03-26 18:01:02 a smaller group should be established to be the final arbiter of conflict 2019-03-26 18:01:23 yeah, core could be that (for emergency situations), after it gets trimmed down 2019-03-26 18:01:29 _ikke_: you can be part of more than one team, so you're unaffected :D 2019-03-26 18:01:34 <_ikke_> hehe :) 2019-03-26 18:01:48 though I do recommend minimizing how many you're in (because per-person context switching remains a thing) 2019-03-26 18:02:00 <_ikke_> yes, I agree 2019-03-26 18:02:21 I'd imagine 2-3 is a reasonable "max" that one can expect once everything is rolling 2019-03-26 18:02:34 (e.g docs + openrc + packaging, and similar) 2019-03-26 18:02:57 I find it difficult to put any faith in a proposal which lists more than 3 or 4 people in a position of arbitration 2019-03-26 18:03:03 this shouldn't be solved later 2019-03-26 18:04:02 I don't expect project-wide arbitration to come up very often 2019-03-26 18:04:06 ddevault: thanks for https://paste.sr.ht/~sircmpwn/077de606d0215e300078ba2584c878c69c0176a0 2019-03-26 18:04:12 np 2019-03-26 18:04:18 good to write down exactly what we are trying to solve 2019-03-26 18:04:35 there's some number of project-wide policies to make, but once those are made I expect the number of project-wide decision making to mostly just involve adding/removing admins 2019-03-26 18:04:46 aye 2019-03-26 18:05:01 however, when the once-per-decade Really Important Divisive Issue comes up 2019-03-26 18:05:10 it's important to be prepared to handle it with grace and with the long-term health of the project in mind 2019-03-26 18:05:13 yes, and hopefully by that time we've managed to erode core sufficiently 2019-03-26 18:05:16 hope isn't a strategy 2019-03-26 18:05:22 the issue with trying to do it now is it simply won't happen. 2019-03-26 18:05:45 I spent most of yesterday arguing that the packaging should have access to the main repo, for example 2019-03-26 18:05:50 rather than core continuing to handle that 2019-03-26 18:06:09 and i expressed my worries about that 2019-03-26 18:06:11 side q: how long has this discussion been ongoing? 2019-03-26 18:06:19 something like a month 2019-03-26 18:06:37 the document's evolved a LOT since then 2019-03-26 18:06:56 you opened a box of worms :) 2019-03-26 18:06:59 my concern is that if we try to do the changes to core *now*, nothing will get done, period. 2019-03-26 18:07:28 I would rather we end up with a single divisive design-by-committee decision, rather than the status quo be kept for another decade 2019-03-26 18:07:30 also, a smaller core with dispute resolution powers helps to prevent k_niini #4 2019-03-26 18:07:46 <_ikke_> I think you still need a relatively small set of people responsible for the strategical goals (rather than tactical goals) 2019-03-26 18:07:52 yes, and I *am* in favor of a smaller core with dispute resolution powers (and catch-all for anything missing) 2019-03-26 18:08:08 I just don't think it's realistic to displace everyone in core right this second 2019-03-26 18:08:13 like you said, these disputes would hopefully be infrequent and entrusting this small set of people with that responsibility shouldn't have a large effect on ncopa et al being overburdened 2019-03-26 18:08:16 what I'd like to do right this second is move all of packaging into packaging 2019-03-26 18:08:35 the thing I hope then happens is lots of core members move into packaging, (hopefully removing themselves from core because they "don't care", as I hear on occasion) 2019-03-26 18:08:46 you're getting to something else I wanted to talk about 2019-03-26 18:08:54 is there an incremental path to adopting a new governance model? 2019-03-26 18:09:18 no, right now it's "get the document in" 2019-03-26 18:09:30 I have lots of TODOs in my personal notes (offline, part of my private syncthing only) 2019-03-26 18:09:36 for things to suggest "later" 2019-03-26 18:09:57 I assure you, I'm sufficiently motivated to push those through (or at least open the can of worms and see what happens), just perhaps after a small break ^^;; 2019-03-26 18:10:09 do you have an actionable todo list for v1? 2019-03-26 18:10:40 v1 (the document you've seen) is mostly an "under the hood" reorganization 2019-03-26 18:10:49 have a nice evening everyone. im gonna find something to eat and then have the meeting with linode 2019-03-26 18:10:50 MOST things remain "as is", but with the new framework to expand and allow new people in 2019-03-26 18:10:55 ncopa: enjoy! 2019-03-26 18:11:01 meeting with linode? 2019-03-26 18:11:04 I used to work there 2019-03-26 18:11:17 linode recently added official alpine support 2019-03-26 18:11:19 I suspect that's related 2019-03-26 18:11:22 nice 2019-03-26 18:11:23 <_ikke_> yes 2019-03-26 18:12:07 so the TODO for v1 is 1. get the document accepted; 2. prime everyone for v2 (in a few months); 3. remind people that new members etc are a thing now; 4. ask the infra team (likely through clandmeter) to reorganize gitolite ACLs to reflect the new structure 2019-03-26 18:12:23 (and moving packaging into packaging, as I mentioned - I want that for v1) 2019-03-26 18:12:54 so in the immediate future, 2019-03-26 18:13:23 your plan is to nail down a list of action items for changes that need to be made in the document before it can be accepted, then pass it around for discussion/ratification? 2019-03-26 18:13:32 also, what's the interim model that k_niini referred to? 2019-03-26 18:13:35 yes, and this has mostly done 2019-03-26 18:13:42 let me fetch that for you... 2019-03-26 18:14:22 <_ikke_> There was an earlier initiative to formalize how people would join alpine 2019-03-26 18:14:23 https://lists.alpinelinux.org/alpine-devel/6024.html + https://lists.alpinelinux.org/alpine-devel/6025.html 2019-03-26 18:14:45 thing is, it went through ~1.5 years ago, and was "actively used", but it clearly did not solve the problems at hand 2019-03-26 18:15:08 <_ikke_> SpaceToast: It did at least help in more people getting commit access 2019-03-26 18:15:12 it seems k_niini felt that the approach to ratifiying the new policies is out of line with the interim policies 2019-03-26 18:15:18 is it clear in what specific way that's the case? 2019-03-26 18:15:34 no, it isn't :/ 2019-03-26 18:15:48 in fact, a lot of their criticisms of my proposal apply to the interim policy as well 2019-03-26 18:15:52 (go over them, one by one!) 2019-03-26 18:16:03 I think that's *why* they leveraged those criticisms, though 2019-03-26 18:16:09 gotcha 2019-03-26 18:16:18 well, thanks for your patience in explaining it to my dumb self 2019-03-26 18:16:22 because the old policy does not specify how to update it, which opens the door for the *possibility* of someone getting upset (as in this case) 2019-03-26 18:16:34 which is why I'm seriously considering adding that specific bit in :) 2019-03-26 18:16:40 yes, that ought to be documented 2019-03-26 18:16:50 I'm just not sure it need be within that document specifically 2019-03-26 18:16:52 rather than elsewhere 2019-03-26 18:17:00 where? 2019-03-26 18:17:13 I think the policy on how to update policies 2019-03-26 18:17:15 should be a policy itself 2019-03-26 18:17:19 in the "policy" section 2019-03-26 18:17:25 rather than the team section 2019-03-26 18:17:30 oroborus policy 2019-03-26 18:17:35 roughly 2019-03-26 18:17:43 overengineering perhaps 2019-03-26 18:17:52 I think it's more atomic that way 2019-03-26 18:18:07 these documents have implications for each other 2019-03-26 18:18:09 since we *will* have more policies anyway 2019-03-26 18:18:19 perhaps the heading "Teams and Internal Organization" is the problem 2019-03-26 18:18:23 and "updating policies" is a general thing 2019-03-26 18:18:39 perhaps, what would you call it, if it is to describe team-specific details? 2019-03-26 18:18:51 I'd move this under a subsection of a more general document which has rules for updating itself 2019-03-26 18:18:52 the "Internal Organization" part was added to signal to external entities 2019-03-26 18:18:55 some kind of Alpine Charter or so 2019-03-26 18:18:56 "this is where you find out who to talk to" 2019-03-26 18:19:13 bylaws, perhaps 2019-03-26 18:19:15 I dunno, words are hard 2019-03-26 18:19:30 I think the entire developer handbook is that document :) 2019-03-26 18:19:41 it'll contain a list of policies, but also guides for contributors, etc 2019-03-26 18:19:42 aight 2019-03-26 18:22:24 k_niini gave more of their thoughts on pleroma, by the way: https://pleroma.site/notice/9h9ao4xZFQ6MLjanRY 2019-03-26 18:23:10 my take is that any successful model will be built on a foundation of trust. If you can't trust core you ought to fork anyway. 2019-03-26 18:23:20 making core smaller makes it easier to trust them, fwiw 2019-03-26 18:24:42 <_ikke_> kaniini wants to run Alpine like a government, where the 'people in power' change every so often 2019-03-26 18:25:31 they also want ALL members to vote 2019-03-26 18:25:37 which.... does not solve the problems we wish to solve 2019-03-26 18:26:04 what's also interesting is that people think this isn't public, despite the multiple ML postings about it (thanks _ikke_, ncopa :) ) 2019-03-26 18:26:20 sure, a lot of the conversation happens here.... but this is also public (logged by algitbot) 2019-03-26 18:26:40 often also mentioned in a-devel, and anyone is free to chime in (e.g ddevault, whose feedback is as welcome as everyone else's) 2019-03-26 18:26:58 the "technical and managerial boards" thing seems... strange 2019-03-26 18:27:14 <_ikke_> seems to be way to formal for a project like alpine 2019-03-26 18:27:23 indeed, there's no way to make everyone happy 2019-03-26 18:27:39 I think that kaniini was disgruntled well before this effort started, and not all of the arguments are founded in reason. They may have some other stuff going on 2019-03-26 18:27:49 aye, possible 2019-03-26 18:27:50 important to reflect on the good insights, but not let the bad ones drag the process down 2019-03-26 18:28:12 <_ikke_> on pleroma he says this is some kind of powergrab 2019-03-26 18:28:25 yes, of course, I am the shill of the core team, no other explanation is available! 2019-03-26 18:28:38 I think the current state (well, the final state I'm thinking of (v3)) is a good balance for the current state of the project 2019-03-26 18:29:05 the ability to update is important in case we grow past it, so it's on my TODO now (trying to pick between v1 and v2 for it, since it should apply to more than just team stuff) 2019-03-26 18:29:24 <_ikke_> yes, it's better to iterate and adopt as needs change 2019-03-26 18:30:14 I think I'll add it to v1, to be fully certain 2019-03-26 18:31:05 ddevault: what do you think of the following proposal for "tiebreakers" 2019-03-26 18:31:12 <_ikke_> And I think we first should focus on the primary concerts we have at this moment, which is more related to delegate things 2019-03-26 18:31:19 in the scenario that a 2/3 majority cannot be attained in a team admin vote, 2019-03-26 18:31:19 <_ikke_> concerns* 2019-03-26 18:31:47 no, let's focus on the primary concerts 2019-03-26 18:31:54 I plan on going go magical mirai 2019 in august 2019-03-26 18:31:57 ok ¯\_(ツ)_/¯ 2019-03-26 18:32:03 going to* 2019-03-26 18:32:05 man 2019-03-26 18:32:12 SpaceToast: sorry, continue 2019-03-26 18:32:17 which one? :) 2019-03-26 18:32:26 osaka 2019-03-26 18:32:29 nice ^^ 2019-03-26 18:32:58 anyway, in the scenario that a 2/3 majority cannot be attained in a team admin vote, the core team shall discuss it internally, and all vote together (members included) 2019-03-26 18:33:10 if a 2/3 majority still cannot be attained, a simple majority of the core team becomes the final decision 2019-03-26 18:33:21 (only if someone calls for it, though) 2019-03-26 18:33:30 +1 2019-03-26 18:33:38 but it doesn't work unless the core team is small and has an odd number of people 2019-03-26 18:33:39 (i.e it's expected that your motion not passing -> you don't continue, unless you REALLY think it's a HUGE mistake) 2019-03-26 18:33:53 I think we expect core team to not be divided, and to be small 2019-03-26 18:33:56 perhaps the core team should be explicitly defined as 3 people 2019-03-26 18:34:03 hmm 2019-03-26 18:34:09 can't do that right now, but it's something to consider 2019-03-26 18:34:14 >I think we expect core team to not be divided 2019-03-26 18:34:16 that works until it doesn't :) 2019-03-26 18:34:20 in my v2, I have "Encourage core members that don't care about administration to move to Packaging" 2019-03-26 18:36:04 hmm 2019-03-26 18:36:08 if EVERYONE is truly THAT divided 2019-03-26 18:36:23 perhaps it's good to stall and have the two parties talk to each other, to try and sort it out 2019-03-26 18:36:41 I don't think anyone will ever be happy with a brexit-style majority, when EVERYONE is conflicted 2019-03-26 18:36:48 (example given chosen deliberately) 2019-03-26 18:37:29 perhaps the core team, with the trust we place in them to guide the project with wisdom and care, will decline to resolve a dispute if they are unsure themselves, until it becomes absolutely necessary 2019-03-26 18:37:41 assume everyone on the core team is (1) smart and (2) has the best interests of the project at heart 2019-03-26 18:38:05 <_ikke_> Which history seems to indicate :-) 2019-03-26 18:38:17 the cynic in me wants to say "quite the assumption" very badly ;) 2019-03-26 18:38:30 well, let me put it this way 2019-03-26 18:38:38 if those two principles do not hold, the entire Alpine Linux project is a write-off 2019-03-26 18:38:46 and I'll take my interests elsewhere 2019-03-26 18:38:53 but thankfully, I do trust the people I assume would land in that position 2019-03-26 18:40:48 ok, that sounds fair 2019-03-26 18:40:51 took a bit of thinking, that one 2019-03-26 18:40:55 and yes, core has to be REALLY small then 2019-03-26 18:40:59 3-5 max 2019-03-26 18:41:18 I do still think a more representative-democratic approach is better, but this is the fallback scenario 2019-03-26 18:42:05 let me connect this back to my point on delegation 2019-03-26 18:42:20 in my opinion the ultimate authority of the project should rest in a small number of highly capable and trusted hands 2019-03-26 18:42:56 then, in order to shoulder that burden, they delegate responsibilities to others, through a formal process or otherwise, even to the point of having little actual work left to do for themselves if necessary 2019-03-26 18:43:13 <_ikke_> I tend to agree with ddevault 2019-03-26 18:43:14 but they retain the right to withdraw or change the responsibilities they've delegated to someone, or delegate more, as they see fit 2019-03-26 18:43:39 that seems a lot more power-grabby ala k_niini to me 2019-03-26 18:43:48 the project is not a few people, the project is everyone working on it together 2019-03-26 18:43:51 <_ikke_> SpaceToast: How so 2019-03-26 18:44:01 comes back to trust 2019-03-26 18:44:03 it goes both ways 2019-03-26 18:44:04 <_ikke_> SpaceToast: It's basically already the case 2019-03-26 18:44:12 the contributors to the project have to trust the leaders 2019-03-26 18:44:15 not according to k_aniini! 2019-03-26 18:44:16 and the leaders have to trust the contributors 2019-03-26 18:44:35 <_ikke_> The core team currently has all power 2019-03-26 18:44:43 <_ikke_> (I don't like the term power anyway) 2019-03-26 18:44:57 yes, and I think power should be distributed alongside everything else :) 2019-03-26 18:45:05 I'm ok with having a panic "resolve all conflicts" button 2019-03-26 18:45:08 <_ikke_> distributed or delegated? 2019-03-26 18:45:10 fwiw, this is how I run my open source projects 2019-03-26 18:45:14 distributed 2019-03-26 18:45:18 and to date it has been extremely successful 2019-03-26 18:45:28 how big are your open source projects? 2019-03-26 18:45:42 ~300 contributors in the main two 2019-03-26 18:45:46 no offense in that sense, what I mean is that this get scary when scale goes up 2019-03-26 18:45:59 about ~30 regulars who are trusted with some degree of responsibility 2019-03-26 18:46:10 also, the ability to delegate is in and of itself something you can delegate 2019-03-26 18:46:15 thus it scales even further 2019-03-26 18:46:42 trying to do math.. 2019-03-26 18:47:51 looking at bigger proejcts 2019-03-26 18:47:59 python did a similar thing until guido stepped down, and imo the new python governance model is similar too 2019-03-26 18:48:25 yes, the BDFL model is popular in straightforward open source projects 2019-03-26 18:48:32 can you go into more detail re: new python governance model? 2019-03-26 18:48:48 the thing is that alpine has a bit more "to it", since it's not a single thing 2019-03-26 18:48:56 they chose a new BDFL 2019-03-26 18:49:00 ah 2019-03-26 18:49:13 but there are still a group of Empowered Important People 2019-03-26 18:49:28 who derive their power in princple from a delegation of the BDFL's responsibilities to them 2019-03-26 18:49:47 imo replacing the BDFL with a committee of 3 or something similar is also wise and works roughly the same 2019-03-26 18:50:07 so long as you have a sufficient supply of highly trusted people 2019-03-26 18:50:07 ok, does core remain bound by projectwide policies (even if they were accepted by 2/3 majority of the admins)? 2019-03-26 18:50:21 (under your idea) 2019-03-26 18:50:39 to put it bluntly, projectwide policies exist at the pleasure of core 2019-03-26 18:50:49 in order to maintain the trust that we place in core, they naturally wouldn't be able to abuse this 2019-03-26 18:50:59 but when reason must prevail, they can selectively ignore something 2019-03-26 18:51:10 ok, so a soft trust model, like everyone else is in 2019-03-26 18:51:39 the primary policy I'm thinking of is specificity delegation 2019-03-26 18:51:41 linux also runs with a fairly similar model 2019-03-26 18:51:58 since core would handle "everything" by default, that'd make ALL other teams more specific than core 2019-03-26 18:52:12 which means that (unless policy is overriden), teams override core 2019-03-26 18:52:21 unless core overrides policies, which is the big red button :tm: 2019-03-26 18:52:25 (remember gpl2?) 2019-03-26 18:52:29 aye, teams are entrusted with policymaking power within their domain 2019-03-26 18:52:38 so I suppose that can work 2019-03-26 18:52:40 but core steps in if they need to 2019-03-26 18:52:47 we'd need to talk to ncopa though 2019-03-26 18:52:52 that's quite a long way for core to go 2019-03-26 18:53:02 and he's having trouble trusting the packaging team enough to handle main/ :) 2019-03-26 18:53:14 aye, it's also just the opinions of some random who wandered in here when he happened to be highlighted yesterday 2019-03-26 18:53:22 (though the issue is with the mess that need be cleaned up, so I think packaging should have blanche carte over aports in general) 2019-03-26 18:53:24 don't forget the grain of salt 2019-03-26 18:54:00 I look at ideas from a purely meritocratic perspective ¯\_(ツ)_/¯ 2019-03-26 18:54:03 fwiw, perhaps the vision I have for "core" should better be called "lead" or something 2019-03-26 18:54:06 usually helps with that 2019-03-26 18:54:18 core is currently called core because that's what it was called before 2019-03-26 18:54:19 I think it's fine to have two teams for managing aports, one for main and one for everything else 2019-03-26 18:54:22 I think it's called "Base" in gentoo 2019-03-26 18:54:35 no, you end up with massive issues when you do that, as discussed yesterday 2019-03-26 18:54:36 calling the team which manages main core and calling the team that does admin shit something else is fine 2019-03-26 18:54:50 we could do that too, perhaps 2019-03-26 18:55:25 there could also be something like 2019-03-26 18:55:36 core [ packaging [ community[...] ] ] 2019-03-26 18:56:05 since everyone who can work in main will naturally be allowed to work elsewhere in aports 2019-03-26 18:56:34 dunno if that made any sense 2019-03-26 18:58:05 well actually 2019-03-26 18:58:12 this could work if core was defined to handle all of packages 2019-03-26 18:58:18 but then, shouldn't it be called packaging? :) 2019-03-26 18:58:33 but yes, the issue is we want a venn diagram in which there are no cross-sections 2019-03-26 18:58:48 any given circle must either be outermost and not intersect with anything, or be completely inside another circle 2019-03-26 18:58:53 for everything to work smoothly 2019-03-26 18:59:11 which is why the current state of "core is main/; packaging is community/ + testing/" is so difficult 2019-03-26 19:02:45 https://sr.ht/fNXt.png 2019-03-26 19:03:18 why must there be no cross-sections? 2019-03-26 19:03:34 because then you get constant conflicts that are not resolvable in quick ways 2019-03-26 19:03:54 do you? I assume those would be rare, and core could step in 2019-03-26 19:04:13 core stepping in is slow, and should be the big red button 2019-03-26 19:04:19 <_ikke_> SpaceToast: My feeling is that it's not packaging is community + testing, but that not everyone in packaging automatically gets push rights to main 2019-03-26 19:04:38 the default conflict resolution mechanism is "whatever team is more specific relating to the subject wins by default" 2019-03-26 19:04:52 <_ikke_> but even that can be subjective 2019-03-26 19:04:54 if you have teams that are not strict sub/supersets, any disagreement between them needs to be escalated 2019-03-26 19:05:03 not if everything is a strict sub or superset 2019-03-26 19:05:12 which is exactly why we don't want cross-sections 2019-03-26 19:05:14 possibly related: contributors should recognized when they're stretched thin and change course accordingly, but we shouldn't discourage people who want to work in several fields from doing so 2019-03-26 19:05:30 source: am person who may want to do that 2019-03-26 19:05:33 <_ikke_> SpaceToast: Like I'm currently listed as core, but I don't have push rights to main 2019-03-26 19:05:43 certainly, you can join multiple teams, and choose which team you're acting on behalf of at any given moment 2019-03-26 19:05:54 <_ikke_> I'm in infra, but I don't have access it every piece of infrastructure 2019-03-26 19:06:07 _ikke_: yes, but that can count as internal team organization stuff 2019-03-26 19:06:12 not inter-team details 2019-03-26 19:17:04 ddevault, _ikke_ (,ncopa): does this seem like an adequate actionable set of things to do *right now*? https://brpaste.xyz/tZPnNg 2019-03-26 19:29:51 SpaceToast: sounds good to me 2019-03-26 19:30:14 so I guess we need to figure out who we trust enough to go on there 2019-03-26 19:30:21 though I would advocate for that team being exactly 3 people 2019-03-26 19:30:34 it's the smallest number of people which has multiple perspectives but cannot disagree with itself 2019-03-26 19:30:50 mhm, I think it depends on who might want to go there 2019-03-26 19:30:59 but it should probably be either 3 or 5 2019-03-26 19:31:15 I think I can do 2 right now, just rename core to packaging, and packaging to "community packaging" 2019-03-26 19:31:20 and that should set that straight 2019-03-26 19:31:37 3 can be done relatively easily 2019-03-26 19:31:50 4 and 5 would need me to think about how to organize the structure again, so it might not happen today 2019-03-26 19:32:05 perhaps this document should just mention top-level teams 2019-03-26 19:32:18 and each top-level team ought to have its own document 2019-03-26 19:32:25 on which the packaging team can establish its community subteam 2019-03-26 19:32:59 yes, that's what I was going for initially 2019-03-26 19:33:16 but the document was small enough to begin with that there wasn't a concern, and people suggested keeping things on one page :) 2019-03-26 20:04:17 trying to consider how to properly markup teams, because "just top level" means only "base" is mentioned 2019-03-26 20:04:34 I'm considering having each team's page specify its parent team, but not list subteams 2019-03-26 21:32:25 ddevault: I've temporarily decided to not split teams out, mostly to avoid (even) further confusion from people that first see the document 2019-03-26 21:32:40 I expect it to happen once we've stabilized the definitions 2019-03-26 21:33:28 took quite a while :) 2019-03-26 21:33:53 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/teams.html new document, in case anyone has comments ( ddevault, _ikke_, ncopa, for whenever you all see this ) 2019-03-26 21:34:23 also please note the new section on the left: Policies 2019-03-26 21:34:39 I managed to get everything we discussed in, including both things k_niini asked for 2019-03-26 21:37:42 ha! 2019-03-26 21:37:53 the tabs vs spaces was just an example 2019-03-26 21:38:06 i´ll read it more in detail tomorrow 2019-03-26 21:38:48 it's an example, but it's an example that exists, and needs to be documented. 2019-03-26 21:38:59 might as well do it now, while I'm going over various policies to add, eh? :) 2019-03-26 21:39:28 and sure, I'll take the rest of today off, and read any feedback whenever I next wake up (which may be a bit awkward, given the state of my sleep schedule, which apparently got stabbed in the back tonight) 2019-03-26 21:40:21 (sidenote: core has been renamed to "packaging", and old packaging (community + testing) has been renamed to "packaging: community" 2019-03-26 21:40:38 (I think this better reflects what they actually do, and makes my inner sophist happy) 2019-03-26 22:20:18 [13:28:25] yes, of course, I am the shill of the core team, no other explanation is available! 2019-03-26 22:20:21 i did not say that 2019-03-26 22:20:30 i said the policy proposals are flawed 2019-03-26 22:20:39 i also have no interest in running alpine as a 'government' 2019-03-26 22:20:50 it was a facetious statement regarding some of your pleroma content, don't worry about it too much 2019-03-26 22:20:55 but i also have no interest in participating in a project that has a policy as flawed as that 2019-03-26 22:21:21 well, several of your criticisms have been taken into account, and the document modified to attempt to resolve 2019-03-26 22:21:30 some seem silly and/or inactionable, so they haven't been 2019-03-26 22:21:41 regardless of whether you care to go on, I thank you for your insight. 2019-03-26 22:22:16 core does more than just deal with main, though. that is why i proposed privately that core be split into several teams 2019-03-26 22:22:31 right now, core is a catch all 2019-03-26 22:22:33 that's what I've been suggesting for something like 2 weeks now 2019-03-26 22:22:39 the details have simply been complicated. 2019-03-26 22:22:55 owever, i do like what i see in the new version 2019-03-26 22:22:57 the document you've likely gone over had focused on codifying the status quo, with my plans being to push for further change later down the road 2019-03-26 22:23:26 I suspect you will still dislike that not all members get to vote (but I've explained the reasoning in great detail today already), and I suspect you will dislike the existence of the new "Base" team 2019-03-26 22:23:44 however, as ddevault points out, some degree of "what if everyone disagrees" conflict resolution ultimately needs to exist (regarding that latter one) 2019-03-26 22:23:51 yes, the lack of members being able to not vote is a problem to me 2019-03-26 22:24:12 and so, i vote with my feet, for now 2019-03-26 22:24:24 it very much seemed like it in your initial critique (but it seemingly contradicted point 4) 2019-03-26 22:24:46 either way, again, thank you - your criticism (even if it wasn't perfect) resulted in direct improvements to the proposal - a positive outcome :) 2019-03-26 22:25:01 I wish you luck in your future endeavors, that I suspect there will be multiple of. 2019-03-26 22:25:06 the behavior of teams as a unit should reflect full consensus 2019-03-26 22:25:21 that means team members should have the vote 2019-03-26 22:25:38 or, put differently, explain to me why team members should *not* have the vote 2019-03-26 22:25:57 backroom deals in debian are why i quit debian over a decade ago to come work on alpine instead 2019-03-26 22:26:09 1. team members may not necessarily be trusted enough to determine the direction of the project 2019-03-26 22:26:12 so i am very skeptical of any proposal that enables that type of deal 2019-03-26 22:26:18 team membership is being given push access 2019-03-26 22:26:24 (after having contributed for a while) 2019-03-26 22:26:32 2. as the project grows, the number of members will grow 2019-03-26 22:26:40 this reiterates my point 2019-03-26 22:26:44 the more people that HAVE to be present for voting to be effective, the more unlikely any vote is to go through 2019-03-26 22:26:44 if they have push access 2019-03-26 22:26:51 then they are already determining the direction of the project 2019-03-26 22:27:01 I would rather vote on more points, than have fewer votes in general 2019-03-26 22:27:03 so would you rather them act in good faith by participating in consensus-making 2019-03-26 22:27:22 or would you rather them be like "fuck this entire thing" and just push what they want to 2019-03-26 22:27:38 case in point: jirutka (which was completely improperly handled) 2019-03-26 22:28:30 I just don't see how having 500 people vote on every project-wide issue helps fix the goals the proposal sets out to fix 2019-03-26 22:28:40 the goal is to allow the project to get from point A to point B more efficiently 2019-03-26 22:28:42 i'm not saying every project-wide issue requires a vote 2019-03-26 22:28:45 that's the job of core 2019-03-26 22:28:47 and I am. 2019-03-26 22:28:49 to build rough consensus 2019-03-26 22:29:01 so we either vote less often (thus the whole process is less democratic) 2019-03-26 22:29:25 and why does it matter if 500 people vote for that matter 2019-03-26 22:29:25 or we allow representative voting (so you don't get a vote yourself, necessarily, but since your team functions as a unit, your admins likely know what the team wants and thinks) 2019-03-26 22:29:44 reaching 2/3 majority with 500 people voting means that 300 people must vote 2019-03-26 22:29:46 this is something software already exists for 2019-03-26 22:29:52 no it doesn't 2019-03-26 22:29:52 participation rates are almost always MUCH lower than that. 2019-03-26 22:30:00 you establish quorum based on the total number of votes 2019-03-26 22:30:13 then you simply have backroom deals again - between people that actually care to show up 2019-03-26 22:30:43 what exactly are you worried about, though? 2019-03-26 22:30:46 i think that's not really fair, in debian and fedora, participation rates are high 2019-03-26 22:30:56 that team admins will vote the exact opposite way than their team? 2019-03-26 22:31:05 on a consistent basis, and no one on the team will complain? 2019-03-26 22:31:08 this just seems unlikely 2019-03-26 22:31:12 debian governance has improved, this governance is moving backwards 2019-03-26 22:31:17 especially since all votes must be held in a transparent manner 2019-03-26 22:32:03 and if we're counting majority based on the number of votes, it means that the timeout must be reached more or less every time their is a vote, which also significantly slows down anything that does require one 2019-03-26 22:32:12 in short - I don't see what we're gaining 2019-03-26 22:32:16 I see lots of losing. 2019-03-26 22:32:32 and likelise, i see lots of lossage with the proposals so far 2019-03-26 22:32:36 which is why i resigned 2019-03-26 22:32:56 the loss appears to be purely philosophical, and one that seems to apply elsewhere as well 2019-03-26 22:33:06 further, the status quo is significantly worse, so I wouldn't call that "backwards" 2019-03-26 22:33:22 as mentioned by others before, core basically has ultimate power as-is now, without even the expectation of anything being different by default 2019-03-26 22:33:26 yes i agree that the status quo, as well as the interim policies we follow now are very flawed 2019-03-26 22:33:53 then certainly, the proposed state of things is working forward, just potentially not as far forward as you would like 2019-03-26 22:34:08 i disagree on that 2019-03-26 22:34:16 i see the proposed state of things as a bait and switch 2019-03-26 22:34:30 it's "democracy" but at the end of the day, the game remains rigged 2019-03-26 22:34:30 who's baiting, and what's being switched in its place? 2019-03-26 22:34:37 what... game? 2019-03-26 22:34:50 my understanding is that it is in everyone's common interest to improve the project 2019-03-26 22:35:01 if that is not the case, I can certainly see there being power dynamics and rigging 2019-03-26 22:35:11 sure, but different folks have different ideas on what 'improve' means 2019-03-26 22:35:19 however, the idea is that everyone voting should have the project's best interests in mind, without making the bar to entry impossibly high 2019-03-26 22:35:36 for example, many contributors are paid with VC money to work on alpine 2019-03-26 22:35:42 which would be the direct result of having everyone vote, by the way, which goes against the solutions to the problems in question 2019-03-26 22:35:50 their idea of 'improve', naturally, is what makes their paymasters happy 2019-03-26 22:36:07 say the docker and ibm teams disagree on feature X 2019-03-26 22:36:10 what then? 2019-03-26 22:36:20 why should there be an ibm team? 2019-03-26 22:36:28 :D :D :D :D :D :D :D 2019-03-26 22:36:39 and this is why the proposal is flawed 2019-03-26 22:36:40 and why should the docker team have anything to say on feature X, if it isn't directly related to the docker software? ;) 2019-03-26 22:36:50 you are looking at it from the wrong angle :) 2019-03-26 22:36:59 in order for an ibm team to exist, all the team admins (together), must approve the creation of such a team 2019-03-26 22:37:03 wrong 2019-03-26 22:37:11 or Base can force it (under the latest revision) 2019-03-26 22:37:18 but if Base is compromised, the whole project is a writeoff anyway 2019-03-26 22:37:29 again, wrong in order for an ibm team to exist, ibm hires people to work on alpine, and they collude together 2019-03-26 22:37:39 this is happening today 2019-03-26 22:37:42 same with docker 2019-03-26 22:37:48 and for them to collude properly, they must be in administrative positions 2019-03-26 22:37:55 and they are 2019-03-26 22:37:57 .... to get into which you must get the rest of the admins to bring you in 2019-03-26 22:38:05 and if anyone abuses their power in a visible manner, they get removed 2019-03-26 22:38:20 and so my point is 2019-03-26 22:38:30 if ibm really wanted to have something happen, could they just not hire enough people to work on alpine that they would win through sheer numbers, if everyone can vote? 2019-03-26 22:38:33 all contributors on a team should have the power of voting on that team's business 2019-03-26 22:38:42 on *that team's business*, yes 2019-03-26 22:38:45 and all contributors to the project should have the power of voting on project-wide matters 2019-03-26 22:38:47 on *the entire project*, I'm not so sure. 2019-03-26 22:38:53 i'm *very* sure 2019-03-26 22:39:28 so far, your argument has literally been "there are multiple conspiracies at hand, and doing things my way makes it slightly less likely that they directly affect us" 2019-03-26 22:39:46 I'm not sure making everything else slower o work around that is optimal 2019-03-26 22:40:13 no, my argument is that giving people a direct voice in the entire project (which these types of votes are rare) 2019-03-26 22:40:18 works, and works well 2019-03-26 22:40:29 debian and fedora are both exemplary models for this 2019-03-26 22:40:36 I expect these votes to be less rare 2019-03-26 22:40:50 since anything that directly relates to the project (rather than any specific existing team) is at question here 2019-03-26 22:41:14 in practice those issues are rare 2019-03-26 22:41:28 Debian has had less than 100 project-wide votes in two decades 2019-03-26 22:41:31 in practice, we would have had to hold something like 12 votes today alone :) 2019-03-26 22:42:53 doing things the right way is not meant to be easy 2019-03-26 22:43:34 certainly, but your statement of "in practice those issues are rare" is clearly contradicted by the events of today alone, not to mention the last month or so 2019-03-26 22:44:55 they aren't rare when starting up, but once things are solidified, they are rare 2019-03-26 22:45:08 we only have quasi-related data 2019-03-26 22:45:11 and anyway, even still, you present a final version 2019-03-26 22:45:17 after all, debian is not alpine 2019-03-26 22:45:17 and vote on that 2019-03-26 22:45:35 debian has a lot more policies in place as-is, whereas the list of the alpine ones has only now begun to be built up 2019-03-26 22:46:56 in short, I find that the only thing to be gained (tangibly, not philosophically) is a slight boost in resistance to manipulation from external forces 2019-03-26 22:47:09 (slight boost since, in the scenario where everyone votes, they can simply hire a lot more people) 2019-03-26 22:47:33 there's a symbolic thing to it too 2019-03-26 22:47:36 I would certainly be open to reconsidering my stance a few years down the line, once everything *has* settled, and we have data 2019-03-26 22:47:41 you make people feel like their opinions actually matter 2019-03-26 22:47:51 yes, that's the philosophical bit 2019-03-26 22:47:54 but either way, since this is being unilaterally decided 2019-03-26 22:48:08 however, as you said, having push access already means your opinion (within your own domain) matters 2019-03-26 22:48:09 and this project is governing in a way that is not in concordance with software freedom 2019-03-26 22:48:21 then i'm going to continue to stay out 2019-03-26 22:48:31 something something stallman and theo in a boxing ring in texas? ;) 2019-03-26 22:48:58 I think that roughly summarizes our philosophical differences, actually. 2019-03-26 22:49:10 go work on a fucking BSD then 2019-03-26 22:49:16 I basically did? 2019-03-26 22:49:21 Alpine's modeled after FreeBSD, after all :) 2019-03-26 22:49:22 then go back to working on one 2019-03-26 22:49:31 I just like the kernel :D 2019-03-26 22:49:46 (and apk is quite nice) 2019-03-26 22:50:07 (I would certainly consider (also) contributing to a BSD that incorporated linux features (such as proper namespacing) and apk-tools) 2019-03-26 22:50:55 (and the strange GPLthumping is a good part of why I left gentoo) 2019-03-26 22:51:40 i'm not a GPL thumper, but I believe strongly in open governance 2019-03-26 22:51:56 I'm not calling you one, I meant that there's a significant amount of that within gentoo 2019-03-26 22:51:58 and i certainly believe there are places for GPL and AGPL 2019-03-26 22:52:31 (for instance, lua is horrifyingly hacked up to follow a policy against static linking... because that makes the GPL unhappy) 2019-03-26 22:52:38 open governance, to me, is the root of software freedom 2019-03-26 22:52:50 enabling people to have a say is not the same as push access 2019-03-26 22:53:09 some people may want to have a say but have no ability to directly effect the change they pursue 2019-03-26 22:53:13 people can always come in and give their opinion 2019-03-26 22:53:25 I can't speak for everyone, but I take ALL opinions into account, based on their merit, regardless of who's giving them 2019-03-26 22:53:38 (for instance, you aren't part of the project right now, but that's not a reason to take you any less seriously) 2019-03-26 22:53:51 and I'm in favor of full transparency 2019-03-26 22:54:04 full transparency means letting EVERYONE vote 2019-03-26 22:54:13 you may notice that basically all the negotiations, talks, and evolution of the proposal has happened in public channels, that are logged, and available for anyone to go through 2019-03-26 22:54:29 no, full transparency means that all documents and all information is available to everyone, including people outside the project. 2019-03-26 22:54:51 there are two aspects to transparency 2019-03-26 22:55:22 what you say is one of those aspects 2019-03-26 22:55:28 participation is the other 2019-03-26 22:55:33 participation = voting 2019-03-26 22:55:46 I disagree on both counts 2019-03-26 22:56:08 the reason why i fundamentally disagree with the proposal is because it's too little, too late 2019-03-26 22:56:08 I don't see how participation is a necessary part of transparency, and I don't see how you are currently not participating 2019-03-26 22:56:28 you are not voting (not being part of the project anymore), but you are clearly participating by proposing meritocratic ideas. 2019-03-26 22:57:06 the reason why i am not part of the project anymore is because it is hell-bent on adopting policy that will harm the ability of contributors to participate 2019-03-26 22:57:11 i don't want a meritocracy 2019-03-26 22:57:21 alpine is too big, and too important, to be a meritocracy 2019-03-26 22:57:36 a meritocracy is the fastest route towards making any given thing (including alpine) as good as it can possibly be 2019-03-26 22:57:55 if you don't want a meritocracy, I must conclude that you are not primarily interested in improving the project 2019-03-26 22:58:21 i am primarily interested in improving the project, but i want to see a hybrid approach 2019-03-26 22:58:37 i want to see the ability for the developers as a whole to override the decisions of teams 2019-03-26 22:58:45 sometimes meritocracies get it wrong 2019-03-26 22:58:54 like this policy process is getting it wrong, right now 2019-03-26 22:58:59 so... you want less improvement over time because you are worried of multiple ongoing massive-scale conspiracies interfering 2019-03-26 22:59:11 you are painting it in a negative light which shows bias 2019-03-26 22:59:18 which demonstrates why meritocracy is flawed 2019-03-26 22:59:38 what do you think of Linux? 2019-03-26 22:59:41 as a project 2019-03-26 22:59:52 i don't care either way what Linus does 2019-03-26 22:59:57 not Linus 2019-03-26 22:59:59 Linux. 2019-03-26 23:00:03 the kernel 2019-03-26 23:00:10 don't care 2019-03-26 23:00:14 it's irrelevant 2019-03-26 23:00:25 well, I would like to apply your logic to other projects 2019-03-26 23:00:32 you were very eager to do that in the context of Debian and Fedora 2019-03-26 23:00:41 because they are similar projects 2019-03-26 23:00:46 the Linux kernel is not 2019-03-26 23:00:55 and frankly, i find the governance of the Linux kernel to be abhorrent 2019-03-26 23:01:07 I agree, but it's a bit more than governance, isn't it? 2019-03-26 23:01:17 so comparing your proposal to Linux's governance 2019-03-26 23:01:22 would certainly make me more skeptical 2019-03-26 23:01:28 that's not quite what I'm doing 2019-03-26 23:01:56 I'm trying to explore your point of view by applying the same rules and opinions (since I assume they're consistent, right?) to a different scenario 2019-03-26 23:02:07 I'm using the Linux Kernel for a few reasons: 2019-03-26 23:02:14 1. changes within the Linux Kernel DIRECTLY affect us 2019-03-26 23:02:23 there is no question regarding that (I would hope) 2019-03-26 23:02:35 2. it features overt cases of most of the things you are complaining about 2019-03-26 23:02:56 as such, I'm interested in exploring the ramifications when it comes to alpine, as seen by you, and how you would propose dealing with it. 2019-03-26 23:03:19 i've already said that team maintenance is fine 2019-03-26 23:03:24 if you don't think it matters, that would suggest that you shouldn't care quite as much about the case at hand here, which is a far more reaching "maybe", with significantly less pressure on it. 2019-03-26 23:03:33 my issue is with the lack of project-wide oversight 2019-03-26 23:03:37 and team-wide oversight 2019-03-26 23:03:48 project-wide oversight is now done by the "Base" team (we need only figure out who goes there) 2019-03-26 23:04:04 and who decides who is on that 2019-03-26 23:04:09 the member list is set to 3 (to guarantee quorum, and minimize amount of overall trust) 2019-03-26 23:04:12 and how does Base get overridden 2019-03-26 23:04:21 come on, man 2019-03-26 23:04:32 I'd imagine it will be decided upon initialization (so, sometime around now), and it cannot get overriden, since that's kind of the point of project-wide oversight. 2019-03-26 23:04:47 you either have oversight, in which case the oversight HAS to be the absolute authority 2019-03-26 23:04:59 that's not the case 2019-03-26 23:05:01 or you do NOT have oversight, which was how I had it previously, which you also did not like 2019-03-26 23:05:11 if your oversight cannot fix things that it finds to be incorrect 2019-03-26 23:05:14 then it is not oversight 2019-03-26 23:05:16 in Debian, the tech-ctte can be overridden by a project-wide vote 2019-03-26 23:05:19 it's a meekly group made to complain 2019-03-26 23:05:34 but in this case, oversight is there to oversee project-wide votes.. 2019-03-26 23:05:45 then that's fine 2019-03-26 23:06:13 i am glad we now agree that project-wide votes are necessary 2019-03-26 23:06:16 oversight of team-internal things is already done by the project-wide voting group - if something within your team is wrong, you bring it up to some other team's admins 2019-03-26 23:06:29 no 2019-03-26 23:06:32 yes, and the project-wide votes is done through a representative system, where admins vote representing their team. 2019-03-26 23:06:36 *all* devs should be able to vote 2019-03-26 23:06:37 directly 2019-03-26 23:06:58 we appear to be going in circles 2019-03-26 23:07:03 or, rather, begging the question 2019-03-26 23:07:13 you just said that this must happen while in the process of explaining why it must happen 2019-03-26 23:07:42 you know what 2019-03-26 23:07:48 i should have just stayed and pulled a jirutka 2019-03-26 23:07:50 and run you out 2019-03-26 23:08:17 that would be hypocritical though 2019-03-26 23:08:25 before or after the proposal goes through? ;) 2019-03-26 23:08:47 if it's after, I would go as per the proper procedure (complaining to X, and then asking Base to reconsider, given the circumstances) 2019-03-26 23:09:04 however, an interesting thing to note: 2019-03-26 23:09:04 going to some other team's admins is insane 2019-03-26 23:09:06 you go to base 2019-03-26 23:09:12 and ALL DEVS VOTE 2019-03-26 23:09:14 if most people here do not want me here 2019-03-26 23:09:18 do I really want to stay? 2019-03-26 23:09:36 i mean, i do want you here, but i do not want this policy as proposed 2019-03-26 23:09:38 which is why i quit 2019-03-26 23:09:47 actually, here's an interesting potential for compromise 2019-03-26 23:09:50 it was a protest quit 2019-03-26 23:09:52 can I go through it with you? 2019-03-26 23:10:01 sure, but i will probably still say no 2019-03-26 23:10:05 consider https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/voting.html 2019-03-26 23:10:16 if in place of the Base vote 2019-03-26 23:10:32 Base are the party that organizes an "EVERYONE VOTES" vote 2019-03-26 23:10:46 (as a pure extreme-case fallback, if Base's added votes do not give 2/3 majority) 2019-03-26 23:10:48 would you prefer that? 2019-03-26 23:11:05 no, i would prefer that base organizes that if requested by anyone 2019-03-26 23:11:06 I am ok with allowing everyone to vote in the extreme divisive cases, since those will not significantly affect project performance 2019-03-26 23:11:20 i also want to see base term-limited 2019-03-26 23:11:46 I have no problems with term-limiting base, though I'd rather we have more people chime in 2019-03-26 23:12:00 the issue with term limits is that once a term has passed, you need to find 3 more people you have near-absolute trust in 2019-03-26 23:12:10 you stagger the term limits 2019-03-26 23:12:13 (see: the python problem, took them a while) 2019-03-26 23:12:21 you still need to find SOMEONE you have near-absolute trust in 2019-03-26 23:12:24 that is hard. 2019-03-26 23:12:24 sure 2019-03-26 23:12:27 but only once 2019-03-26 23:12:32 per term... 2019-03-26 23:12:39 for the first 3 terms 2019-03-26 23:12:48 would you allow term-rotation? 2019-03-26 23:12:50 yes 2019-03-26 23:12:59 (aka A is on Base for a term, then A is off Base for a term, and then A comes back again) 2019-03-26 23:13:03 the point is if base is all powerful 2019-03-26 23:13:12 then somebody should not be able to hold a seat on base 2019-03-26 23:13:15 indefinitely 2019-03-26 23:13:34 Python shows that that can work out well, but I don't mind term rotations for the all-powerful Base 2019-03-26 23:13:35 but if you make base terms last for 3 years, and stagger them 2019-03-26 23:13:52 ok, that seems reasonable (though I'll still ask for further input) 2019-03-26 23:13:53 then you're only voting for one person each 'election' 2019-03-26 23:14:00 now, regarding project-wide EVERYONE votes cases 2019-03-26 23:14:11 my concern (as I've stated before) is effectively slowdown through DDoS 2019-03-26 23:14:20 how do we limit the volume of projectwide votes? 2019-03-26 23:14:35 base can say no to any request for a general resolution 2019-03-26 23:14:37 perhaps Base should have the power to decide that EVERYONE should vote on an issue, if it is brought up and is sufficiently divisive? 2019-03-26 23:14:40 just as in debian and fedora 2019-03-26 23:14:47 and the default to "base said no" is to have the admins vote, then? 2019-03-26 23:14:58 yes 2019-03-26 23:15:03 that sounds acceptable to me 2019-03-26 23:15:12 let me write this down and discuss with everyone tomorrow 2019-03-26 23:15:19 but i would prefer to limit each team to one admin, we can call them a "chair" 2019-03-26 23:15:29 no, multi-admin is done by design 2019-03-26 23:15:54 if your "chair" leaves, the team is in chaos until a new one shows up 2019-03-26 23:16:00 this makes everything more complicated 2019-03-26 23:16:06 I'm ok with limiting the max amount of admins 2019-03-26 23:16:09 (say 3?) 2019-03-26 23:16:12 sure 2019-03-26 23:16:14 that works for me 2019-03-26 23:16:19 okay, that works for me too 2019-03-26 23:16:41 i believe elections for 'base' should always be project-wide 2019-03-26 23:16:43 obviously 2019-03-26 23:17:03 this also ensures people who want to be on base have good reasons to be on base 2019-03-26 23:17:04 I agree, and it's rare enough that it shouldn't matter 2019-03-26 23:17:07 because they have to convince 2019-03-26 23:17:18 I'm against "campaigning" though. 2019-03-26 23:17:48 i'm not really in favor of that, but i do believe that people who are running to be on base 2019-03-26 23:17:57 should have a platform for people to consider 2019-03-26 23:18:11 if you want this power, what do you plan to do with it, etc 2019-03-26 23:18:26 the power should only be used when directly requested 2019-03-26 23:18:37 as such, if you plan to do something with it, I shall vehemently oppose that candidate 2019-03-26 23:20:51 well now that this proposal is effectively reworked to be a dissolution of core 2019-03-26 23:20:56 i am happier with it 2019-03-26 23:21:09 I care about the proposal (and the project) being as good as possible 2019-03-26 23:21:18 your suggestions have improved it, so I am happy ) 2019-03-26 23:21:39 let me make sure the list to discuss tomorrow is complete... 2019-03-26 23:21:56 1. Base can choose to have a project-wide vote on request, if request is denied the normal voting process happens 2019-03-26 23:22:02 2. Base elections are staggered (3 years) and are voted by EVERYONE 2019-03-26 23:22:08 3. People can come back for another term in Base after one election after them leaving 2019-03-26 23:22:14 does that seem complete, or did I miss something? 2019-03-26 23:22:46 Base can choose to have a project-wide vote on request OR if they deem it necessary 2019-03-26 23:22:53 ok, fair 2019-03-26 23:22:59 if denied, team admins are polled 2019-03-26 23:23:08 voting should be condorset-style 2019-03-26 23:23:16 where you rank options by preference 2019-03-26 23:23:17 yes, that's the "normal voting process" (re: team admin polling) 2019-03-26 23:23:33 ok, I'll add that, I don't have an issue (though I expect MOST votes to be yes/no questions) 2019-03-26 23:23:57 4. In the case of multiple-answer votes, they shall be done condorset-style (rank by preference) 2019-03-26 23:24:44 great 2019-03-26 23:25:00 I actually agree with all of these measures, so I'll try and get them in tomorrow 2019-03-26 23:25:09 if you like, you could be present, in case anyone has concerns 2019-03-26 23:25:37 (even if you aren't a part of the project, I (can't speak for others) value *everyone's* opinions (including ddevault and mps, neither of which are a part of the project as of now either) 2019-03-26 23:26:15 ah, right, 5. Max 3 admins per team 2019-03-26 23:32:39 [13:27:39] I think that kaniini was disgruntled well before this effort started, and not all of the arguments are founded in reason. They may have some other stuff going on 2019-03-26 23:33:19 my skepticism is based on years of failed governance, yes. but they do have reason, unfortunately i can't elaborate on those reasons because the data behind them is confidential. 2019-03-26 23:33:32 so much for transparency ;) 2019-03-26 23:33:40 i will just say that someone on core ran someone else on core out of the project 2019-03-26 23:33:55 I see 2019-03-26 23:34:05 and they remain on core to this day, even though they have an agreement with core that they will not "interact with other persons in the project" 2019-03-26 23:34:15 ah, and now I know what's going on 2019-03-26 23:34:48 well, I certainly denounce that kind of behavior, and it is my understanding that that is the reason we have a code of conduct now 2019-03-26 23:34:57 the CoC was created as a response to that incident 2019-03-26 23:35:03 I do have some issues with the current one, but I'd rather wait until the dust is settled from the current proposal to tackle that (if at all) 2019-03-26 23:35:34 the current proposal with the edits we have come to agreement on tackle it by eradicating core 2019-03-26 23:35:50 that depends entirely on how you view core, I think. 2019-03-26 23:36:02 well, core as we know it today, i should clarify 2019-03-26 23:36:16 core, the administrative entity remains - it simply contains elected positions, now 2019-03-26 23:36:24 it is also scaled way back 2019-03-26 23:36:28 core, the holder of main/ remains - it simply is called "packaging" 2019-03-26 23:36:33 yes, that was part of the goals, after all 2019-03-26 23:36:37 right now, core is a catch-all 2019-03-26 23:36:45 this means a bottleneck and lots of context switching 2019-03-26 23:36:50 and OBVIOUSLY has to be minimized 2019-03-26 23:37:14 still, I'm glad we could find compromises that we both agree on and that make the proposal better 2019-03-26 23:37:30 next step is to make sure no one else has (significant) problems with them, and we can then go and enact. 2019-03-26 23:37:34 well implementation of this policy will resolve concerns 2019-03-26 23:37:43 and maybe i will consider coming back to alpine when i have more time 2019-03-26 23:37:49 no worries :) 2019-03-26 23:37:58 I'm sure you'll be welcomed whenever you are ready (if ever) 2019-03-26 23:41:13 the other thing i would like to see is the policy proposal approved by all stakeholders 2019-03-26 23:41:23 instead of core deciding yes or no 2019-03-26 23:42:10 the issue there is with identifying and reaching stakeholders, as well as deciding what that even means (I can think of at least 3 interpretations off the top of my head) 2019-03-26 23:42:45 most people actually within the project are currently in the team listing, and core (now named "packaging") is the biggest one of them, with most unique entries 2019-03-26 23:43:18 further, the status quo *is* "core does all" right now, so that complicates things 2019-03-26 23:43:44 I would be ok with core approving a vote of all the currently listed members, once all concerns are rectified. 2019-03-27 01:22:40 latest iteration (with *everything* mentioned so far addressed) should now be live over at beta.docs.a.o 2019-03-27 01:22:48 now I'm really done for the day, though 2019-03-27 09:49:26 morning 2019-03-27 09:49:36 it seems like there have been progress 2019-03-27 12:39:12 yes, I believe k_niini is happy now 2019-03-27 12:39:17 and morning :) 2019-03-27 12:39:38 we managed to come up with modifications that do improve everything without sacrificing literally every goal 2019-03-27 12:40:20 I also can't think of much else to improve, except list of teams and their members, at this point, so I'd say this version could be a release candidate, with just any remaining concerns to address 2019-03-27 21:27:12 do you folks think it would be wise to wait until the governance restructuring is settled before trying to spin up the python work? 2019-03-27 21:28:06 normally, I'd say yes 2019-03-27 21:28:14 but... we've been trying to get at it for a month now 2019-03-27 21:28:28 I honestly think the current state is a solid release candidate (check it out :) ), but you never know what might happen 2019-03-27 21:28:44 I'd say that if by the end of next week we're not in the process of implementing it, you should probably start anyway 2019-03-27 21:29:00 alright, we'll see 2019-03-27 21:29:13 did you want me to give another round of feedback on the latest iteration, then? 2019-03-27 21:29:16 you can always move your stuff into the official fold, it's just a question of timing and difficulty 2019-03-27 21:29:18 sure, if you want 2019-03-27 21:30:25 well, I have things on my plate. But if you ask for my feedback, consider it an open offer to reprioritize my plate 2019-03-27 21:30:59 I think I covered everything discussed last time, and k_niini's suggestions shouldn't have affected that much 2019-03-27 21:31:06 so I don't think it's a high priority thing (given that) 2019-03-27 21:31:16 so if you've other things to do, absolutely feel free to do them first :) 2019-03-27 21:31:23 aye aye 2019-03-28 10:24:53 ddevault: i think it may have higher priority to get python3 updated to 3.7 2019-03-28 10:26:01 SpaceToast: i talked a bit with mort while i was in cambridge and he gave some useful (general) suggestions 2019-03-28 10:26:54 he also consulted one of his students who is an expert in the field 2019-03-28 10:27:42 one of the questions was if there was any example of opensource project that had a good org structure 2019-03-28 10:28:17 and ubuntu was mentioned as a good example 2019-03-28 10:28:53 even if they have a commercial company they have tried to keep the company org and open source org separated 2019-03-28 11:57:56 morning 2019-03-28 12:04:00 morning 2019-03-28 12:04:58 took a quick look at how ubuntu's organized 2019-03-28 12:05:16 I think that's severe overkill for us quite right now (e.g separation between technical and community boards) 2019-03-28 12:05:35 but with the current state of the proposal transitioning to a model like that wouldn't actually be *that* difficult, from what I can see 2019-03-28 12:06:14 looks like k_niini's and ddevault's suggestions combined got us a lot closer to that type of model than previously :) 2019-03-28 12:06:24 speaking of - did anyone have any further concerns? 2019-03-28 12:15:20 maybe this discussion should be moved to #alpine-devel where are more developers to hear their opinions 2019-03-28 12:17:25 they're doing *actual* work there ;) and I'm pretty sure there have been callouts/invitations on a semi-regular basis (e.g from _ikke_, before the meeting) 2019-03-28 12:18:00 also a lot of this goes through the ML as well (including the internal core dev one, based on the timing of k_niini coming in) 2019-03-28 12:33:26 Yes, I have some more thoughts on how to help us move this forward 2019-03-28 12:33:56 i think it would make sense to in the very beginning of the doc state what the goal is 2019-03-28 12:34:16 <_ikke_> And perhaps also what the goal not is 2019-03-28 12:34:29 define the scope 2019-03-28 12:34:44 yes, that may makes sense 2019-03-28 12:35:43 state what the goal of the organization is, and then list a few principles that are used to achive that goal 2019-03-28 12:35:59 hmm, okay 2019-03-28 12:36:10 the idea here is that a simple uncontroversial goal is somethign that can easily be agreed with 2019-03-28 12:36:14 that can be a simple-ish single section 2019-03-28 12:36:25 have everyone agree with that first 2019-03-28 12:36:33 I think the goal is to "make a good distribution", but we'd need to actually discuss that :) 2019-03-28 12:36:49 thats the goal of the alpine linux project itself 2019-03-28 12:37:21 actually i would like to have a separation between an "admin" board and a "technical" board, but maybe not now 2019-03-28 12:37:52 this type of concern is why I ended up agreeing with the suggestion to have a policy on how to update ... policies 2019-03-28 12:38:04 yeah 2019-03-28 12:38:17 the idea here is to find a common ground 2019-03-28 12:38:28 (point being that anything missing can be added anytime with a simple patch + vote) 2019-03-28 12:38:44 its difficult and time consuming start debate on the rules if not everyone agrees on the goal 2019-03-28 12:39:00 well, ddevault had that paste, right? 2019-03-28 12:39:16 i think that was the problems listes 2019-03-28 12:39:19 what I'm concerned about is that, say, 2 years down the line, we open ourselves up to someone showing up and saying "they don't look busy to me, let's nudo everything" 2019-03-28 12:39:20 but yeah 2019-03-28 12:39:31 s/nudo/undo/ 2019-03-28 12:39:53 we sort of have the project goal defined on alpinelinux.org already 2019-03-28 12:40:18 mhm 2019-03-28 12:40:41 I guess what I'm mostly saying is that I don't know if we necessarily need to do that as part of the bootstrapping process 2019-03-28 12:41:51 well, i think we should with a few sentences explain in the beginning what we are trying to achive 2019-03-28 12:42:16 because there will always be people who will disagree with specific rules 2019-03-28 12:43:23 but if that is because they dissagere with the overall project goal, then its fairly easy to say "sorry, you will have to find another project if you want achice that" 2019-03-28 12:43:59 right now we already have a few sentences that mostly talk about delegation of work etc.. 2019-03-28 12:44:03 do you have anything specific in mind? 2019-03-28 12:44:35 for example, i thnk one of the goals is to have a friendly community 2019-03-28 12:44:59 there have in the past been people who have disagreed with that 2019-03-28 12:45:12 I don't disagree with that, but I do find it... vague 2019-03-28 12:45:14 that we end up with better code if its a harsh environment 2019-03-28 12:45:29 different people operate under different definitions of friendly, for instance 2019-03-28 12:45:45 yes 2019-03-28 12:45:47 so I'm guessing you mean more abstract "overall" goals? 2019-03-28 12:45:53 correct 2019-03-28 12:46:02 the idea here is have abstract overall goals 2019-03-28 12:46:07 maybe that should go on a different page then ^^ 2019-03-28 12:46:11 perhaps the "introduction" section 2019-03-28 12:46:25 and a few abstract overall principles 2019-03-28 12:46:31 okay 2019-03-28 12:47:26 for example, a person who believes a harsh environment is good, will likely want have other rules 2019-03-28 12:48:09 and we could easily end up spend lot of time debating specific rules with a such person 2019-03-28 12:48:30 well, the obvious question becomes: how do we choose the project goals? 2019-03-28 12:48:39 who determines what they are? 2019-03-28 12:48:48 as per current document it'd be Base 2019-03-28 12:48:52 as per now it's unclear :) 2019-03-28 12:49:41 <_ikke_> Right now we have the core team 2019-03-28 12:50:26 brb 2019-03-28 12:57:34 at least there should be a short summary what we want achive at the top 2019-03-28 12:58:16 because we are presenting a long doc with lots of rules and asking people if they are ok with those 2019-03-28 12:58:34 well, the doc is split up into pages/sections now 2019-03-28 12:58:45 since the statement would apply to the whole handbook 2019-03-28 12:58:51 I think it should be in the introduction :) 2019-03-28 12:59:10 (otherwise we'd be duplicating it in a bunch of locations) 2019-03-28 12:59:24 but I find the content to be the bigger challenge right now 2019-03-28 13:08:37 +1 for friendly community goal 2019-03-28 13:10:08 another example, there was some strong opinion expressed that there should be no benevolent dictator for life, and tried to get that expressed in the rules 2019-03-28 13:10:33 and then there was another one thought we *should* have a dictator 2019-03-28 13:10:51 so, i want to take a step back and ask "why" 2019-03-28 13:11:02 I wanted a 3 person committee in the same role 2019-03-28 13:11:11 why dont we want dictator or why do want dictator 2019-03-28 13:11:20 why do we want a 3 person committe? 2019-03-28 13:11:31 hm, I have an answer 2019-03-28 13:11:34 what is the goal we want to achive with any of those 2019-03-28 13:11:36 but it's long-form and would be better for the ML 2019-03-28 13:12:02 i think the answer to most of those are fairly evident and relatively non-controversial 2019-03-28 13:12:10 as per the current proposal state, we have a 3-person committee, but they have terms 2019-03-28 13:12:26 so my question is why do the have terms? 2019-03-28 13:12:31 but you can repeat ad-infinitum (so we expect ~4 people to rotate, more or less, unless trust is broken) 2019-03-28 13:12:31 terms seems fine 2019-03-28 13:12:32 what is the purpose of that? 2019-03-28 13:12:34 is there a limit to the number of terms served? 2019-03-28 13:12:37 ah, cool 2019-03-28 13:12:41 no limit, but you can't replace yourself, basically 2019-03-28 13:12:48 so you take a 1 year break at the end of every 3 year term 2019-03-28 13:13:11 ncopa: in the scenario where Base breaks project trust, it's useful to have the ability to not re-elect them 2019-03-28 13:13:17 but why do we have terms? why cant you sit there forever? 2019-03-28 13:13:17 as opposed to have everyone abandon the project 2019-03-28 13:13:33 it means that in the worst of scenarios, the project will live on, more or less 2019-03-28 13:13:49 it's not expected to happen, but k_niini has a point that it could 2019-03-28 13:13:55 I could live without forcing members off of the committee periodically 2019-03-28 13:13:58 so the goal was to cover that possibility without incuring significant costs 2019-03-28 13:14:04 yes and i asked kaniini "why" 2019-03-28 13:14:13 I think the current solution is pretty good :) 2019-03-28 13:14:22 certainly after 3 years of leading the project you deserve a break anyways 2019-03-28 13:14:22 and if the goals could be expressed in a short principle 2019-03-28 13:14:40 for example "we want avoid power abuse" 2019-03-28 13:14:45 or similar 2019-03-28 13:14:48 I suppose the principle could be "project above individual power" 2019-03-28 13:14:54 successful project usually have BFDL even if 'he' is invisible 2019-03-28 13:15:06 ubuntu is an example of that 2019-03-28 13:15:26 mps: we have 3 BDs "for life with 1 year breaks every 3 years unless something goes wrong", per current proposal 2019-03-28 13:15:52 i dont really want discuss if we should have 1 onr 3 of them 2019-03-28 13:16:02 why break? 2019-03-28 13:16:22 i want to have the guiding principle behind the reasoning expressed 2019-03-28 13:16:22 well, first off, burnout is a thing (see: guido) 2019-03-28 13:16:36 avoid power abuse 2019-03-28 13:16:46 aboid depend on a single individual 2019-03-28 13:16:47 and secondly it gives an opportunity to "elect someone else" in the short run 2019-03-28 13:17:00 the 3 is for a non-single-person quorum, yeah 2019-03-28 13:17:17 I don't think it's so much "avoid power abuse" as it is "have the ability to deal with power abuse" 2019-03-28 13:17:23 another principle could be that it should be possible for any individual to leave without the entire rpject collapsing 2019-03-28 13:17:28 (power abuse will happen eventually no matter what) 2019-03-28 13:17:31 true! 2019-03-28 13:17:32 that's ok if he want or need a break, but he works quite fine he shouldn't be forced to 'take break' 2019-03-28 13:17:59 mps: he could be forced if he got sick. but i get your point 2019-03-28 13:18:24 so i want us to think about the underlying principles and goals 2019-03-28 13:18:39 group (3) could also abuse project as could one person 2019-03-28 13:18:41 as _ikke_ said earlier, we dont have an org just for the sake of having an org 2019-03-28 13:18:51 the org servers a purpose 2019-03-28 13:19:06 i want that purpose expressed 2019-03-28 13:19:23 ok, so do I draft it and we discuss the draft, or do we try to get an authoritative list? 2019-03-28 13:19:45 you can draft it and we discuss it 2019-03-28 13:19:48 ok 2019-03-28 13:21:05 the idea here is that once we have a set of principles and goals that we can agree on, its easier to discuss specific rules 2019-03-28 13:21:52 ideally we should have like 3 sentances for guiding principles 2019-03-28 13:22:00 3 or 4 2019-03-28 13:22:20 to explain my stance about BFDL, it could be one person, three or even five. And I don't think it should be 'set in stone'. It could be removed from a project if make a lot of harm to project 2019-03-28 13:22:44 who's gonna remove the highest authority within the project? :) 2019-03-28 13:22:54 terms make these events a lot less... traumatic 2019-03-28 13:23:01 sure, harm was done, so just wait out the term and don't re-elect them 2019-03-28 13:23:03 all developers by voting 2019-03-28 13:23:07 thats a thing that me and mort discussed 2019-03-28 13:23:26 so yes, we may want the ability to deal with that in place 2019-03-28 13:23:29 mps: so all developers vote, and the highest authority (which has the power to do that) says "no, invalid" 2019-03-28 13:23:58 if someone makes harm to project he should be removed ASAP and not wait term end 2019-03-28 13:24:00 I think terms don't have any significant downside (sure, you have to hold 1 election / year, but that's not so bad), but provide a non-traumatic implicit way to deal with such extreme cases 2019-03-28 13:24:08 i think the idea is to have the ability to do a "full community vote" that can overrul the highes authority 2019-03-28 13:24:13 mps: again, what you're suggesting is called "civil war", in normal terms 2019-03-28 13:24:39 that kind of activity is devastating to a project 2019-03-28 13:24:55 and likely will cause much more harm than waiting out a term with someone that abuses power at the helm 2019-03-28 13:24:57 SpaceToast: right, but sometimes 'war' is solution to remove bad actor 2019-03-28 13:25:10 unless you have a non-traumatic way to resolve the situation. 2019-03-28 13:25:27 so, the underlying principle is "ability to deal with power abuse" or similar 2019-03-28 13:25:32 yes 2019-03-28 13:25:37 there may be different ways to deal with it 2019-03-28 13:25:40 such events are usually traumatic 2019-03-28 13:25:40 not necessarily prevent it (that's not realistic) 2019-03-28 13:25:48 good point 2019-03-28 13:25:53 except that we, *right now* have a non-traumatic way to deal with it 2019-03-28 13:26:43 I still have a hope that most have good nature and such traumatic events are rare 2019-03-28 13:26:47 "this is usually bad, so let's do the bad thing instead of the less bad thing" seems silly, to me 2019-03-28 13:27:25 The purpose of the organization: "To build and maintain an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency." 2019-03-28 13:27:25 SpaceToast: you know this saying: perfection is enemy of good 2019-03-28 13:27:28 or something like that 2019-03-28 13:27:43 ok, so single sentence, followed by guiding principles 2019-03-28 13:28:03 also one of the comments I got from the field experts, was to not try cover every possibility initially 2019-03-28 13:28:23 yes, that's why we're not doing the whole "tech/community" board stuff 2019-03-28 13:28:28 we don't know if we need it 2019-03-28 13:28:37 ie not have rules to deal with every possibility 2019-03-28 13:28:42 but as ddevault said - if Base is compromised, the project is a write-off 2019-03-28 13:29:03 kaniini's suggestion is simply an easy way to deal with that situation that doesn't involve destroying the project, and has virtually no downsides 2019-03-28 13:29:12 (well, after we talked it over it became that, at least :) ) 2019-03-28 13:29:16 but we need a documented way to change the rules 2019-03-28 13:29:21 we have one 2019-03-28 13:29:24 yes 2019-03-28 13:29:29 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/update.html 2019-03-28 13:29:30 so that is in place 2019-03-28 13:29:35 yes 2019-03-28 13:29:44 those are the more important stuff 2019-03-28 13:29:46 the discussion with k_niini really made me realize how badly we need it 2019-03-28 13:29:58 which is kind of why I think the current set of rules is sufficient for bootstrapping 2019-03-28 13:30:10 yes, that was one of the more important things in kaniinis feedback 2019-03-28 13:30:14 but ok, let's make the project goal/principle section in the introduction, and link to it from the team org bit 2019-03-28 13:30:39 I expect I'll have it finished within ~5.5h 2019-03-28 13:30:57 so if you could take a look at my draft before bed (and give feedback in the morning) that'd be awesome ncopa :) 2019-03-28 13:40:08 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/voting.html#_base_vote 2019-03-28 13:40:28 this should also mention that the base team can choose to simply decide the matter without futher votes 2019-03-28 13:41:03 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/conflicts.html#_conflicts_between_a_subteam_and_its_parent 2019-03-28 13:41:14 this implies that the python team could chose spaces instead of tabs in APKBUILDs 2019-03-28 13:41:57 more reasonable would be that each project has the authority over its domain, and any question over what is and is not within its domain can be settled by vote 2019-03-28 13:42:36 not quite, the tabs-instead-of-spaces in APKBUILDs isn't a team thing, it's a project-wide policy 2019-03-28 13:42:38 more realistic example: maybe the python team thinks python packages ought to be built with different LDFLAGS from the rest of Alpine. It's uncelar if this is within their domain of decision-making so a broader discussion and/or vote may be called for 2019-03-28 13:42:45 unclear* 2019-03-28 13:42:45 to modify it, the python team would need to modify the policy document 2019-03-28 13:43:15 and yes, this is why updating the policy list is a thing you can do 2019-03-28 13:43:38 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/update.html 2019-03-28 13:43:43 >Do not squash commits 2019-03-28 13:43:45 re: Base deciding the matter, because of all the measures we have in place that sounds fine 2019-03-28 13:43:46 why? 2019-03-28 13:43:57 because the history of the evolution of the proposal is important 2019-03-28 13:44:05 squashing commits is pretty in technical things 2019-03-28 13:44:09 history is important in policy things 2019-03-28 13:45:02 on the other hand 2019-03-28 13:45:12 consider that if a proposal is squashed into a single atomic change 2019-03-28 13:45:20 each version of the git log represents a policy document that was once in force 2019-03-28 13:45:28 it's far too late for that ;) 2019-03-28 13:45:34 the discussion is preserved in the ML anyway 2019-03-28 13:45:51 also, policy documents are actually a part of a bigger thing (the developer handbook) which contains other non-policy content 2019-03-28 13:45:54 (well, *will contain*) 2019-03-28 13:46:11 there are technical solutions to that, if we care 2019-03-28 13:46:18 e.g. subtrees 2019-03-28 13:46:24 sure, it can be moved out etc 2019-03-28 13:46:32 let me put it this way 2019-03-28 13:46:55 I'm the person handling all the docs, and I would rather see the full history :) 2019-03-28 13:47:00 (regarding docs specifically) 2019-03-28 13:47:15 ACTION shrugs 2019-03-28 13:47:25 https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/short.html 2019-03-28 13:47:29 ultimately that's just another policy that can be changed 2019-03-28 13:47:33 I think this can be replaced with team-specific policy pages 2019-03-28 13:47:53 the policies section is for project-wide policies 2019-03-28 13:47:57 for which the barrier to entry for making changes is smaller (and decided by the team?), like not needing to call for a project-wide vote to change a python packaging policy 2019-03-28 13:48:00 (as opposed to per-team policies) 2019-03-28 13:48:08 then why do you have a policy here that only affects aports? 2019-03-28 13:48:18 because this is an existing historical project-wide policy 2019-03-28 13:48:26 I don't buy it 2019-03-28 13:48:31 ¯\_(ツ)_/¯ 2019-03-28 13:48:39 there's nothing historical about a new document 2019-03-28 13:48:41 do it right the first time? 2019-03-28 13:49:02 the initial document state (pre-all-the-changes) as discussed in the meeting was mostly codifying the existing structure 2019-03-28 13:49:06 which is the jumping-off point 2019-03-28 13:49:22 the goal of having these policies (as per ncopa) is to have some sort of consistency across the entire project 2019-03-28 13:49:32 tabs vs spaces was actually used as an example, with python being the case 2019-03-28 13:49:44 we actively *don't* want specific subteams overriding that, for the sake of project-wide consistency 2019-03-28 13:49:50 + it was always a project-wide thing 2019-03-28 13:50:05 (core and developers used to overlap a lot less) 2019-03-28 13:50:27 this just feels like writing the US constitution with a section making insider trading illegal 2019-03-28 13:50:32 like 2019-03-28 13:50:35 not the place for that policy 2019-03-28 13:50:42 important though it may be 2019-03-28 13:50:58 well, would you rather have a larger section saying "subteams may not overwrite this specific one"? 2019-03-28 13:51:03 under packaging-parent? 2019-03-28 13:51:09 that feels quite clumsy 2019-03-28 13:51:30 I would rather not document team-specific policy in the governing document for all of Alpine 2019-03-28 13:51:44 ncopa: any opinions? 2019-03-28 13:51:55 thing is, this *is* supposed to apply to all of alpine 2019-03-28 13:52:10 including the doc team? or infra? 2019-03-28 13:52:15 if we, at some point, have, say, "unofficial overlay" teams (e.g compatibility with adelie) that should still apply 2019-03-28 13:52:21 we'd better use tabs in /etc/postfix/main.cf :P 2019-03-28 13:52:24 if the infra write apkbuilds yes 2019-03-28 13:52:43 if the infra writes APKBUILDs they they're subject to the rules of the packaging team 2019-03-28 13:52:51 that doesn't make them someone else's rules 2019-03-28 13:53:15 since the packaging team is the authority over what gets into aports, anyone who wants to get into aports needs to follow the rules they set forth 2019-03-28 13:53:24 why does it need to be set at a higher level for that to hold? 2019-03-28 13:53:34 because more specific teams override less specific ones 2019-03-28 13:53:42 but that's done to allow for greater flexibility 2019-03-28 13:53:49 the issue is that we *don't* want to be flexible on that one thing 2019-03-28 13:53:57 (for the purposes of consistency) 2019-03-28 13:54:12 this is silly 2019-03-28 13:54:35 I don't think we can expect a mutiny over tabs any time soon 2019-03-28 13:54:52 why they should get special treatment just because we've been using them as a contrived example for debate is beyond me 2019-03-28 13:55:15 mutiny kind of implies breaking the rules; it wouldn't be breaking the rules if you straight up were allowed to do it 2019-03-28 13:55:29 I'm not saying that they should be allowed to do it 2019-03-28 13:55:57 I'm saying that this numbers equally among a thousand other rules we can and will apply to aports 2019-03-28 13:56:08 like requring a check() function or enumerating all of your makedeps correctly 2019-03-28 13:56:34 ok, so do we lose the flexibility of allowing subteams to override parent rules within their domain? 2019-03-28 13:56:45 in what cases is that flexibility called for? 2019-03-28 13:57:27 remember that from a philisophical sense 2019-03-28 13:57:36 packaging team has a rule that "if you have multiple slotted versions of a package, the generic one will refer to the latest one" 2019-03-28 13:57:36 all teams derive their authority from base 2019-03-28 13:57:42 so subteams exist at the pleasure of their parent teams 2019-03-28 13:57:49 lua team might want latest to mean 5.2 (even if 5.3 is available) for luajit compatibility 2019-03-28 13:57:50 as an example 2019-03-28 13:58:02 so let them 2019-03-28 13:58:03 s/latest/generic/ 2019-03-28 13:58:06 do we need a rule for that? 2019-03-28 13:58:12 but then they have to have the ability to override parental rules 2019-03-28 13:58:16 in a non-blocking manner 2019-03-28 13:58:31 rules are more like guidelines, use trust and best judgement to Do The Right Thing always 2019-03-28 13:58:36 if you have to check each parent's rules for clauses ala "this can/can't be overriden" that's slow 2019-03-28 13:58:41 and if someone is Doing The Wrong Thing, they've lost that trust and then we can invoke the policies for that 2019-03-28 13:59:01 people usually want to make sure they're doing the right thing 2019-03-28 13:59:15 explicitly allowing things (e.g X can override Y) means they don't even have to think about it, and can get to doing 2019-03-28 13:59:19 aye, but a simple discussion among the stakeholders will suffice 2019-03-28 13:59:35 ok, so we change the conflict resolution thing 2019-03-28 13:59:52 let me summarize more clearly what the root of my beef with this particular part of the document is 2019-03-28 13:59:54 parent policies override child policies; if a child wants a conflicting policy, they talk to the parent, and work it out amongst themselves 2019-03-28 14:00:08 back from lunch 2019-03-28 14:00:13 hey ncopa :) 2019-03-28 14:00:20 (1) teams should be self-governing, and set their own internal policies at their discretion 2019-03-28 14:00:38 (2) because teams have authority over their domain, external teams who want to contribute with them are naturally subject to their rules for contribution 2019-03-28 14:01:24 (3) the entire system is built on a foundation of trust, and letting things slide when it's the right thing to do is an important feature of that trust 2019-03-28 14:01:40 therefore: we needn't codify every detail in the top-level governance document 2019-03-28 14:01:49 and more specifically with respect to the current revision, 2019-03-28 14:02:45 it appears to subvert points 1 and 3 in favor of a more strict governance model, but achieving the flexibility afforded by these principles requires a convoluted policy that puts things in the wrong place and is more confusing 2019-03-28 14:02:52 2019-03-28 14:04:01 well, the goal of the convoluted policy (re: conflict resolution) was to codify 1 as to make any potential friction point resolution faster 2019-03-28 14:04:34 re ^^^ 2019-03-28 14:04:39 note that the governance of subteams is at the discretion of the first-class team per principle 1 2019-03-28 14:04:50 is sort of why i want the general principles and goals in place first 2019-03-28 14:04:56 makes sense :) 2019-03-28 14:05:00 so we dont spend time on debating spaces vs tabs 2019-03-28 14:05:29 as to how to resolve this; I suppose the Misc bit and the conflict resolution could be removed, up until we split teams (except Base, since their policies are project-wide) into their own pages 2019-03-28 14:05:46 but ok, let's do general principles and goals first 2019-03-28 14:06:01 I'd also strike the bit about subteams overriding parent team policies or whatever 2019-03-28 14:06:05 ncopa: I personally prefer spaces significantly over tabs; but it'd be very strange if my APKBUILDs different from all the rest :) 2019-03-28 14:06:16 ddevault: that's the "conflict resolution" bit, yes 2019-03-28 14:06:17 per principle 1 it's at each team's discretion to do this or some other model 2019-03-28 14:08:24 i was also thinking during the lunch, if it would be possible to stash away everything non critical, from the doc, and try have the real bare minimum there 2019-03-28 14:08:36 to avoud distraction for the important subjects 2019-03-28 14:08:49 ncopa: well, the doc's part of the developer handbook, which'll have a lot of other stuff 2019-03-28 14:09:07 but they'll be separated out in sections in the navigation menu 2019-03-28 14:09:31 im thinking the doc that we will end up vote/agree on 2019-03-28 14:09:48 mhm 2019-03-28 14:09:50 to bootstrap the org 2019-03-28 14:09:56 I've been kind of worried about how much it's been growing, yeah 2019-03-28 14:10:02 so 2019-03-28 14:10:10 (I was going to voice that concern re: guiding principles, but I suppose it makes sense) 2019-03-28 14:10:11 the problem you originally wanted to solve was to offload me 2019-03-28 14:10:24 I want(ed) to solve a lot more problems than that :) 2019-03-28 14:10:30 that's certainly one of them, though 2019-03-28 14:10:37 while writing down how to organize teams, you also touched how things are decided 2019-03-28 14:10:56 and who decides what 2019-03-28 14:11:00 we do need that, immediately after bootstrapping, though; just not the conflict resolution bit 2019-03-28 14:11:28 i think that is more important than what teams we have 2019-03-28 14:11:54 besides Base, sure 2019-03-28 14:11:57 what im thinking 2019-03-28 14:12:06 but we do already have existing teams (which it makes sense to codify/write down) 2019-03-28 14:12:12 but not make new ones pre-bootstrap 2019-03-28 14:12:34 we want have separate teams that can decide their daily work for themselves, and organize themselves 2019-03-28 14:12:46 to offload me, to help project move faster etc 2019-03-28 14:13:21 but since it also mentions who decides what, the question becomes bigger 2019-03-28 14:13:46 and i dont think we can just change the rules on who decides what without letting *everybody* know 2019-03-28 14:13:51 i mean, we probably can 2019-03-28 14:13:59 well we have to let EVERYBODY know anyway 2019-03-28 14:14:04 since it's a new governance model regardless 2019-03-28 14:14:07 but it could potentially blow up in our face 2019-03-28 14:14:10 yes 2019-03-28 14:14:22 so, in the end, this is a new governance 2019-03-28 14:14:35 having a system that can then walk on its own, rather than some strange crutch system should be preferable 2019-03-28 14:15:20 but I'm ok with trimming it down to make appraisal easier 2019-03-28 14:15:22 since we need present it to *everybody* i want avoid start discussions about details and rules 2019-03-28 14:15:25 (we already identified a few things to remove) 2019-03-28 14:15:43 ok, and the governing principles is a part of that, I'm guessing 2019-03-28 14:16:19 but if we lesta say only focus on the governance model first. the goal, the buiding principles behind the thinking (so far easy for everyone/majority to agree on) 2019-03-28 14:16:37 and only the rules for how decisions are made by who 2019-03-28 14:17:19 then we avoid discussions if the security team should have more people or tabs vs spaces 2019-03-28 14:17:25 etc 2019-03-28 14:17:38 i mean discussions in the full public with *everyone* 2019-03-28 14:18:09 well, that's already the case - we occasionally mention this happening on the ML and #a-d, and the channel is publicly logged 2019-03-28 14:18:19 anyone can come in and talk about it (e.g mps, ddevault, so on) 2019-03-28 14:18:35 (only if they know it's going on) 2019-03-28 14:18:43 that's why it's mentioned in the ML and #a-d :) 2019-03-28 14:19:17 anyway, so you'd rather remove the team definitions besides Base for now, ncopa? 2019-03-28 14:19:39 (I guess the advantage of doing that is it then becomes easier to add them as separate pages) 2019-03-28 14:20:01 but the thing has changed since i sent it to the current core team, so i can no longer say that the core team all voted "yes" 2019-03-28 14:20:18 yes, i think that may simplify the bootstrap process 2019-03-28 14:20:24 ok 2019-03-28 14:22:13 fwiw, in the long run i would actually want separation between admin lead and tech lead (committes, or dictator or whatever) - but that is another discussion 2019-03-28 14:22:51 theoretically speaking, Base is both 2019-03-28 14:23:09 but in practice, it's expected that Base will mostly do admin, and actual teams will be handling the tech parts 2019-03-28 14:23:18 so i think once we have established how we decide things, it should be easier to decide about the proposal about the teams 2019-03-28 14:23:25 mhm 2019-03-28 14:23:25 and faster hopefully 2019-03-28 14:23:30 aye... 2019-03-28 14:23:40 without needing to involve the entire world 2019-03-28 14:23:44 my vacation is ending (I'm back at work Monday, and I'm busy all of Saturday) 2019-03-28 14:23:59 so I'd like to get all the big edits done before then 2019-03-28 14:24:04 understand 2019-03-28 14:24:07 and good to know 2019-03-28 14:24:15 I'll obviously keep working on it (I wasn't on vacation last week, for example) 2019-03-28 14:24:28 but the speed at which I'll be able to do things will decrease relative to this week 2019-03-28 14:24:31 and yes, this is something that needs to be prioritized 2019-03-28 15:05:42 ncopa, ddevault: quickly applied the suggestions and drafted project goals and guiding principles (so we can start discussing and (if need be) modifying) 2019-03-28 15:05:57 do you have a diff handy? 2019-03-28 15:06:17 let me generate one real quick 2019-03-28 15:06:43 https://brpaste.xyz/raw/XaeIHA 2019-03-28 15:06:51 a lot of it is moving stuff around for organizational purposes though 2019-03-28 15:06:59 you can always look at the git log if you'd like 2019-03-28 15:07:05 link? 2019-03-28 15:07:09 https://git.alpinelinux.org/docs/developer-handbook/ 2019-03-28 15:08:22 ty 2019-03-28 15:08:56 nitpick: s/NOTE:// in 1efc2a9 2019-03-28 15:09:07 NOTE: TIP: etc are asciidoc admonitions 2019-03-28 15:09:10 oh, cool. 2019-03-28 15:09:13 they're there to *highlight* important parts 2019-03-28 15:09:17 aye, my mistake 2019-03-28 15:09:20 no worries :) 2019-03-28 15:09:25 one of the reasons I really prefer asciidoc 2019-03-28 15:10:23 would you like some editorial help boiling down the principles in b92a553 into a more concise & philisophical form? 2019-03-28 15:10:28 overall +1 to these changes 2019-03-28 15:10:41 sure 2019-03-28 15:10:45 I'm a writer, not an editor :) 2019-03-28 15:10:54 also, should "independent, non-commercial, general purpose Linux distribution..." also mention free software? 2019-03-28 15:11:04 (I actually have a good friend that helps me edit the stuff I write; I keep telling him to join alpine's doc team, but he doesn't want to right now; 2019-03-28 15:11:10 I suspect once we get this passed it'll be easier :) ) 2019-03-28 15:11:23 I just copy pasted what ncopa wrote 2019-03-28 15:11:32 I think it's directly from a.o's about page 2019-03-28 15:11:52 ah cool 2019-03-28 15:12:15 I wouldn't mind changing it, but I don't know if this is the time or place 2019-03-28 15:13:12 agreed 2019-03-28 15:13:56 what do you think of this? https://paste.sr.ht/~sircmpwn/0b9f0c12c6d058c19cb4db03cd4a01c2e9dfe5a2 2019-03-28 15:13:58 re: succinctness of the principles, I do do quite a bit of philosophy, but I mostly focus on epistemology and metaphysics; aesthetics is a bit out of reach ^^ 2019-03-28 15:15:01 I think there were some strong opinions re: a democratic approach (e.g see k_niini) 2019-03-28 15:15:16 I was trying to partially convey that as well through the "allow all members to influence the project" thing 2019-03-28 15:15:47 I think that influence is derived from the power to effect change and progress 2019-03-28 15:16:09 and the trust/respect/responsibility thing 2019-03-28 15:16:09 and with this phrasing it extends beyond members and into the community at large 2019-03-28 15:16:17 hmm... 2019-03-28 15:16:31 okay 2019-03-28 15:16:42 regarding that last one 2019-03-28 15:16:49 ideally, we'd like people to do the right AND written thing 2019-03-28 15:17:01 while I agree doing the right thing should have priority, 2019-03-28 15:17:07 we cannot possibly capture all of the right things into writing 2019-03-28 15:17:10 I'm not sure if that's how we want to word a guiding principle 2019-03-28 15:17:18 yes, but, consider someone with a misguided view of what is right 2019-03-28 15:17:22 and if we attempt it, we will probably capture many of the wrong things in writing 2019-03-28 15:17:28 defending themselves as doing the right thing, while wrecking everything 2019-03-28 15:17:37 well 2019-03-28 15:17:43 you have to convince everyone else that you're doing the right thing :) 2019-03-28 15:17:54 so now we're introducing additional "things to do" 2019-03-28 15:18:00 that's kind of why I prefer the "without fear" bit 2019-03-28 15:18:14 hm, not sure how that follows 2019-03-28 15:18:16 it encourages us to codify "yes, do that"s, and doesn't hit that potential problem spot 2019-03-28 15:18:33 ddevault: or, do right thing and don't try to convince everyone 2019-03-28 15:18:37 if you have to convince other people to not get punished, you might not do the obviously right thing, out of fear that others will disagree 2019-03-28 15:18:48 it's kind of a balancing act 2019-03-28 15:19:00 a punitive solution is almost never the right one 2019-03-28 15:19:10 working against the consensus is never the "right thing" 2019-03-28 15:19:19 it violates the mutual trust 2019-03-28 15:19:23 what if the consensus is that the earth is flat? :) 2019-03-28 15:19:36 if everyone on the project agrees that the earth is flat, then the earth will be flat 2019-03-28 15:19:42 there's no objective truth in this context 2019-03-28 15:19:48 alpine is a product of its people 2019-03-28 15:19:52 something something pilot wave theory ;) 2019-03-28 15:20:11 still, that opens things up to... funny scenarios 2019-03-28 15:20:16 that I'm not sure I like 2019-03-28 15:20:21 I mean, what I'm getting at is 2019-03-28 15:20:32 e.g taking something that does not work (in any way), and changing it in ways others don't like, but results in it actually working 2019-03-28 15:20:39 that seems like the right thing to do, even if the changes are not liked 2019-03-28 15:21:05 I don't think we can prioritise correctness over harmony 2019-03-28 15:21:17 it comes back to losing faith in the mutual trust and respect, which is the foundation upon which the entire system is built 2019-03-28 15:21:31 we trust each other to recognize the correct thing to do 2019-03-28 15:22:01 what I'd ideally like to do 2019-03-28 15:22:08 is to allow correctness to win without disrupting harmony 2019-03-28 15:22:23 I think it will 2019-03-28 15:22:27 but you're approaching the problem backwards 2019-03-28 15:22:39 if you have faith in the system of mutual trust and respect, then correctness will follow 2019-03-28 15:22:51 if you think correctness will not follow, you don't trust your peers 2019-03-28 15:22:59 (to be correct, or rational when their incorrectness is challenged) 2019-03-28 15:23:15 that this system is built on trust is an axiom of the system 2019-03-28 15:23:21 we needn't codify things which follow directly from that trust 2019-03-28 15:23:28 perhaps my life experience (and resulting personal philosophy) is getting in the way 2019-03-28 15:23:42 I trust individuals after they've proven themselves (to me), but I expect the structure to be decentralized 2019-03-28 15:23:51 I guess that's why we have team admins as contact points for inter-team comms 2019-03-28 15:23:53 the balance is why the base team is 3 highly trusted people 2019-03-28 15:23:56 so ok, I'll trust you :) 2019-03-28 15:24:13 we cannot place absolute faith in every member of such a large team 2019-03-28 15:24:26 so we establish a small group which is responsible for preserving the harmony 2019-03-28 15:24:34 and if we cannot trust them, we cannot trust Alpine Linux 2019-03-28 15:24:49 pushed 2019-03-28 15:24:56 (refresh with cache invalidation) 2019-03-28 15:24:58 ^^ 2019-03-28 15:25:08 I hope that I'm not being too pushy 2019-03-28 15:25:12 just expressing my personal feelings 2019-03-28 15:25:17 you can take them into account in any degree you wish 2019-03-28 15:25:24 there is no such thing as too pushy if your ideas are meritocratous 2019-03-28 15:25:33 at least, that's how I see things 2019-03-28 15:35:51 dropped a little patch in your inbox 2019-03-28 15:36:15 do you think separating the governance documents from the "developer handbook" would be wise? 2019-03-28 15:36:20 perhaps with a link to the former from the latter 2019-03-28 15:37:16 I think it could be a thing to consider later 2019-03-28 15:37:21 aight 2019-03-28 15:37:26 developer handbook to me seems like the evolution of the current developer wiki 2019-03-28 15:37:41 roughly the idea is to be like the user handbook ... but for developers 2019-03-28 15:37:46 and re: considering later 2019-03-28 15:37:53 this is why I moved things around (making new modules etc) 2019-03-28 15:38:00 modules are designed in a way as to make it easy to move them between repos 2019-03-28 15:38:09 gotcha 2019-03-28 15:38:35 so if we do wanna move it, it's basically "make new repo, copy over ROOT/Policies/Teams dirs; make new ROOT/index.adoc; modify antora.yml in both" 2019-03-28 15:38:37 and you're done 2019-03-28 15:39:53 re: my inbox patch 2019-03-28 15:40:25 I'd like to keep the phrasing identical to ncopa's for now for the first one 2019-03-28 15:40:32 and the second one explicitly came up, so I think it makes sense to keep it 2019-03-28 15:41:07 the phrasing already wasn't identical 2019-03-28 15:41:10 was it? 2019-03-28 15:41:18 I straight up copy pasted what he wrote 2019-03-28 15:41:25 oh 2019-03-28 15:41:28 so it SHOULD be identical to the letter 2019-03-28 15:41:32 unless my clipboard is spying on me!!!! 2019-03-28 15:41:39 what he wrote was adapted from https://alpinelinux.org/about/ 2019-03-28 15:41:42 yeah 2019-03-28 15:41:53 I just re-adapted it from the original source to better fit the format 2019-03-28 15:41:56 ¯\_(ツ)_/¯ 2019-03-28 15:41:56 certainly, we don't want to build and then abandon, so "maintain" makes sense to keep :) 2019-03-28 15:42:19 and regarding community 2019-03-28 15:42:29 the principles are supposed to reinforce the project goals 2019-03-28 15:42:43 + I find that trust/responsibility/respect don't necessarily imply friendliness 2019-03-28 15:42:58 I can respect someone without being friendly, and I can be friendly while having zero respect for someone 2019-03-28 15:43:28 I'll elaborate in a moment, brb 2019-03-28 15:43:28 I think I want to remove the trailing dots (or add them to the principles) though 2019-03-28 15:43:36 nw 2019-03-28 15:46:50 also for reference, I prefer patches be posted to brpaste.xyz (with a link ala brpaste.xyz/my_id?diff for review, so I can then wget brpaste.xyz/raw/my_id if I want to apply it) 2019-03-28 15:48:15 try mutt :) 2019-03-28 15:48:17 or lists.sr.ht! 2019-03-28 15:48:20 anyway 2019-03-28 15:48:32 building alpine linux is the goal 2019-03-28 15:48:35 a friendly community is the means 2019-03-28 15:48:44 a productive community is the means 2019-03-28 15:48:48 a friendly community is a separate goal 2019-03-28 15:48:54 I suggest applying the changes to the project goals heading and s/community/friendly community/ in the second section 2019-03-28 15:48:57 (again, something ncopa explicitly wanted) 2019-03-28 15:49:09 a friendly community is the goal of this effort, perhaps 2019-03-28 15:49:16 but the ultimate goal of alpine linux is to make alpine linux 2019-03-28 15:49:26 at least imo 2019-03-28 15:49:28 sure, and that's a project goal 2019-03-28 15:49:39 I'm going off what ncopa said, and he listed a friendly community as an explicit goal, though 2019-03-28 15:49:44 aight 2019-03-28 15:54:14 re: mutt; I find mutt's network code to be... questionable 2019-03-28 15:54:21 and my mail server doesn't have any push-capable keys 2019-03-28 15:54:29 I do have thunderbird but I'm far too lazy to go through that 2019-03-28 15:54:57 (I also take git-format-patch though!) 2019-03-28 15:56:10 also, taking over fish? really? :) 2019-03-28 15:56:27 I use fish, begrudgingly 2019-03-28 15:56:52 you may be interested in a project I'm working on with much less questionable network code: https://git.sr.ht/~sircmpwn/aerc2 2019-03-28 15:56:55 *somewhat less 2019-03-28 15:57:19 tell me when you think it's of beta quality, I'll be sure to check it out :) 2019-03-28 15:57:31 I have some... highly negative views of fish 2019-03-28 15:57:34 and bash for that matter 2019-03-28 15:57:42 but then again I have my own zsh framework 2019-03-28 15:57:43 then you'll probably appreciate another project I'm working on 2019-03-28 15:57:45 https://mrsh.sh 2019-03-28 15:57:55 I'm good ;) 2019-03-28 15:57:58 emulate -L sh 2019-03-28 15:58:11 ACTION shrugs 2019-03-28 15:58:21 eventually I'll be making the case for mrsh to become alpine's default shell 2019-03-28 15:58:29 I will probably fail in that effort! 2019-03-28 15:58:41 (I tend to use zsh for interactive usage, mksh for scripts whose portability I don't care about, and busybox ash (well, pure POSIX) for portable scripts 2019-03-28 15:58:52 note: busybox ash is not posix 2019-03-28 15:58:54 (mksh has actually been getting smaller since... might as well just use zsh, really) 2019-03-28 15:59:04 yes, what I mean is I write pure POSIX and interpret it with ash 2019-03-28 15:59:08 kk 2019-03-28 15:59:21 mrsh could replace ash for me (in that use-case) 2019-03-28 15:59:23 we've found a surprising number of bugs in dash while we've been working on mrsh, actually 2019-03-28 15:59:35 I'm quite aware that dash is... strange 2019-03-28 16:01:47 but yeah, I would suggest trying out zsh; the worst part is the initial config setup and how to manage a growing conf; and that's what my framework's for :) (https://github.com/5paceToast/toasty-zsh) 2019-03-28 16:02:04 I am familiar with zsh 2019-03-28 16:02:07 dislike it 2019-03-28 16:02:22 the perfect shell is strictly POSIX with a nice interactive mode ala fish 2019-03-28 16:02:31 and it's about 70% done :) 2019-03-28 16:02:40 so... fish, but everything fish stands against 2019-03-28 16:02:42 ;) 2019-03-28 16:03:02 zstyle and zsh's extended substitions/arrays are quite the thing though 2019-03-28 16:03:07 for interactive use especially 2019-03-28 16:03:43 for interactive use especially? dunno about that 2019-03-28 16:06:48 maybe I just do very weird things in interactive sessions on the regular 2019-03-28 16:07:05 (e.g I'll often omit writing a script, just define a 3 line function (that'd be ~15 lines elsewhere) and run with it) 2019-03-29 09:00:56 Morning. I just sent an email to the alpine-devel list with RFC on the project goals and guiding principles. 2019-03-29 09:02:16 This way we can filter out those who may want implement rules that goes for different direction early 2019-03-29 09:14:30 ncopa: 'Do the right thing over doing the written thing'. care to elaborate a little? 2019-03-29 09:16:03 to me this sentence looks fine, if I understood it correctly, i.e. good work is more important than written rules 2019-03-29 09:37:01 I’m afk at the moment. Personally I think that is a candidate to be removed or reworded 2019-03-29 16:40:51 you know, maybe I should ack too, as erm... redundant as that would be 2019-03-29 17:41:30 i should have mentioned that it was you that wrote it in the first place 2019-03-29 17:43:00 well, I technically wrote the first part, and ddevault the guiding principles (or rather, he adapted it from my first draft) 2019-03-29 17:43:06 you can see the first draft in the git logs though