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