Re: Recommended way of proposing changes in someone else Fedora packages configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith <jsmith@xxxxxxxxxxxxxxxxx> wrote:
On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski <mszpak@xxxxx> 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.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux