[Adeos-main] [RFC] git workflow

[Adeos-main] [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4254 bytes --]

Hi,

some may already be used to working with git, I'm still learning. So
take the following with a grain of salt:

This is a proposal how to create and maintain an ipipe git repository
(we may have a lot of them...). To start small but still create
something useful, I had a look at 2.6.16-i386-1.5-02 vs. the related
stable tree on kernel.org. These are my steps to setup a tree, publish
it, keep it in sync with upstream, or merge ipipe-specific patches:

[Setup]
 0. Install git (I worked with ancient 1.2.4 from OpenSuSE 10.1)

 1. Clone the reference tree

    # git clone git://git.kernel.org/pub/scm/linux/kernel/git/\
      stable/linux-2.6.16.y.git linux-2.6.16-ipipe

 2. Configure your repository (default author/mail, shorthand for upload
    URL to public repos)

    # cd linux-2.6.16-ipipe
    # git repo-config user.name "Jan Kiszka"
    # git repo-config user.email "jan.kiszka@domain.hid"
    # echo "URL: ssh://kiszka@domain.hid" \
      > .git/remote/pub

 3. Import the fitting ipipe patch

    # git apply --index /path/to/adeos-ipipe-2.6.16-i386-1.5-02.patch
    # git commit -m "Import I-pipe 1.5-02" -s

 4. Publish tree, for web access and/or to work collaboratively on it

    # ssh kiszka@domain.hid
        # mkdir linux-2.6.16-ipipe
        # git init-db --shared
        # exit
    # git push pub master

    The first steps create an empty shareable git repos on my-host. The
    second pushes the master branch to the remote repository. There are
    some more steps to perform in order to publish that tree on my-host
    for http:// or git:// access, I haven't looked at this yet.

    Now anyone with whatever access to the public repos can pull from it
    to get the latest official nifty ipipe 2.6.16 tree.


[Keeping up-to-date]
 1. The original kernel tree may have been updated, and the ipipe patch
    needs to be rebased

    # git fetch
    # git rebase origin

    The result /should/ be new commits on top of the updated original
    tree. I haven't tried this in practice yet.

    I also read that release tags of the original trees are not
    automatically fetched after cloning. This needs further
    investigation.

 2. Push new version to public repos

    # git push pub master


[Merge I-pipe updates and release new patch]
 1. The reference I-pipe tree or some contributor may have come up with
    a worthwhile patch

    # git apply --index /path/to/avoid-ipipe_lock_cpu.patch
    # git commit -m "avoid ipipe_lock_cpu when interrupt flags are
                     ignored anyway"

    There is certainly also some magic (but likely simple) dance to pull
    individual commits from something like the "I-pipe Master Tree", but
    don't ask me for details yet (I'm still not really familiar with
    git's addressing scheme).

 2. Push new version to public repos

    # git push pub master

 3. Generate an I-pipe patch

    # git diff origin..master > adeos-ipipe-2.6.16-i386-1.5-03.patch

    As this tree only contains x86 stuff, this is OK. Once we may have
    multi-arch trees, some cherry picking would be required to extract
    only arch/<arch> and include/asm-<arch> aside the generic diffs.

 4. Tagging your tree after release is smart, too

    # git tag -s ipipe-1.5-03


[Duplicate your working repository]
 You may want to build further git working trees on other hosts. In
 order to have the same environment as above, simply cloning the ipipe
 tree is not correct (origin would become the ipipe tree, not vanilla).
 Instead:

 1. Perform steps 1 and 2 of the [Setup] procedure.

 2. Pull the missing ipipe pieces from the ipipe tree

    # git pull pub master


So far. I hope I can motivate some more I-pipe hackers to give this a
try (as time permits...) so that we could soon lay out the real I-pipe
repositories. Though I'm still stumbling about mighty git mechanisms
here and there, my feeling is that this tool can be /really/ helpful for
our not-that-simple distributed maintenance scenario. And to enhance my
poor git skills, I would offer to take over the stable 2.6.16-i386
series (expecting that it will be a really trivial job :o)).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

Jan Kiszka wrote:
> ...
> [Keeping up-to-date]
>  1. The original kernel tree may have been updated, and the ipipe patch
>     needs to be rebased
> 
>     # git fetch
>     # git rebase origin

I meanwhile learned that rebasing doesn't work well with public git
tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n
out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the
linear history.

Either we only push out final trees (but that would lock-out early
testers that may want to pull from devel-head), or we need to evolve
with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe
cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like
the paravirt stuff does on i386 ATM). We would then have to merge the
upstream patches into the I-pipe tree, effectively adopting them to
I-pipe. An extraction of a potential I-pipe patch stack would be more
complicated that way, but not infeasible.

Comments?

Jan

Re: [Adeos-main] Re: [RFC] git workflow

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Jan Kiszka wrote:
> 
>>...
>>[Keeping up-to-date]
>> 1. The original kernel tree may have been updated, and the ipipe patch
>>    needs to be rebased
>>
>>    # git fetch
>>    # git rebase origin
> 
> 
> I meanwhile learned that rebasing doesn't work well with public git
> tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n
> out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the
> linear history.
> 
> Either we only push out final trees (but that would lock-out early
> testers that may want to pull from devel-head), or we need to evolve
> with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe
> cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like
> the paravirt stuff does on i386 ATM). We would then have to merge the
> upstream patches into the I-pipe tree, effectively adopting them to
> I-pipe. An extraction of a potential I-pipe patch stack would be more
> complicated that way, but not infeasible.
> 
> Comments?

I am a complete git newbie myself. But the simpler way I would imagine
to develop the I-pipe would be to create one branch for each version of
the kernel. We would then use a script to generate all architectures
specific patches.

Porting from one version to the next means merging the difference
between the ipipe branch for linux 2.x.y and the linux 2.x.y sources
with the linux-2.x.y+1 sources.


-- 
                                                 Gilles Chanteperdrix

Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> ...
>>> [Keeping up-to-date]
>>> 1. The original kernel tree may have been updated, and the ipipe patch
>>>    needs to be rebased
>>>
>>>    # git fetch
>>>    # git rebase origin
>>
>> I meanwhile learned that rebasing doesn't work well with public git
>> tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n
>> out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the
>> linear history.
>>
>> Either we only push out final trees (but that would lock-out early
>> testers that may want to pull from devel-head), or we need to evolve
>> with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe
>> cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like
>> the paravirt stuff does on i386 ATM). We would then have to merge the
>> upstream patches into the I-pipe tree, effectively adopting them to
>> I-pipe. An extraction of a potential I-pipe patch stack would be more
>> complicated that way, but not infeasible.
>>
>> Comments?
> 
> I am a complete git newbie myself. But the simpler way I would imagine

Then I'm at least not alone. :)

> to develop the I-pipe would be to create one branch for each version of
> the kernel. We would then use a script to generate all architectures
> specific patches.
> 
> Porting from one version to the next means merging the difference
> between the ipipe branch for linux 2.x.y and the linux 2.x.y sources
> with the linux-2.x.y+1 sources.

Of course, we could branch per major release and rebase on top of new
kernel versions. But that would mean we have to wait until the official
release to publish our trees. Otherwise, the risk would be the later
fixes require a rebase.

The point is likely how to extract ipipe stuff from a fully merged git
tree. I think this should not be that tricky - as long as every patch in
some series only touches existing files exclusively (i.e. no two patches
modify the same source file). Then we could simply apply some diff mask
(git diff origin..master file1 file2 file3...) to generate those
individual patches for reference to anyone willing to port stuff to a
new arch or board.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] Re: [RFC] git workflow

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Jan Kiszka wrote:
>>>
>>>
>>>>...
>>>>[Keeping up-to-date]
>>>>1. The original kernel tree may have been updated, and the ipipe patch
>>>>   needs to be rebased
>>>>
>>>>   # git fetch
>>>>   # git rebase origin
>>>
>>>I meanwhile learned that rebasing doesn't work well with public git
>>>tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n
>>>out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the
>>>linear history.
>>>
>>>Either we only push out final trees (but that would lock-out early
>>>testers that may want to pull from devel-head), or we need to evolve
>>>with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe
>>>cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like
>>>the paravirt stuff does on i386 ATM). We would then have to merge the
>>>upstream patches into the I-pipe tree, effectively adopting them to
>>>I-pipe. An extraction of a potential I-pipe patch stack would be more
>>>complicated that way, but not infeasible.
>>>
>>>Comments?
>>
>>I am a complete git newbie myself. But the simpler way I would imagine
> 
> 
> Then I'm at least not alone. :)
> 
> 
>>to develop the I-pipe would be to create one branch for each version of
>>the kernel. We would then use a script to generate all architectures
>>specific patches.
>>
>>Porting from one version to the next means merging the difference
>>between the ipipe branch for linux 2.x.y and the linux 2.x.y sources
>>with the linux-2.x.y+1 sources.
> 
> 
> Of course, we could branch per major release and rebase on top of new
> kernel versions. But that would mean we have to wait until the official
> release to publish our trees. Otherwise, the risk would be the later
> fixes require a rebase.

Is it a big deal ?

> 
> The point is likely how to extract ipipe stuff from a fully merged git
> tree. I think this should not be that tricky - as long as every patch in
> some series only touches existing files exclusively (i.e. no two patches
> modify the same source file). Then we could simply apply some diff mask
> (git diff origin..master file1 file2 file3...) to generate those
> individual patches for reference to anyone willing to port stuff to a
> new arch or board.

Yes, what we need is something similar to "svn merge" functionality.

-- 
                                                 Gilles Chanteperdrix

Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>
>>>>
>>>>> ...
>>>>> [Keeping up-to-date]
>>>>> 1. The original kernel tree may have been updated, and the ipipe patch
>>>>>   needs to be rebased
>>>>>
>>>>>   # git fetch
>>>>>   # git rebase origin
>>>> I meanwhile learned that rebasing doesn't work well with public git
>>>> tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n
>>>> out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the
>>>> linear history.
>>>>
>>>> Either we only push out final trees (but that would lock-out early
>>>> testers that may want to pull from devel-head), or we need to evolve
>>>> with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe
>>>> cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like
>>>> the paravirt stuff does on i386 ATM). We would then have to merge the
>>>> upstream patches into the I-pipe tree, effectively adopting them to
>>>> I-pipe. An extraction of a potential I-pipe patch stack would be more
>>>> complicated that way, but not infeasible.
>>>>
>>>> Comments?
>>> I am a complete git newbie myself. But the simpler way I would imagine
>>
>> Then I'm at least not alone. :)
>>
>>
>>> to develop the I-pipe would be to create one branch for each version of
>>> the kernel. We would then use a script to generate all architectures
>>> specific patches.
>>>
>>> Porting from one version to the next means merging the difference
>>> between the ipipe branch for linux 2.x.y and the linux 2.x.y sources
>>> with the linux-2.x.y+1 sources.
>>
>> Of course, we could branch per major release and rebase on top of new
>> kernel versions. But that would mean we have to wait until the official
>> release to publish our trees. Otherwise, the risk would be the later
>> fixes require a rebase.
> 
> Is it a big deal ?

Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot
simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of
patches is practically frozen once published. In your private tree you
are, of course, free to do this and then extract some patch to post
upstream.

> 
>> The point is likely how to extract ipipe stuff from a fully merged git
>> tree. I think this should not be that tricky - as long as every patch in
>> some series only touches existing files exclusively (i.e. no two patches
>> modify the same source file). Then we could simply apply some diff mask
>> (git diff origin..master file1 file2 file3...) to generate those
>> individual patches for reference to anyone willing to port stuff to a
>> new arch or board.
> 
> Yes, what we need is something similar to "svn merge" functionality.
> 

That's integrated in git-pull.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] Re: [RFC] git workflow

[Wolfgang Denk]

In message <4587F9CE.3060403@domain.hid> you wrote:
> 
> Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot
> simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of
> patches is practically frozen once published. In your private tree you
> are, of course, free to do this and then extract some patch to post
> upstream.

I'm not sure if it really makes sense to maintain this as a git
repository - that would be OK if we wanted to provide a pre-patched
tree to the public (which might be a good thing to have, btw.).

As long as we're basicly trying to manage the patches in a way that
integrates well with git we should do exactly that: manage the
patches under git, i. e. use stgit (see http://www.procode.org/stgit/).

Just my 0.02 <insert your favorite currency unit here>

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
The best things in life are for a fee.

Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

Wolfgang Denk wrote:
> In message <4587F9CE.3060403@domain.hid> you wrote:
>> Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot
>> simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of
>> patches is practically frozen once published. In your private tree you
>> are, of course, free to do this and then extract some patch to post
>> upstream.
> 
> I'm not sure if it really makes sense to maintain this as a git
> repository - that would be OK if we wanted to provide a pre-patched
> tree to the public (which might be a good thing to have, btw.).

This is one of my motivations to push git forward. Having
2.6.20-rcX+ipipe already available for download and testing may help to
follow the kernel development on the bleeding edge more closely.

The other aspect is that when you merge the kernel patches into a
working ipipe tree and you get a conflict, you also directly obtain
information about what change caused it and maybe what the background of
that patch was. That's at least my theory which still needs to be proven
in practice.

> 
> As long as we're basicly trying to manage the patches in a way that
> integrates well with git we should do exactly that: manage the
> patches under git, i. e. use stgit (see http://www.procode.org/stgit/).

I heard about it before, but I still have to take a closer look. Does
this generate also some kind of publishable git tree with history for
the managed patches? One problem with a stack might be that we loose
information about ipipe changes themselves. My idea is that some
modification to the ipipe core stored as commit in the reference tree
could directly be pulled by other arch maintainers.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] Re: [RFC] git workflow

[Wolfgang Denk]

Dear Jan,

in message <45881A69.1040704@domain.hid> you wrote:
>
> This is one of my motivations to push git forward. Having
> 2.6.20-rcX+ipipe already available for download and testing may help to
> follow the kernel development on the bleeding edge more closely.

Agreed.

> The other aspect is that when you merge the kernel patches into a
> working ipipe tree and you get a conflict, you also directly obtain
> information about what change caused it and maybe what the background of
> that patch was. That's at least my theory which still needs to be proven
> in practice.

THis will work, but if you go this route you will sonn have the git
repo only, as it will become more and more difficult to extract the
ipipe patches which you need anyway.

That's why I recommend to use stgit to maintain the ipipe patches. So
you have a clearly defined flow of information.

> I heard about it before, but I still have to take a closer look. Does
> this generate also some kind of publishable git tree with history for
> the managed patches? ...

Yes, it does.

>                  ... One problem with a stack might be that we loose
> information about ipipe changes themselves. ...

No, that's not true, as the patches itself are managed under git,  so
you have the full power of git for the patch history, too.

This will be much more powerful than the  other  approach  -  if  you
maintain  a  patched  tree  under git, it will be pretty difficult to
find out which changes make up the ipipe patch, and which  are  other
stuff.

>                                         ... My idea is that some
> modification to the ipipe core stored as commit in the reference tree
> could directly be pulled by other arch maintainers.

That sounds as if you are planning  to  use  stgit  already,  without
knowing it yet :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
"Just think, with VLSI we can have 100 ENIACS on a chip!"
- Alan Perlis

Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

Wolfgang Denk wrote:
> Dear Jan,
> 
> in message <45881A69.1040704@domain.hid> you wrote:
>> This is one of my motivations to push git forward. Having
>> 2.6.20-rcX+ipipe already available for download and testing may help to
>> follow the kernel development on the bleeding edge more closely.
> 
> Agreed.
> 
>> The other aspect is that when you merge the kernel patches into a
>> working ipipe tree and you get a conflict, you also directly obtain
>> information about what change caused it and maybe what the background of
>> that patch was. That's at least my theory which still needs to be proven
>> in practice.
> 
> THis will work, but if you go this route you will sonn have the git
> repo only, as it will become more and more difficult to extract the
> ipipe patches which you need anyway.
> 
> That's why I recommend to use stgit to maintain the ipipe patches. So
> you have a clearly defined flow of information.
> 
>> I heard about it before, but I still have to take a closer look. Does
>> this generate also some kind of publishable git tree with history for
>> the managed patches? ...
> 
> Yes, it does.
> 
>>                  ... One problem with a stack might be that we loose
>> information about ipipe changes themselves. ...
> 
> No, that's not true, as the patches itself are managed under git,  so
> you have the full power of git for the patch history, too.
> 
> This will be much more powerful than the  other  approach  -  if  you
> maintain  a  patched  tree  under git, it will be pretty difficult to
> find out which changes make up the ipipe patch, and which  are  other
> stuff.

Might be true when you browse the log. But I guess some magic can be
applied in that case as well, or we put a unique tag into the commit
name ("[IPIPE] optimise IRQ fast-path").

> 
>>                                         ... My idea is that some
>> modification to the ipipe core stored as commit in the reference tree
>> could directly be pulled by other arch maintainers.
> 
> That sounds as if you are planning  to  use  stgit  already,  without
> knowing it yet :-)

Well, I may still oversee something, but after having a first look and
also reading the tutorial it seems to me that there is actually no magic
behind stgit. Means, it just works with the same mechanism plain git
does. When you "stg pull", you remove your patches from the stack, apply
the upstream changes, and then add your patches again - git rebase. So
when you want to publish your stgit tree, you still need to merge your
patches (stg commit). And at that moment you set the whole tree ordering
in stone. Back to #1.

stgit is surely useful for managing private trees, but I don't see how
it can help us when we want to publish our working trees.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] Re: [RFC] git workflow

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Wolfgang Denk wrote:
>> Dear Jan,
>>
>> in message <45881A69.1040704@domain.hid> you wrote:
>>> This is one of my motivations to push git forward. Having
>>> 2.6.20-rcX+ipipe already available for download and testing may help to
>>> follow the kernel development on the bleeding edge more closely.
>> Agreed.
>>
>>> The other aspect is that when you merge the kernel patches into a
>>> working ipipe tree and you get a conflict, you also directly obtain
>>> information about what change caused it and maybe what the background of
>>> that patch was. That's at least my theory which still needs to be proven
>>> in practice.
>> THis will work, but if you go this route you will sonn have the git
>> repo only, as it will become more and more difficult to extract the
>> ipipe patches which you need anyway.
>>
>> That's why I recommend to use stgit to maintain the ipipe patches. So
>> you have a clearly defined flow of information.
>>
>>> I heard about it before, but I still have to take a closer look. Does
>>> this generate also some kind of publishable git tree with history for
>>> the managed patches? ...
>> Yes, it does.
>>
>>>                  ... One problem with a stack might be that we loose
>>> information about ipipe changes themselves. ...
>> No, that's not true, as the patches itself are managed under git,  so
>> you have the full power of git for the patch history, too.
>>
>> This will be much more powerful than the  other  approach  -  if  you
>> maintain  a  patched  tree  under git, it will be pretty difficult to
>> find out which changes make up the ipipe patch, and which  are  other
>> stuff.
> 
> Might be true when you browse the log. But I guess some magic can be
> applied in that case as well, or we put a unique tag into the commit
> name ("[IPIPE] optimise IRQ fast-path").
> 
>>>                                         ... My idea is that some
>>> modification to the ipipe core stored as commit in the reference tree
>>> could directly be pulled by other arch maintainers.
>> That sounds as if you are planning  to  use  stgit  already,  without
>> knowing it yet :-)
> 
> Well, I may still oversee something, but after having a first look and
> also reading the tutorial it seems to me that there is actually no magic
> behind stgit. Means, it just works with the same mechanism plain git
> does. When you "stg pull", you remove your patches from the stack, apply
> the upstream changes, and then add your patches again - git rebase. So
> when you want to publish your stgit tree, you still need to merge your
> patches (stg commit). And at that moment you set the whole tree ordering
> in stone. Back to #1.
> 
> stgit is surely useful for managing private trees, but I don't see how
> it can help us when we want to publish our working trees.

A while ago I also played a bit with stgit and I was also not convinced, 
that it's the right tool for our purpose. Nevertheless, I could reduce 
the amount of git trees to manage (but I have to spend more time for a 
better judgment).

Currently I'm porting IPIPE v1.6 over arch/powerpc rising a few code 
management issues. I started porting with i386-1.6-01 extracting the 
common part from that patch and adapting the arch specify code for 
arch/powerpc. Now IPIPE is at v1.6-02 and I realized various 
modifications, also of the noarch part including some serious bug fixes 
(local_irq_disable_head in main.c did hang my system). But now, there is 
no easy way to update the noarch part as we deal with combined noarch + 
arch patches. From a new git based code management system, I would 
appreciate a separation of noarch and arch. This would make it easier to 
keep the archs in sync with Philippe's reference implementation (for 
x86). Any comments?

Wolfgang.

Re: [Adeos-main] Re: [RFC] git workflow

[Gilles Chanteperdrix]

Wolfgang Grandegger wrote:
> A while ago I also played a bit with stgit and I was also not convinced, 
> that it's the right tool for our purpose. Nevertheless, I could reduce 
> the amount of git trees to manage (but I have to spend more time for a 
> better judgment).
> 
> Currently I'm porting IPIPE v1.6 over arch/powerpc rising a few code 
> management issues. I started porting with i386-1.6-01 extracting the 
> common part from that patch and adapting the arch specify code for 
> arch/powerpc. Now IPIPE is at v1.6-02 and I realized various 
> modifications, also of the noarch part including some serious bug fixes 
> (local_irq_disable_head in main.c did hang my system). But now, there is 
> no easy way to update the noarch part as we deal with combined noarch + 
> arch patches. From a new git based code management system, I would 
> appreciate a separation of noarch and arch. This would make it easier to 
> keep the archs in sync with Philippe's reference implementation (for 
> x86). Any comments?

