On 07/03/19 17:36, Tomas Tomecek wrote:
Hi Miro, sorry for a late reply: I wanted to think it through. Comments inline.
On Tue, Feb 26, 2019 at 4:43 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 20. 02. 19 23:24, Tomas Tomecek wrote:
Hello,
at DevConf.cz, we have introduced a new project: packit [1] [2].
[1] https://www.youtube.com/watch?v=KpF27v6K4Oc
[2] https://github.com/packit-service/packit
From the ticket:
>> FESCo is concerned that the presented idea of how this automation
>> should work is only applicable to a very limited set of packages and
>> would rather see a focus on automating stuff for greater
>> audience.
>
> Yes and no. With source-git [3] this is applicable to any project.
>
> [3] https://github.com/packit-service/packit#ehm-whats-source-git
This sounds like it is only applicable to projects:
- controlled by Fedora AND
- not concerned by the separation of concerns between upstream and downstream.
That's correct. Our short-term plan for packit is that people who are
upstreams (or are interested in the source-git workflow) would use it
to land their releases into Fedora.
For other project that don't want to have spec file in upstream we could
use release-monitoring.org, which will create PR in dist-git (these are
plans for future, right now we are only creating bug in bugzilla)
without the need to bother upstream developer.
It's than on package maintainer to look at the changes and approve or
reject them.
However it says something about source-git only projects as well. This seems
like it is adding one extra level of complexity. Care to elaborate how this
works exactly?
A) for the package maintain who deliberately chose to do this
Such packager would only work in the source-git/upstream repository
and would NOT need to touch dist-git in any way: packit would handle
everything.
Basically: do work in the upstream repo, make a release and packit
would propose a PR in Fedora dist-git to update to the upstream
release. Very similar steps for source-git.
B) for a provenpackager doing a mass change (e.g. removing py2 subpackages)
Just do it. We plan for packit to sync spec file changes back to
upstream/source-git (listen to fedmsg events from dist-git). So that
they are equal in both places.
C) for releng doing a mass rebuild
^ it's the same
I understand that the workflow is not suitable for a bunch of
projects. Right now we have a set of goals to fulfill. Once they are
done (by Flock), we can start talking about how to make it suitable
for everyone. If that makes sense.
Tomas
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
