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: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
_______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