IMHO, having the noarch and arch code separated is a nuisance. If there
was a centralized ipipe branch for 2.6.19, you would simply synchronize
your working copy with the server using the equivalent of "cvs/svn
update" and "cvs/svn commit". On the other hand, if the arch and noarch
code was separated, you would end up with twice as much updates and
commits.

-- 
                                                 Gilles Chanteperdrix

Re: [Adeos-main] Re: [RFC] git workflow

[Wolfgang Grandegger]

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> A while ago I also played a bit with stgit and I was also not convinced, 
>> that it's the right tool for our purpose. Nevertheless, I could reduce 
>> the amount of git trees to manage (but I have to spend more time for a 
>> better judgment).
>>
>> Currently I'm porting IPIPE v1.6 over arch/powerpc rising a few code 
>> management issues. I started porting with i386-1.6-01 extracting the 
>> common part from that patch and adapting the arch specify code for 
>> arch/powerpc. Now IPIPE is at v1.6-02 and I realized various 
>> modifications, also of the noarch part including some serious bug fixes 
>> (local_irq_disable_head in main.c did hang my system). But now, there is 
>> no easy way to update the noarch part as we deal with combined noarch + 
>> arch patches. From a new git based code management system, I would 
>> appreciate a separation of noarch and arch. This would make it easier to 
>> keep the archs in sync with Philippe's reference implementation (for 
>> x86). Any comments?
> 
> IMHO, having the noarch and arch code separated is a nuisance. If there
> was a centralized ipipe branch for 2.6.19, you would simply synchronize
> your working copy with the server using the equivalent of "cvs/svn
> update" and "cvs/svn commit". On the other hand, if the arch and noarch
> code was separated, you would end up with twice as much updates and
> commits.

That would mean that we handle more than one arch in a branch, e.g. 
i386, ppc, powerpc, etc., and the arch maintainer just commits his arch 
specific changes. Well, this sounds good.

Wolfgang.

Re: [Adeos-main] Re: [RFC] git workflow

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> A while ago I also played a bit with stgit and I was also not
>>> convinced, that it's the right tool for our purpose. Nevertheless, I
>>> could reduce the amount of git trees to manage (but I have to spend
>>> more time for a better judgment).
>>>
>>> Currently I'm porting IPIPE v1.6 over arch/powerpc rising a few code
>>> management issues. I started porting with i386-1.6-01 extracting the
>>> common part from that patch and adapting the arch specify code for
>>> arch/powerpc. Now IPIPE is at v1.6-02 and I realized various
>>> modifications, also of the noarch part including some serious bug
>>> fixes (local_irq_disable_head in main.c did hang my system). But now,
>>> there is no easy way to update the noarch part as we deal with
>>> combined noarch + arch patches. From a new git based code management
>>> system, I would appreciate a separation of noarch and arch. This
>>> would make it easier to keep the archs in sync with Philippe's
>>> reference implementation (for x86). Any comments?
>>
>> IMHO, having the noarch and arch code separated is a nuisance. If there
>> was a centralized ipipe branch for 2.6.19, you would simply synchronize
>> your working copy with the server using the equivalent of "cvs/svn
>> update" and "cvs/svn commit". On the other hand, if the arch and noarch
>> code was separated, you would end up with twice as much updates and
>> commits.
> 
> That would mean that we handle more than one arch in a branch, e.g.
> i386, ppc, powerpc, etc., and the arch maintainer just commits his arch
> specific changes. Well, this sounds good.

Ack, at least for Philippe's main tree. Splitting trees makes sense

 o when a different person maintains it (you and Gilles may want to
   publish your arch trees for early testers)
 o for different bases (e.g. 2.4 or 2.6.16-stable or Blackfin)

On major releases of the original kernel tree we could create a branch
and maybe continue in those branches to maintain a stable patch version
as long as reasonable. This would also involve pulling critical fixes to
the HEAD down into those branches (or the other trees).

Well, I'm still convinced that "deeply merged" ipipe patches in those
git trees are the way to go. I'm optimistic we will easily find
mechanisms (scripts) to extract a potential ipipe patch series from
those trees. I think Philippe did this with his CVS managed tree as
well. The patch borders should run clearly along files and (arch-)subdirs.

And my original idea to have a dedicated I-pipe tree without further
kernel code is probably not needed for this workflow.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]