I'd like to be a provenpackager, mainly since I want to add #VCS keys and it's quite annoying to have to manually request an ACL in 3 different branches in pkgdb just for this.
Also it's likely I will touch most of the desktop-related packages at some point.
I'm inclined to +1. Walters works on projects which end up being all over the place packaging-wise.
He's not terribly likely to tromp over existing maintainers.
+1 (from former FESCo member)
Mailed sponsors list for feedback. Added meeting keyword to add to the next meeting agenda.
-1, invalid rationale
Global changes such as adding #VCS "keys" (more like magic comments, I guess, seeing how they start with a '#') only make sense if there's a guideline that they should be there. That's something for FPC to decide, not some random provenpackager. I think magic (machine-parsable) comments are a misfeature we shouldn't get into. If we consider VCS keys to be useful, RPM needs to understand them, if not, then why would we want to allow somebody to add them to all packages?
I'm going out on a limb and assuming that Walters is only planning on adding the comment to a few packages, not the entire distribution, and as such I don't see a problem with it. Neither do I see a problem with him being able to commit to desktop packages, as well as others as he has offered programming help before.
So +1 from me.
Hi, yes that's correct, I don't plan to commit to all packages. Basically my current goal is packages within my "sphere" which is largely stuff in @desktop - @base.
Also Kevin specifically: I have proposed it as a standard:
I pinged spot but didn't actually get it added to their queue yet, I'll look at that.
Note I also patched RPM so it doesn't have to be a comment long term.
If it is accepted though, it's on my TODO list to write a script to automate adding them, where the package owner would confirm by some means "yes this is the right VCS URL". Being provenpackager would assist with that.
It's not that I mind you being a proven package Colin, but I cannot follow your rationale:
Hi Christoph, thanks for your comments.
That's true, however I would like to get some real-world testing of the proposal, and a good way to do this is by applying my scripts to a small but realistic set of packages. If the proposal gets changed later, I'm fully willing to update any packages I've changed.
It only exists if the current version is from a VCS snapshot, whereas I want the data to always be there, so that we can e.g. later perform correspondence checking between the source tarballs and the VCS, and so my scripts like "fedpkg-vcs pull-retarget HEAD" can automatically create a VCS snapshot that follows the guidelines.
The problem is that just because upstream uses a VCS doesn't mean a checkout is a valid tarball. For example, if you try doing that on any package from KDE SVN (other than the core KDE modules for which translations are in the kde-l10n langpacks), you'll end up with a package without translations, or with a build error on the %find_lang step (unless you want to duplicate the functionality of KDE's create_tarball.rb script). Another issue is with autotools-using packages, where sometimes generated files are included in tarballs, but not in the VCS. And then there's the completely arcane stuff like TIGCC where my tarball creation script copies stuff from 2 separate CVS repos and one directory which is not in CVS into a directory tree which doesn't match the one in CVS, building straight from CVS is outright impossible; there may be other projects doing something like that.
Oh, there are also now apps (e.g. Amarok, Konversation) where the code is in Gitorious git whereas the translations are in KDE SVN.
And no, translations in KDE SVN are not organized in per-app directories, the organization is language/module/application.po, e.g. de/extragear-multimedia/amarok.po, so they have to be collected by create_tarball.rb or a similar script. The create_tarball.rb script also adds a few lines to the toplevel CMakeLists.txt to build the translations.
I agree those are issues to be tackled, and in fact not all projects even use revision control, sadly. However, I suggest these are issues to be discussed in the FPC, not in this provenpackager request.
Yeah -- I've added a Discussion section to the bottom of the proposal page: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
Please add concerns directed at the policy there.
cwickert added the note that this isn't a packaging guideline yet and that's probably a sufficient note for this ticket.
This request was approved. Added to group. Congrats.
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.3 — Documentation