XSF Editor Team - 2016-01-05

hey all

o/

EHLO

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

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

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

Ash: would you be able to do that?

Will do

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

SamWhited: could you take care of that?

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

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

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

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

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

Cool :)

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

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

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

we really ought to take ownership of that, but I don't think any of us have time to really make that better

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

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

Go for it :)

or you can, whichever (-:

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

thanks Sam

just note the point about squashing into a single commit

Do we actually bump the rev for typo fixes?

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

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

right

I seem to have missed all the fun again

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

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

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.

Makes sense

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

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

*noncombative

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

I believe xnyhps is Thijs Alkemade

https://github.com/xnyhps

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

well, usually (-:

Ash: great!

Ah, found another spec he authored; (tpa)

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

Merged

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

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

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

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

SamWhited: it happens

heh

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

er .. —interactive

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

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

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

As I recall, we worked out that they do not

Ash: agreed on the crib sheet

git rebase means nothing to me!

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

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.

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

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)

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

What's perseus?

The web server.

Ah, gotcha

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

thanks!

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

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

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

It honestly makes no sense at all

Ash: What problems were you running into?

I have no idea what it does!

Oh, what it does is fairly simple :)

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

mgic = magic

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

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

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.

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

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

But I guess it's too late now!

Oh well

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

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)

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

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.

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

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.

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

The tree branch thing is probably easier to explain :)

Ash: Only every time you use Git ;)

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.

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

Until today that is

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

Merges are evil :)

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

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

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

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.

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

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.

I find it hard to disagree.

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

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

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)

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

wow, I missed a lot