Re: Lintian based autorejects
Russ Allbery wrote:
> Luk Claes <firstname.lastname@example.org> writes:
>> As before Manoj seems to interpret things and word things so they fit
>> the way he can use them at the moment he needs them. As long as that
>> continues I'm not going to even try to get the Debian Policy and RC bug
>> policy consistent and the Debian Policy will remain not useful for
>> anything release related as it will be incomplete and sometimes
>> conflicting with actual practice.
> On behalf of the other four Policy maintainers who aren't Manoj and who so
> far as I know you don't have personal conflicts with, let me just say
> "gee, thanks." This is how we can ensure that Policy continues not to be
> the document that it should be and people have to keep reading multiple
> documents to figure out what they're required to do.
Note that this predates me joining the Release Team, so I don't think
it's just a personal issue between Manoj and me...
> I have a limited amount of time to spend on Debian as a whole, which is
> divided between Lintian, Policy, and my own packages. Reading things like
> the above is extremely demoralizing and both tends to reduce that overall
> time committment and the amount of time I'm willing to invest in Policy in
> particular. If people are going to undercut or ignore that work, what's
> the point of me trying to fight upstream?
Exactly, I have only a limited amount of time and don't want to spend it
on demotivating discussions with Manoj about why he uses two standards.
Though just ignoring these is also of no help, so in general I just
point out when he does it (probably not in a very objective way due to
how hard it demotivates me to see people in such positions doing that).
For the actual matter at hand I think it's very wrong to do a MBF
without going through d-devel for several reasons:
- it gives developers a chance to fix bugs before they are filed to
decrease high bug traffic that is normal for MBFs
- it gives developers a chance to discuss the severity and tags that
should be used without the need to change them afterwards
- it gives developers a chance to change the preconditions for bugs
before they are filed
- it gives developers a chance to share ideas on how to fix the bugs and
include that information in the bug reports
- it gives developers a chance to update any relevant documentation
before the bugs are filed