XSF logo XSF Editor Team - 2016-01-05


  1. m&m has left
  2. SamWhited has joined
  3. winfried has left
  4. SamWhited has left
  5. winfried has left
  6. winfried has joined
  7. winfried has left
  8. winfried has joined
  9. winfried has left
  10. winfried has joined
  11. Ash has joined
  12. winfried has left
  13. winfried has joined
  14. winfried has left
  15. winfried has joined
  16. SamWhited has joined
  17. m&m has joined
  18. m&m hey all
  19. Kev o/
  20. Ash EHLO
  21. m&m sorry about the last couple of weeks, between holidays and sickness, I was not able to get online much at all
  22. m&m to me, it looks like PRs #126, #130, and #143 are simple editorial changes
  23. m&m we need to send notifies to XEP-0071 authors (Peter Saint-Andre) and XEP-0313 authors (Kevin Smith, Matthew Wild)
  24. m&m Ash: would you be able to do that?
  25. Ash Will do
  26. m&m we already got an accept for PR #130 so it just needs to be merged with an editorial rev
  27. m&m SamWhited: could you take care of that?
  28. Ash I had a question a while back: "What should we put in the 'initials' and 'remarks' for a revision which came from a github pull request?"
  29. Ash I think I was going to merge #130 at the time
  30. m&m for the <initials/>, put "XEP Editor({your initials})"
  31. Ash I suppose I was thinking it would be nice to mention the github user somewhere.
  32. m&m for the <remark/>, I summarize the change (almost always just the PR title), and put "({name of submitter})"
  33. Ash Cool :)
  34. m&m I try to find their real name, which is inline with how we've published XEPs in general
  35. m&m so for a pseudo template, that would be "{PR title} ({submitter name})"
  36. m&m also, be sure to squash/fixup the commits into one, or xepdiff can get confused
  37. m&m we really ought to take ownership of that, but I don't think any of us have time to really make that better
  38. Ash There's also PSA's mail to the editor list with updates for Jingle ICE. Happy to pick that up too.
  39. m&m yeah, I was about to take care of that myself, if you don't mind (-:
  40. Ash Go for it :)
  41. m&m or you can, whichever (-:
  42. SamWhited Sorry, had a conflicting meeting and apparently my phone wasn't receiving any messages; back now. Will look into PR 130
  43. m&m thanks Sam
  44. m&m just note the point about squashing into a single commit
  45. stpeter has joined
  46. SamWhited Do we actually bump the rev for typo fixes?
  47. m&m I think we do, yes … but it's a "patch" release (e.g., 0.7 -> 0.7.1)
  48. Ash It feels like we should always bump the rev for all changes
  49. m&m right
  50. stpeter I seem to have missed all the fun again
  51. m&m we've had this discussion before in this room … but can't remember how long ago
  52. Ash Don't worry - I'm just sending you an email, stpeter!
  53. Kev I think that any two pages claiming to be the same version of a XEP should be identical. So I think yes, bumping patch versions is right even for typos.
  54. SamWhited Makes sense
  55. Kev I think it was me who presented this argument before in a subtle, noncobative and eloquent way last time.
  56. Kev Or, possibly, I just shouted until everyone gave in. Readers can fill in the blanks.
  57. Kev *noncombative
  58. SamWhited Anyone know xnyhps's initials off the top of their head? I never remember what anyone's real name is if they don't actually use it
  59. m&m I believe xnyhps is Thijs Alkemade
  60. Ash https://github.com/xnyhps
  61. SamWhited Oh hey, profiles have real names on them, nifty. Thanks
  62. m&m well, usually (-:
  63. stpeter Ash: great!
  64. SamWhited Ah, found another spec he authored; (tpa)
  65. stpeter personally I think non-substantive typo fixes are OK in place, but I don't have the energy to fight on the matter
  66. SamWhited Merged
  67. SamWhited Ah, drat, I seem to have destroyed his ownership of the commit; oops. Oh well, he's credited anyways
  68. SamWhited Will pay more attention next time and make sure I'm just the committer
  69. Ash Might be good to have a crib sheet of git commands to do this kind of thing.
  70. Ash I get a bit lost with anything vaguely complicated in git!
  71. m&m SamWhited: it happens
  72. m&m heh
  73. m&m I've been using $(git rebase —interact master) for a lot of this
  74. m&m er .. —interactive
  75. SamWhited I generally just git merge --squash, but I forget that this loses history, I should really be maintaining authorship of the commit.
  76. m&m I think that's why I've been using interactive rebase
  77. Ash So XEP-0071 is draft. Do editorial changes need to go through council? I assume not…
  78. Ash thinks we had this discussion some time ago
  79. m&m As I recall, we worked out that they do not
  80. stpeter Ash: agreed on the crib sheet
  81. Ash git rebase means nothing to me!
  82. Ash I'm definitely XKCD #1597 when it comes to git!
  83. SamWhited I find that Git is pretty easy and the commands relatively straight forward, I just need to pay attention to what I'm doing :) yah, a rebase would have been better here.
  84. m&m although I don't want to re-start the DVCS flame war, I still wrap my head around hg better than git, but that's me
  85. SamWhited I don't especially care between the two when it comes down to it, but if I have to pick I choose Git every time just because it's more common, and if I'm nitpicking, HG has too many different branching models (branches vs. named branches vs. I forget the other two or three)
  86. m&m ok, I'll run the perseus-side commands in an hour or two, which should generate the requisite emails
  87. SamWhited What's perseus?
  88. Kev The web server.
  89. SamWhited Ah, gotcha
  90. stpeter I like the email format for pinging authors about changes - very helpful!
  91. m&m thanks!
  92. winfried has left
  93. winfried has joined
  94. m&m Ash: can you finish reving and merging PR #126, within the next 30 minutes or so?
  95. m&m I'm going to rev and merge PR #126 now
  96. Ash I was just doing that - although it's taken me flipping ages to figure out git rebase
  97. Ash It honestly makes no sense at all
  98. SamWhited Ash: What problems were you running into?
  99. Ash I have no idea what it does!
  100. Kev Oh, what it does is fairly simple :)
  101. Ash I think I've just about got a mgic incantation that does what I need it to
  102. Ash mgic = magic
  103. Kev Conceptually you rebase the current HEAD (top of the current branch) on top of some other commit.
  104. SamWhited Ash: rebase takes some commits, and moves them on top of some other (base) commits.
  105. Kev So it rewinds HEAD, putting each patch on to a stack until it gets back to a commit that your current branch has in common with the branch you want to rebase onto. Then it applies all the commits from the other branch, then it applies all the commits from that temporary stack.
  106. Kev (Well, queue, really, as it's in-order)
  107. Ash I've now got my master into the state I want - with a single commit from Thijs, but with my extra rev info
  108. Ash But I guess it's too late now!
  109. Ash Oh well
  110. Ash I think it's almost impossible to explain rebase. It's one of those things that probably suddenly just clicks.
  111. SamWhited With Git it's important to understand the basic concepts of the branch model first, and then rebase is really easy I think (at least, if you like thinking in trees)
  112. SamWhited It's just "break this leaf (or leafs) off and move it over to some other place and reattach it"
  113. Kev If you have two branches, B1 and B2. B1 looks like (commit list) A B C D 1 2 3 4. B2 looks like A B C D m n o p. You have B1 checked out. You say `git rebase B1`. It looks for the last common commit (D) and moves all the commits after that from your current branch off to the side somewhere (1234). Then it advances to the branch you want to rebase onto (B2), so now B1 is ABCDmnop. Then it applies the commits it put to the side. So now B1 is ABCDmnop1234.
  114. SamWhited Git is incredibly easy to explain on a whiteboard, and hard otherwise, I think.
  115. Kev Oh, I like that, I've never thought of rebase in terms of tree, I think of it in terms of rewinding and fast-forwarding and then applying patches.
  116. Ash I think I sort of get it. Thankfully it's something I generally don't have to deal with.
  117. Kev The tree branch thing is probably easier to explain :)
  118. Kev Ash: Only every time you use Git ;)
  119. SamWhited Kev: Yah, that always just confused me until I started thinking about it in terms of the tree model, but that may just be the way I think of things in general. Might be harder for some folks, no idea.
  120. Ash I've been using git for several years and haven't yet needed to use rebase...
  121. Ash Until today that is
  122. SamWhited Ash: It's not strictly necessary, but it helps keep history clean (if you care about such things)
  123. Kev Merges are evil :)
  124. Ash But i've generally not cared about what history looks like,
  125. SamWhited I'm with Kev, but a lot of people are completely against rebasing too *shrug*
  126. Kev It's actually not keeping history clean that I really care about for aesthetic reasons, but for reconstructive reasons.
  127. Kev With linear history you know 'trunk was this state. Then it was this state. Then it was this state'. Questions like "When did X get broken" stop making so much sense with merge.
  128. Kev And bisect is useful enough that risking merge breaking it is a big minus for me.
  129. SamWhited Git bisect is pretty much the greatest thing ever… the number of hours I've saved tracking down bugs with it is probably pretty huge.
  130. Kev I find it hard to disagree.
  131. stpeter has left
  132. Ash Thanks for the git lessons btw. I feel like I've learnt something.
  133. Ash So my time spent trying to rebase that commit wasn't entirely wasted!
  134. Ash I also found out that Atom does something weird to xep-0071.xml when you edit and save it, which causes git to pick up all kinds of changes (not sure if it's doing tab <-> space conversion or something)
  135. Kev It'll trim trailing whitespace unless you tell it not to.
  136. winfried has left
  137. winfried has joined
  138. stpeter has joined
  139. stpeter has left
  140. m&m wow, I missed a lot
  141. stpeter has left
  142. m&m has left
  143. Ash has left
  144. stpeter has joined
  145. SamWhited has left