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

[Petr Spacek]

On 19.10.2015 19:32, Christopher wrote:
> On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith 
> wrote:
> 
>> On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski  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

-- 
Petr Spacek  @  Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Petr Pisar]

On 2015-10-19, Kevin Kofler  wrote:
> 1. git clone …
> 2. commit your changes
> 3. git format-patch
> 4. 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Sun, 18 Oct 2015 21:12:42 -0400
Neal Gompa  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


pgpNL8MoLznS9.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Jared K. Smith]

On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Jeff Peeler]

On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi  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!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Pierre-Yves Chibon]

On Mon, Oct 19, 2015 at 10:18:15AM -0400, Jeff Peeler wrote:
> On Sun, Oct 18, 2015 at 4:00 PM, Kevin Fenzi  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Christopher]

On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith 
wrote:

> On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski  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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Alec Leamas]

On 18/10/15 18:46, Kevin Fenzi wrote:
> On Sun, 18 Oct 2015 15:36:24 +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?
> 
> 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Sun, 18 Oct 2015 21:41:41 +0200
Alec Leamas  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



pgpT5EYw0WUQd.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Marcin Zajączkowski]

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  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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Neal Gompa]

On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski  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?​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Christopher]

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  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Sun, 18 Oct 2015 15:36:24 +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?

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


pgpk1X23e2p8x.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct