On Thu, 2019-12-05 at 18:59 +0100, Alexis Ballier wrote: > On Thu, 2019-12-05 at 18:39 +0100, Michał Górny wrote: > > On Thu, 2019-12-05 at 17:36 +0100, Alexis Ballier wrote: > > > On Thu, 2019-12-05 at 17:09 +0100, Michał Górny wrote: > > > > +################################################################ > > > > #### > > > > +# > > > > +# This file specifies packages that are considered deprecated > > > > (but > > > > not > > > > +# masked yet). It will trigger pkgcheck warnings whenever other > > > > +# packages depend on them. > > > > > > > > > > repoman would be more useful for this > > > > > > > Then feel free to take repoman over, and start maintaining it. I've > > lost interest in contributing to the project after the last pointless > > refactoring made adding anything even more effort, and it doesn't > > seem > > that anyone else has. > > > > Given that pkgcheck is a. faster by design, b. running checks > > in parallel, c. has sane API making contributing a pleasure, I don't > > really see a point in putting any more effort to support a dead > > repoman. > > > > it's not about who's maintaining what here... > just s/pkgcheck/QA tools/ and be done with it
Oh, I've listed pkgcheck there because it's the only tool implementing the file at the moment. I'm happy to replace it with larger list or something more generic once there are other tools. However, I believe that saying 'pkgcheck' right now has the advantage that devs know which tool to use to see the result. > unless i missed something, repoman is still the standard for pre-commit > checks and raising everyone's attention on potential > improvements/issues; Nope. Per quite recent Council meeting pkgcheck is fully acceptable alternative, and to my knowledge a number of devs have switched already. Because they value their time and good package quality. > pkgcheck is mostly used by your CI checks for > producing huge reports, which is nice but addresses a different problem There is nothing stopping you from running pkgcheck locally. In fact, it should work out of the box these days. If you have any problems, please report them and I'm sure they will be addressed promptly. > i could see this file being useful for auto-generating lists on qa- > reports like for eapis too I don't think there's really a point in duplicating this. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
