Gajim - 2016-08-17

  1. deronnax hey buddy
  2. deronnax buddies*
  3. deronnax have you consider moving to github ?
  4. johannes deronnax: I proposed it and there are quite some people that are rather opposed to it. However I made up an inofficial mirror of the code here:
  5. deronnax I thibk this is really stopping contributor
  6. johannes However, there are also people who would like that, you are not the first to bring up these arguments
  7. deronnax like, I would love to contribute, if I do so it's on my free time, I have little time, so if it's on github I can do it because I know I'll spend most of my time coding
  8. vorner Is the problem hg not being git, or is it actually specific to the github vs. some other hosting?
  9. deronnax this is a big part of the problen
  10. deronnax this is a big part of the problem
  11. Link Mauve deronnax, use git-hg then, problem solved. :)
  12. Link Mauve I do the opposite, I use hg-git so I can use hg to interact with an upstream using git, it integrates perfectly in my workflow.
  13. deronnax not intested in/don't trust it
  14. Link Mauve Ok.
  15. deronnax plus, I guess you don't have the simple "submit pull request" like github
  16. deronnax the thing is, and I think i'm not the only : I'm very interested in Gajim, and very uninterested by its coding infrastructure (the bug tracker, the mercurial, the workflow)
  17. Holger The maintainer doesn't like GitHub, and he maintains Gajim in his free time as well.
  18. Link Mauve You have the simple "send a patch by email" like git, which worked long before github and will continue to work long after it’s gone.
  19. Holger I don't understand how people get so obsessed about GitHub-or-nothing.
  20. deronnax because time is rare and we only want to spend it coding, not getting used to something we won't really re-use outside of this particular project
  21. Holger If everyone tries to push his infrastructure preferences on others, collaboration won't work well.
  22. deronnax thanks god it doesn't have to happen because github won hands down years ago :)
  23. deronnax even CPython is moving to github
  24. johannes deronnax: were they not one of the main supporters of hg/mercurial aside from sun/oracle?
  25. Holger I don't think anybody is questioning that GitHub has a huge market share. Quite the opposite, I think some dislike the idea of moving to GitHub precisely for this reason.
  26. deronnax johannes, they were. they surrendered
  27. deronnax Holger, it makes sense for very big, famous project, like mozilla not to move to github, but for small projects like Gajim, it doesn't
  28. deronnax it just hold back people from contributing
  29. Holger If maximizing the number of contributions would be the only criterion when deciding on the infrastructure, then you'd probably be right.
  30. johannes As mentioned earlier, the good part with a DVCS is that one can have multiple mirrors and declare one authoritative but however sync the others and take contributions from there, using their mechanisms.
  31. johannes I used to propagate hg once too, for contribution and other purposes I would actually also prefer git to hg nowadays as well.
  32. Holger I use GitHub myself and I'm fine with it. I just think it's lame to come along and tell maintainers to how to do their job. Those who do the maintenance work decide how it's done.
  33. Holger johannes: Yes once there's others who also do actual review work, the situation is different of course.
  34. johannes As for issues there might be a point in one central repo. Something that actually also prevents me from using trac is the need for a separate account there. To remove that hurdle one could consider adding (GitHub) OAuth to the trac in question
  35. johannes Holger: as for the one pr that ended up in my repo, a non-asterix person actually did a review - kalkin
  36. johannes non-formal, but review and +2
  37. johannes we could even git Gerrit for free with the GitHub which is one of the better formal review tools
  38. Holger Sure if he and/or others are up to doing more review work then I'd negotiate any tools that might help with Asterix of course. That's quite different from coming along and telling people "hey I'm too lazy to look into your workflow so you move to GitHub NOW!".
  39. johannes Which is why either syncing issues or just taking the PR opportunity from GitHub might actually be a valuable starting point.
  40. Link Mauve johannes, my proposal is to add XMPP auth to trac, btw.
  41. Link Mauve It’s a pretty nice protocol, and doesn’t require people to create an account at any silo.
  42. johannes i have not yet heard about that procedure
  43. Link Mauve
  44. vorner I personally don't like github and one of the „features“ I dislike most is the web-based monster around merge requests. Not that I'd have any say in this, but just saying this might also be the stopping point.
  45. Holger You can handle them without using the web interface though.
  46. Holger Well the maintainer can. You can't submit them outside the web.
  47. Holger And no, I don't like the way PRs work, either.
  48. Link Mauve The two things I find absolutely terrible at github, are issues and pull requests.
  49. vorner Holger: But I still have to communicate through the interface if I want to discuss it with the requestor.
  50. Holger You can use email for that.
  51. Holger I mean GitHub supports that.
  52. Link Mauve Oh, and they also send me only every other email, so I have to poll their web interface manually if I want to be sure I didn’t miss something important.
  53. vorner Do I get to know the person's email through the interface?
  54. Holger Link Mauve: Really? I never noticed any lost comment.
  55. johannes nobody says anything on exclusivity of one procedure. Git is a DVCS. There are multiple ways to get to you goal, which could be processing a patchset. and a vast amount of people like the GitHub stuff, so why not provide them with that. and whoever does not like it, takes his/her personally preferred other way...
  56. vorner Also, they kind of don't support reasonable git hooks, but that's probably not the killer feature for most people.
  57. Holger vorner: No.
  58. Link Mauve Holger, it seems I’m alone with that issue, and their support was super-not-helpful.
  59. Holger :-/
  60. vorner johannes: This works on the side of the submitters. Not on the side of the maintainer.
  61. Holger With regard to issue tracking I seem to have little demands. Everyone hates most trackers with passion, whereas they all work okay-ish for me, including the GitHub one. The problem is the actual issues they track :-)
  62. Link Mauve Holger, as soon as I’ve said that I’m self-hosting my email service, they basically stopped communication.
  63. Link Mauve Telling me to check with my ISP.
  64. Link Mauve I’ve been self-hosting since 2007, changed IPs only once, I quite know what I’m doing.
  65. Holger "I checked with and they said: [...]"
  66. Link Mauve :D
  67. johannes That is indeed the point. Although I do actually find JIRA made by Atlassian to be the most commendable trade-off of suck with use among the trackers known to me, but that is just my personal opinion. As for the GitHub issue system: Yes it is actually bad in quite a few places, however it has the vast network and userbase of GitHub thus enabling network effects which are by far the most valuable part in GitHub...which probably is among the most interesting reasons why a lot of projects chose GitHub...
  68. Link Mauve johannes, both are non-free though.
  69. johannes that depends one one's defintion of free...
  70. johannes but as I said: the valuable part of GitHub is neither their software, nor the free/non-free parts of it but the userbase/platform/network effects. Which is why one probably wants to keep the authoritative repo somewhere else/self-hosted and just profit from the mentioned effects by means of a mirror...
  71. Link Mauve johannes, I’ve heard that argument so many times, by people asking me to use facebook, to use github, to use twitter, to use one of the myriad of smartphone-only or smartphone-mostly chat applications…
  72. mulles I will have time soon and do a list of sane defaults for the gajim UI, which can than be discussed. Would this be welcomed ?
  73. lovetox im testing gajim here on ubuntu 16.4
  74. lovetox menus are totally broken
  75. lovetox you cant even add a contact with unity