Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
(*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute)
Marcin
To support this, I try to keep a mirror in GitHub for my packages... But it's hard to stay in sync sometimes and nobody really knows it's there. It'd be nice if this were supported directly, perhaps by automatically mirroring all packages in GitHub, like the ASF does, and emailing maintainers when activity occurs.
On Sun, Oct 18, 2015, 09:36 Marcin Zajączkowski mszpak@wp.pl wrote:
Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
(*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute)
Marcin
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Thanks for your responses, guys!
On 2015-10-18 16:57, Christopher wrote:
To support this, I try to keep a mirror in GitHub for my packages... But it's hard to stay in sync sometimes and nobody really knows it's there. It'd be nice if this were supported directly, perhaps by automatically mirroring all packages in GitHub, like the ASF does, and emailing maintainers when activity occurs.
I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests). GitHub is currently probably the most popular Git hosted repositories provider. Maintainers could subscribe to their project on GitHub to get notifications about the new PRs (or it could be done automatically if GitHub login is associated with FAS).
There could be optionally a support in fedpkg for merging that PRs easily (or just an Git alias to do it - with one precised repo location it would not be a problem).
Automatic mirroring could be probably done automatically by GitHub. Things like GitHub account association in FAS or CLA verification (https://github.com/google/guava/pull/2163#issuecomment-141642504) would require some additional work.
Nevertheless I agree with Kevin about dependence on GitHub in that element of the workflow (although not the crucial one). Maybe GitHub integration would not be so beneficial as probably most of the contributions come from people already related to Fedora and it would be better to have that interface in the internal Fedora infrastructure one day.
Marcin
On Sun, Oct 18, 2015, 09:36 Marcin Zajączkowski mszpak@wp.pl wrote:
Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
(*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute)
Marcin
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski mszpak@wp.pl wrote:
Thanks for your responses, guys!
On 2015-10-18 16:57, Christopher wrote:
To support this, I try to keep a mirror in GitHub for my packages... But it's hard to stay in sync sometimes and nobody really knows it's there. It'd be nice if this were supported directly, perhaps by automatically mirroring all packages in GitHub, like the ASF does, and emailing maintainers when activity occurs.
I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests). GitHub is currently probably the most popular Git hosted repositories provider. Maintainers could subscribe to their project on GitHub to get notifications about the new PRs (or it could be done automatically if GitHub login is associated with FAS).
There could be optionally a support in fedpkg for merging that PRs easily (or just an Git alias to do it - with one precised repo location it would not be a problem).
Automatic mirroring could be probably done automatically by GitHub. Things like GitHub account association in FAS or CLA verification (https://github.com/google/guava/pull/2163#issuecomment-141642504) would require some additional work.
Nevertheless I agree with Kevin about dependence on GitHub in that element of the workflow (although not the crucial one). Maybe GitHub integration would not be so beneficial as probably most of the contributions come from people already related to Fedora and it would be better to have that interface in the internal Fedora infrastructure one day.
Marcin
Perhaps GitLab might be more appealing, since it is a FOSS service and it could be brought in-house relatively easily?
On Sun, 18 Oct 2015 21:12:42 -0400 Neal Gompa ngompa13@gmail.com wrote:
Perhaps GitLab might be more appealing, since it is a FOSS service and it could be brought in-house relatively easily?
Not really.
There was an effort started I think in 2012 or 2013 to package it... https://fedoraproject.org/wiki/GitLab
I don't think adapting it would be at all easy.
kevin
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski mszpak@wp.pl wrote:
I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests).
While I like the idea of making it easier for people to submit patches, I'm not sure setting up a read-only GitHub mirror is the answer.
In my day job, I happen to maintain a huge GitHub mirror of a large open source code repository where the upstream has not yet moved to Git. Unfortunately, what happens is that people submit pull requests against the read-only mirror, but the upstream maintainers rarely if ever look at the pull requests. We end up closing most of the pull requests with a message that says "Contact upstream directly and try to get your patches to them."
I also think it would be non-trivial to map Fedora users to GitHub accounts, or to keep said information in sync.
-- Jared Smith
On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith jsmith@fedoraproject.org wrote:
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski mszpak@wp.pl wrote:
I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests).
While I like the idea of making it easier for people to submit patches, I'm not sure setting up a read-only GitHub mirror is the answer.
In my day job, I happen to maintain a huge GitHub mirror of a large open source code repository where the upstream has not yet moved to Git. Unfortunately, what happens is that people submit pull requests against the read-only mirror, but the upstream maintainers rarely if ever look at the pull requests. We end up closing most of the pull requests with a message that says "Contact upstream directly and try to get your patches to them."
The ASF uses a pubsub bot to notify project's devel mailing lists when a PR is issued against the read-only mirrors on GitHub. This email contains instructions on how to add a second remote and perform the pull request manually. It also explains how to force the PR to be closed without write access to the mirror (with a commit message that says something like "this closes #X", where X is the PR number, which gets processed when the mirror is next sync'd). In this way, it opens up the community to a wider audience by enabling contributors to use tools they are comfortable with, but in a way that doesn't technically add a dependency on GitHub. Fedora could do something similar by automatically opening a BZ issue, in the same way upstream monitoring opens up new BZs.
I know this would be really useful, because before I submitted my first package to Fedora, I had a slightly difficult time figuring out how to contribute, or even check out and view a project's git repository (doing an anonymous clone with fedpkg wasn't obvious).
I also think it would be non-trivial to map Fedora users to GitHub accounts, or to keep said information in sync.
This would be non-trivial... but it's also completely unnecessary. The mirrors can/should be read-only while the Fedora repos remain authoritative, with maintainer write-access.
The ASF does allow committers to affiliate with the ASF org in GitHub (where the read-only mirrors exist) by voluntarily adding their GitHub usernames to a database, but this doesn't get them any special access to the mirrors... it's just for flair, to show off their membership on their GitHub profile. As far as I'm concerned, this is a completely unnecessary thing to do. Perhaps at some point, we could do this by offering a voluntary field for GitHub username, but it's certainly not essential to using GitHub to enable pull-requests.
Of course, Fedora doesn't have to do it the way the ASF did, but I think there's value in looking at what they've done, because there's value in exposing Fedora's packages to a large (and growing) community of GitHub.
On 19.10.2015 19:32, Christopher wrote:
On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith jsmith@fedoraproject.org wrote:
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski mszpak@wp.pl wrote:
I like the idea with mirroring Fedora Git to GitHub. Read only mirror just to be a dedicated place for that kind of contributions (via pull requests).
While I like the idea of making it easier for people to submit patches, I'm not sure setting up a read-only GitHub mirror is the answer.
In my day job, I happen to maintain a huge GitHub mirror of a large open source code repository where the upstream has not yet moved to Git. Unfortunately, what happens is that people submit pull requests against the read-only mirror, but the upstream maintainers rarely if ever look at the pull requests. We end up closing most of the pull requests with a message that says "Contact upstream directly and try to get your patches to them."
The ASF uses a pubsub bot to notify project's devel mailing lists when a PR is issued against the read-only mirrors on GitHub. This email contains instructions on how to add a second remote and perform the pull request manually. It also explains how to force the PR to be closed without write access to the mirror (with a commit message that says something like "this closes #X", where X is the PR number, which gets processed when the mirror is next sync'd). In this way, it opens up the community to a wider audience by enabling contributors to use tools they are comfortable with, but in a way that doesn't technically add a dependency on GitHub. Fedora could do something similar by automatically opening a BZ issue, in the same way upstream monitoring opens up new BZs.
I know this would be really useful, because before I submitted my first package to Fedora, I had a slightly difficult time figuring out how to contribute, or even check out and view a project's git repository (doing an anonymous clone with fedpkg wasn't obvious).
I also think it would be non-trivial to map Fedora users to GitHub accounts, or to keep said information in sync.
This would be non-trivial... but it's also completely unnecessary. The mirrors can/should be read-only while the Fedora repos remain authoritative, with maintainer write-access.
The ASF does allow committers to affiliate with the ASF org in GitHub (where the read-only mirrors exist) by voluntarily adding their GitHub usernames to a database, but this doesn't get them any special access to the mirrors... it's just for flair, to show off their membership on their GitHub profile. As far as I'm concerned, this is a completely unnecessary thing to do. Perhaps at some point, we could do this by offering a voluntary field for GitHub username, but it's certainly not essential to using GitHub to enable pull-requests.
Of course, Fedora doesn't have to do it the way the ASF did, but I think there's value in looking at what they've done, because there's value in exposing Fedora's packages to a large (and growing) community of GitHub.
This sounds very very cool. For reference: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
On Sun, 2015-10-18 at 15:36 +0200, Marcin Zajączkowski wrote:
Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
(*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute)
I usually just email or BZ a git-formatted patch. That can easily be applied with git am.
On Sun, 18 Oct 2015 15:36:24 +0200 Marcin Zajączkowski mszpak@wp.pl wrote:
Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
We have talked about such a frontend to pkgs.fedoraproject.org (most likely reusing code from pagure.io), but we haven't imemented anything yet.
(*) - a given package repo could be forked and published to GitHub with a change in a separate branch. The new repo could be added locally by a maintainer (as a new remote Git repository) and that new branch could be merge into master and pushed to Fedora repository. Nevertheless it requires some knowledge about Git and a few manual Git commands to execute)
And adds a dependence on github to some degree.
So, for now, it's get your change upstream (if it's something upstream could take) and it will trickle down to Fedora repos, or use a bugzilla bug and attachment I am afraid.
I do like the idea of having PR's for packages, it would really help in some cases.
kevin
On 18/10/15 18:46, Kevin Fenzi wrote:
On Sun, 18 Oct 2015 15:36:24 +0200 Marcin Zajączkowski mszpak@wp.pl wrote:
Hi,
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
We have talked about such a frontend to pkgs.fedoraproject.org (most likely reusing code from pagure.io), but we haven't imemented anything yet.
Perhaps OT, but I cannot resist: Have you discussed the overall workflow here? Cloning package, unpack sources, create patches, make a build, revise patches, finalize the spec, perhaps upstream to package owner...
All this is IMHO quite messy with a lot of manual steps (?). In the best of worlds I could:
- With a single command create an unpacked source directory with a patch series reflecting the spec patches. - After creating/editing patches, just build using the new patchset. - When the patch(es) are finalized, have the spec updated in a single command e. g., syncing the spec with a git or quilt series or so. - Of course, something like a pull request would be nice. But isn't it the icing on the cake in this context?
Or is it perhaps already possible, I just missed how to do it?
--alec
On Sun, 18 Oct 2015 21:41:41 +0200 Alec Leamas leamas.alec@gmail.com wrote:
Perhaps OT, but I cannot resist: Have you discussed the overall workflow here? Cloning package, unpack sources, create patches, make a build, revise patches, finalize the spec, perhaps upstream to package owner...
Nope. As I said this has been just some "hey, it would be nice if" type discussions. If someone wants to commit to head up an effort around this that would be great, but I don't think anyone is currently.
All this is IMHO quite messy with a lot of manual steps (?). In the best of worlds I could:
- With a single command create an unpacked source directory with a
patch series reflecting the spec patches.
- After creating/editing patches, just build using the new patchset.
- When the patch(es) are finalized, have the spec updated in a
single command e. g., syncing the spec with a git or quilt series or so.
- Of course, something like a pull request would be nice. But isn't
it the icing on the cake in this context?
Or is it perhaps already possible, I just missed how to do it?
Well, there's already http://www.rpm.org/wiki/PackagerDocs/Autosetup That some packages use, and also a git setup like some package use, for example look at the grub2.spec.
I'd think a pagure.io like frontend would but at somewhat of a different level than this. You would:
* Go to the interface and create a fork of the package you want to change. * Clone that fork and work on it locally with the normal fedpkg tools. * When it's set, submit a PR to the package owners with all the changes in your fork you want to submit.
kevin
On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi kevin@scrye.com wrote:
I'd think a pagure.io like frontend would but at somewhat of a different level than this. You would:
- Go to the interface and create a fork of the package you want to change.
- Clone that fork and work on it locally with the normal fedpkg tools.
- When it's set, submit a PR to the package owners with all the changes in your fork you want to submit.
Using pagure would be very much a superior work flow. But basically anything that supports handling and reviewing patches would be a big step forward above the current bugzilla based process. This thread reminds me of an email I sent earlier this year:
https://lists.fedoraproject.org/pipermail/devel/2015-January/207033.html
There I was simply yearning for a tool to help with newly introduced packages. If Fedora can utilize a tool (such as pagure) to help with the entire lifetime of the package, all the more better!
On Mon, Oct 19, 2015 at 10:18:15AM -0400, Jeff Peeler wrote:
On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi kevin@scrye.com wrote:
I'd think a pagure.io like frontend would but at somewhat of a different level than this. You would:
- Go to the interface and create a fork of the package you want to change.
- Clone that fork and work on it locally with the normal fedpkg tools.
- When it's set, submit a PR to the package owners with all the changes in your fork you want to submit.
Using pagure would be very much a superior work flow. But basically anything that supports handling and reviewing patches would be a big step forward above the current bugzilla based process. This thread reminds me of an email I sent earlier this year:
https://lists.fedoraproject.org/pipermail/devel/2015-January/207033.html
There I was simply yearning for a tool to help with newly introduced packages. If Fedora can utilize a tool (such as pagure) to help with the entire lifetime of the package, all the more better!
I just wanted to let people know that: - we have a cloud instance of pagure running on the top of a (outdated) dist-git at: http://209.132.184.205/ feel free to see what's right/wrong with it and can/should be fixed Note: there is currently a problem in the way the data was loaded in the DB, so some users are not getting their packages attributed, I need to look into this and reload the DB - I created a tag for tickets/issues related to this 'project' for pagure, so feel free to look at the remaining tickets if you would like to help: https://pagure.io/pagure/issues?tags=pkgs.fp (Looking at the list now, I realize that not all the work/steps done were documented in a ticket ^^).
Hope this help, Pierre
Marcin Zajączkowski wrote:
I would like to propose a minor (yet important) change in one of the Fedora packages configuration (a SPEC file and/or a patch). Is it possible to create (something like) a pull request which could be reviewed by the maintainer in some convenient way (*) and optionally merged? Or the only way is to create a patch and put it into a Buzilla ticket?
1. git clone … 2. commit your changes 3. git format-patch 4. attach to Bugzilla
Where's the problem?
(*) - a given package repo could be forked and published to GitHub
A dependency on a third-party proprietary web service is a no go.
Kevin Kofler
On 2015-10-19, Kevin Kofler kevin.kofler@chello.at wrote:
- git clone …
- commit your changes
- git format-patch
- attach to Bugzilla
The 3rd and 4th step can be simplified to "git send-bugzilla" command.
Although I think it can attach a patch only to already existing bug report. This could be implemented and fedpkg tool could gain the capability to send patches from local dist-git branch :)
-- Petr