From Fedora Project Wiki

(init & save)
 
(almost done)
Line 1: Line 1:
= Packit =
= Packit =


You may have also heard about this project as "Fedora Packaging Service", which is really just a working title. Packit is the name of the upstream project and we are trying to figure out the proper name using the Fedora brand.
You may have also heard about this project as "Fedora Packaging Service", which is really just a working title. [https://github.com/packit-service/packit Packit] is the name of the upstream project and we are trying to figure out the proper name using the Fedora brand.


Packit stands for multiple things:
Packit stands for multiple things:
* Packaging automation: get latest bits into Fedora rawhide with minimum amount of manual steps
* Packaging automation: get latest bits into Fedora rawhide with minimum amount of manual steps
* Upstream integration: let upstream know how their project stands in Fedora
* Upstream integration: let upstream know how their project stands in Fedora
* [https://github.com/packit-service/packit#ehm-whats-source-git Source-git]
* Reusing existing services: we don't want to reinvent the wheel: we'll use existing tools and integrate with present services and only write new code if we need to
* Reusing existing services: we don't want to reinvent the wheel: we'll use existing tools and integrate with present services and only write new code if we need to
* Be opt-in: you don't need to use it and you can opt out any time you want
* Be opt-in: you don't need to use it and you can opt out any time you want
Line 11: Line 12:
== Update workflows ==
== Update workflows ==


[https://pagure.io/fesco/issue/2084#comment-554463 Igor Gnatenko wrote] a very nice comment about this.
There are multiple distinct update scenarios which take place now for Fedora packages. Let's introduce them.
=== I am an upstream and downstream developer ===
This means that you care about Fedora a lot. Especially during development: you want to be sure that your project works well in Fedora.
It's also possible that you have a spec file in the upstream repo. And if you don't, you should consider adding it. That's how you can check that your project still has the correct RPM packaging.
This is the workflow which packit is trying to cover.
=== Upstream doesn't care about downstream ===
Sadly, this might be the case for most of the packages. Hence we need to maintain the spec file downstream.
This is where we think [https://github.com/packit-service/packit#ehm-whats-source-git source-git] will help.
=== rpm-bumspec is just enough ===
There is a bunch of packages where performing an update to latest upstream release is composed of updating version, release and a new changelog entry. This is trivial to automate.
=== We can generate the spec file ===
We already have a bunch of spec file generators that we use in Fedora: pyp2rpm, rust2rpm, gem2rpm, npm2rpm...
We can use them to perform the update: regenerate the spec file for the new upstream release.
Right now this is out of scope for packit.




Line 16: Line 46:


=== Spec files in upstream repos? Are you out of your mind? ===
=== Spec files in upstream repos? Are you out of your mind? ===
This indeed doesn't make sense for plenty of projects. But if upstream and downstream are the same people, then why ask them to maintain one file in multiple places? Why not just use automation to sync the file across multiple places?


=== What about the-new-hotness? ===
=== What about the-new-hotness? ===
We are in touch and aware of [https://github.com/fedora-infra/the-new-hotness/issues/189 the plans].
We feel like that the-new-hotness is trying to cover workflow 3) while packit aims for 1) and 2).


=== Are you trying to take away my package(s) from me? ===
=== Are you trying to take away my package(s) from me? ===


No.
No.
You are still the maintainer of your package and you are responsible for the spec file content. We are just trying to automate the tedious tasks.
=== Will you push to dist-git directly? ===
No. We will open pull requests and maintainers will be responsible for merging them.
=== Will the bot be able to merge those pull requests? ===
Short-term: no.
Long-term: a good topic for discussion. It's really up to Fedora project to allow such policy.
=== What about Fedora changes and mass updates? ===
Good question. We thought about this but haven't reached any conclusions yet.
=== Can I become an early adopter? ===
Yes, please! We are trying a list of people [https://github.com/packit-service/packit#candidates-for-early-adoption in the readme] at the moment.
=== How can I watch your progress? ===
The best thing right is to watch our [https://github.com/packit-service/packit upstream repo]. In future we are planning to write blog posts about new features.

Revision as of 21:59, 20 February 2019

Packit

You may have also heard about this project as "Fedora Packaging Service", which is really just a working title. Packit is the name of the upstream project and we are trying to figure out the proper name using the Fedora brand.

Packit stands for multiple things:

  • Packaging automation: get latest bits into Fedora rawhide with minimum amount of manual steps
  • Upstream integration: let upstream know how their project stands in Fedora
  • Source-git
  • Reusing existing services: we don't want to reinvent the wheel: we'll use existing tools and integrate with present services and only write new code if we need to
  • Be opt-in: you don't need to use it and you can opt out any time you want

Update workflows

Igor Gnatenko wrote a very nice comment about this.

There are multiple distinct update scenarios which take place now for Fedora packages. Let's introduce them.

I am an upstream and downstream developer

This means that you care about Fedora a lot. Especially during development: you want to be sure that your project works well in Fedora.

It's also possible that you have a spec file in the upstream repo. And if you don't, you should consider adding it. That's how you can check that your project still has the correct RPM packaging.

This is the workflow which packit is trying to cover.

Upstream doesn't care about downstream

Sadly, this might be the case for most of the packages. Hence we need to maintain the spec file downstream.

This is where we think source-git will help.

rpm-bumspec is just enough

There is a bunch of packages where performing an update to latest upstream release is composed of updating version, release and a new changelog entry. This is trivial to automate.

We can generate the spec file

We already have a bunch of spec file generators that we use in Fedora: pyp2rpm, rust2rpm, gem2rpm, npm2rpm...

We can use them to perform the update: regenerate the spec file for the new upstream release.

Right now this is out of scope for packit.


FAQ

Spec files in upstream repos? Are you out of your mind?

This indeed doesn't make sense for plenty of projects. But if upstream and downstream are the same people, then why ask them to maintain one file in multiple places? Why not just use automation to sync the file across multiple places?

What about the-new-hotness?

We are in touch and aware of the plans.

We feel like that the-new-hotness is trying to cover workflow 3) while packit aims for 1) and 2).

Are you trying to take away my package(s) from me?

No.

You are still the maintainer of your package and you are responsible for the spec file content. We are just trying to automate the tedious tasks.

Will you push to dist-git directly?

No. We will open pull requests and maintainers will be responsible for merging them.

Will the bot be able to merge those pull requests?

Short-term: no.

Long-term: a good topic for discussion. It's really up to Fedora project to allow such policy.

What about Fedora changes and mass updates?

Good question. We thought about this but haven't reached any conclusions yet.

Can I become an early adopter?

Yes, please! We are trying a list of people in the readme at the moment.

How can I watch your progress?

The best thing right is to watch our upstream repo. In future we are planning to write blog posts about new features.