Re: [HTCondor-devel] Possible corruption in V7_9_2-branch

[Nathan Panike <nwp@xxxxxxxxxxx>]

On Mon, Nov 26, 2012 at 03:03:32PM -0600, Todd Tannenbaum wrote:
> On 11/26/2012 1:56 PM, Nathan Panike wrote:
> >Karen,
> >
> >I was addressing the question of whether code from master was improperly
> >merged into V7_9_2-branch.  My simplistic answer was "no", since the code
> >in question is also on V7_8-branch.  A broader question is whether the
> >code "should not" have gone into V7_9_2-branch, and then the answer is
> >"yes", because it was not authorized by the wrangler.
> >
> 
> Karen was simply merging from stable to V7_9_2 to master, since she
> made changes in stable that are required in V7_9_2.  Her changes
> were authorized to go into the release branch.  All the other cruft
> below came along for the ride.

It would have been easy enough to do:
$ git checkout V7_9_2-branch
$ git cherry-pick c3fd5f68744c

and avoid pulling all the cruft in.

> 
> I think the fundamental problem is identified by Dan below: we run
> into these problems when code goes into the stable branch that the
> we do not merge through a developer release branch.  This happens if
> the wrangler says "no" (seems very rare... why wouldn't the wranger
> want critical code reviewed bug fixes), or happens when our merge
> path at
>   https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=SourceCodeBranches
> is not followed for whatever reason. Aviary exasperates the problem,
> since it sees many commits on the stable branch.

TJ has been adamant about not pulling stable into developer release
branch, mostly because of Aviary.

I would just like a clear policy to implement in code. The current
policy---which is not really a policy at all---where code is sometimes
merged through the release branch and sometimes not, is simply not
something that can be observed by a computer.

+1 to the idea where the the release branches are locked down, and the
wrangler cherry-pick's commits onto them.

> 
> Todd
> 

Nathan Panike

> 
> >It appears your merge pulled more into V7_9_2-branch than you intended:
> >$ git diff-tree -r --abbrev 0a43668 5f44f22
> >:100644 100644 307d0e9... b182e63... M	doc/Makefile
> >:100644 100644 8f74707... e497c39... M	doc/user-man/dagman-node.eps
> >:100644 100644 ac915c5... a89b428... M	doc/version-history/7-8.history.tex
> >:100644 100644 3474c2a... ca1c839... M	src/condor_contrib/aviary/src/AviaryQueryServiceSkeleton.cpp
> >:100644 100644 f218bec... d40cd83... M	src/condor_contrib/aviary/src/AviaryScheddPlugin.cpp
> >:100644 100644 3a5fc86... d4878f9... M	src/condor_contrib/aviary/src/Job.cpp
> >:100644 100644 9c63059... c81b7b0... M	src/condor_contrib/aviary/src/aviary_query_server.cpp
> >:100644 100644 26659e2... 119ab2d... M	src/condor_daemon_client/dc_startd.cpp
> >:100644 100644 69fef28... bb3d5f0... M	src/condor_startd.V6/command.cpp
> >:100644 100644 d1dc126... e53d1a3... M	src/condor_utils/my_hostname.cpp
> >
> >It seems, in view of Dan's comments below, that "merges" of V7_8-branch
> >-> V7_9_2-branch might better be done using "git cherry-pick" instead of
> >"git merge". This will have the happy consequence that I do not have to
> >add rather convoluted logic to htcondorbot to check this case, as
> >htcondorbot had actually done the correct thing below.
> >
> >On Mon, Nov 26, 2012 at 01:29:10PM -0600, Dan Bradley wrote:
> >>Hi Karen,
> >>
> >>The developer wiki says that in some cases we should ask the release
> >>wrangler whether to merge bug fixes into a release branch.  In some
> >>cases, the wrangler says no.  Is that a problem, given the
> >>procedures used for merging the docs?  I thought we had a solution
> >>for merging docs without merging code, but I don't recall if it was
> >>actually implemented or if it turned out to be flawed in some way.
> >>
> >>--Dan
> >>
> >>On 11/26/12 1:09 PM, Karen Miller wrote:
> >>>From Nathan, but not sent to the group.  Just thought y'all
> >>>would want to know that there is not a problem with the repo.
> >>>Karen
> >>>
> >>>
> >>>On 11/26/2012 12:49 PM, Nathan Panike wrote:
> >>>>It is a false positive
> >>>>
> >>>>Problem is caused by not merging 7.8 ->  7.9.2 ->  master consistently.
> >>>>
> >>>>55a70d4a321 is on 7.8 and got merged 7.8 ->  master.
> >>>>
> >>>>Then Karen came along and merged 7.8 ->  7.9.2 ->  master.
> >>>>
> >>>>The result is that 55a70d4a321 is on master, before it is on 7.9.2; this
> >>>>caused htcondorbot to think there is corruption.
> >>>>
> >>>>I will fix this code so this false alarm does not happen again.
> >>>>
> >>>>Nathan Panike
> >>>>
> >>>>On Mon, Nov 26, 2012 at 11:55:12AM -0600, Todd Tannenbaum wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>-------- Original Message --------
> >>>>>Subject: [HTCondor-devel] Possible corruption in V7_9_2-branch
> >>>>>Date: Mon, 26 Nov 2012 11:36:38 -0600
> >>>>>From: htcondorbot<nwp@xxxxxxxxxxx>
> >>>>>To: htcondor-devel@xxxxxxxxxxx
> >>>>>
> >>>>>Attention HTCondor developers:
> >>>>>
> >>>>>It looks like development code from master may have been pushed into
> >>>>>V7_9_2-branch at 06095c4.
> >>>>>This should be inspected and---if necessary---corrected as
> >>>>>soon as possible.
> >>>>>
> >>>>>First run
> >>>>>git fetch --all
> >>>>>
> >>>>>4b7252b is master
> >>>>>5f44f22 is new V7_9_2-branch
> >>>>>0a43668 is old V7_9_2-branch
> >>>>>
> >>>>>How to reproduce
> >>>>>
> >>>>>For master:
> >>>>>git rev-list 4b7252b --not 0a43668
> >>>>>
> >>>>>For V7_9_2-branch:
> >>>>>git rev-list 5f44f22 --not 0a43668
> >>>>>
> >>>>>Notice that 06095c4 is in both lists, which is not expected.
> >>>>>
> >>>>>The following commands may be useful in resolving this issue:
> >>>>>
> >>>>>gitk 4b7252b 5f44f22 --not 0a43668
> >>>>>git --git-dir=/p/condor/repository/CONDOR_SRC.git reflog master@{now}
> >>>>>git --git-dir=/p/condor/repository/CONDOR_SRC.git V7_9_2-branch@{now}
> >>>>>
> >>>>>Your friendly repository-watching htcondorbot
> >>>>>_______________________________________________