Re: Debian git workflow
On 03-04-15 17:55, Felix Natter wrote: does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? If this means that from one release to the next is only one commit, I personally don't like it. Usually history (with good commit messages) helps a lot with figuring out why what happened and where bugs were introduced. Not only for my own packages, but especially if I look at packages done by others, be it to fix some bug via NMU or because of take over. Basically, if you are only doing one commit, there is hardly any use for the repository, as I could get the same by downloading the packages from snapshot.d.o. Paul signature.asc Description: OpenPGP digital signature
Re: Debian git workflow
hello Paul, Paul Gevers elb...@debian.org writes: On 03-04-15 17:55, Felix Natter wrote: does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? If this means that from one release to the next is only one commit, I personally don't like it. Usually history (with good commit messages) That's exaggerated: I usually manage to split this into ~10 commits, but they all share the same timestamp. See: http://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git helps a lot with figuring out why what happened and where bugs were introduced. Not only for my own packages, but especially if I look at packages done by others, be it to fix some bug via NMU or because of take over. Basically, if you are only doing one commit, there is hardly any use for the repository, as I could get the same by downloading the packages from snapshot.d.o. Ok. If there is no strong opinion about it, I will choose one method based on personal judgement. Thanks and Best Regareds, -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87619dxefp@bitburger.home.felix
Re: Debian git workflow
Felix Natter fnat...@gmx.net writes: hello mentors, Dear mentors, does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? Thanks and Best Regards, Felix my workflow with more complex packages is that I start early and push the packaging (branching off the current alioth stable version) to github.com/fnatter/foo-debian-unstable, where I import almost every beta, fix the problems that occur and push the result to github. That way, my changes are securely stored and errors are easier to debug because I know which beta caused it (and it is less pressure on me when the actual release happens). However, this means that I copy all the changes to the stable alioth repo when the result happens, and while I try to put issues in separate commits, three issues remain: - all the pieces of work (update dep X, fix man page, bump Standards-Version, fix lintian Y, ...) have (almost) the same timestamp - different changes to one file share a commit (I know there is git functionality to split this, but this has so far been too error-prone for me). - collaboration is made more difficult As an example, see: http://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git The advantage of this approach is that the upstream/master branch does not contain all those unneeded (orig-)imports (which can be ~10 per release).. -- What do you think, which approach is better? Thanks and Best Regards, -- Felix Natter -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87384h2omh@bitburger.home.felix
Debian git workflow
hello mentors, my workflow with more complex packages is that I start early and push the packaging (branching off the current alioth stable version) to github.com/fnatter/foo-debian-unstable, where I import almost every beta, fix the problems that occur and push the result to github. That way, my changes are securely stored and errors are easier to debug because I know which beta caused it (and it is less pressure on me when the actual release happens). However, this means that I copy all the changes to the stable alioth repo when the result happens, and while I try to put issues in separate commits, three issues remain: - all the pieces of work (update dep X, fix man page, bump Standards-Version, fix lintian Y, ...) have (almost) the same timestamp - different changes to one file share a commit (I know there is git functionality to split this, but this has so far been too error-prone for me). - collaboration is made more difficult As an example, see: http://anonscm.debian.org/cgit/pkg-java/knopflerfish-osgi.git The advantage of this approach is that the upstream/master branch does not contain all those unneeded (orig-)imports (which can be ~10 per release).. -- What do you think, which approach is better? Thanks and Best Regards, -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv8pdvas@bitburger.home.felix
