[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Merged recent work in 4.3.x into the SOC branch; please review

From: James Youngman
Subject: Merged recent work in 4.3.x into the SOC branch; please review
Date: Sat, 1 Dec 2007 19:52:31 +0000

[note: CC'ed to the mailing list]

(for the benefit of the list members CC'ed, the code Leslie wrote for
the Google Summer of Code programme was managed via git at
http://repo.or.cz/w/findutils.git, but the "upstream" repository for
findutils code is still the CVS tree described at


Eyeballing the current list of findutils bugs at
https://savannah.gnu.org/bugs/?group=findutils, I see that a large
fraction of the remaining bugs are now fixed or greatly helped by the
changes you already made for the Google Summer of Code.  I fixed most
of the other bugs, but left those that overlapped with your SOC work.
 I'd like to get us into a position where we can fix those bugs by
merging your code into the main findutils code base.

During the Google Summer of Code I tried to keep the SOC git branch
failrly close to 4.3.x in order to reduce the eventual merge burden.
I haven't done such a merge in quite a while now.      Per our
previous discussion though, I currently plan to release 4.4.0 and make
a new development branch before merging your changes into the trunk.
The thinking behind this is that your changes are quite large and
there are many changes in 4.3.x that are now stable, so it makes sense
to roll that existing work into a new stable branch.

All this may be old news, but the 4.3.x tree has also moved on since
the conclusion of the Google Summer of Code.  I started to merge the
4.3.x changes to date into the "polzer" branch at
http://repo.or.cz/w/findutils.git, but the merge work was significant.
  Instead of doing the merge the usual way, I merged your "polzer"
branch and the "master" (that is, currently 4.3.x) branch into
"polzer2".  The thinking here is that I didn't want to introduce bugs
into your "polzer" branch just by making a mistake with a manual

If you have the time, I would like for you to check that work.  I've
already done the bulk of it, I just need you to essentially review the
merge.   If you are amenable to doing this, there are two obvious

1. Merge "polzer2" into "polzer", carefully.   By "carefully" I mean
taking into account the rather high probabilty that I made a mistake.

2. Redo the merge yourself and then compare against what I did in the
polzer2 branch.  This is perhaps more time consuming but will likely
avoid the mistake I made, which was to forget to "pull" origin:polzer
into my local copy of your branch before merging from master (i.e. the
4.3.x trunk).

This actually doesn't need to be done right now, because a stable
4.4.0 release is not exactly imminent.   Since this is a reasonably
large amount of work however, I thought I'd mention it now, since no
doubt you have other time commitments too.   Just to give you an idea
of the work still left, there are about 55K lines of diffs between the
current 4.3.x code and your current "polzer" branch, but only about 3K
lines of diffs between the "polzer2" code (i.e. the result of my merge
attempt) and the current 4.3.x trunk.   Hence my claim that I've
already done the bulk of the work, but hence also my concern that a
mistake may have been made somewhere in there.

Of course, thanks again for all the work you did already.  Sorry to
ask you to do this too, but since your're the original author of those
changes you are going to be the best judge of whether they have
actually been correctly merged or not, I think.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]