Re: Whatâ??s the use for Standards-Version?
On Aug 12, Josselin Mouette (joss@debian.org) wrote:
> Le mercredi 12 août 2009 à 11:06 -0400, Neil Roeth a écrit :
> > I've had some packages for years during which policy was changed and required
> > corresponding changes in my packages. In that case, the "previous developer"
> > was me, so I'm pretty confident that the previous developer did at least as
> > good a job as the current developer. :-)
> >
> > Your statement is a broad indictment of your fellow DDs as incompetent
> > developers who cannot perform the simple task of reading a few lines of policy
> > changes and determine if they imply any required changes for their packages.
> > Oh, well, it's your life, make all the enemies you want.
>
> When you only work on 6 packages for which you do a pretty good job, you
> tend to assume that other packages in the archive are maintained the
> same way. Well hereâ??s a scoop, a lot of packages in the archive belong
> to maintainers with hundreds of them in their hands, whether alone or in
> teams. Not all packages can receive the level of attention you are
> expecting.
You weren't saying people don't have time to give them attention, you were
saying they were incompetently making the changes. That's a different
argument and the one to which I responded.
If people don't have time to handle all their packages properly, they should
reduce the number of packages they maintain. I don't work on more packages
precisely because I know my DD time is limited and there is a minimum level of
attention that I think is required for each. I find the standards version and
upgrading checklist combo to be a net time saver.
> Try going through large parts of the archive when you need to test a
> change, for example. You may be surprised with the overall quality
> youâ??ll meet. After that, you may change your mind about expecting a
> declarative field to be conformant with the rest of the packaging.
I suspect you are right, the general quality might not be up to my standards.
However, as Manoj said, we did all sign up to maintain packages that conform
to policy, and I think the problem you are describing is with some DDs not
living up to their commitment rather than with the current process. Removing
this just makes it easier for people to be sloppy, shift work onto someone
else, and pretend they are living up to that commitment.
> Heck, I wouldnâ??t even trust *myself* to do that correctly. Bumping the
> standards version is a boring task I have to do so much that I never
> bother to have a look at the upgrading checklist, except for the most
> complex packages.
Why would you bump the standards version without actually checking to see if
the package meets that standard? That's worse than leaving it as it was. I
trust myself to make a conscientious effort to do it correctly if I choose to
do it at all, but I no longer trust you.
> > > This also assumes that the upgrading checklist contains all relevant
> > > information, which is also wrong for real cases.
> >
> > Even if it contains most of the relevant information, it is useful. If there
> > is something missing, that's when someone filing a bug can be a backup.
> > No need to throw out the baby with the bath water.
> >
> > BTW, I just glanced at the debian-policy bug page and see none related to the
> > upgrading checklist. Can you provide some bug numbers of those "real cases"
> > of missing information so I can check my packages? No hurry, if you've just
> > neglected to file them, do that first, then let me know. Thanks.
>
> Iâ??m not implying the upgrading checklist itself is incomplete.
I don't see any semantic difference between "the upgrading checklist is
incomplete" and "This also assumes that the upgrading checklist contains all
relevant information, which is also wrong for real cases".
> But there
> are other things in Debian than following the policy, you know? Most of
> the changes needed in packages are not here because of changes in the
> policy itself, but because of changes in other packages: packaging
> helpers, toolchain, menu system, various pieces of low-level plumbing
> that upstream redesigns every other monthâ?¦ these are the things that
> require attention. Not looking at whether the package is using the
> Speedo fonts.
Yes, so go ahead and leave it at the last version it complied with and wait
for the RC bugs. Just don't do more damage by changing it without making the
corresponding changes.
> > If there are current bugs, sure, you should attack those first. But you're
> > making a stronger argument that because the workflow is not bulletproof, that
> > invalidates the whole process and it should be discarded. I disagree, I find
> > it very useful and hope we keep it.
>
> It may be useful for you, but it is being an annoyance for others. The
> suitable thing to do in such cases would be to make the field optional.
> Would that be OK?
Disappointing, because I think it only serves to lower the standard (not
technically, but practically), but preferred over deprecating it.
>
> --
> .''`. Josselin Mouette
> : :' :
> `. `' â??I recommend you to learn English in hope that you in
> `- future understand thingsâ?? -- Jörg Schilling
--
Neil Roeth
Reply to: