Re: Why do we list individual copyright holders?
On Tue, Jan 02, 2018 at 10:51:56PM +0100, Markus Koschany wrote:
> Am 02.01.2018 um 21:57 schrieb Tollef Fog Heen:
> > ]] Markus Koschany
> > [...]
> > Also, the Standards-Version header is only recommended to be included,
> > it's not mandatory. If its existence offends you so much and you have
> > so few bugs to fix in your packages that the primary effort of
> > maintaining your package is updating the Standards-Version header then
> > just don't include it?
>
> I'm neither offended by this field nor emotionally affected by it. I'm
> just concerned about the fact that we maintain information in our source
> packages which
>
> a ) can be modified more efficiently outside of them
> b ) are redundant for a large group of maintainers
>
> 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?
So from my perspective I *want* this field because it helps me to understand
where I left the last time.
But there are others too: How's about when you orphan your package? Or some
other team mate jumps in? NMUs? QA-team?
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.
>
> The changelog is something which can be naturally derived from the
> changes made to a source package and excellent tools like
> git-buildpackage ("gbp dch") make this kind of work rather simple. A
> package description usually doesn't change. Only in rare circumstances
> it has to be adjusted. A Standards-Version header changes frequently,
> gets obsolete even faster and provides no valuable information to the
> end-user of a package (which a package description and changelog
> obviously do)
If the end user would be the only consumer of the package... The end user
usually only used the binary package, so in this logic we should stop
provoiding source pacakges and just ship binaries compiled on the maintainer
machine? After all, they can get the source upstream!
Of course this a gross hyperbolic, but I see a bit of a tedency in the latest
threads with the same overall topic to simplify a maintainers life (which is a
good thing). But usually in those topic only consider only one stakeholder
(mostly the maintainers side) and completly ignore other uses of such a
information... If we make things easier, I guess, we should concentrate to
find a way which makes it less effort in a sum and not me a bit sad because I
think of Debian being a collaborative thing and not a personal optimization
problem.
--
tobi
Reply to: