[Debian-eeepc-devel] rt2860 Git reporitory

[Damyan Ivanov]

Hi Glenn,


Before going on further, please  don't take any of the complains below 
as a personal attack against you. They are not. Even if I point 
problems in the work you have done, I very much appreciate the time 
and effort you put in. Moreover, I offer to fix the situation in a way 
that should only improve things.

Secnd foreword: please read the whole mail. It starts with the 
complains and ends with the proposal.




I am very much tempted to redo the rt2860.git repository from start.

Right now, each new upstream release is stored once as .tar.gz and 
under a directory whose name includes the version. Aside for being 
grossly inefficient (unless Git does some magic), this very much voids 
using a source management too for tracking upstream changes. Right 
now, commit fea49085c3b26416a96c121f848dd032603f5cb7 (New upstream 
version) contains an import of many new files (under 
rt2860-source-1.8.0.0) and no single changed file.

If one wants to see the diff, s/he should diff manually. Even manual 
diff won't quite do it as the rt2860-1.7.0.0 tree also has changes to 
the upstream code.

Which brings me to the second reason for redoing the repository: 
upstream changes are applied directly. I am used to quilt and find it 
excellent for tracking upstream changes. How do you check the changes 
to upstream code now? Browsing the whole history is not an option. Ah, 
and the package already uses quilt anyway.

Another approach for tracking changes to upstream code could be a farm 
of branches, one for each self-contained feature. I am yet to master 
this so I don't feel like going this path unless others love it.  
A good guide for this approach is 
http://www.eyrie.org/~eagle/notes/debian/git.html

As of keeping track of released upstream tarballs, there is that nifty 
tool called 'pristine-tar' which does an exellent job keeping them in 
a separate branch of the Git repository.

Last point, please commit when a feature is complete. Mixing two 
features in single commit is bad later when one wants to see why 
something was changed. See b187e72da2abf5066d91c80df5afcb8d95fa7c0d 
(initial cleanup of makefiles, on makefile branch). This commit 
changes two .c files, renames one Makefile, deletes another, and 
moddifies two. Go figure how all these changes are related. I wouldn't 
call them "a cleanup" in any case.


After the rework I am proposing, the repository would have the 
following branches:
  * master - package is built from here
  * upstream - upstream releases (expanded tarballs) are tracked here
  * pristine-tar - a branch whhere pristine-tar keeps the service 
    information in order to be able to create upstream .orig.tar.gzs
  * makefile - same as now

I intent to start an empty repository named rt2860-clean.git and 
cherry-pich the commits from the current one one by one fixing each to 
follow the above layout. When done (all commits from rt2860.git 
migrated), I shall rename rt2860.git ti rt2860-old.git and 
rt2860-clean.git to rt2860-source.git. After this, you have to 
re-clone the repository. Your old clone can be kept so you can verify 
that I did not break things.

This would take some hours, so please tell me if you see something 
wrong in my plan.


-- 
dam            JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20081009/86a806ae/attachment.pgp