On Thu Jan 23, 2025 at 2:28 PM GMT, Matthew Vernon wrote:
I'd much much rather MRs were associated with bug reports; that way I only have to remember to check one place for outstanding issues in my packages, and years down the line when I wonder "why did this change get made" I can look up the bug report in the BTS.
On Fri Jan 24, 2025 at 12:32 AM GMT, Otto Kekäläinen wrote:
Yes, for bugs that makes sense. Please note however that Merge Requests is more than just patches/bug fixes. It is a general mechanism to facilitate code reviews. It does not necessarily make sense to publish every commit as a patch on bugs.debian.org before committing it to the git repository. Also, in many cases it may be most efficient to file at bugs.debian.org only the issue, and do the actual code submission, testing, and re-submission as a Merge Request.
I don't think what you write here is incompatible with what Matthew suggested (unless I've misunderstood either or both of you).
The BTS is the project's System of Record for bug tracking. Many devs are quite comfortable with relying upon email alerts from the BTS. Rather than require them to adopt alerts from Salsa, if MRs from Salsa were automatically bridged to BTS bugs, either existing ones (where identified) or new ones, greybeards can continue with their established workflows, our system-of-record is kept up-to-date *and* the Salsa UI is available for new or prospective contributors.
I think you are arguing that all package changes, not just bug fixes, should be reviewed and thus go through the MR process, but would not warrant a BTS bug. I think, with functioning integration/automation, having potentially-superfluous BTS issues would not be a problem.
What I propose is very hand-wavey, I think it's worth exploring and sketching out in more detail.
(We appear to be carefully avoiding a discussion about the problems that the BTS has at the moment, but we can't avoid that forever.)
-- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎ j...@debian.org 🔗 https://jmtd.net
