diff options
Diffstat (limited to 'meeting-logs/20170212.txt')
| -rw-r--r-- | meeting-logs/20170212.txt | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/meeting-logs/20170212.txt b/meeting-logs/20170212.txt new file mode 100644 index 0000000..50f4ba2 --- /dev/null +++ b/meeting-logs/20170212.txt @@ -0,0 +1,221 @@ +[00:00:00] - {Tageswechsel: Sonntag, 12. Februar 2017} +[20:04:38] <dilfridge> council meetin! +[20:04:45] <dwfreed> rich0: ^5 +[20:04:55] <dilfridge> so let's start with +[20:05:00] <dilfridge> 1) Roll call +[20:05:03] -*- K_F here +[20:05:03] -*- rich0 here +[20:05:07] -*- WilliamH here +[20:05:17] -*- ulm here +[20:05:39] -*- dilfridge here +[20:05:39] -*- jlec is still here +[20:06:26] <dilfridge> blueness: ping +[20:07:08] <dilfridge> does anyone want to text him? we can start in the meantime +[20:08:36] <dilfridge> ok sent him a text +[20:08:46] <dilfridge> anyway let's start +[20:09:03] <dilfridge> as far as I can see only one agenda point has been brought up +[20:09:13] <dilfridge> and sorry for not sending out an agenda, somehow fosdem came in the way +[20:09:15] <WilliamH> dilfridge: you mean glep 27? +[20:09:19] <dilfridge> yep +[20:09:24] <dilfridge> https://archives.gentoo.org/gentoo-project/message/0a21c4f6829ea34214169a96cacce931 +[20:09:42] <dilfridge> does anyone have an idea on what to do with that glep? +[20:09:57] <dilfridge> personally I dont like very much the implementation details in there, +[20:10:01] <ulm> that message starts at the wrong end +[20:10:13] <dilfridge> ulm: well, yes, that too +[20:10:14] <ulm> there should be an alternative proposal first +[20:10:24] <ulm> then we can revisit the old one +[20:10:24] <K_F> not sure if I agree on that +[20:10:31] <WilliamH> ulm: there was never an implementation of the glep either. +[20:10:44] <K_F> given that it hasn't been implemented, it seems clean to reject it before working on the alternative +[20:10:45] <dilfridge> ... but the general idea of a management of system user ids is a good one +[20:11:33] <K_F> I'm not convinced it can be done in a good way without having a centralized database, e.g LDAP +[20:11:35] <dilfridge> well, given that it's never been implemented we could put it back into draft status and ask for improvements +[20:11:44] <WilliamH> I would say either reject or defer it, what's the difference? +[20:11:55] <rich0> Conceptually there is nothing wrong with it. It just isn't much more than a concept. +[20:11:57] <jlec> What reason do we have to reject it? +[20:12:05] <K_F> defer sounds like picking it up later, reject would be clear statement +[20:12:15] <rich0> I think defer is a better word. +[20:12:16] <K_F> jlec: well, it not having been implemented is a good reason on its own +[20:12:38] <K_F> in order to provide a possibility for others to come up with a proposal that doesn't fight existing policy per se +[20:12:39] <rich0> If somebody wants to take it forward, great. If somebody comes up with a better alternative, that is also fine. Nobody should really feel bound to something so vague. +[20:12:44] <dilfridge> well, reject means "throw it away"... defer means "maybe in the future", which is weird for something that has already been accepted +[20:12:53] <dilfridge> (on paper9 +[20:12:56] <jlec> K_F: may or maybe not. Can be lack of technical detail or maturity, which is a reason, or lack of manpower which is not. +[20:13:11] <WilliamH> How did it get approved anyway, don't we require a reference implementation of a glep before we approve it? +[20:13:18] <dilfridge> heh +[20:13:20] <dilfridge> good point +[20:13:24] <K_F> jlec: well, the way I see it it is certainly incomplete +[20:13:59] <WilliamH> or am I confusing gleps with new eapis? ;-) +[20:14:04] <rich0> I think there was also an interest in Council guidance on the best way to actually go about it, if not GLEP 27. +[20:14:04] <dwfreed> WilliamH: reference implementation requirement is a relatively recent requirement +[20:14:15] <jlec> K_F: so that's a reason then +[20:14:19] <dwfreed> that GLEP is 13 years old +[20:14:40] <rich0> So, I think we're agreed on where we're going, just not exactly how to word it. +[20:14:40] <ulm> formally an accepted GLEP can only be replaced +[20:14:54] <ulm> it cannot go back to an earlier state +[20:14:55] <dilfridge> well, I agree that we'd need some central "database"... the question is where to put it +[20:15:05] <rich0> ulm: so, sounds like we need a NOOP GLEP then. :) +[20:15:12] <rich0> But, that seems silly. +[20:15:31] <ulm> no, what we need is a true replacement +[20:15:50] <ulm> I don't see what it would buy us to reject the existing one now +[20:16:01] <dilfridge> well +[20:16:01] <rich0> Well, either way it sounds like everybody can just ignore GLEP 27. +[20:16:38] <dilfridge> then we should probably make a statement like "improvement and alternatives to glep27 are welcome" +[20:16:45] <jlec> +1 +[20:16:46] <ulm> it's pending implementation, or it can be replaced by a successor GLEP +[20:16:54] <rich0> I think we just need to recognize the reality that the current one is vague and somebody could very well come up with something better, as we have no investment in GLEP 27. +[20:17:19] <K_F> dilfridge: rich0 works for me +[20:18:04] <rich0> Do we want to weigh in on any of the discussion? As far as alternatives go? +[20:18:22] <rich0> There was an agenda request: "Perhaps we could spur a discussion (unless there's a conclusion I +[20:18:22] <rich0> haven't found yet?) on this so maintainers know how to correctly deal +[20:18:22] <rich0> with UID/GID in ebuilds and openrc scripts." +[20:18:29] <ulm> it's all in bug 53269 +[20:18:31] <willikins> ulm: https://bugs.gentoo.org/53269 "GLEP 27 needs to be implemented (Portage Management of UIDs/GIDs)"; Gentoo Hosted Projects, PMS/EAPI; CONF; vapier:pms-bugs +[20:19:49] <rich0> Well, it isn't "all" in that bug considering we just had a recent mailing list discussion. +[20:20:35] <dilfridge> the old spec has mostly been a flop +[20:20:38] <ulm> s/all/most/ +[20:21:10] <K_F> I'm still wondering if we aren't trying to solve something using the wrong approach, if depending on specific UIDs they should be handled in a centralized user management, not expecting default values of a single distribution +[20:21:40] <ulm> IMHO even the problems to be solved haven't been clearly identified yet +[20:21:54] <K_F> ulm: that'd be part of the question, yes +[20:21:56] <dilfridge> K_F: I guess that's the difference between system and user accounts +[20:21:58] <rich0> So, I've already stated my thoughts on the list. +[20:22:07] <ulm> there's a lot of ideas, but not sure if everyone agrees on the goal +[20:22:10] <dwfreed> K_F: some (terrible) applications have hardcoded UID and/or GID expectations +[20:22:21] <K_F> dwfreed: still doesn't make it correct behavior +[20:22:22] <rich0> I think there are benefits in trying to standardize UIDs within a distro, even if they don't always end up that way 100% of the time. +[20:22:46] <dwfreed> K_F: practical vs correct +[20:22:52] <rich0> Centralized user management can be painful to handle on small scales, so not having to fight the distro on this front could be useful. +[20:22:56] <dwfreed> I tend to lean toward practical +[20:22:57] <K_F> rich0: isn't it more dangerous to believe a UID is fairly consistent than to realize it isn't and manage it if needed? +[20:23:11] <ulm> rich0: not sure if that's possible given that we have both linux and bsd +[20:23:15] <rich0> K_F: Sure, but managing it is painful, so why not minimize the amount of UID reshuffling? +[20:23:18] <dilfridge> fairly consistent is a good step towards consistent +[20:23:41] <dilfridge> if we have it fairly consistent now, we can target "consistent in x years" +[20:23:45] <K_F> rich0: that could be one argument for some form of standardization, yes; to make migration to a centralised system easier +[20:23:58] <dwfreed> one of the goals of GLEP 27 is to be able to identify the stale users you don't need anymore, so they can be removed +[20:24:05] <rich0> Every admin should always check that UIDs that need to be in sync are in sync, but I'd rather do that check and find that I need to remap 1 UID than find out I need to remap 15 of them. +[20:24:07] <K_F> rich0: but it sounds like having a proper way to do such migration, with appropriate tools and re-shuffling happening during process can be a worthy goal in itself, more than standardizing UIDs +[20:24:11] <dwfreed> K_F: I'm not going to set up LDAP for 5 servers +[20:24:12] <K_F> which can not be correct to begin with +[20:24:20] <dwfreed> even less so for 1 server +[20:24:43] <rich0> dwfreed: ++ +[20:25:13] <rich0> That is the issue. There are always better solutions like LDAP, kerberos, and so on. However, they incur a significant fixed overhead that is prohibitive in small deployments. +[20:25:36] <K_F> if that is an issue, should work on making it easier +[20:25:51] <dwfreed> LDAP and easy don't go well together +[20:25:55] <dwfreed> less so with kerberos +[20:26:35] <rich0> I'm not sure that LDAP even helps for things like bind mounts across containers. +[20:26:55] <dwfreed> even so, why do I need LDAP when /etc/passwd / /etc/group are just as good of a database for a single machine? +[20:26:56] <rich0> Sure, with nfs you can probably remap UIDs. +[20:27:10] <jlec> RedHats IdM around freeIPA is awesome. But still overkill for a single server +[20:27:43] <rich0> In any case, if you're creating an account it isn't like it costs you anything to at least check if the standard ID is available. +[20:28:08] <K_F> I'm more worried about an expectation of it being standard in the rest of a configuration +[20:28:43] <rich0> K_F: this seems a bit like requiring all future EAPIs to be GUIDs so that nobody assumes they're ordered. +[20:28:46] <K_F> in any case, its more food for ML discussion of an alternative implementation, GLEP 27 isn't very useful the way I see it +[20:29:17] <K_F> rich0: I'd say there is a difference of magnitude when it comes to, in particular, security considerations of those +[20:29:36] <rich0> yeah, i get your argument +[20:29:36] <K_F> and also interoperability +[20:29:54] <K_F> solving it in a gentoo-specific way vs something that works on a wider scope +[20:30:00] <rich0> So, then how about another analogy: +[20:30:06] <K_F> do we really want to isolate people to require only using gentoo if they start using it? +[20:30:25] <K_F> or allow a gentoo server or two and having twenty ubuntu laptops +[20:30:30] <rich0> Since we don't consistently close security bugs on time, we should deliberately leave vulerabilities in the tree so that users don't get a false sense of security. :) +[20:30:46] <dilfridge> (rolling eyes) +[20:30:57] <K_F> rich0: point is noted +[20:30:59] <rich0> K_F: nobody is suggesting that they HAVE to use the default UIDs. +[20:30:59] <dwfreed> GLEP 27 allows for the system administrator to override UIDs and GIDs specified in the profile through the normal methods +[20:31:13] <rich0> And software shouldn't be written to assume them. +[20:32:14] <rich0> Well, does that count as "discussion?" :) +[20:32:15] <dilfridge> in any case we won't be able to solve this during this council meeting +[20:32:33] <dilfridge> so what statement shall we make if any? +[20:32:49] <WilliamH> The core question here was to ask us to change the status of glep 27. +[20:33:05] <dilfridge> so ulm says it can only be replaced. +[20:33:07] <WilliamH> not bikeshed a solution for it. ;-) +[20:33:10] <rich0> I think we should make notice that GLEP 27 has never been implemented, so if somebody came up with something better it would not be viewed as a step backwards. +[20:33:16] <dilfridge> ++ +[20:33:34] <jlec> +1 +[20:33:40] <ulm> rich0: if it was inplemented then its status would be "final" +[20:33:42] <K_F> dilfridge: The council feels no strong commitment to GLEP 27 and is open to alternative solutions if somone wants to work on it... +[20:33:49] <K_F> and yeah, rich0++ above.. +[20:33:50] <dilfridge> do we need a vote on this? +[20:34:11] <K_F> probably not required formally +[20:34:12] <rich0> Sure, why not. Don't we get paid by the vote? +[20:34:16] <dilfridge> :P +[20:34:18] <dilfridge> ok, +[20:34:33] <K_F> if doing a vote, should have a specific text to vote for though +[20:34:40] <dilfridge> let's use the wording by k_f with slight modifications, +[20:35:15] <dilfridge> "Since GLEP 27 has never been implemented, the council is open to alternative solutions and improvements on the idea." +[20:35:27] <dilfridge> ok? +[20:35:38] <K_F> wfm +[20:35:43] <dwfreed> lgtm +[20:35:44] <jlec> me too +[20:35:47] <ulm> fine +[20:35:54] <dwfreed> (not that my statement matters much) +[20:35:56] <dilfridge> so, yes/no? +[20:35:57] -*- dilfridge yes +[20:36:00] -*- WilliamH yes +[20:36:05] -*- K_F yes +[20:36:31] -*- jlec yes +[20:37:09] -*- ulm yes +[20:37:11] <dilfridge> ulm: rich0 +[20:37:20] -*- rich0 yes +[20:37:22] <dilfridge> ok +[20:37:24] <dilfridge> thanks +[20:37:33] <dilfridge> this concludes that agenda point +[20:37:37] <dilfridge> next +[20:37:46] <dilfridge> open bugs with council involvement +[20:38:13] <dilfridge> there's bug 571490 which I'll finish when this /&%&/)&/ exam is done +[20:38:15] <willikins> dilfridge: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council +[20:38:30] <dilfridge> and there's bug 565566 +[20:38:32] <willikins> dilfridge: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs +[20:38:52] <dilfridge> does anyone know what the status there is? +[20:39:04] <dilfridge> the changelogs are somewhere but noone knows how to get or use them? +[20:39:21] <K_F> changelogs are in separate rsync location +[20:39:23] <dilfridge> (and noone is missing them either?) +[20:39:27] <ulm> rsync://rsync.gentoo.org/gentoo-repo-changelog +[20:39:46] <dilfridge> ok +[20:40:28] <ulm> and still wrong order there +[20:40:42] <ulm> i.e. oldest first +[20:41:19] <dilfridge> whoever cares enough should do the ping on the bug :] +[20:41:19] <WilliamH> Yeah, it was announced on the list, but I haven't heard much about anyone missing them. +[20:41:34] <ulm> my personal opinion is that it is quite pointless to have that rsync module +[20:41:48] <ulm> and also the checksums should be removed from manifest files +[20:41:59] <K_F> well, if anyone want to maintain it and it doesn't cause issues for rest of rsync sync, I don't really care +[20:42:02] -*- dilfridge agrees with ulm +[20:42:18] <WilliamH> ulm: are you advocating just dropping the changelogs? If so I agree. +[20:42:18] <dwfreed> the module is useful for offline changelog access +[20:42:34] <dwfreed> not everybody has internet access all the time +[20:42:59] <WilliamH> dwfreed: the thing is, that is a low-hanging fruit, I haven't heard a lot of people saying anything about it. +[20:43:03] <ulm> dwfreed: I thought we had solved that with git +[20:43:09] <dilfridge> I suggest just waiting another month if the changelogs magically revert order. +[20:43:09] <dwfreed> git is heavy +[20:43:26] <dwfreed> also the changelog module includes the CVS era changelogs +[20:43:41] <dilfridge> If not we can always apply another "polite ping" :P +[20:44:06] <dwfreed> bumping the bug is unlikely to get noticed; easiest method is to poke robbat2 on IRC directly +[20:44:34] -*- dilfridge thinks we just found a minion +[20:44:35] <dwfreed> leave him a !note, for example +[20:46:03] <WilliamH> totally unrelated question. Why are we still combining multiple repos to create the rsync tree? +[20:46:20] <ulm> are we? +[20:46:23] <dwfreed> yes +[20:46:31] <K_F> WilliamH: metadata generation, thickening, glsa +[20:46:32] <dilfridge> yes, news + glsa + ... +[20:46:40] <K_F> and yes, news.. +[20:46:41] <ulm> commit access +[20:46:45] <K_F> makes perfect sense to separate it +[20:46:51] <dwfreed> https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/rsync-gen.sh +[20:47:03] <ulm> non-ebuild devs should be able to commit news, or glsas +[20:47:06] <dwfreed> portage does not presently know how to pull those parts from separate places +[20:47:30] <K_F> would be inefficient even if it did +[20:47:37] <K_F> rather than synching on staging server +[20:47:46] <dwfreed> indeed, even if you tell portage to only sync certain parts, it still expects to find it in the main module +[20:49:16] <dilfridge> for anyone who wants to do that "manually", hasufell published a set of scripts on github that assembles it locally +[20:49:40] <dilfridge> i.e. pulls all the parts from git and arranges them +[20:50:03] <dilfridge> anyway, I think we're getting distracted. seems like we just wait another month. +[20:50:07] <dilfridge> next point: +[20:50:11] <dilfridge> open floor +[20:50:13] <dilfridge> anyone? +[20:50:34] <dwfreed> I'm the only non council member to speak during this entire meeting +[20:50:43] <dwfreed> and I don't have anything to add in open floor +[20:50:55] <WilliamH> heh +[20:51:54] <dilfridge> ... +[20:52:15] <dilfridge> nothing +[20:52:25] <dilfridge> with that, [bang] meeting closed |