Hi team, I think this is my first reply using notmuch+Messages mode, so I hope this works ok. David Bremner <david@tethera.net> writes: > As some of you might have noticed, I've recently done more than 170 > uploads to rebuild arch dh-elpa using packages (to fix the bug about > clearing HOME that dh-elpa 1.16 fixed). I still have a few more NMUs to > do (non-team packages), but I thought I'd mention a few things before I > forget > Thanks again! > 1) Please check your merge requests on salsa. For 13 packages where I > could not cleanly rebuild against master (or whatever the default HEAD > is), I did a merge request for the changes. > Ok, will do. > 2) It would be great if we as a team could decide on one or two git > workflows, and maybe record them somehow in the repo. The current > situation creates extra work for team wide uploads. > Nothing to add here. I use patches-unapplied, and have been steadily moving away from pristine-tar. 'hope it isn't an inconvenience to grab the orig tarball from the archive using some other method. > 3) Another potentially controversial idea is to have master (or whatever > "debcheckout -a" fetches) always buildable and corresponding to > unstable. This would require all UNRELEASED changelogs live on branches > I'm mostly fine with this if there's the stigma against uploads that don't add anything that is user-facing is dropped. Why? It's a best-practises git workflow style (feature branch merged to stable/release branch). That said, from what I've read there's often freedom to rebase the feature branches to make git history cleaner, and this seems like it could negatively affect teamwork on a single devel branch or else atomise packaging work into a bunch of branches. Personally I prefer to gradually push a bunch of improvements to master and then role them up into a release when a significant reason presents itself, and do the testing then. Also, I think CI for all packages, for every commit is a bad thing from a energy consumption and carbon-footprint perspective... Can we compromise by saying that the responsibility to test/fix/release is on the primary uploader if that person chooses to use the accumulated UNRELEASED method? I can write trivial script to head -1 the changelog and send an email to the uploader if necessary, so that these types of repos can be pruned from big jobs like the recent dh-elpa 1.16 rebuild one. > 4) We do have some packages in the team that need some easy QA work > (checking standards versions, update Vcs-*, etc...) Does the team tracker page have the comprehensive list? Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature