Re: 2.6.19-rcX vs 2.6.20

Re: 2.6.19-rcX vs 2.6.20

[Gerrit Renker]

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

It seems that I am not the only one having headaches about which patches
are applied and which not. I spent a major part yesterday trying to get
the set of patches consistent with regard to Dave's/Arnaldo's latest tree.

What I have been doing over time is collecting all patches that were posted on this
list and have not made it upstream into a consistent, stacked set of patches.

With my own work this adds up to currently 17 patches, including:
	* 3 patches from Andrea which have also not been merged
	* 1 patch (typo) by Ian which has not been merged
	* patches from me with annotations that Arnaldo made incorporated
	* a few bug fixes (see also earlier posting)
	* general updates (such as the one Ian pointed out, but also the
          second part of the oops patch to reduce the number of forward decls)

Every day, after pulling, I have to reconstruct the whole stacked batch of patches
by applying them one after the other again. Even the script which does this is tedious.
Now I see the headaches it costs Arnaldo as well and hence:

  ==> Is there any way of using a separate DCCP repository for the mere purpose of
      keeping accepted and discussed patches in a consistent state?

It is little point if everyone keeps a separate stack of patches. On the other hand, it
is frustrating work having to chase after old and partially applied patches, battle with
rebased trees, merged close windows etc. 

With regard to 2.6.19-rX vs 2.6.20 I think that it is better not to submit more patches
not (only) because David said so, but with regard to `postponing headaches': all non-2.6.19-rX
patches have later again to be rebased/changed. Yesterday, this killed two of my repositories
and I had to change each manually from scratch again.


Arnaldo, what do you think is best ? I think it would be ideal if there was a consistent
tree, that would save a lot of work. 

What I could contribute to make this easier is to keep track of changes and merging (i.e.
the grunt work) - I am pulling the latest netdev tree daily anyway. Would this help? I am
not insinuating bypassing the revision process, but I am getting tired of rebasing. 

Well I hope it won't stay like this forever ...



PS: Ian, for a laugh I attach a script which I have been using a lot, it basically
answers your question `is this upstream or not' - in colour :)

[-- Attachment #2: is_patched_already.sh --]
[-- Type: application/x-shellscript, Size: 941 bytes --]

Re: 2.6.19-rcX vs 2.6.20

[Arnaldo Carvalho de Melo]

On 10/24/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> It seems that I am not the only one having headaches about which patches
> are applied and which not. I spent a major part yesterday trying to get
> the set of patches consistent with regard to Dave's/Arnaldo's latest tree.
>
> What I have been doing over time is collecting all patches that were posted on this
> list and have not made it upstream into a consistent, stacked set of patches.
>
> With my own work this adds up to currently 17 patches, including:
>         * 3 patches from Andrea which have also not been merged
>         * 1 patch (typo) by Ian which has not been merged
>         * patches from me with annotations that Arnaldo made incorporated
>         * a few bug fixes (see also earlier posting)
>         * general updates (such as the one Ian pointed out, but also the
>           second part of the oops patch to reduce the number of forward decls)
>
> Every day, after pulling, I have to reconstruct the whole stacked batch of patches
> by applying them one after the other again. Even the script which does this is tedious.
> Now I see the headaches it costs Arnaldo as well and hence:
>
>   => Is there any way of using a separate DCCP repository for the mere purpose of
>       keeping accepted and discussed patches in a consistent state?
>
> It is little point if everyone keeps a separate stack of patches. On the other hand, it
> is frustrating work having to chase after old and partially applied patches, battle with
> rebased trees, merged close windows etc.
>
> With regard to 2.6.19-rX vs 2.6.20 I think that it is better not to submit more patches
> not (only) because David said so, but with regard to `postponing headaches': all non-2.6.19-rX
> patches have later again to be rebased/changed. Yesterday, this killed two of my repositories
> and I had to change each manually from scratch again.
>
>
> Arnaldo, what do you think is best ? I think it would be ideal if there was a consistent
> tree, that would save a lot of work.
>
> What I could contribute to make this easier is to keep track of changes and merging (i.e.
> the grunt work) - I am pulling the latest netdev tree daily anyway. Would this help? I am
> not insinuating bypassing the revision process, but I am getting tired of rebasing.
>
> Well I hope it won't stay like this forever ...
>
>
>
> PS: Ian, for a laugh I attach a script which I have been using a lot, it basically
> answers your question `is this upstream or not' - in colour :)

Well, I'm not being a diligent maintainer, have to review many patches
yet, I guess I should just create a net-2.6.20 git tree to fix this
situation, but I guess you guys could also maintain git trees
somewhere, so that I could pull from you, what do you think?

- Arnaldo

Re: 2.6.19-rcX vs 2.6.20

[Gerrit Renker]

Hi Arnaldo,

|  I guess I should just create a net-2.6.20 git tree to fix this
|  situation, but I guess you guys could also maintain git trees
|  somewhere, so that I could pull from you, what do you think?
If that would make the situation better, I'll do that. We've got
web servers and the like here. So ... that would be like
	* patches sent to Arnaldo for checking
	* Arnaldo merges into his 2.6.20 tree
	* Gerrit (or Ian or Andrea) pulls Arnaldos changes
	* whoever pulled last, keeps it consistent with netdev tree
	* next time patches come in for revision, Arnaldo can pull 
          from the up-to-date tree
	* or ... ?

That would be great - these patches are just in the way to get other
work done.

Gerrit
	

Re: 2.6.19-rcX vs 2.6.20

[Ian McDonald]

On 10/24/06, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> It seems that I am not the only one having headaches about which patches
> are applied and which not. I spent a major part yesterday trying to get
> the set of patches consistent with regard to Dave's/Arnaldo's latest tree.
>
<snipped>

My general philosophy of patching/maintaining it is as follows:
- When Dave M hasn't got a revision+1 tree open I just use Linus' tree
unless there is good reason. The reason for this is that you don't
have to rebase all the time
- When Dave M has a revision+1 tree open I use that (e.g. will need to
use net 2.6.20 soon I imagine)
- Whatever tree I use I use stgit on top of it on a separate branch. I
generally "stg export -d -n" to put all patches into subdirectory,
"stg pop -a" to pop the patches off, do a "stg pull" and then start
applying/deleting patches as I go.
- I have been using git apply --check as well which basically mirrors
the script of Gerrit's.

I publish my patch sets up to http://wand.net.nz/~iam4/dccp/patches
and have a file description.txt file there to describe what I have.

I can't reiterate enough how much stgit has helped me!!

I could put up a git tree if required but is it worth it for the
number of patches I do for the effort I would need to put in?

I would like to see bug fixes in 2.6.19 too if they are obvious fixes
e.g. the one I sent today. I won't get into the debate about other
cosmetic ones....

Ian
-- 
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand

Re: 2.6.19-rcX vs 2.6.20

[Gerrit Renker]

Hi Ian  

Thanks for the tip, I know your web repository and will certainly look at
stgit (I am doing something like that at the moment). 

|  I would like to see bug fixes in 2.6.19 too if they are obvious fixes
|  e.g. the one I sent today. I won't get into the debate about other
|  cosmetic ones....
The problem is not in cosmetics. Each new patch potentially changes offsets
and contexts of outstanding ones (cosmetic or not), so doing `x' now will
imply having to re-do `y' at a later time, whereas my idea was to to both `x' and
`y' at one time.

To make a start, I will submit the batch of what I have (but explicitly not for 2.6.19)
so that hopefully the patch situation can be a little clarified.

Gerrit