-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [21:00:16] * dilfridge has changed topic for #gentoo-council to: "Next meeting: Sunday, October 18, 2015 19:00 UTC | http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=0&sec=0 | https://wiki.gentoo.org/wiki/Project:Council | Agenda: https://archives.gentoo.org/gentoo-project/message/9b567a5ff7647a7991fdac4e166895d8" [21:00:29] !expn council [21:00:30] council = jlec,k_f,blueness,dilfridge,rich0,williamh,ulm, [21:00:35] meeting time!!! [21:00:39] -*- blueness here! [21:00:43] -*- jlec here [21:00:44] who's here? [21:00:46] -*- rich0 here [21:01:01] -*- ulm here [21:01:38] was k_f the one who couldn't meet today? [21:01:41] I know that K_F can't make it, anyone seen WilliamH? [21:02:33] bot sez he was around ~3 hrs ago [21:03:27] ok let's wait a moment, maybe someone can text him [21:03:45] so while we're waiting; did we finish the games business last week? [21:03:57] we did [21:05:00] mgorny: i thought we did until you said there was new information about fhs 3.0 [21:05:03] let's start [21:05:52] blueness: mgorny: we can always put it on the agenda again next time. for now we've removed the games user requirement. [21:06:09] -*- blueness remains silent, you're in charge [21:06:15] -*- mgorny too [21:06:29] 2) Github and attitudes [9] [21:06:37] [9] https://archives.gentoo.org/gentoo-project/message/4929c54fc37dee78cdff606d4d9cb030 [21:07:08] now this is a tricky one [21:07:31] here's my personal take [21:07:54] we should try as much as possible to keep the information from github also available outside github [21:08:28] which would mean e.g. a) publicly archiving notification mails, b) mirroring the pull request branches [21:09:08] but once that is done I see no big problem with github (it's one additional channel) [21:09:16] also https://www.gnu.org/software/repo-criteria.html has appeared in the mean time [21:09:27] AFAICS they haven't officially rated github yet, but from a quick glance I'd guess it will get an F mark [21:09:50] git.g.o too [21:09:52] dilfridge: this reminds me about the fight between vapier and flameeyes regarding attaching build.log's to bug reports [21:10:15] mgorny: why that? [21:10:38] mgorny: if something is wrong, we can always fix git.g.o to at least C [21:10:43] if git.g.o gets and F lets get it up to C [21:10:44] we can't fix github [21:10:50] ulm: gentoo.org promotes licesnse other than GPL3+ more than GPL3+ :) [21:11:07] well I like the idea of transparently mirroring pr's to bugzilla, just that ideally that would have to be both ways and I'm not sure that is feasible [21:11:20] so [21:11:27] huh, surely GPL-2 is good enough [21:11:33] ulm: nope - that's an F [21:11:37] as for notification mails, someone would have to mail github support first to see if they can fix their mails to reliably reach @gentoo.org [21:11:47] dilfridge: i would feel so much better if the pr's and discussion were mirrored to our github [21:12:04] right now i'm getting only some notifications. not sure if it isn't wiki-like behavior, i.e. one mail till you visit again [21:12:31] github does not support Tor so it will definitely get an F, it can't meet C3 [21:12:42] tbh, I find the requirement of GPL-3+ on there a bit silly, but then it's coming from the fundamentalists, so one should expect fundamentalist expectations [21:12:48] blueness: we can try to set up gogs to have _our_ github [21:13:13] awilfox: in what sense does it "not support Tor"? [21:13:14] Bircoph: how close to github would _our_ github be [21:13:21] dilfridge: git protocol [21:13:40] awilfox: won't that work over https with tor? [21:13:43] i doubt we really want hosting dozen copies of gentoo.git for people to randomly commit to [21:13:46] mgorny: let me say something right up front, i *love* github's workflow, i just wish it were in our control [21:13:48] blueness: close enough, we have a positive experience of running gogs for local projects [21:13:52] I've never tried it, but I think we're drifting [21:13:53] afaik Tor is only a transport layer, cant you run arbitrary tcp over it? [21:14:03] the https will work, yes, but the git protocol itself doesn't work and I don't remember why [21:14:12] plus what hasufell already pointed out, gogs doesn't work for big repos [21:14:18] it has something to do with the way github runs it, I hit this back in 2013 when doing some tor testing [21:14:24] Ok, so FSF hates git. :) [21:14:29] dilfridge: correct you can run arbitrary tcp over tor [21:14:30] lol [21:14:33] and i do [21:15:14] awilfox: one can use git over Tor, but only if exit node allows this protocol. Many exit points does not. [21:15:15] my sense of this is that people are going to use github unless there is a better alternative, which infra isn't ready to do right now. [21:15:21] mgorny: what can we mirror and what can't we mirror from github? [21:15:28] ulm and everyone else, so how serious should we take the fsf repo criteria? [21:15:30] So, I'm all for mirroring/etc and integrating as best we can. [21:15:43] blueness: purely theoretically, we can mirror everything exposed via API and git [21:16:00] which means commits, comments etc. [21:16:01] mgorny: okay practically what can we mirror? [21:16:13] IMO if we wanted to do things 100% the FSF way we'd have just used their social contract/etc instead of our own. [21:16:17] well, practical limitations would be: [21:16:23] I wrote a script that copies github (comments | wiki | issues | issue comments | PR | PR comments) to gitlab [21:16:28] not sure if that would help with gogs [21:16:34] 1. whether we want to mirror all the stuff people commit -- i.e. size, license issues etc. [21:16:34] dilfridge: not sure, I'm just saying that we shouldn't blame any dev if they refuse using github [21:16:42] I obviously support what they're doing, but Gentoo has always accepted compromises that FSF rejects (we're fairly similar to Debian on that). [21:16:52] 2. if people remove comments and stuff, we may be fetching too rarely to notice [21:16:55] mgorny: (i'm listening) [21:17:31] and that's basically the limitations, the rest is choosing a data format and writing the code [21:17:40] i don't think we need real time mirroring [21:17:42] comments etc. have unique ids, so we can even detect removals etc. [21:17:56] I guess another question I have is just how critical is it that all this stuff be accessible 20 years from now? If our mirroring is imperfect, what's the downside, especially if we're using bugzilla and infra in general for the most critical stuff? [21:18:06] we just need enough mirroring that if github goes away we didn't loose anything we'd regret [21:18:11] I thinnk we should listen to FSF, but not feel obliged to comply with their proposals [21:18:19] For example, if one of flameeyes's build logs available via http only goes away, will anybody even notice? [21:18:26] jmbsvicetto: +1 [21:18:32] jmbsvicetto: ++ [21:18:37] +1 [21:18:40] +1 [21:18:50] [Like] [21:19:17] I guess another question is what is a council decision even needed on? [21:19:21] blueness: but that was 'practical theory'. you'd have to find someone to implement that [21:19:45] Is the question "is it OK to mirror github to bugzilla" and so on - if so I think we're all leaning towards yes. [21:19:56] rich0: the question before the council is whether we can force devs to respect pull requests from github [21:20:05] If the question is "are devs obligated to use github and respond to stuff there" - I think that is more controversial. [21:20:11] blueness: define "respect" [21:20:24] i'm not sure if there's anything left to decide [21:20:24] rich0: read the last paragraph of the above email [21:20:26] What, specifically, are we asking them to do. [21:20:37] I can imagine the mirroring of the pullrequest git branches is rather simple, just that there the question of e.g. licensing or copyright issues may come up [21:20:44] rich0: From my reading, the council was asked to "force" developers to accept / support github. I respectfully suggest you should refuse to do that [21:20:45] rich0: this https://archives.gentoo.org/gentoo-project/message/4929c54fc37dee78cdff606d4d9cb030 [21:20:48] the initial idea was that all developers could use github and help people [21:21:03] but since that's not going to ever work, the current deal with reviewers team handling and proxying stuff seems to work well [21:21:19] I think we need to be careful in our wording. [21:21:34] this is the script I used to put github into gitlab, so yes, it is possible to mirror everything here: https://code.foxkit.us/snippets/1 -- depending on time constraints and what gogs' API looks like, I'd be willing to take a stab at doing the same. [21:21:52] If a bug gets mirrored to bugzilla devs shouldn't be closing it simply because it started on github. [21:22:05] I suspect most of us would support that. [21:22:08] rich0: sure [21:22:20] I think it gets fuzzier when it comes to duplicates/etc. [21:22:36] ok so let's first focus on that thing alone [21:22:37] In general though, devs shouldn't be just refusing to look at patches because they weren't submitted right. [21:22:39] mgorny: (this is not a question of defiance but one of principle) suppose I dont' want to respect a pull request from github against one of my packages, and i insist on it being discussed on bugzilla, what will the reviewers team do? [21:23:03] rich0: what about RESOLVED NEEDINFO? is that acceptable if the bug isn't self-contained? [21:23:05] reviewers try to get one of the maintainers to approve [21:23:06] rich0: exactly mirroring a bug and pr and patches is good [21:23:24] when someone tells he can't live without a bug, we tell the submitter 'sorry, you need to report a bug' [21:23:33] ulm: whether it is acceptable might be debatable, but it really seems stupid. Just what do we gain from ignoring information? [21:23:34] mgorny: okay i will not approve unless its discussed on bugzilla, now what? [21:23:41] I think we're having the tail wag the dog here. [21:23:55] We use bugzilla because it improves our communication. [21:24:12] rich0: no we are not the tail wagging the dog, we have to lead on this [21:24:22] If we are ignoring communication simply becuase it doesn't come in via bugzilla then we're choosing to distribute flawed software intentionally over a matter of what tools are being used. [21:24:37] blueness: I'm not saying that WE are the tail wagging the dog. [21:24:40] blueness: it's not my problem [21:24:46] i do my best to get PR merged [21:24:51] I'm saying that bugzilla is the tail wagging the dog of communication. [21:25:00] rich0: ah, okay [21:25:09] if you don't want to work with user, and user doesn't want to work with you, then it doesn't get merged [21:25:15] so far had no issues like that though [21:25:18] but we can say that this work flow is in violation of the social contract [21:25:36] blueness: in what way? [21:25:52] because that work flow depends on infra that is not in gentoo's control [21:26:02] Gentoo doesn't depend on propreitary tools. I don't think that means that Gentoo developers are forbidding from using proprietary software. [21:26:14] blueness: please also forbid us from using random pastebins [21:26:21] rich0: it's not so easy, but a question how to balance things against each other [21:26:24] mgorny: i understand the point [21:26:25] if devs have to waste time with using unusual communication channels, they cannot spend it on more important things [21:26:38] rich0: if patches (and pull requests) will stay purely on github, this will violate social contract [21:26:41] ulm: well, nobody is forcing them to do anything [21:26:53] Bircoph: who does? [21:26:59] if they will be duplicated on our infra and attached or linked to the bug, this is ok [21:27:02] Bircoph: there is no requirement to post patches in bugzilla, so how can posting them someplace else be worse than not posting them at all? [21:27:05] the developer who merges a patch? the developer who reviews it? [21:27:06] mgorny: its a question of dgree, small items i don't care [21:28:04] dilfridge: can i suggest we just table this issue because its a thorny issue and we won't really resolve it. we just won't decide anything and continue observing the FSF and listening to our developers [21:28:15] I think we need concrete proposals. [21:28:17] I dont think we should table it [21:28:18] rich0: yes, correct. But code should be on our infra. Bugzilla is not the only way. git mirroring will work too. [21:28:26] dilfridge: okay [21:28:28] I'm just trying to come up with a list of possible outcomes [21:28:47] as i see it, we'll waste the whole meeting on this and never get anything that satisfies everyone [21:28:52] nah [21:28:55] best case, we get a long list of tasks nobody's willing to do [21:28:55] so, [21:29:02] I'm not expecting to satisfy everybody :) [21:29:05] dilfridge: let's continute discussing [21:29:23] I'm not going to say that gentoo devs have to use github. [21:29:29] the mail is asking whether devs should be "advised" to cooperate with people using github [21:29:31] could we put it to the end of the agenda, and in the meantime solve solvable problems? ;-) [21:29:32] I'm also not going to say that gentoo devs are forbidden from using github [21:29:51] there are several ways how to formulate or implement that [21:30:01] So, if devs want to post their work there and other devs want to pretend that it isn't happening and just let their packages be buggy, well, I guess we're not going to stop that. [21:30:01] rich0: what was the decision wrt flameeyes build.logs, do you recall? [21:30:03] 1) no requirements on anyone [21:30:12] But, devs aren't required to fix bugs reported in bugzilla either. [21:30:31] blueness: was there decision at all? [21:30:33] If you log a bug against my pacakge I can leave it unread for 5 years. [21:30:42] 2) we ask devs to be cooperative, while at the same time requiring that as much as possible from github is mirrored [21:30:42] Unless it is security critical. [21:30:48] i thought it was more like someone implementing autoassigner and flameeyes ragequitting in the meantime [21:30:56] 3) we ask devs to be cooperative [21:31:19] Is anything preventing github from being mirrored today? [21:31:30] Does somebody need our blessing for infra to accept changes/etc? [21:31:36] mgorny: vapier was closing bugs with links to build.logs not attached to bugs as NEED INFO [21:31:42] gentlement please forget about Diego vs Mike, we don't have to pick the most childish behaviour as a base for decisions. [21:31:48] we decided that tinderbox was an exception [21:31:50] I think the council can try to remove barriers to progress at least. [21:32:00] dilfridge: sorry [21:32:29] It actually is a good analogy though. [21:32:40] now, from options 1-3, only 2 is imho viable [21:32:45] blueness / rich0: iirc, there was never a decision from council about the log attachment in bugzilla. There was a request for "common sense" [21:32:48] dilfridge: those three options can come with contigencies though, like 3) we ask devs to be cooperative IF .... [21:33:10] yeah which is what I mean with 2 :) [21:33:18] funny thing, nobody mentioned the social contract when we talked about having logs hosted on amazon [21:33:28] dilfridge: yeah true, i can be on board with 2 [21:33:35] I'm not sure what 2 actually is. [21:33:40] what do we mean by "require" [21:33:49] mgorny: if i'd heard about it i might have said something [21:34:25] I certainly want to encourage both cooperation and mirroring. [21:34:32] mgorny: logs << code + logs + discussions [21:34:32] rich0: i agree [21:34:39] I'm not really sure what the "or else..." clause is which the word "require" tends to imply. [21:34:44] ok how about this [21:34:59] I think we can be pretty much certain that github is not magically going away [21:35:21] in the sense of, within a few months people will still be sending pull requests [21:35:32] (not in the sense of long-term archival) [21:35:53] so [21:36:09] nobody here wants to switch off pr functionality, right? [21:36:30] which means we either stick with it, or stick with it and improve it. [21:36:47] so why not host repos ourselves, and allow people to pull from that? [21:37:15] blah blah gitlab blah packaging ruby blah [21:37:21] xiaomiao: I think that would be the ideal solution. The problem is that none of the existing FOSS tools are ones infra wants to support. [21:37:31] rich0: so fix infra [21:37:38] rich0: you are much more eloquent than me [21:37:39] and we can barely handle the services we run [21:37:44] see how slow bugzie, wiki is [21:37:45] all that is needed is *git* hosting [21:37:55] xiaomiao: no [21:37:57] xiaomiao: we already have git hosting [21:38:02] even with all javascript nonsense that slows things down, github is faster than our tools [21:38:13] we don't have git hosting for users, which is what GH adds [21:38:20] please no wiki bashing again [21:38:20] mgorny: so fix that [21:38:22] let me compare this for you [21:38:26] GH adds a lot more, like PRs/etc. [21:38:27] hardware is cheap [21:38:31] in github: you click two times, 5 seconds and repo done [21:38:32] Nice web guis and so on. [21:38:36] rich0: a PR is just a branch and a notification [21:38:42] xiaomiao: this discussion isnt about git hosting, it's about the user interface and the interaction [21:38:48] in infra: you open a bug which alraedy takes a few minutes and wait... then infra tells you on missing details and you wait [21:38:59] and right now, i'm probably the only person creating repos [21:39:13] i don't want having to create a few extra repos every day [21:39:26] and manually copying commits to avoid people pushing whole gentoo.git over and over again [21:39:27] dilfridge: you can drive GH from CLI [21:39:38] that's not the point. [21:39:43] maybe I am too stupid to see why it has to be complex [21:40:08] xiaomiao: we want to make it easier for people to contribute, not harder [21:40:10] the only reason i'm using github is because a lot of people use it [21:40:13] xiaomiao: you can just do all this stuff by mail list like lkml too, but the whole point is to have a web-based tool for people who don't want to work that way, which seems to be about 95% of them. [21:40:20] any gentoo-hosted solution is not going to be even half there [21:40:40] mgorny: so negative [21:40:54] I use github because I get paid for it [21:41:20] dilfridge: so make it easy for them to push a branch [21:41:31] and make it easy to get notifications [21:41:36] now what's left? [21:41:47] useful reviews [21:41:54] well, you're basically re-implementing this (-> gogs, gitlab, ...) [21:42:07] it is entirely possible to run gitlab on gentoo, I do, but let's just say.. 'bundle' has no equivalent to epatch_user, and some of those gems aren't happy on linux [21:42:16] This is a tangent, but part of me wonders if a solution is to try to get infra to focus on being able to run stuff outside of infra (like federated identity/etc). [21:42:18] and it's the easiest of a bad lot [21:42:36] rich0: or delegate [21:42:36] awilfox: not everyone is happy with go concepts either [21:42:47] -*- dilfridge bangs on the table, order please [21:43:06] the discussion about github software alternatives doesnt really get us ahead [21:43:22] suggestion [21:43:26] Agree, for now, though in the long term it might be the only thing that actually does get us out of this mess. [21:43:51] should we pass a motion encouraging mgorny's mirroring efforts + notification archiving + pr branch mirroring? [21:44:06] I'm fine with that [21:44:10] dilfridge: i'm no longer willing to do that [21:44:14] you have to find someone else [21:44:27] It doesn't have to mention him by name [21:44:40] it still needs someone to do the work though [21:44:59] rich0: i would then say that we actively discourate the use of github until such time as proper mirroring is in plac [21:44:59] Sure, but that is outside of our power other than asking. [21:45:14] blueness: I am not in favor of that [21:45:17] blueness: then we're losing over 15 contributors [21:45:29] mgorny: that's on your conscience then :) [21:45:32] who can do more than 2 complaining devs [21:45:50] mgorny: sorry until such time as we have proper mirroring then we loose the contributors and ask them to use bugzilla [21:46:04] blueness: assuming you can get 4 votes in favor... [21:46:12] let's ee [21:46:26] And I'd love to see you enforce it [21:46:28] plus a few devs quitting [21:46:39] why quit? [21:46:40] then the social contract is a joke [21:46:44] i'd call that the last nail to the coffin of gentoo [21:46:47] I still fail to see why we can't offer them some nice git hosting to push to plus email notifications [21:46:47] mgorny: that's everyone's own decision [21:47:02] why quit? why quit when council actively discourages accepting contributions in gentoo? [21:47:09] mgorny: devs quit over sunrise overlay [21:47:19] easy to find reasons [21:47:21] mgorny: no we encourage the social contract [21:47:37] no, you use social contract as an excuse for your personal wannabes [21:47:39] I'm just not seeing what the next step is besides "discouraging" [21:47:54] Are we going to start kicking devs who use it? [21:47:56] rich0: just that [21:48:16] no more, no "punishment" nothing, just that we frown upon the use of github until proper mirroring [21:48:32] a position in defense of the social contract [21:48:42] and those of us that want to ignore it can safely ignore it [21:48:47] well, I've stated my opinion, which is against that. but, I understand that this is a bit of a line we're waking [21:49:01] I won't force anybody to use github, but I'm not going to discourage contribution [21:49:08] i suggest we stop wasting time, vote and move on to doing something useful [21:49:22] i understand but i think the posiion of the council has to be behind the SC [21:49:30] -*- dilfridge is writing up a resolution proposal [21:49:33] blueness: I'm all for the SC [21:49:41] I just don't see this as being in violation [21:49:54] i think the interpretation i've forwarded does reflect a majority interpretation [21:50:22] dilfridge: I suggest we also vote on a proposal for encouraging the creation of mirrors/etc. [21:50:43] sorry this takes a moment [21:51:32] take your time [21:51:33] dilfridge: take youre time [21:51:40] lol ulm :) [21:51:44] :) [21:51:50] the only impatient here is my dog [21:52:06] who is begging for my attention [21:53:08] ok [21:53:12] here's a suggestion [21:53:26] The Gentoo council encourages contributions to Gentoo via manyfold ways. However, it also [21:53:26] recognizes that the usage of Github, being a closed-source service, poses the danger of [21:53:26] data lock-in and should not be preferred. [21:53:26] With this background the council asks for implementation of [21:53:26] * the two-way mirroring of Github pull requests to bugzilla (including comments and patches) [21:53:26] * the public archiving of Github repository e-mail notifications [21:53:26] * and the mirroring of Github pull request git branches on Gentoo infrastructure [21:53:26] Once this is achieved the council believes that the requirements of the Gentoo Social contract [21:53:26] are fulfilled. [21:54:07] I'd prefer breaking it up, so that I can actually vote yes to something. [21:54:14] But I'm not sure it will really change anything [21:54:33] dilfridge: i can support that, well put [21:54:43] If you want to vote on that, then we can do so. [21:54:53] more opinions? [21:55:07] rich0: you can always just voice your opinion instead of forcing a rewrite [21:55:24] ie what you agree with and what you don't and we can still vote the motion as a unit [21:55:28] blueness: trust me, I have no difficulties with voicing my opinion :) [21:55:33] dilfridge: if you're putting that proposal forward, I believe you should present as an option the implementation of comparable solutions [21:55:49] dilfridge: in effect, it says that the requirements of the social contract are currently not fulfilled [21:56:00] ulm: it actually dosn't say that [21:56:07] it says than when those things are done it is fulfilled [21:56:16] it doesn't say that they aren't fulfilled when they aren't done [21:56:31] It does say that it "should not be preferred" [21:56:37] "Once this is achieved the council believes" seems pretty clear to me [21:56:42] That is really teh strongest language in it. [21:57:02] ulm: I think the opposite. I'm actually thinking about voting yes [21:57:21] nevertheless, people are going to assume you mean that unless you say otherwise [21:57:24] --> _robbat2|irssi (nobody@gentoo/developer/robbat2) hat #gentoo-council betreten [21:57:30] I'd rather have it spelled out what we're voting on [21:57:38] reformulating [21:57:40] I'll happily say otherwise on the lists/blog/etc as soon as we finish voting if it passes :) [21:57:41] not some wording that is open to interpretation [21:58:05] yeah now i'd like to see clarificationtoo [21:58:25] fair enough - it gets us nowhere to just be back on this topic in a month [21:58:32] maybe you should vote whether this is breaking the social contract in the first place [21:59:06] because i see 2 devs saying that, and no more strong opinions [22:00:10] new version [22:00:12] actually a social contract is exactly that, it may even have legal standings, i was thinking of asking the fondation of having our lawyer look at it [22:00:13] The Gentoo council encourages contributions to Gentoo via manyfold ways. However, it also [22:00:13] recognizes that the usage of Github, being a closed-source service, poses the danger of [22:00:13] data lock-in and should not be preferred. Several developers have posed the question [22:00:13] whether the current usage of Github is in line with the Gentoo social contract- a question [22:00:13] open to interpretation. [22:00:13] With this background the council asks for implementation of [22:00:13] * the two-way mirroring of Github pull requests to bugzilla (including comments and patches) [22:00:13] * the public archiving of Github repository e-mail notifications [22:00:13] * and the mirroring of Github pull request git branches on Gentoo infrastructure [22:00:13] or functionally equivalent alternatives. The council believes that this should suffice [22:00:13] for all developers to dispell doubts about adherence to the Gentoo social contract. [22:00:55] i have a friendly amendment, if i may [22:01:00] sure go ahead [22:01:05] that sounds pretty good I think [22:01:08] While I'm fine with this wording, it still doesn't state that it is against the social contract [22:01:27] it specifically states it is open to interpretation, which means the council is specifically not saying it is or isn't [22:01:28] instead of "several developers" and using the active voice, use the passive, because we're not sure who's agreeing or isnt␈'t [22:01:50] which I think is probably the best phrasing as it keeps the temperature down so-to-speak [22:02:09] awilfox: i agree [22:02:38] new version [22:02:38] [22:02:42] The Gentoo council encourages contributions to Gentoo via manyfold ways. However, it also [22:02:42] recognizes that the usage of Github, being a closed-source service, poses the danger of [22:02:42] data lock-in and should not be preferred. The question has been posed whether the current [22:02:42] usage of Github is in line with the Gentoo social contract- a question still open to [22:02:42] interpretation. [22:02:42] With this background the council asks for implementation of [22:02:42] * the two-way mirroring of Github pull requests to bugzilla (including comments and patches) [22:02:42] * the public archiving of Github repository e-mail notifications [22:02:42] * and the mirroring of Github pull request git branches on Gentoo infrastructure [22:02:42] or functionally equivalent alternatives. The council believes that this should suffice [22:02:42] for all developers to dispell doubts about adherence to the Gentoo social contract. [22:03:08] yes [22:03:14] I'm fine with that [22:03:30] +1 [22:03:47] -*- dilfridge is fine with it too [22:04:23] was that a vote? [22:04:34] let's do it official [22:04:40] vote on the text above :) [22:04:42] -*- rich0 yes [22:04:44] -*- dilfridge yes [22:04:46] -*- blueness yes [22:04:55] -*- ulm yes [22:05:20] <_robbat2|irssi> (unofficial comment: [the above in an automated fashion]++) [22:05:43] jlec? [22:06:25] _robbat2|irssi: i'm glad your here, what do you think of this issue from an infra point of view [22:06:36] ok that's 4 yes, 2 absent, 1 AWOL [22:06:52] motion passed (but still happy to hear input from _robbat2|irssi :) [22:07:00] <_robbat2|irssi> blueness: it beats the alternative of running GitLab [22:07:15] understood [22:07:29] <_robbat2|irssi> the only piece that needs future work is real self-service repos for developers [22:07:47] _robbat2|irssi: I understand your concerns. I do think a strong FOSS alternative is actually the best long-term solution to the github problem for everybody though [22:07:58] yep and maybe even for "contributors" [22:08:05] the "diaspora problem" [22:08:20] so [22:08:30] dilfridge: i'm sorry but i can't stay much longer, if i leave that leaves on 3 [22:08:38] one hour has passed but at least we have nailed this pudding to the wall [22:08:56] [22:08:57] vote [22:08:58] yeah, this was the most contentious issue before us. [22:09:02] continue or next week? [22:09:18] next week please [22:09:21] -*- dilfridge next week [22:09:37] Granted, we really only kicked the can on this one. But, I think it was as much as we can do. I really do understand the concerns everybody has - I'm on the fence myself just on the other side of it. [22:09:37] -*- ulm continue [22:09:39] -*- rich0 next week [22:10:02] i'm sorry guys, i'll see you later [22:10:14] I guess this means next week. [22:10:23] thanks everyone, see you soon [22:10:40] -*- dilfridge bangs the gavel [22:10:43] meeting closed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJWJBieXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5XNgQAIbZJzPZekK59bFJNyIrfSjC Z9qO5f9d6D8vTtrHnxDXh8hWUjAg0p5VCxXmlD33yBTmXEnMFKCSvc255MgpvfdP Jow9Rx1/jrDe672T0FDrD76Lda7ia2EzCkAd1g+Qh11aEE0oQ7W7wcaIqLBW9LSB 2uUbsbShh11iaFsastSxiFdeZmKB8AcWuZOSi6l/MvCF37t8d3wHONM8kvwUKm8/ tDIdYzmbevL8AX4RxP3gw+w2NLPTMOFVkydDM+PBHS9YBR+Q3iLiWP9z/cD5zaIo 8RWLfHpNXmnOSo3FNAa2U4Vd//FYxHGbhb5LEfIa1J0WFjFQerwVks7ztg1vtEEB 9V6D7kkgJePolNi1D/xNYu7KPbnjKLwR0kPH6iSPLsmCqTFE9zoNVnihkVOPuDad Znga02CpKnFYvql8KEk/mY8o/Yp4HVriog8/L+4B/AHbyNbBQ/gD06kxu1B21zb/ kqacTaSWMskPRapF9Hp/+sAR7q2SjRU9c8G98c0y5t0axbj7pkMcK4SepYi3qzSe JZXeIDxLEYkucwLCgN9dTWBdqvSPY9oIMSgqJS5Rpt+nBc0JXlD0tlRNDgvfj0d6 hDjevQCubhQH5OAyivv1nT7LvMnKWcBqNFENhQWjyr1qPAplFG6UvNrfeZ1LPh8x 5YY+cW1DRDXAHH4roDOR =U+g7 -----END PGP SIGNATURE-----