Re: gnuzilla, iceweasel, thundersomewhat

[Alexander Sack]

On Sun, Oct 01, 2006 at 05:13:41PM -0500, Karl Berry wrote:
>     No, we keep on our CVS repository only modified files and arrange them to
> 
> Right, and that's worked fine so far, since you have been doing all the
> programming.
> 
> But now that Alexander is interested in also pursuing development, it
> seems like it would be better to have the actual sources in CVS, that
> can be checked out/built/updated in the normal way, instead of through a
> process that happens only on your machine.  How else can multiple people
> on the project work together?

On the short run, I would be fine if the process doing this is available
in a reproducible and well documented fashion. Anyway, on the long run
we should really try to figure out, how we can maintain a complete
fork and update this with minimal work ...

> 
>     Do you mean sync it only on upstream releases or sync it at specific
>     intervals?
> 
> As I implied before, I think our first goal should be to sync only at
> releases, as we have been doing.  That is ambitious enough!  After that
> is working and something has been released, we could consider trying to 
> 
>     many files have to be checked one by one.
> 
> I know patches can't just be blindly applied and the result expected to
> work.  But isn't applying the diffs still the place to start?  I mean,
> somehow our sources have to get updated from their new sources, and how
> to do that if not by applying the diffs?  Probably get hints about
> problem areas by hunks that fail to apply, too.

I hope we can find a consens to keep changes minimal ... so
maintainance and adaption work needed on new releases stays minimal
too.

... I like the idea how one can organize this using git. Its not a
safe bet, but improves the way you can maintain diffs to a forked
code-base.

The idea is to maintain a mainline branch where you import your
mozilla code. Then you create a branch and make your changes to the
upstream codebase on it. As soon as upstream releases a new version,
you upgrade/import those changes to the mainline branch (which should
always work) and then do 'git rebase' your forked branch to the new
mainline HEAD.

git makes use of some sophisiticated strategies to make adapt your
changes considering the diff done to the mainline branch.

Don't know how to accomplish this using other rcs.

> 
> I guess the other way to do it would be to diff our tree against the
> previous mozilla release (the one we started from), and then apply our
> changes to their new release.  Of course, again there will be plenty of
> manual checking afterwards, there's no way to avoid it.
> 
>     we need a script that cleans the original tree from files we don't
>     need;
> 
> I will try to make a start at it as soon as I can, but I can't check
> every file I found (let alone all the files I didn't find).  Alexander,
> if it's something you can push, that would be great.  Otherwise I will
> put out a notice for more volunteers.

I can't guarantee for anything, as I am going on a month vacation
pretty soon and have to finish some real life work before. Anyway, I
will try to motivate some more mozilla maintainers from debian to help
on this. A notice requesting for more volunteers should be added
anyway.


 - Alexander

-- 
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack            | : :' :      The  universal
 address@hidden           | `. `'      Operating System
 http://www.asoftsite.org  |   `-    http://www.debian.org