Re: Standardizing the layout of git packaging repositories
On 2014-08-20 02:21:35 +0800 (+0800), Thomas Goirand wrote:
> Well, for the changelog of OpenStack stuff, the FTP masters have
> express their opinion that it's just too big to be in every
> packages, so I have to *not* include them.
Understandable for some of those larger projects with many thousands
of changes (and I think python-pbr has introduced short-form
changelog generation options in more recent releases to reduce the
level of detail considerably so it hopefully becomes less of an
issue over time).
> As for the AUTHORS file, it isn't helpful at all from a package
> maintainer stand point. What's important is who is the copyright
> holder, and this should go directly in debian/copyright. To this
> day, I have no way to have that file fully right, considering how
> many contribution there is in OpenStack. I've raised that issue on
> the OpenStack dev list, but I don't think my message went through
> the correct way.
[...]
There still seems to be some legal contention around Apache License
2.0 expecting an authors list for a project. And I agree copyright
license headers are sort of a subjective issue if a given committer
feels their contribution to a particular file is or is not
significant enough to amend the years/holders there (also in many
cases the authors are not the copyright holders, but rather their
employers are, so the authors list can be essentially irrelevant
where copyright is concerned).
> Please name the "et cetera". Because it is my understand that it
> is the only thing I would "miss".
Well, as you mentioned, for Python packages the MANIFEST.in could be
getting autogenerated based on .gitignore exclusion patterns or
other details. Project version numbering could also be inferred from
git tags and embedded at release distribution time. If we're talking
in a more general sense (not specifically *your* packaging work on
OpenStack-specific projects),
http://www.gnu.org/software/automake/manual/html_node/The-dist-Hook.html
is a fairly classic example of where developers can expect to be
able to do just about anything between the development and release
states of their source code (like how python setup.py sdist could be
written to do anything while generating a tarball).
Asserting that the development and release state of source should be
identical represents a relatively nontrivial paradigm shift, in my
opinion (not that I think it's a bad idea, just that it indicates a
change in attitudes and behavior for upstream developers as well as
packagers downstream).
> If you think that's a problem, then I can add such a README in all
> of the packages I maintain this way, no problem. Altering the
> version string would be annoying though (I'd have to retag after
> each "git fetch upstream"), but if you insist really a lot, I may
> consider it. It will just take me a *long* time to write the
> READMEs though (since there's more than 100 packages which I
> maintain this way), but I think it's a good idea.
[...]
It only seems like a problem to me because it was, for a long time
(no longer?), convention that if you generated your own tarballs for
a source package (for repacking needs or otherwise) then you
adjusted the version and otherwise made it obvious you as a packager
had done so. Not taking those steps implied that you were asserting
these tarballs you were redistributing were the "original" upstream
release tarballs.
The easiest way I can see as an upstream to avoid confusion around
this is to stop releasing or otherwise emphasizing tarballs,
especially if downstream packagers won't be using them anyway and
will replace them with their own because their tools/workflows are
optimized to do that instead.
--
Jeremy Stanley
Reply to: