-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damyan Ivanov wrote: > 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. Firstly, I disagree with this. Why can't we just clean up the existing repo to your liking. then at least its all in history from the 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. I'm not sure I understand what you mean here. > > 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. Again I am not sure I understand what you mean. the rt2860-1.7.0.0 tree is a pristine untarred source with the debian directory in it. > > 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. I simply followed http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream-real and copied the debian directory over and fixed up the patch series. If you prefer me to do it differently, just point me in the right direction. > > 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. will look into it > > 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. The makefile branch is a test branch for me to try and get rt2860 to build with kbuild. We would like to get these modules built using l-m-e and as such, something needs to be fixed to do so. I am not sure why you even bother to mention a branch in git. Git is meant for development, and as such, I made the branch after discussing with you about fixing the makefiles. (this discussion was some weeks back on irc) You stated that you thought upstream should fix the makefiles, so i made that branch so that if we want to build modules for packaging with l-m-e, then the dev packaging them could simply use that branch rather than have the changes applied to the normal source. The matter of the c files being different in that branch is because i forgot to run a debian/rules clean on the source before i pushed, and therefpore the patches that are in the master branch weren't reverted. Again I dont see why this is a big deal in a development branch. > > > 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. > > I personally dont see the point. But feel free to do so if you like. I am still working on getting kbuild to work, so please dont be offended when I make the makefile branch again. If you don't want me to do so, then I guess if you could supply patches that fix it, that would be even better :)
Glenn > > > ------------------------------------------------------------------------ > > _______________________________________________ > Debian-eeepc-devel mailing list > Debian-eeepc-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjt76UACgkQV8GyuTwyskPSNwCgioBvdEeGLmg1iDA+twG2uGxJ YbYAn2ixjqld9qxEqNErEk0xehCKw0IS =9fri -----END PGP SIGNATURE----- _______________________________________________ Debian-eeepc-devel mailing list Debian-eeepc-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel