On 04/04/2011 11:45, Wookey wrote:
> +++ Chris Jones [2011-04-04 10:40 +0100]:
>> On 01/04/2011 12:08, Nick Bane wrote:
>> After much useful discussion with Nick, I've just written the following
>> page:
>> http://www.balloonboard.org/balloonwiki/SoftwareBuilding/Menuconfig2KernelDevelopment
>
> Cheers for that. It could usefully be expanded into a 'how to use
> menuconfig2' page if someone got enthused.
>
>> which explains the Jones-eye view of how to do kernel hacking. It works
>> for me, but all contributions are welcome.
>
> Amongst other things you said:
> "Be aware that if you add a file to a patch, make sure it's not already
> modified by another patch. This situation quickly leads to misery in
> the form of patches which won't apply in certain situations."
>
> That's not good advice. The whole point of quilt is to make it
> (fairly) easy to manage a stack of patches, and it is fine (expected,
> even) for more than one patch in that stack to change the same file.
> As you point out, for things like balloon3.c it's pretty-much inevitable.
>
Are you sure? There is the problem of the same file in patches in more than
one series. If that patch was refreshed where a file it uses has been
modified by a patch in one series and not another we end up in hell where
only the last ci works. This is a downside of patch sharing with variants.
I tried to make a core set of patches that would apply to most series with
other idiosyncratic patches being added after those to reduce the
likelyhood of this problem. seemed to work.
An alternative is to not share patch sets between series unless they are
the common core.
> We definately _don't_ want people putting unrelated changes in one
> patch because 'that's the patch that edits file foo'. A patch is a
> coherent set of changes across many file, which implements one logic
> change/feature.
>
> The trick to dealing with editing a file affected by multiple patches
> is to make sure that the patch relevant to the changes you want to
> make is current before you make them, and you do a 'quilt refresh'
> before moving to a new/different patch to make some other change to the
> same file. Without this discipline you will indeed get in a mess, and
> either lose your changes, or have them in the wrong patch, and
> generate patches that won't apply for anyone else.
>
> I realise this 'be in the right patch before making changes, and don't
> make changes outside patches' requirement can be awkward if you are
> just hacking about for development purposes, but unless you are
> prepared to nuke your tree at any moment and get a fresh one, then I
> strongly recommend that all changes are kept in a patch, otherwise you
> will lose stuff, and/or get all frustrated, like poor CJ recently..
>
> I've adjusted the wiki page to this effect.
>
> (hector will no doubt pop up in a minute to say 'just use git, you
> neanderthaals')
>
> Wookey
(text/plain)