Hello all,
> I have created a group for the Debian Common Lisp Team (see [3]), and I have > added Peter, Christoph, Tobias and myself as owners. Please let me know if I > should add other DDs. For those of you who are not DDs, you have to create an > account on salsa, and request to join the group (see the Salsa documentation > referenced in [2]). I can login to the group and can see the others members :). > But before that, I would like to take this opportunity to discuss the git > workflow used by the team. The current situation is in my opinion quite > unsatisfactory, because several different workflows are being used, leading to > confusion, mistakes and loss of developers' time. +1 > For dimensions 3) and 4) there is consistency: the pristine-tar branch seems > to > be used nowhere, and the changelog entries are generated on the fly. > For dimension 5), my assumption is that git-buildpackage is used everywhere, > except probably for those packages that follow the one-branch-per-release > scheme. FYI: I use git-buildpackage even in cmucl and friends. I have to use options to set the upstream and debian branch. > Given what seems to be the dominant practice both in the team, my proposal > for standardization would be the following: Love having a good proposal from somebody who knows what he is doing! > 1) Use the "master" branch for Debian packaging, and "upstream" for tracking > upstream sources; when there is the need for an (old-)stable upload, a > dedicated branch with the name of the release (e.g. "stretch") should be > used Sounds good, but how will we know which commit we should use to create the branch on? The commit messages often go ‘prepare for release’, ‘this time for real’, ‘preparing again for release’… > 2) Store the tarball in the "upstream” branch > 3) Use a pristine-tar branch: this is clearly a break with current team > practices, but it makes cooperative work much easier; without that branch, > when somebody else creates a new Debian revision (e.g. -2) while forgetting > to run "uscan --force-download", then the upload is rejected because the > generated tarball has a wrong checksum Sometimes we need to remove non DFSG files. How would we handle this? I guess that even for the normal workflow there is some handy command to automate this? When a new upstream comes out, what do we do with ‘master’? Do you merge the new upstream? Do you archive the master branch and start a new one, based on the new upstream? > 4) For changelog entries, keep the current system (but make sure to use > dpkg-mergechangelogs to facilitate merging of branches) > 5) Use git-buildpackage > > Note that there are other options. For example, the GNOME team has decided 1) > to use DEP-14 branch names, and 2) to track upstream's git in the upstream > branch (see [5] and [6]). I used to track git but then I encountered: - upstream restarting git repositories (this was a while ago) - problems removing non DFSG files from the git repositories I guess there are fixes for the last problem? > Please tell your opinion on this issue (i.e. if you value standardization > within the team and, if yes, which workflow), so that we can move on with the > Salsa migration. Could we also agree to now upload without pushing the code to salsa? This was a problem I’ve hit in the past :( I also see no need for a commits ML… Apropos mailing lists: what to do with [email protected] <mailto:[email protected]> ? I gather that this is also going to go away? All in all I can 100% find me in your proposal, but can I humbly ask for some ‘howto’ commands so that I’m more certain that I’m not messing up? Best regards, Peter
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ pkg-common-lisp-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
