[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: salsa.debian.org: merge requests and such



On Fri, Nov 09, 2018 at 05:41:53PM +0000, Matthew Vernon wrote:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
> >> Colin Watson <cjwatson@debian.org> writes:
> >> > This seems like a little bit of an overreaction to somebody removing a
> >> > single redundant line from a control file, though.  Is moving it really
> >> > worth the added friction?
> >> 
> >> It's more a reaction to the "if you didn't want random commits onto
> >> master, you shouldn't have put it under debian/" policy. I don't, so I
> >> shouldn't have.
> >
> > We're not talking about "random" commits, though, are we ?  We're
> > talking about a commit that a DD thought was very likely a good idea.
> > Were they wrong ?  It would be nice to have a proper reference.
> 
> The particular commit was fine (and had it come as a MR or bug report or
> whatever I'd have had no problem with it at all).

I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)

Honestly, I think it's better for Debian as a whole that people should
be able to do that kind of bulk cleanup with absolutely minimal
friction, rather than the "open 2000 bugs, wait a year, find that 500 of
them are still open" dance that I'm sure many of us are familiar with;
it's one thing when it requires non-trivial thought or testing or when
the substance might in some way be controversial, but when the commits
are this simple it's hard to see a cost-benefit analysis working out
favourably for filing a large number of bugs or even MRs, either for the
developer doing the original work or the maintainers receiving the
patches.

(I do have a few of the packages I maintain in slightly more restrictive
namespaces, admittedly, in cases where my opinion is that working on
them requires an unusual amount of care, but they're still team
namespaces; and I could be convinced that I should open them up further.
I mostly use the "debian" namespace, though, and am happy not to have to
put more than the absolute bare minimum of effort into dealing with the
sort of "chore" commits being done directly here as a result.)

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: