16:01 * csoriano wants to selflish switch gnome-software to GitLab just to
      could do this kind of explanations
16:03 <hughsie> csoriano, it's there already, just as a private repo
16:03 <hughsie> unoffical mirror so to spwak
16:03 <csoriano> oh, I didn't know if you actually started using it with
      jrocha or not
16:03 <csoriano> let me know how it goes so far for you both
16:05 <hughsie> csoriano, it's going 99% well
16:06 <hughsie> the 1% being the reason we can't switch to it
16:06 <kalev> weird stuff, let me try to debug this a bit
16:06 <hughsie> no "rebase and merge"
16:07 <csoriano> hughsie: right. My stance is quite clear about that one, I
      are going to have a meeting
16:07 <csoriano> I'm going to have a meeting with GitLab soon about that*
16:10 * mclasen has come around to liking merge commits
16:12 <hughsie> csoriano, sounds promising, thanks
16:12 <hughsie> mclasen, don't you find they clutter everything up?
16:13 <mclasen> once you let go of the idea of a linear history, its ok
16:14 <csoriano> hughsie: well, you can think of it as promising or as bad
      news :) let's see how it goes
16:15 <csoriano> hughsie: to be fair, I think our stance on clean git history
      + linear history etc is based on poor tooling we had have for so many
      years
16:15 <csoriano> I don't think git it's suposed to be looked at in "plain"
      view
16:15 <hughsie> csoriano, so i'm "holding it wrong"? :)
16:16 <csoriano> what does that mean?
16:16 <rishi> What is "clean git history"? Something other than "linear
      history"?
16:17 <csoriano> what I mean is that if you use some visual tooling like what
      GitLab or so I think non-linear is okaish
16:17 <csoriano> rishi: fixup commits
16:17 <csoriano> I call it that way for when I have meeting with GitLab xd I
      don't know how to call it differently
16:18 <ebassi> If you're doing your development in a branch — like you should
      — and you force push after every code review, you get around it
16:18 <ebassi> Alternatively, you can rebase locally and push before merging
16:20 <ebassi> Also because, even if GitLab adds rebase-and-merge, it won't
      give you autosquash, given that it's an interactive feature
16:20 <csoriano> ebassi: yeah, however there is an issue with comments and
      force push in GitLab, bsically because people seems to not use that
      "clean git history" much so it was not taken too much into account
16:20 <ebassi> So `fixup:` commits won't be squashed
16:21 <csoriano> yeah, so my point was for the review phase
16:21 <mclasen> rishi: a clean git history is one thats bisectable, imo
16:21 <mclasen> ie no broken commits in the middle, every step builds
16:22 <rishi> mclasen: Yeah, bisectable and somewhat sanely
      understandable. eg., hopefully 20 commits stepping towards a feature
      won't be squashed into.
16:22 <rishi> *into one.
16:23 <mclasen> but it is easy to get lost chasing a perfect history -
      diminishing returns kick in quickly
16:23 <fmuellner> rishi: ... or intermingled with 100 unrelated commits from
      master
16:24 <rishi> fmuellner: Yeah. I sometimes grep/search through the log with
      the bug number to avoid that.
16:24 <bochecha> about the rebase-and-merge option missing fro gitlab
      ce... there are settings for each project where you can say « in this
      project, MRs can only be merged if it's a fast-forward merge »
16:24 <bochecha> this way you ask submitters to rebase before you merge, and
      you get the clean history
16:25 <bochecha> and there's also a « in this project, MRs can only be merged
      if it's a fast-forward merge, but I still want the merge commit at the
      end »
16:25 <csoriano> bochecha: then a translation commit happens, now what? :)
16:25 <rishi> So, I guess, linear or not, a "clean history" is still
      desirable.
16:25 <csoriano> bochecha: you need to rebase again
16:25 <bochecha> csoriano: yes
16:25 <ebassi> csoriano: We need to talk to the gnome-i18n team and figure out
      a way to move all translations to a separate branch
16:26 <ebassi> As a matter of policy and tooling
16:26 <csoriano> that includes: asking the contributor, pray so no other
      translation commit happens or that you don't merge a different merge
      request in the meantime
16:26 <bochecha> rebasing before merge is a good idea anyway, it's the only
      way to know before merging that the CI tests what will actually be the
      result of the merge
