Packit-as-a-Service case studies and tips

[Jun Aruga]

I am considering using Packit-as-a-Service [1] for an upstream
project, as the maintainer of the project suggested managing the RPM
spec file on the upstream's repository in Github.

Could you tell me some case studies of the upstream project using
Packit-as-a-Service?
I know rebase-helper [2] is using it.

What I want to do is
* to check the RPM spec file at the pull-request timing on GitHub,
building it on specified build targets (rawhide or fNN).

My questions are
* How to manage a RPM spec file on the upstream repository,
synchronizing it with Fedora rawhide's one.
  For example, in case of rawhide, the RPM spec file's release version
is sometimes automatically updated.
  I am thinking of managing the RPM spec file on the upstream without
%changelog to synchronize it easily.
* Is it possible to manage the RPM spec file including %PatchN and the
patch file on the upstream repository?

[1] https://packit.dev/packit-as-a-service/
[2] https://github.com/rebase-helper/rebase-helper

Thanks.

-- 
Jun | He - His - Him

[Jun Aruga]

>  * How to manage a RPM spec file on the upstream repository,
synchronizing it with Fedora rawhide's one.

As my first step, I am trying to use Packit, having separately managed
the RPM spec file that is only used to run the %check section on the
Fedora scratch build at the pull-request in the upstream.
Seeing the resources such as https://github.com/packit-service/packit .

-- 
Jun | He - His - Him

[Tomas Tomecek]

Hi Jun, thanks for reaching out! I'd suggest CCing someone from our
team in future to make sure we see your message. It's good though you
started the discussion on fedora-devel.

On Thu, Apr 2, 2020 at 8:54 PM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  I am considering using Packit-as-a-Service [1] for an upstream
>  project, as the maintainer of the project suggested managing the RPM
>  spec file on the upstream's repository in Github.
>
>  Could you tell me some case studies of the upstream project using
>  Packit-as-a-Service?
>  I know rebase-helper [2] is using it. 
There is a bunch of projects who are already integrated with
packit-service at this point:
* https://github.com/beaker-project/restraint/blob/master/.packit.yaml
* https://github.com/abrt/faf/blob/master/.packit.yml
* https://github.com/containerbuildsystem/atomic-reactor/blob/master/.packi...
* https://github.com/fedora-modularity/libmodulemd/blob/master/.packit.yml
* https://github.com/packit-service/ogr/blob/master/.packit.yaml (and
us obviously)
* ...

>  What I want to do is
>  * to check the RPM spec file at the pull-request timing on GitHub,
>  building it on specified build targets (rawhide or fNN). 
This the basic use case which packit is helping to solve.

>  My questions are
>  * How to manage a RPM spec file on the upstream repository,
>  synchronizing it with Fedora rawhide's one. 
Ideally, you'd maintain the spec upstream and packit will copy [1] it
for you when you perform releases.

>    For example, in case of rawhide, the RPM spec file's release
> version
>  is sometimes automatically updated.
>    I am thinking of managing the RPM spec file on the upstream without
>  %changelog to synchronize it easily. 
Packit does not sync changelogs b/w the two places because they tend
to differ. As for release number -- those can get out of sync. Luckily
everything is git so changes can be seen easily and reverted or
updated.

>  * Is it possible to manage the RPM spec file including %PatchN and
> the
>  patch file on the upstream repository? 
It is, just include the patch file in the repo.


Please let us know if you need any help with setting everything up.


[1] https://packit.dev/docs/configuration/#supported-jobs
(propose_downstream job)

[Miro Hrončok]

On 08. 04. 20 11:33, Tomas Tomecek wrote:
> > My questions are
> > * How to manage a RPM spec file on the upstream repository,
> > synchronizing it with Fedora rawhide's one.
>  Ideally, you'd maintain the spec upstream and packit will copy [1] it
>  for you when you perform releases. 
Once again I would like to point out that the canonical source of the spec files 
in Fedora is the Fedora git. Copying upstream specfiles to Fedora via automation 
and saying "ideally, you'd maintain the spec upstream" goes against this
principle.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Ernestas Kulik]

On Wed, 2020-04-08 at 11:39 +0200, Miro Hrončok wrote:
>  On 08. 04. 20 11:33, Tomas Tomecek wrote:
>  > > My questions are
>  > > * How to manage a RPM spec file on the upstream repository,
>  > > synchronizing it with Fedora rawhide's one.
>  > Ideally, you'd maintain the spec upstream and packit will copy [1]
>  > it
>  > for you when you perform releases.
>  
>  Once again I would like to point out that the canonical source of the
>  spec files 
>  in Fedora is the Fedora git. Copying upstream specfiles to Fedora via
>  automation 
>  and saying "ideally, you'd maintain the spec upstream" goes against
>  this principle.
>  
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenanc 
As someone who also maintains the code for multiple packages, I say
tough luck. The workflow for keeping upstream changes buildable (and
having the ability to test the changes) and downstream package
specification in sync with said changes could not be worse currently.
Packit solves that for me *and* gives me the ability to pull in
whatever was done downstream.

-- 
Ernestas Kulik
Software Engineer
Base Operating Systems - Core Services - ABRT
Red Hat Czech, s.r.o.

[Miro Hrončok]

On 08. 04. 20 12:26, Ernestas Kulik wrote:
>  As someone who also maintains the code for multiple packages, I say
>  tough luck. The workflow for keeping upstream changes buildable (and
>  having the ability to test the changes) and downstream package
>  specification in sync with said changes could not be worse currently.
>  Packit solves that for me*and*  gives me the ability to pull in
>  whatever was done downstream. 
As someone who routinely does mass changes across the entire collection I 
appreciate you pull in whatever was done downstream. But putting the spec to 
upstream usually means this part is neglected.

In other words, if you are prepared to manually sync the 2 diverging spec files, 
feel free to keep your spec files on the Moon as far as I am concerned, but 
suggesting to other maintainers to maintain their Fedora spec files outside of 
Fedora without stressing this very important point is not helpful.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok