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


  20. Ash


  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


  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


  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


  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


  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


  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


  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