16:26 <csoriano> but most importantly, asking the contributor to rebase
16:26 <rishi> csoriano: Or, the maintainer could rebase and merge him/herself?
16:27 <ebassi> Translations landing directly in master is… Problematic, at
      best
16:27 <csoriano> rishi: and then what? You cannot overtake the branch of the
      other
16:27 <csoriano> also, what's the point to have UI for that if we cannot use
      it?
16:28 <rishi> What do you mean, "then what"? Somebody submitted some patches,
      they looked ok, maintainer merged them.
16:28 <csoriano> rishi: you need to update the code in GitLab somehow no?
16:28 <csoriano> with your rebased branch
16:28 <rishi> Also, I don't write code inside a browser, so I am in the
      terminal anyway.
16:29 <rishi> Never mind. I am sure I am not thinking straight. :)
16:29 <csoriano> rishi: you are the reviewer here though, most probably at
      that point reviewing just nitpicks
16:29 <csoriano> rishi: I think you are just missing that you need to update
      the merge request at GitLab with your rebased branch somehow
16:30 <csoriano> otherwise, you push some code that is nowhere in GitLab
16:30 <csoriano> (rebasing changes commit ID's)
16:30 <rishi> If I am blocking on the contributor to do real code changes,
      then I am blocking.
16:30 <csoriano> rishi: no, just discussing the need to rebase before
      commiting, not actual code changes
16:31 <rishi> But if it is just a matter of a branch that's a bit stale and
      can be easily rebased, then I'd just do that and merge it; and not wait
      for the contributor to do so. That's a waste of time.
16:31 <csoriano> rishi: exactly. Now, usually for that you would just click
      "rebase and merge"
16:31 <rishi> csoriano: Yes, if it is a trivial rebase, the maintainer could
      do it.
16:31 <csoriano> it's a single button
16:31 <csoriano> but, you cannot do that right now because there is no
      "rebase" before the merge
16:31 <csoriano> so you have to rebase manually on CLI
16:31 <csoriano> you do that
16:31 <rishi> Single button or single command. I don't care much about the
      button.
16:32 <csoriano> the point being that, once you rebase locally, you need to
      update the code in the merge request too
16:32 <rishi> Unless I write code in the browser, I am already in the
      terminal, so ... *shrug*
16:32 <csoriano> so the changes are reflected and all the machinery for
      merging/accepting merge request/CI work
16:32 <rishi> What's "code in the merge request"?
16:32 <csoriano> rishi: a branch
16:33 <csoriano> the branch is outdated in GitLab, you need to update it
      somehow
16:33 <csoriano> and that branch is not yours, it's from a different user
16:34 <fmuellner> rishi: if you just take the branch and land it, then the
      link to the corresponding merge request is broken
16:34 <csoriano> anyway, probably very off-topic for this channel. Sorry all
16:35 <rishi> fmuellner: By link, you mean links in the commit messages? Or
      "link" in terms of the GitLab / UI?
16:35 <fmuellner> rishi: the latter
16:35 <fmuellner> mostly the information "the result of this discussion landed
      in these commits yadda yadda"
16:36 <fmuellner> you can manually close the merge request, but it will show
      up as "closed" rather than "merged" (as if the patches were rejected)
16:36 <rishi> Sucks, I guess. :) I am not familiar enough with GitLab to know
      if that can be worked around.
16:36 <csoriano> which implies quite a few of the integration stuff, like when
      looking at branches see that it was merged, having the merge requests
      marked as merged, etc
16:37 <rishi> Basically, I don't like this tendency of waiting for the
      contributor to do something trivial.
16:37 <rishi> Foo Bar didn't fix some white spaces, so users are experiencing
      crashy software.
16:37 <csoriano> rishi: yeah, that's I guess up to the ones pushing for GitLab
      to discuss it. At the end of the day, as you said, you should just
      either click a button or a single command in CLI
16:37 <rishi> Or Foo Bar didn't change some variable names, so nobody gets to
      use Nice New Feature.
16:37 <csoriano> yeah
16:38 <rishi> I mean sure, if we want to train a new contributor - that's
      fine.
16:38 <rishi> It is part of the onboarding - picking up good habits, etc..
16:38 <rishi> But there are lots of cases where the contributor isn't exactly
      new, and patches rot around because ... "process" (!).
16:39 <csoriano> exactly
16:39 <fmuellner> fwiw, this is really an issue with external branches - as
      long as it's some wip/ branch in the regular repo, any gnome dev can
      (force-)push to it
