Upstream for dist-git [RFC]

[Miroslav Suchy]

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