On Fri, Oct 02, 2015 at 03:36:32PM +0200, Henning Schild wrote:
> On Tue, 29 Sep 2015 20:03:45 +0200
> Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org> wrote:
>
> > On Wed, Sep 09, 2015 at 11:31:51AM +0200, Henning Schild wrote:
> > > Hi,
> > >
> > > i am about to merge ipipe into a more recent kernel and would like
> > > to discuss the approach with you guys. As far as i have seen and
> > > been told i should merge and not rebase.
> > >
> > > My current plan:
> > > 1 choose release (4.1 since its LTS)
> > > 2 merge it into ipipe
> > > 3 resolve obvious conflicts
> > > 4 commit broken merge
> > > 5 repair common bits and x86
> > > 6 publish my tree for others to repair other archs
> > >
> > > Steps 2,3 and 4 might become iterations stepping over 3.19 and 4.0.
> > > The merges will not work but the smaller steps will result in less
> > > conflicts at a time.
> > >
> > > What do you guys think of the approach? Are my version choices sane
> > > or are there any reasons to consider other releases as well?
> >
> > I did not answer because I am not sure my opinion really matters. I
> > am only maintaining one architecture, and have not even worked on it
> > for a long time. And have already expressed this opinion several
> > times. But since you are asking for it:
> >
> > - merging with mainline to maintain the modifications made by the
> > I-pipe tree is a bad solution:
> > . first because it is more time consuming than what we did before,
> > that is reapplying the I-pipe patch and fixing the conflicts:
> > . second because the I-pipe changes get lost in the middle of the
> > upstream commits, so the idea that by doing this we could keep the
> > history of changes in the I-pipe tree does not work;
> > . third because when you do the merge, you can not easily ignore the
> > conflicts for the other architecture than the one you are currently
> > working on.
> >
> > - merging by iterating over releases is even more time consuming: it
> > is far from exceptional to see the same piece of code changed by
> > several consecutive releases, with your method you get one conflict
> > by iteration, if you skip all the releases with one big iteration,
> > that means fixing only one conflict.
>
> I found the approach to work OK and surprisingly fast. In some series i
> had to resolve conflicts on the same files, but it was different
> conflicts. Not particularly time consuming or annoying.
>
> I did not ignore the other archs when merging, i just did not test
> them. 4.0 is currently at a state as if i had applied the big patch on
> it and merged to my best knowledge.
That is a problem. It is easier to find bugs in something you
merged, than in something someone else merged.
>
> > - I believe the right solution is to maintain the changes made by
> > the I-pipe tree as a stack of commits applied on top of the upstream
> > kernel, maintained with git. That means using git rebase to switch
> > from one release to the next, and amend each commit to fix the
> > conflicts. This way, every patch becomes a meaningful change to the
> > upstream kernel, we keep the history of changes, and they all appear
> > on top of the upstream commits, making them easy to identify in the
> > git logs. Splitting architecture specific patches allows every
> > architecture maintainer to focus on his architecture, and not have
> > to care about the other architecture commits. Note that I have
> > maintained the FCSE patch (split in something like 7 or 8 commits)
> > for several kernel releases, and I noticed no particular difficulty
> > doing so.
>
> That also does not sound too bad. At the moment we are probably >30
> commits away from mainline, with 95% of the code in one big change that
> does have a broken history. But sorting that into a nice queue of
> independantly working commits will also take a lot of time. And
> maintaining that feature will also cost.
>
> Using a queue has the problem that changing the history (rebasing)
> becomes an essential part of your workflow. I know a lot of people like
> doing that to keep things nice and clean but i am not a big fan. My
> experience is that you end up investing a lot of work to alter
> history that could be useful later.
I was talking about rebasing only when switching from one mainline
release to the next. An I-pipe branch for a mainline release would
never been rebased. You would use the opportunity of the rebase to
the next release to clean up the history.
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://xenomai.org/mailman/listinfo/xenomai
