K-T

>   + Rebasing history that has already been pushed is problematic.  I can
> see this for u/ branches, but it's more questionable for tickets/
> branches.  It messes up other people's history.

I thought:
a) we are now creating a "backup" branch through a hook
    on every rebase, and rebasing has been OK'ed/accepted,
    have I misinterpreted anything?
b) people are not supposed to base their work on other
    people's branches, so how does it mess up other people's
    history? (provided we are not overwriting history
    for master)

I guess we could switch to doing all messy work in u/
branches and push the final squashed and rebased version
to tickets/DM-*.


>   + You need to build and test after your rebase and cleanup.  You can do
> this after pushing your ticket but before merging to master (possibly
> using buildbot), or you can do the merge to master locally and test
> there before pushing the new master.  But assuming that the cleanup had
> no impact is dangerous.

Oh yes, I was only explaining the mechanics of doing the merging,
but indeed it might be useful to have a reminder about testing.


> 	I think "clean history" is somewhat in the eye of the beholder.
> I think the main way to maintain a useful history is to never merge from
> master/next/integration into a ticket branch.  Rebasing of the sort you
> have described seems to me to just avoid parallel branches, at possibly
> significant cost.

If we do the messy work in the next/integration branch,
I believe cleanly applying that work to master would be
a non-trivial job. But maybe I can be proven wrong.

My main goal is to find a way to keep it clean enough so that
we can always relatively easily track down what was done
when and how and by whom. With very convoluted history it
is getting exponentially harder with every messy merge.

Perhaps stop by tomorrow during Qserv Dev meeting?
We will discuss it there. Or maybe we want a DM-wide
discussion? Or maybe it is a SAT topic?

Jacek

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1