On Wed, Oct 30, 2024 at 10:32:45PM -0700, Don Armstrong wrote: > On Tue, 29 Oct 2024, Bill Allombert wrote: > > On Fri, Oct 04, 2024 at 11:04:26PM +0200, Bill Allombert wrote: > > > In any case, please decide either to commit to maintain this package or > > > to let me > > > do it before it is too late for the freeze. > > > > I reviewed debbugs 'git log'. There are work around May done by you > > and Otto to make the GIT repository in a state suitable to an upload > > to unstable, which is a very good news. Unfortunately, this effort was > > not concluded by an upload, so the long standing RC bug was not fixed > > in unstable. > > First off, sorry for taking so long to respond, and I appreciate you > continuing to be polite in response to my silence.
Thanks for answering! > The reason why I didn't upload, is because I didn't want to commit to > maintaining the package through a stable release. What precisely worry you ? The need to do security update ? RC bugs ? User support ? > If you're willing to commit to maintaining it, I'm happy for you to > become part of the debbugs team for the purpose of maintaining the > packaging of the upstream codebase in Debian, committing and tagging > those releases as appropriate in salsa. It seems there is no tag in the GIT repository at all ? (maybe you have local tags that you did not push ?) > In exchange, I'll request that you do the following: > > 1) Keep issues which are open in the debbugs package and require fixes > upstream (or new development) open. [I use this as the "upstream" bug > tracker, which is why I don't want to remove the package from Debian. > Once they are fixed upstream, you can close them as usual in a > changelog. I commit to making sure the changelogs in release_2.6 and > master reflect those fixes.] > > 2) Choose a branch name other than debian for maintaining the Debian > packaging (as we're using that for what runs on bugs.debian.org). [Or > alternatively, coordinate with me and the rest of the team so we can > have a flag day and change the branch names.] I probably need one branch per upstream version anyway. Maybe debbugs-$version > 3) Coordinate with me before releasing anything > 2.6 that isn't tagged > as a release (but feel free to cherry pick patches that you want to > carry as Debian specific patches; I'll try to keep backporting useful > ones to 2.6 since that's what the debian branch is running from.) Practically, should I base my package on 2.6.1 or 2.6.0 ? How do I know when something is 'released' ? 2.6.1 seems to fixes the most pressing issues. The debian/changelog is not up-do-date. By the way, is psuedoheader a typo for pseudoheader ? %grep psuedoheader -r . ./t/06_mail_handling.t:# now check to see if we can close a bug using a psuedoheader done ./debian/changelog: * Add support for a Done: psuedoheader (closes: #950133) ./scripts/process:#psuedoheaders ./scripts/process: last if $phline !~ m/^([\w-]+): # psuedoheader ./Debbugs/Config.pm:packages without a maintainer and bugs missing a Package: psuedoheader Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
signature.asc
Description: PGP signature
