Am 03.01.2018 um 10:11 schrieb Tobias Frost: > On Tue, Jan 02, 2018 at 10:51:56PM +0100, Markus Koschany wrote: [...] >> In fact my primary effort is to improve all packages which I maintain >> and touch and by raising my voice on this list I hope that future >> maintainers will suffer less from obvious design flaws. I am not aware >> of a good reason why keeping the Standards-Version field would help me >> in achieving this goal. > > Well, I think several arguments have been brought up in this thread already. > Can you briefly explain how you will manage to ensure that your pacakge > does not violate a (new) Policy? That you still know in x years which version > you've used? Will you then check the complete package again? Is this less work > than maintaining a simple field?
I know all my packages and I am one of those who actually maintain them, read the docs and uphold our numerous rules. That's why I am participating in this thread because such seemingly simple things like the S-V field, the Vcs fields or d/copyright do affect my daily work. I know the Policy for my packages and if I don't know something I just look it up. I review the Policy changes when they are announced and apply them as needed. I can easily tell that all my packages which were already updated to S-V 4.1.2 are also compliant with 4.1.3 for example. > So from my perspective I *want* this field because it helps me to understand > where I left the last time. Sure. You are entitled to your own opinion. If you want to use the S-V field as a bookmark, please do. But others believe this field could be maintained either outside of the source package or it is not needed at all for their workflow hence they call it an optional feature. I believe debian/control should only include technically required fields and be as simple as possible. Somehow other distributions like Fedora, Gentoo or even FreeBSD can exist without the S-V field to describe their packages. > But there are others too: How's about when you orphan your package? Or some > other team mate jumps in? NMUs? QA-team? Almost all my packages are team-maintained and I believe at least my Java team mates don't need it either. When it comes to those kind of topics we are on the same page because we like to do less redundant work. Most NMUers ignore the S-V field completely because usually they only make targeted fixes. > Maintaining the S-V out of source might sound as a solution, but IMHO it > isn't: > d/control is much more "present" (available) than some other website, > database... etc... And information seems to lose sync when not maintained > closely together. Yes, I don't think that this would save time, contraire. > One > will still need to check if changes in policy applies to the package and > suddently one would need to check two places and wonder if someone forgot to > push an update... > >> If the Standards-Version field is optional, great! Then let's get rid of >> it right now. The Lintian error is presumably as mistake, isn't it? > > In the light of this discussion, I fear we should make S-V mandatory; IMHO > this > is a minor thing to maintain but with a much higher cost in not having it. [...] I'm really surprised that those who upload a package once in a blue moon have the strongest opinions in this thread when we discuss how we can reduce the maintenance burden and do something more useful with our free time. You uploaded 19 packages last year, Tollef 3 and Lars 4. It would be more helpful if you took one step back and tried to understand what it means to maintain hundreds of packages and how time consuming and dull some of our self-imposed packaging tasks can be.
signature.asc
Description: OpenPGP digital signature
