Hi, Adam Šamalík took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babinčák he created upstream for dist-git:
https://github.com/release-engineering/dist-git
This is first attempt and request for comments.
The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git...
Feel free to experiment with this project and we are looking for your questions and comments.
I have one question thou: There is no license information in files header but two files: scripts/httpd/upload.cgi - GPLv1 scripts/dist-git/pkgdb_sync_git_branches.py - GPLv2+ Everything else is without license. Can I assume that we can realease the code under GPLv2+? The author of upload.cgi seems to be Kevin F. - Kevin, are you willing to change license your file to GPLv2+ so we have uniform license across all files?
Future plans: 1) Listen to your initial feedback and do alternations according to your feedback 2) After license clarification, announce this project to Red Hat and CentOS rel-engs and ask them to merge their changes of dist-git to this upstream. 3) Get this package into Fedora distribution 4) Change Fedora dist-git server to use this package. .... 10) Enjoy the benefits of common upstream.
On Thu, 16 Apr 2015 09:42:44 +0200 Miroslav Suchý msuchy@redhat.com wrote:
Hi, Adam Šamalík took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babinčák he created upstream for dist-git:
https://github.com/release-engineering/dist-git
This is first attempt and request for comments.
Great idea/work. ;)
The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git...
Feel free to experiment with this project and we are looking for your questions and comments.
Will try and find time to do so.
I have one question thou: There is no license information in files header but two files: scripts/httpd/upload.cgi - GPLv1 scripts/dist-git/pkgdb_sync_git_branches.py - GPLv2+ Everything else is without license.
All the work in the ansible repo should be covered under the FPCA, so without any explicit license I would think it would be MIT. We could see about getting a list of folks who worked on it and getting them to put it under GPLv2+ if you like. Or we could just stay with MIT?
Can I assume that we can realease the code under GPLv2+? The author of upload.cgi seems to be Kevin F. - Kevin, are you willing to change license your file to GPLv2+ so we have uniform license across all files?
I did not author that file. ;)
It was written by Jesse Keating in 2010. We could try and contact him I suppose?
Future plans:
- Listen to your initial feedback and do alternations according to
your feedback 2) After license clarification, announce this project to Red Hat and CentOS rel-engs and ask them to merge their changes of dist-git to this upstream. 3) Get this package into Fedora distribution 4) Change Fedora dist-git server to use this package. .... 10) Enjoy the benefits of common upstream.
:) Excellent.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/17/2015 05:01 PM, Kevin Fenzi wrote:
All the work in the ansible repo should be covered under the FPCA, so without any explicit license I would think it would be MIT. We could see about getting a list of folks who worked on it and getting them to put it under GPLv2+ if you like. Or we could just stay with MIT?
Any free license is fine. MIT is fine as well.
Mirek
On Thu, Apr 16, 2015 at 09:42:44AM +0200, Miroslav Suchý wrote:
Hi, Adam Šamalík took dist-git files from fedora-infra ansible.git. He separated what belongs to dist-git itself and what is Fedora specific and with cooperation of Dan Mach and Palo Babinčák he created upstream for dist-git:
https://github.com/release-engineering/dist-git
This is first attempt and request for comments.
The changes from ansible.git version are described here: https://github.com/release-engineering/dist-git/blob/master/changes.txt and he extracted some code to be configuration driven: https://github.com/release-engineering/dist-git/blob/master/configs/dist-git...
Feel free to experiment with this project and we are looking for your questions and comments.
I have one question thou: There is no license information in files header but two files: scripts/httpd/upload.cgi - GPLv1
Unless I am mistaken, the file says just GPL without specifying a version, which according to our wiki page [1] means:
GNU General Public License (no version) A GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include.
So seems to me that this is not a problem :)
[1] https://fedoraproject.org/wiki/Licensing:Main
I do have a few questions about the project itself though :)
- Any special reason to use tito? It seems the spec file generated isn't quite complete (cf the %description) and I have heard a couple of horror story about it so I am kinda curious to know what it brings.
- While I find having a single upstream place a great idea I wonder how this will do in practice. For example, I know Fedora has been wanted to move away from md5 into sha for a while. How will this work then for the other instances? Are RH and CentOS also going to make the move? At the same time as Fedora? Basically, I was wondering between sharing a RPM vs sharing an ansible playbook which one might be easier in the long term.
- Out of curiosity, would the dist-git systemd service conflict with the git-daemon one?
- The two cron files are empty is this desired?
- Finally, recently I was wondering about changing the upload.cgi which is a little bit painful to debug when something goes south by a simple one-file flask application that would do the same. Anyone has any thoughts on this idea?
Turned out I found more questions that I thought, hope you don't mind :)
Thanks, Pierre
On 04/17/2015 05:18 PM, Pierre-Yves Chibon wrote:
- Any special reason to use tito?
No special reason. Just that it is IMO simplest thing to get rpm out of git repo.
It seems the spec file generated isn't quite complete (cf the %description)
Indeed :). As I said it is first take. I am sure Adam will fix it soon.
and I have heard a couple of horror story about it so I am kinda curious to know what it brings.
Horror stories? I am eager to hear them :) What Tito brings? Well 8 years ago we had in RHN Satellite team simple script to build rpm. We then made an Makefile, then we wanted some features, like development rpm, better track what was build from where etc. The Makefile was several hundreds lines long. So we split it into several ones. Then we had problem with escape hell (\$foo). So we decided to rewrite it to Python. Since then lot of features landed there and it is very powerful tool. So what it brings? It saves you time and build your rpm package within few seconds. And while it can be technically done by small script, it would take me several years ago. :)
- While I find having a single upstream place a great idea I wonder how this will do in practice. For example, I know Fedora has been wanted to move away from md5 into sha for a while. How will this work then for the other instances? Are RH and CentOS also going to make the move? At the same time as Fedora?
Ideally this would be config driven.
Basically, I was wondering between sharing a RPM vs sharing an ansible playbook which one might be easier in the long term.
I do not agree here. Yes it is doable. And you can see RPM as standardized playbook :). But it give you standardized auditing, signing... How would you sign shared playbook?
Out of curiosity, would the dist-git systemd service conflict with the git-daemon one?
The two cron files are empty is this desired?
No idea here. I will leave this on Adam to answer.
- Finally, recently I was wondering about changing the upload.cgi which is a little bit painful to debug when something goes south by a simple one-file flask application that would do the same. Anyone has any thoughts on this idea?
Well Adam just took what is *now* in our ansible.git. Right now the goal is to create drop-in replacement. Functional improvement are not on radara *right now*, but feel free to request them in GitHub issues or even send PR there.
Mirek
On Fri, 2015-04-17 at 17:18 +0200, Pierre-Yves Chibon wrote:
- Finally, recently I was wondering about changing the upload.cgi which is a little bit painful to debug when something goes south by a simple one-file flask application that would do the same. Anyone has any thoughts on this idea?
I've been thinking about this exact same point for about 3 years, ever since I deployed that upload.cgi script into my infrastructure at $previous_dayjob.
As a coincidence, I've spent most of today reworking the way pyrpkg interacts with the lookaside cache, the end goal being to move away from md5.
And with the thought of replacing that upload.cgi script in the back of my head, I've made sure to make the code modular enough that we could just add a new class to talk to a hypothetical Flask app you'd write in the future.
I'm nowhere near ready to send those patches though (I'll probably need a few more days to finish implementing it and test it properly), but be sure that replacing upload.cgi should eventually become much easier, at least from the pyrpkg side. :)
rel-eng@lists.fedoraproject.org
-
Kevin Fenzi -
Mathieu Bridon -
Miroslav Suchý -
Pierre-Yves Chibon