[Debian-eeepc-devel] rt2860 Git reporitory

[Glenn Saberton]

-----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 at 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-----