XSF Editor Team - 2016-01-05

  1. m&m

    hey all

  2. Kev


  3. Ash


  4. m&m

    sorry about the last couple of weeks, between holidays and sickness, I was not able to get online much at all

  5. m&m

    to me, it looks like PRs #126, #130, and #143 are simple editorial changes

  6. m&m

    we need to send notifies to XEP-0071 authors (Peter Saint-Andre) and XEP-0313 authors (Kevin Smith, Matthew Wild)

  7. m&m

    Ash: would you be able to do that?

  8. Ash

    Will do

  9. m&m

    we already got an accept for PR #130 so it just needs to be merged with an editorial rev

  10. m&m

    SamWhited: could you take care of that?

  11. 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?"

  12. Ash

    I think I was going to merge #130 at the time

  13. m&m

    for the <initials/>, put "XEP Editor({your initials})"

  14. Ash

    I suppose I was thinking it would be nice to mention the github user somewhere.

  15. m&m

    for the <remark/>, I summarize the change (almost always just the PR title), and put "({name of submitter})"

  16. Ash

    Cool :)

  17. m&m

    I try to find their real name, which is inline with how we've published XEPs in general

  18. m&m

    so for a pseudo template, that would be "{PR title} ({submitter name})"

  19. m&m

    also, be sure to squash/fixup the commits into one, or xepdiff can get confused

  20. 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

  21. Ash

    There's also PSA's mail to the editor list with updates for Jingle ICE. Happy to pick that up too.

  22. m&m

    yeah, I was about to take care of that myself, if you don't mind (-:

  23. Ash

    Go for it :)

  24. m&m

    or you can, whichever (-:

  25. SamWhited

    Sorry, had a conflicting meeting and apparently my phone wasn't receiving any messages; back now. Will look into PR 130

  26. m&m

    thanks Sam

  27. m&m

    just note the point about squashing into a single commit

  28. SamWhited

    Do we actually bump the rev for typo fixes?

  29. m&m

    I think we do, yes … but it's a "patch" release (e.g., 0.7 -> 0.7.1)

  30. Ash

    It feels like we should always bump the rev for all changes

  31. m&m


  32. stpeter

    I seem to have missed all the fun again

  33. m&m

    we've had this discussion before in this room … but can't remember how long ago

  34. Ash

    Don't worry - I'm just sending you an email, stpeter!

  35. 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.

  36. SamWhited

    Makes sense

  37. Kev

    I think it was me who presented this argument before in a subtle, noncobative and eloquent way last time.

  38. Kev

    Or, possibly, I just shouted until everyone gave in. Readers can fill in the blanks.

  39. Kev


  40. 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

  41. m&m

    I believe xnyhps is Thijs Alkemade

  42. Ash


  43. SamWhited

    Oh hey, profiles have real names on them, nifty. Thanks

  44. m&m

    well, usually (-:

  45. stpeter

    Ash: great!

  46. SamWhited

    Ah, found another spec he authored; (tpa)

  47. stpeter

    personally I think non-substantive typo fixes are OK in place, but I don't have the energy to fight on the matter

  48. SamWhited


  49. SamWhited

    Ah, drat, I seem to have destroyed his ownership of the commit; oops. Oh well, he's credited anyways

  50. SamWhited

    Will pay more attention next time and make sure I'm just the committer

  51. Ash

    Might be good to have a crib sheet of git commands to do this kind of thing.

  52. Ash

    I get a bit lost with anything vaguely complicated in git!

  53. m&m

    SamWhited: it happens

  54. m&m


  55. m&m

    I've been using $(git rebase —interact master) for a lot of this

  56. m&m

    er .. —interactive

  57. SamWhited

    I generally just git merge --squash, but I forget that this loses history, I should really be maintaining authorship of the commit.

  58. m&m

    I think that's why I've been using interactive rebase

  59. Ash

    So XEP-0071 is draft. Do editorial changes need to go through council? I assume not…

  60. Ash thinks we had this discussion some time ago

  61. m&m

    As I recall, we worked out that they do not

  62. stpeter

    Ash: agreed on the crib sheet

  63. Ash

    git rebase means nothing to me!

  64. Ash

    I'm definitely XKCD #1597 when it comes to git!

  65. 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.

  66. 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

  67. 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)

  68. m&m

    ok, I'll run the perseus-side commands in an hour or two, which should generate the requisite emails

  69. SamWhited

    What's perseus?

  70. Kev

    The web server.

  71. SamWhited

    Ah, gotcha

  72. stpeter

    I like the email format for pinging authors about changes - very helpful!

  73. m&m


  74. m&m

    Ash: can you finish reving and merging PR #126, within the next 30 minutes or so?

  75. m&m

    I'm going to rev and merge PR #126 now

  76. Ash

    I was just doing that - although it's taken me flipping ages to figure out git rebase

  77. Ash

    It honestly makes no sense at all

  78. SamWhited

    Ash: What problems were you running into?

  79. Ash

    I have no idea what it does!

  80. Kev

    Oh, what it does is fairly simple :)

  81. Ash

    I think I've just about got a mgic incantation that does what I need it to

  82. Ash

    mgic = magic

  83. Kev

    Conceptually you rebase the current HEAD (top of the current branch) on top of some other commit.

  84. SamWhited

    Ash: rebase takes some commits, and moves them on top of some other (base) commits.

  85. 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.

  86. Kev

    (Well, queue, really, as it's in-order)

  87. Ash

    I've now got my master into the state I want - with a single commit from Thijs, but with my extra rev info

  88. Ash

    But I guess it's too late now!

  89. Ash

    Oh well

  90. Ash

    I think it's almost impossible to explain rebase. It's one of those things that probably suddenly just clicks.

  91. 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)

  92. SamWhited

    It's just "break this leaf (or leafs) off and move it over to some other place and reattach it"

  93. 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.

  94. SamWhited

    Git is incredibly easy to explain on a whiteboard, and hard otherwise, I think.

  95. 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.

  96. Ash

    I think I sort of get it. Thankfully it's something I generally don't have to deal with.

  97. Kev

    The tree branch thing is probably easier to explain :)

  98. Kev

    Ash: Only every time you use Git ;)

  99. 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.

  100. Ash

    I've been using git for several years and haven't yet needed to use rebase...

  101. Ash

    Until today that is

  102. SamWhited

    Ash: It's not strictly necessary, but it helps keep history clean (if you care about such things)

  103. Kev

    Merges are evil :)

  104. Ash

    But i've generally not cared about what history looks like,

  105. SamWhited

    I'm with Kev, but a lot of people are completely against rebasing too *shrug*

  106. Kev

    It's actually not keeping history clean that I really care about for aesthetic reasons, but for reconstructive reasons.

  107. 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.

  108. Kev

    And bisect is useful enough that risking merge breaking it is a big minus for me.

  109. 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.

  110. Kev

    I find it hard to disagree.

  111. Ash

    Thanks for the git lessons btw. I feel like I've learnt something.

  112. Ash

    So my time spent trying to rebase that commit wasn't entirely wasted!

  113. 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)

  114. Kev

    It'll trim trailing whitespace unless you tell it not to.

  115. m&m

    wow, I missed a lot