16:39 <fmuellner> including the maintainer to clean stuff up before merging
16:41 <rishi> csoriano: fmuellner: I guess I can't associate a different
      branch to a issue?
16:42 <csoriano> rishi: yeah you can. It's the concept of merge-request that
      has these issues
16:42 <csoriano> but merge request are the main concept, it's where
      discussions about the code happen
16:44 <rishi> I guess I need to play with it a bit more before saying anything
      further.
16:45 <csoriano> rishi: if you contributed on GitHub, it's mostly like that
16:47 <fmuellner> csoriano: even more ot - do we want some pattern to link
      commits to merge requests?
16:47 <ebassi> I'm positively shocked about the amount of GNOME devs that seem
      to be completely unaware of how github works, if I may be blunt
16:48 <csoriano> ebassi: I think we have a pretty good dev-chamber, not many
      people contributed to non-GNOME or non-phased-out softwares I guess
16:48 <csoriano> including me 
16:48 <ebassi> csoriano: "pretty good" is not the qualifier I would use
16:48 <csoriano> I contributed before to Motif than to any github repo, can
      you believe it? :D
16:48 <csoriano> oh yeah, good is not the word indeed
16:49 <csoriano> fmuellner: it's upstream somewhere, if you find it feel free
      to add it to #8
16:49 <rishi> ebassi: Maybe that says something about GitHub?
16:50 <rishi> Also, I am surprised about the number of GNOME developers who
      don't know a lot of other things. So what?
16:50 <ebassi> rishi: No, it doesn't
16:50 <mclasen> ebassi: you might call it insular
16:50 <rishi> Mileages vary, I guess.
16:51 <ebassi> "monoculture" would be an appropriate way to call it; "echo
      chamber", another :-/
16:51 <fmuellner> I doubt anyone is hacking on gnome because of bugzilla/cgit
16:51 <ebassi> It's worrying
16:51 <rishi> GitHub: the land of "Commit some code", "This makes Foo work"
      style project maintnenance.
16:51 <ebassi> rishi: That's a bad generalisation
16:51 <rishi> As I said, mileages vary.
16:52 <csoriano> I truly think there is a cultural difference, but not related
      to GitHub itself or so. It's more like fmuellner said, people that work
      on GNOME stuff and not interested on most software that lives in GitHub
16:52 <rishi> Your position doesn't seem any less extreme.
16:52 <ebassi> rishi: It means you're not contributing to anything outside of
      GNOME
16:53 <ebassi> Which means you're not exposed to other communities, and other
      projects
16:53 <ebassi> It also means you don't expose the GNOME ethos to other
      communities ;-)
16:54 <mclasen> some good stuff lives on github like systemd or flatpak
16:54 <ebassi> Not all free software communities/projects are garbage
      dumpsters on fire, even on big platforms like github
16:55 <ebassi> And some of them even have good things to teach to GNOME
16:55 <fmuellner> ebassi: but also: many communities/projects on github don't
      share more than the hosting platform
16:55 <fmuellner> that is, they aren't necessarily any less insular than gnome
16:56 <ebassi> fmuellner: Sure, but I expect GNOME developers to be good at
      outreach :-)
16:56 <rishi> ebassi: I get that you are in love with GitHub, that's ok.
16:56 <rishi> ebassi: You are also making assumptions about what I do or do
      not do, that's also ok. :P
16:56 <ebassi> And here we go
16:57 <mclasen> fmuellner: one aspect where they are crucially less insular is
      that everybody already has an account
16:57 <csoriano> mclasen: I think most importantly is, they know how-to to
      contribute
16:57 <ebassi> rishi: One day you'll be able to have a discussion without
      throwing stuff in people's face
16:57 <fmuellner> mclasen: good point
16:58 <csoriano> they contribute to Visual Code in the same way they can
      contribute to Flatpak
16:58 <mclasen> csoriano: not so sure about that - I mean, yes, the basic
      mechanics of 'make a pull request' are covered with a web ui
16:58 <mclasen> but understanding the project and the code well enough to
      create an acceptable pr is not any easier on github
16:59 <mclasen> and github makes it a lot easier to accept prs that fall short
      of that, which may be what rishi alluded to
16:59 <rishi> ebassi: I'll try to assume you didn't write that.
16:59 <csoriano> right. But you take the boring barrier. Suposedly
      understanding the code/writting it is the fun part
17:01 <mclasen> true