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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820005735.gy1...@yuggoth.org