Review Request: Make KAuth ready for frameworks + API Changes

[Stephen Kelly]

Now I'm confused.

>> Stephen Kelly wrote:
>>     It was rebased onto some relatively recent commit, but not the tip of
>>     the branch.

You disagreed with what I said:

>  - Given that the branch was rebased on top of the last frameworks' commit
>  (as you can see from the log), 

... actually I don't see that in the log. Here's what I see:

http://i.imgur.com/xhbCC.png

Do we have a difference in definitions, or is something else causing the 
confusion?

> - Last but not least, looking just at the merge commit shows you the full 
diff the branch introduced - in such a case, for example, is incredibly 
useful to track all of the API changes at once. Yes, you could have used git 
diff <merge commit> <first commit before the rebased branch> and it would 
have had the same effect, but the approach is more clean

I tried this with gitk and git show. Neither worked as you describe.

> Starting from the point that this discussion is mostly about one's own
> taste (and again, that's why we NEED a clear policy), my reason for doing
> this is that:

Policies won't help. 

Only technical measures like not accepting pushes with merges, except 
between release-lines (master, 4.8 branch etc) would work, if such a thing 
would be decided on, or if your workflow became policy, only accepting 
pushes with only merge commits on release-line branches. 

I doubt such a thing could be both decided on though. I can imagine what the 
hook would look like in both cases.

More importantly though, you seem to have broken the frameworks branch.

For example (there are other breakages) 
046123dcd8f0f9b900ed1d694e7bbb9f21549ade breaks the build because 
earlyAuthorize has been removed and you didn't port the users of it in the 
frameworks branch away from that API.

Could you do the port and push a commit fixing the build of the whole 
frameworks branch? I guess maybe until now you have only compiled KAuth or 
somthing.

Thanks,

Steve.