Hi, Thank you for your opinions.
I will take reference to them for future plan. The ARM port of b86 was done with some embedded customers. It contains their requirements. It resulted in the modification of 1,225 files. And 460 new files are added to the b86 code base. It shows gaps between the current solaris and the requirement of embedded market. To realize single code base, much more discussion and investigation about porting layer was required. Since I cannot skip merging of b111b, it will be done. But it doesn't mean we don't catch up with the latest codebase. Thanks, Koji Uno Cyril Plisko wrote: > Koji and everyone, > > On Thu, Aug 27, 2009 at 1:12 PM, Koji Uno<Koji.Uno at sun.com> wrote: >> Hi, >> >> In the discussion, there are two items, timing >> and menas of merging. >> >> I am going to work as follows. Let me know comments. >> >> - The initial code is came from onnv-gate and is >> periodically mergerd from onnv-gate by mercurial. >> >> - The first target is set to b111b, now. Because it is >> a stable version. The next one is not set, yet. > > I do not think that 111b is better that any other build. It may make a > difference if you were to cut the final code for a production > distribution, but at that stage of the ARM architecture port I would > be surprised if you would ever notice a difference. > But see below for more details. > >> - The changesets of ARM are inserted into the series >> of onnv ones. It is not the same as onnv ones, but >> it is going to be syncronized. >> > > It seems to me we are essentially talking about similar approaches. > I would like to elaborate more on what I have in mind. > > First of all assumptions (I sincerely believe they are true, but I am > open to other opinions) > > 1. ARM porting code introduces less changes than the peer ON-gate in a > single period of time (based on the number of developers working on > the code) > > 2. ARM porting project is essentially a series of changes _to_ the ON > source base to allow it to run on ARM platform. > (when they ask you about your work they say - "What changes does you > code introduce to ON ?") > > 3. It is a general desire to _not_ lag too much behind the ON gate. > Ideally to not lag behind at all. > > 4. Small and contained changes are easier to review and manage than > the ones spanning large amount of files/code. > > > Second there are a couple of rules that need to be followed. > (ARM changesets = Changesets produced by the ARM proting project) > > 1. The ARM changesets to on-gate are kept on top of the on-gate > upstream changesets, and not interleaved with them. > > 2. The ARM changesets are kept as a series of small changes/patches to > the original code. > > 3. Merges are evil. > > > Now keeping in mind these assumptions and rules let's see how tools > that we have can help us: > > Mercurial provides at least two mechanisms for developer to do a long > term work that changes significantly the original code base, while > allowing to safely track the upstream changes. > > 1. Mercurial Patch Queue (MQ) > > With MQ you produce changesets that are always "pushed" on top of the > upstream source. Why is it good ? Because it allows you to track the > upstream effortlessly. You "pop" your changes, pull the updates from > the upstream and "push" you changes on top of the new tip again. MQ > handles all the underlying mechanics. What about conflicts ? Sure, > from time to time there will be conflicts. With MQ you can pinpoint > the exact changeset of yours that introduced conflict and rework it to > fit the new upstream. MQ lets you do it with no additional overhead of > tracking previous merges, since the result of MQ is _always_ > *mergeless*. > > MQ allows you too keep the work as a series of patches that are > applied in certain order. If you keep your patches small enough and > concise it makes wonders to you and your fellow developers. > > a. For new project members it is easy to understand what project is > doing - it is very obvious from the order of patches in the sequence > and their description. > > b. For you it helps a lot when you hit conflict - it help narrow down > the exact change that introduced conflict and rework it independently > of the other patches. > > c. It makes the job of code reviewers much easier. > > d. It allows you to *version* your patches - i.e. a certain on-gate > changeset introduces some new API that you need to support (say VM > API). Unfortunately when you modify your patches accordingly it > renders them incompatible with previous on-gate. In that case you > record the fact that there is a dependency between the version of your > patch and that new VM API. From now on you can continue developing > code, that is compatible with both branches (well, to the extent that > it is possible at all of course). > (Needless to say you only do it when absolutely have to - supporting > two different branches generates a lot of overhead) > > e. When you track the upstream you can estimate the amount of damage > of moving to the new version in a matter of seconds - and safely roll > back if you discover that the are surprises. > > f. When you finally come to integrate your code into the upstream > (ultimate goal !) the result of your work is self-documented and > clean. (see also c.) > > g. The results of your efforts are there for other ports to learn from > - they have a very clear trail to follow. > > > I probably can go on with this list, but I think I covered major points. > > > 2. The Mercurial 1.3.1 that is rumoured to be integrated soon will > have a "rebase" extension, which can be used to do similar things. > There are some mechanical differences, but the overall scheme is the > same. > > > 3. Oh, and git makes mercurial look like a joke when doing these things :) > > > > Well, that was an unusually long mail for me. I hope I described the > methodology clear enough. > I'd appreciate comments from all the parties. > >
