Re: Pull request template for github mirror

[Lasse Schuirmann]

Hi,

I just spoke with aruiz and ebassi on IRC and quickly cooked up a
small autoresponse for you. Is there any volunteer repository for
testing?

I've already tested it on one of my repositories and it works. Guide
to activation:

1. Go to app.gitmate.io
2. Login with an account that has admin access to the GNOME mirror repository
3. Click on add repositories and click on each repository, wait for
the green acknowledgement to pop up.
4. Go to the configuration page, deactivate all the GitMate features
and activate the PR autoresponse feature, fill in the text you want in
the autoresponse.

GitMate will then perform the autoresponse on every opened or
resynchronized (pushed) PR using the user you authenticated at
GitMate. (I usually log into GitHub with my gitmate-bot account to
make sure it's clear to everyone that it's a bot at work here and not
me.)

On long term we can for sure plan cool things like keeping PRs and BZ
issues in sync, if you want I can add a feature to auto close PRs.

Lasse

2016-02-29 17:12 GMT+01:00 Milan Crha :
> On Mon, 2016-02-29 at 14:52 +, Emmanuele Bassi wrote:
>>   $ git pull github-mirror pull/${PR_ID}/head:pr-${PR_ID}
>>   $ git checkout pr-${PR_ID}
>>
>> From then on, you can push/merge/pull/rebase as usual.
>
> Hi,
> well, it's too much overhead for:
> a) someone whom does not have a github account
> b) wants to get to a patch which consist of 20 lines total.
>
> Imagine the wasted bandwidth...
>
> Anyway, this diverged from the subject of this thread a bit.
> Bye,
> Milan
>
> P.S.: If people could help to newcomers from github with the workflow
> on the GNOME side the same, then there probably wouldn't be needed any
> read-only, pull-request-disabled mirror of GNOME projects
> on the github at all :)
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Milan Crha]

On Mon, 2016-02-29 at 14:52 +, Emmanuele Bassi wrote:
>   $ git pull github-mirror pull/${PR_ID}/head:pr-${PR_ID}
>   $ git checkout pr-${PR_ID}
> 
> From then on, you can push/merge/pull/rebase as usual.

Hi,
well, it's too much overhead for:
a) someone whom does not have a github account
b) wants to get to a patch which consist of 20 lines total.

Imagine the wasted bandwidth...

Anyway, this diverged from the subject of this thread a bit.
Bye,
Milan

P.S.: If people could help to newcomers from github with the workflow
on the GNOME side the same, then there probably wouldn't be needed any
read-only, pull-request-disabled mirror of GNOME projects
on the github at all :)

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Milan Crha]

On Mon, 2016-02-29 at 15:44 +0100, Frederic Crozat wrote:
> Once you have the url of the pull request, just add ".patch" to it
> and you'll get a properly formatted patch.

Hi,
yes, that's the trick I was told to do. My point was that there is
absolutely no sign in the Web UI of github to do so, thus unless you
know someone whom is already capable of it, you are just doomed. Or at
least I was, until I asked the co-worker.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Emmanuele Bassi]

Hi;

On 29 February 2016 at 14:44, Frederic Crozat  wrote:
> 2016-02-29 15:28 GMT+01:00 Milan Crha :
>
>> As I work with raw patches usually (I just got use to it after all the
>> years) the github web UI is very confusing for me and I didn't find a
>> way to convert the pull request into the patch. I asked a co-worker
>> whom has a github account for a help and he also didn't find it, but he
>> knew a trick and told me about it - it didn't involve any click-able
>> way on the github pages to get to the patch, sadly. Maybe my workflow
>> is just too different from that supported by the github, or vice versa.
>
> Once you have the url of the pull request, just add ".patch" to it and
> you'll get a properly formatted patch.
>
> For instance, on one of the pending pull request on e-d-s:
> https://github.com/GNOME/evolution-data-server/pull/3
>
> => https://github.com/GNOME/evolution-data-server/pull/3.patch

All pull requests on GitHub live on their own branch in a separate ref:

https://help.github.com/articles/checking-out-pull-requests-locally/

  $ git pull github-mirror pull/${PR_ID}/head:pr-${PR_ID}
  $ git checkout pr-${PR_ID}

>From then on, you can push/merge/pull/rebase as usual.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Frederic Crozat]

2016-02-29 15:28 GMT+01:00 Milan Crha :

> As I work with raw patches usually (I just got use to it after all the
> years) the github web UI is very confusing for me and I didn't find a
> way to convert the pull request into the patch. I asked a co-worker
> whom has a github account for a help and he also didn't find it, but he
> knew a trick and told me about it - it didn't involve any click-able
> way on the github pages to get to the patch, sadly. Maybe my workflow
> is just too different from that supported by the github, or vice versa.

Once you have the url of the pull request, just add ".patch" to it and
you'll get a properly formatted patch.

For instance, on one of the pending pull request on e-d-s:
https://github.com/GNOME/evolution-data-server/pull/3

=> https://github.com/GNOME/evolution-data-server/pull/3.patch

-- 
Frederic Crozat
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Milan Crha]

On Fri, 2016-02-26 at 23:30 +, Alberto Ruiz wrote:
> These contributions (there's about 200 pull requests, see link below)
> would likely not have happened if we didn't have a presence in
> Github. Shutting down the mirror would simply stop that energy.

Hi,
I think it would be good to check the numbers in more detail.

The github mirror had been officially announced on 2013-08-15. Since
them there had been created 515 pull requests (I modified your search
query on the github) [1].

Then I tried to query GNOME bugzilla for bugs with not-obsolete patches
whose status changed after 2013-08-15 [2]. The first run stopped at
500, the second run at 1 bugs. It can be that some patches got
changed status while they had been contributed before the github mirror
announcement, thus the numbers might not be accurate, but I believe
they are quite close.

And now, if I count properly, those 515 pull requests represent 5.15%
of the GNOME contribution for the past ~2.5 year.

I tried to query also for committed patches only [3] in the GNOME
bugzilla, which returned 8199 bugs, which is around 6.28% of the
contribution to the GNOME projects (not only sources).

I do not want to judge whether it's too low or not. It depends on
several things and on the point of view. I only wanted to have some
comparable numbers (which I hope I managed to get from the bugzilla).

In my case, I found, thanks to your link, some pull requests in the
github for the projects I take care of, and they were like this:
 - one correct - committed to sources
 - one incorrect - I sent an email to the creator (no github
   account here)
 - two for README files, which I both "rejected", but fixed it in
   the sources in a better way
 - one obsolete - I do not know why it is still opened
 - one for translation - out of my hands, translations are treated
   very differently from the sources
 - one semi-pending - its author found the right place to contribute
   and made more extensive changes directly through the GNOME bugzilla
   already, which I appreciate

As I work with raw patches usually (I just got use to it after all the
years) the github web UI is very confusing for me and I didn't find a
way to convert the pull request into the patch. I asked a co-worker
whom has a github account for a help and he also didn't find it, but he
knew a trick and told me about it - it didn't involve any click-able
way on the github pages to get to the patch, sadly. Maybe my workflow
is just too different from that supported by the github, or vice versa.

That's just it. No judgement from my side, but also do not expect me to
regularly check github mirrors for any pull requests, rather expect bad
experience from the possible contributors of the projects I maintain.
Being it on me, I'd rather drop those projects from the github and let
them use the only right place for the contribution, the GNOME
infrastructure.
Bye,
Milan

[1] 
https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome=Issues=searchresults

[2] 
https://bugzilla.gnome.org/buglist.cgi?chfieldfrom=2013-08-15=Now=attachments.ispatch=attachments.isobsolete=attachments.gnome_attachment_status_id=102746=equals=notequals=changedafter_format=advanced=1=1=2013-08-15

[3] 
https://bugzilla.gnome.org/buglist.cgi?chfieldfrom=2013-08-15=Now=attachments.ispatch=attachments.isobsolete=attachments.gnome_attachment_status=attachments.gnome_attachment_status=0_id=102750=equals=notequals=changedafter=equals=bug_id_format=advanced=1=1=2013-08-15=committed
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Ben Iofel]

I like the github mirrors. They provide a much better browsing & searching
experience than git.gnome.org

On Fri, Feb 26, 2016, 6:10 PM Lasse Schuirmann 
wrote:

> Is there any advantage of having those mirrors after all? Nobody really
> seems to care and I'm against adding a folder to trick a proprietary tool
> into not hurting us. It's read only anyway...
>
> (I have not followed all previous discussions regarding this though.)
> On 27 Feb 2016 12:02 a.m., "Jehan Pagès" 
> wrote:
>
>> Hello,
>>
>> Speaking as one of the GIMP developers (which does not mean I speak on
>> behalf of the GIMP project here, but in my name). I certainly don't
>> want us to start using github, and actually would not care if we
>> stopped using it to mirror our repository. As you say yourself, this
>> is very confusing and probably a lot of people would think that all
>> these GNOME projects are actually hosted there as upstream, since
>> nothing tells otherwise by looking at the github page!
>>
>> BUT if we really have to continue mirror the repos there, I would
>> personally say that we may as well do it well and add such a file, if
>> that is all it takes to stop people from creating pull requests.
>> Isn't there more simply a way to just forbid pull requests? I see we
>> already don't use the bug tracker nor the wiki. Isn't it possible to
>> do the same for the pull request UI?
>>
>> Also another thing I was wondering is: who has the rights to close the
>> pull requests? On the GIMP project for instance, we have 4 pull
>> requests: https://github.com/GNOME/gimp/pulls
>> I have (exceptionnally) pushed one of the commits separately, some
>> time ago, another is not valid anymore, and the last 2 have also been
>> made on the bugtracker by this contributor since then. Could someone
>> with rights on the Github GNOME account close these 4 pull requests?
>> Thanks.
>>
>> Jehan
>>
>>
>> On Fri, Feb 26, 2016 at 11:16 PM, Thomas H.P. Andersen 
>> wrote:
>> > Hi maintainers,
>> >
>> > We have mirrors of git set up at github.com/gnome. Apparently
>> developers are
>> > mistaking these mirrors as upstream and send pull requests there.
>> Unless the
>> > maintainers actively keeps an eye on it these pull requests will go
>> > unnoticed.
>> >
>> > One way to deal with this is to add a pull request template to github
>> > telling the user that this is not the correct place for submitting
>> patches
>> > and a link to the relevant bugzilla page.
>> >
>> > The way to add a pull request template is by creating a file
>> > .github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github
>> are
>> > just mirrors such a file would have to go into upstream git.
>> >
>> > I volunteer to create template files for all our mirrored repositories
>> if
>> > there is interest. I understand that adding these files upstream may be
>> > controversial, but I think that being visible on github is helpful to
>> new
>> > developers, and this could be a way to avoid those lost patches.
>> >
>> > Tell me what you think.
>> >
>> > - Thomas
>> >
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[philip . chimento]

On Sat, Feb 27, 2016 at 6:12 AM Jehan Pagès 
wrote:

> Hi,
>
> On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz  wrote:
> > Perhaps I should jump in as I created the mirror alongside Andrea Veri.
> >
> > The mirror in general is quite useful, a lot of people fork projects and
> > check them out automatically instead of checking them out from
> git.gnome.org
> > and then pushing them in github. These contributions (there's about 200
> pull
> > requests, see link below) would likely not have happened if we didn't
> have a
> > presence in Github. Shutting down the mirror would simply stop that
> energy.
> >
> >
> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen
>
> Ok.
>
> > I do know it is not ideal to have unattended contributions, mind though,
> > GitHub won't allow an option for disabling Pull Requests even though we
> > asked for it. And I committed to not allow usage of PRs since we don't
> want
> > to rely on a closed service for our operations.
> >
> > As per Thomas suggestion I think it's an overkill to modify every single
> > repo. The real solution is to finish this script/hook that would find the
> > right bugzilla product URL in the .doap file and create a bug in bugzilla
> > automatically for the user. If we were able to then allow logins from
> > github's OAuth into our bugzilla instance that'd be great as it would
> reduce
> > friction.
>
> If that means just creating a bugzilla ticket with the patch attached,
> and closing the pull request, the problem is that we lose discussion
> with the contributor. Even though we would add a message on the pull
> request basically saying "we opened a bug report at this address,
> please continue the discussion there", I noticed that many people who
> would use github rather than the project's prefered method of
> contribution (GNOME's bugzilla in our case) are simply reluctant on
> creating a new account for some reason (as though they did not have to
> do so for github, but somehow they consider this one a given). So we
> could not ask them to modify the patch, etc. Basically I would be a
> little scared we end up with tickets where the contributor never
> answer to our patch modification requests, and we never close the
> report nonetheless because the original proposition still made sense
> (just quality, code logics, or whatnot are not acceptable just yet to
> be merged in our tree). Basically more ghost bug reports. We already
> have a lot of these on the GIMP project.
>
> If that means "syncing" the github pull request and the bugzilla
> ticket, as Lasse suggests, that's a little more useful, since we can
> still have a dialog with the contributor without having him to create
> an account. But in such a case, we should still make sure that
> contributors understand this is not the prefered way of contributing,
> by at least adding a message atop. Indeed the problem of the sync
> solution is that we give legitimity to github pull requests. From
> contributor's point of view, they become equivalent to making a ticket
> on GNOME's bugzilla. So why would they ever make an account upstream?
> Moreover how will it be possible to move tickets to another project
> now (as far as I know, you cannot "move" a pull request)? Should we
> start blocking bugzilla tickets when synced to a github pull request,
> and thus limit ourselves to what github decides?
> As such, as you say above, we would start "relying on a close service
> for our operations".
>
> These look like very difficult implementation decisions if we want to
> keep usability (be able to discuss with contributors) while still stay
> independent of github repos.
>

Depends on how much work the maintainer is willing to do to retain new
contributors. Myself, I'd treat a pull request just like a patch that
didn't follow the coding style; the first few times I'll just fix it up
myself and thank the contributor, mentioning to please read the guidelines
for next time. After a few contributions, when they are invested, then I
have more leverage to ask that they do it in the preferred way, and it's
less likely they'll think it's too much work and give up. You can use the
same technique for getting people to move to Bugzilla.

As Lasse says this could be enforced by a script, but maintainer discretion
goes a long way too :-)

Regards,
Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Juan Pablo Ugarte]

On Sat, 2016-02-27 at 15:46 +0100, Sébastien Wilmet wrote:

[...]

> Also, in every module it is normally explained how to contribute and
> submit patches, either in the README or HACKING file. The HACKING
> file
> contains other important information for contributing.

True, that is why I made a symbolic link CONTRIBUTING.md -> HACKING in
Glade but that does not work so I had to make HACKING a link to
CONTRIBUTING.md :)

greets

JP
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Thomas H.P. Andersen]

On Sat, Feb 27, 2016 at 3:46 PM, Sébastien Wilmet  wrote:

> On Sat, Feb 27, 2016 at 12:44:45PM +0100, Sébastien Wilmet wrote:
> > This has already been discussed:
> >
> https://mail.gnome.org/archives/desktop-devel-list/2015-May/msg4.html
> >
> > The suggestion was to add a CONTRIBUTING.md file, which I did for the
> > modules that I maintain.
>
> Replying to myself, adding the CONTRIBUTING.md file has apparently had
> the intended effect for at least the gedit, gtksourceview and latexila
> modules.
>
> For gtksourceview, I see that one contributor has opened a pull request
> recently, but closed it by himself and opened a bug in bugzilla.
>
> Also, in every module it is normally explained how to contribute and
> submit patches, either in the README or HACKING file. The HACKING file
> contains other important information for contributing. So, if someone
> creates a pull request on GitHub, it means that the contributor didn't
> read the README or HACKING, so the patch has probably a poor quality… Do
> we really need to care about all those random patches by contributors
> who don't do their homework?
>

yes. It is a bit of a stretch to assume that a patch will be low quality
simply because the author did not read the HACKING file.

I prefer what Lasse is proposing. However, just like the CONTRIBUTING.md
file any maintainer can already add a .github/PULL_REQUEST_TEMPLATE.md file
to be even more visible about the policy on pull requests.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Hubert Figuière]

On 27/02/16 08:28 AM, Patrick Welche wrote:
> I am mystified and pleasantly surprised: there was a fine pull-request
> against the dasher project on github. I still don't know how you can
> discover the individual commits that make up a pull-request. Today
> I merged the github fork which presumably contained all of the commits
> in the pull-request and more. I pushed to git.gnome, and magically the
> pull-request on github got closed(!) How is this all meant to work?

When you have write permission is shows the commands to do it from the
command line. Sadly it doesn't here since no one has write permission.
(makes no sense, but nothing we can do)

The help explain how to map pull request with remote git branches:
https://help.github.com/articles/checking-out-pull-requests-locally/
Nothing that a "git remote add" and "git fetch" can't solve.

As for the commits, there is a "commits" tab in the web UI, they are
listed individually.


Hub
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Lasse Schuirmann]

I could see having a script that keeps BZ and GH in sync and if a
participant tries it the second time just telling him that he please
should register a BZ account (your proprietary trial is over ;)).

My vision of this "sync" is actually a complete sync: a comment on BZ
happens -> will get mirrored to GitHub. A comment on the patch happens
-> will get mirrored as a commit comment. Same the other way round.
User pushes/force pushes new patches, old will be marked obsolete and
the new ones will be attached.
Sincerely,

Lasse Schuirmann

cont...@viperdev.io
http://viperdev.io/


2016-02-27 15:12 GMT+01:00 Jehan Pagès :
> Hi,
>
> On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz  wrote:
>> Perhaps I should jump in as I created the mirror alongside Andrea Veri.
>>
>> The mirror in general is quite useful, a lot of people fork projects and
>> check them out automatically instead of checking them out from git.gnome.org
>> and then pushing them in github. These contributions (there's about 200 pull
>> requests, see link below) would likely not have happened if we didn't have a
>> presence in Github. Shutting down the mirror would simply stop that energy.
>>
>> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen
>
> Ok.
>
>> I do know it is not ideal to have unattended contributions, mind though,
>> GitHub won't allow an option for disabling Pull Requests even though we
>> asked for it. And I committed to not allow usage of PRs since we don't want
>> to rely on a closed service for our operations.
>>
>> As per Thomas suggestion I think it's an overkill to modify every single
>> repo. The real solution is to finish this script/hook that would find the
>> right bugzilla product URL in the .doap file and create a bug in bugzilla
>> automatically for the user. If we were able to then allow logins from
>> github's OAuth into our bugzilla instance that'd be great as it would reduce
>> friction.
>
> If that means just creating a bugzilla ticket with the patch attached,
> and closing the pull request, the problem is that we lose discussion
> with the contributor. Even though we would add a message on the pull
> request basically saying "we opened a bug report at this address,
> please continue the discussion there", I noticed that many people who
> would use github rather than the project's prefered method of
> contribution (GNOME's bugzilla in our case) are simply reluctant on
> creating a new account for some reason (as though they did not have to
> do so for github, but somehow they consider this one a given). So we
> could not ask them to modify the patch, etc. Basically I would be a
> little scared we end up with tickets where the contributor never
> answer to our patch modification requests, and we never close the
> report nonetheless because the original proposition still made sense
> (just quality, code logics, or whatnot are not acceptable just yet to
> be merged in our tree). Basically more ghost bug reports. We already
> have a lot of these on the GIMP project.
>
> If that means "syncing" the github pull request and the bugzilla
> ticket, as Lasse suggests, that's a little more useful, since we can
> still have a dialog with the contributor without having him to create
> an account. But in such a case, we should still make sure that
> contributors understand this is not the prefered way of contributing,
> by at least adding a message atop. Indeed the problem of the sync
> solution is that we give legitimity to github pull requests. From
> contributor's point of view, they become equivalent to making a ticket
> on GNOME's bugzilla. So why would they ever make an account upstream?
> Moreover how will it be possible to move tickets to another project
> now (as far as I know, you cannot "move" a pull request)? Should we
> start blocking bugzilla tickets when synced to a github pull request,
> and thus limit ourselves to what github decides?
> As such, as you say above, we would start "relying on a close service
> for our operations".
>
> These look like very difficult implementation decisions if we want to
> keep usability (be able to discuss with contributors) while still stay
> independent of github repos.
>
> Jehan
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Patreon: https://patreon.com/zemarmot
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Jehan Pagès]

Hi,

On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz  wrote:
> Perhaps I should jump in as I created the mirror alongside Andrea Veri.
>
> The mirror in general is quite useful, a lot of people fork projects and
> check them out automatically instead of checking them out from git.gnome.org
> and then pushing them in github. These contributions (there's about 200 pull
> requests, see link below) would likely not have happened if we didn't have a
> presence in Github. Shutting down the mirror would simply stop that energy.
>
> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen

Ok.

> I do know it is not ideal to have unattended contributions, mind though,
> GitHub won't allow an option for disabling Pull Requests even though we
> asked for it. And I committed to not allow usage of PRs since we don't want
> to rely on a closed service for our operations.
>
> As per Thomas suggestion I think it's an overkill to modify every single
> repo. The real solution is to finish this script/hook that would find the
> right bugzilla product URL in the .doap file and create a bug in bugzilla
> automatically for the user. If we were able to then allow logins from
> github's OAuth into our bugzilla instance that'd be great as it would reduce
> friction.

If that means just creating a bugzilla ticket with the patch attached,
and closing the pull request, the problem is that we lose discussion
with the contributor. Even though we would add a message on the pull
request basically saying "we opened a bug report at this address,
please continue the discussion there", I noticed that many people who
would use github rather than the project's prefered method of
contribution (GNOME's bugzilla in our case) are simply reluctant on
creating a new account for some reason (as though they did not have to
do so for github, but somehow they consider this one a given). So we
could not ask them to modify the patch, etc. Basically I would be a
little scared we end up with tickets where the contributor never
answer to our patch modification requests, and we never close the
report nonetheless because the original proposition still made sense
(just quality, code logics, or whatnot are not acceptable just yet to
be merged in our tree). Basically more ghost bug reports. We already
have a lot of these on the GIMP project.

If that means "syncing" the github pull request and the bugzilla
ticket, as Lasse suggests, that's a little more useful, since we can
still have a dialog with the contributor without having him to create
an account. But in such a case, we should still make sure that
contributors understand this is not the prefered way of contributing,
by at least adding a message atop. Indeed the problem of the sync
solution is that we give legitimity to github pull requests. From
contributor's point of view, they become equivalent to making a ticket
on GNOME's bugzilla. So why would they ever make an account upstream?
Moreover how will it be possible to move tickets to another project
now (as far as I know, you cannot "move" a pull request)? Should we
start blocking bugzilla tickets when synced to a github pull request,
and thus limit ourselves to what github decides?
As such, as you say above, we would start "relying on a close service
for our operations".

These look like very difficult implementation decisions if we want to
keep usability (be able to discuss with contributors) while still stay
independent of github repos.

Jehan

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Sébastien Wilmet]

On Fri, Feb 26, 2016 at 11:16:32PM +0100, Thomas H.P. Andersen wrote:
> We have mirrors of git set up at github.com/gnome. Apparently developers
> are mistaking these mirrors as upstream and send pull requests there.
> Unless the maintainers actively keeps an eye on it these pull requests will
> go unnoticed.

This has already been discussed:
https://mail.gnome.org/archives/desktop-devel-list/2015-May/msg4.html

The suggestion was to add a CONTRIBUTING.md file, which I did for the
modules that I maintain.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Lasse Schuirmann]

Oh I'm just thinking... I'm currently writing a lot on GitMate which
is some github bot automation stuff, I could write a really simple
function to autorespond to PRs or do some other stuff with it (make
patches for BZ? Keep them in sync?) automatically as I have the
infrastructure (i.e. a modular system where you can easily register
functions to webhooks) ready.

@Alberto, maybe ping me about the OAuth problem, I've spent a bit of
time on that kind of stuff lately. I have no problem getting your
script to work either, might be simpler.

Lasse
Sincerely,

Lasse Schuirmann

cont...@viperdev.io
http://viperdev.io/


2016-02-27 3:25 GMT+01:00 Hubert Figuière :
> On 26/02/16 06:30 PM, Alberto Ruiz wrote:
>> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen
>>
>> I do know it is not ideal to have unattended contributions, mind though,
>> GitHub won't allow an option for disabling Pull Requests even though we
>> asked for it. And I committed to not allow usage of PRs since we don't want
>> to rely on a closed service for our operations.
>
> I think someone should poke the maintainers of each module, have them
> make a decision and eventually get the PR closed (either by taking,
> rejecting or redirecting the contribution).
>
> Very few people have permissions to close these request (there are 4
> members in the "GNOME" github project AFAI). I think we should add
> people that are okay with it. I'm fine helping with that - ie getting
> write access. My user name on github is "hfiguiere"
>
> It is very important that we don't ignore contributions.
>
> Cheers,
>
> Hub
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Hubert Figuière]

On 26/02/16 06:30 PM, Alberto Ruiz wrote:
> https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen
> 
> I do know it is not ideal to have unattended contributions, mind though,
> GitHub won't allow an option for disabling Pull Requests even though we
> asked for it. And I committed to not allow usage of PRs since we don't want
> to rely on a closed service for our operations.

I think someone should poke the maintainers of each module, have them
make a decision and eventually get the PR closed (either by taking,
rejecting or redirecting the contribution).

Very few people have permissions to close these request (there are 4
members in the "GNOME" github project AFAI). I think we should add
people that are okay with it. I'm fine helping with that - ie getting
write access. My user name on github is "hfiguiere"

It is very important that we don't ignore contributions.

Cheers,

Hub
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Alberto Ruiz]

Perhaps I should jump in as I created the mirror alongside Andrea Veri.

The mirror in general is quite useful, a lot of people fork projects and
check them out automatically instead of checking them out from git.gnome.org
and then pushing them in github. These contributions (there's about 200
pull requests, see link below) would likely not have happened if we didn't
have a presence in Github. Shutting down the mirror would simply stop that
energy.

https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome+state%3Aopen

I do know it is not ideal to have unattended contributions, mind though,
GitHub won't allow an option for disabling Pull Requests even though we
asked for it. And I committed to not allow usage of PRs since we don't want
to rely on a closed service for our operations.

As per Thomas suggestion I think it's an overkill to modify every single
repo. The real solution is to finish this script/hook that would find the
right bugzilla product URL in the .doap file and create a bug in bugzilla
automatically for the user. If we were able to then allow logins from
github's OAuth into our bugzilla instance that'd be great as it would
reduce friction.

Anyhow, Thomas, I got stuck with the OAuth aspect of this script:
https://gist.github.com/aruiz/4583b78e1d56f79f083d

If you really want to help, I would suggest I give you access to the API
keys and finish it. How does that sound?

2016-02-26 23:10 GMT+00:00 Lasse Schuirmann :

> Is there any advantage of having those mirrors after all? Nobody really
> seems to care and I'm against adding a folder to trick a proprietary tool
> into not hurting us. It's read only anyway...
>
> (I have not followed all previous discussions regarding this though.)
> On 27 Feb 2016 12:02 a.m., "Jehan Pagès" 
> wrote:
>
>> Hello,
>>
>> Speaking as one of the GIMP developers (which does not mean I speak on
>> behalf of the GIMP project here, but in my name). I certainly don't
>> want us to start using github, and actually would not care if we
>> stopped using it to mirror our repository. As you say yourself, this
>> is very confusing and probably a lot of people would think that all
>> these GNOME projects are actually hosted there as upstream, since
>> nothing tells otherwise by looking at the github page!
>>
>> BUT if we really have to continue mirror the repos there, I would
>> personally say that we may as well do it well and add such a file, if
>> that is all it takes to stop people from creating pull requests.
>> Isn't there more simply a way to just forbid pull requests? I see we
>> already don't use the bug tracker nor the wiki. Isn't it possible to
>> do the same for the pull request UI?
>>
>> Also another thing I was wondering is: who has the rights to close the
>> pull requests? On the GIMP project for instance, we have 4 pull
>> requests: https://github.com/GNOME/gimp/pulls
>> I have (exceptionnally) pushed one of the commits separately, some
>> time ago, another is not valid anymore, and the last 2 have also been
>> made on the bugtracker by this contributor since then. Could someone
>> with rights on the Github GNOME account close these 4 pull requests?
>> Thanks.
>>
>> Jehan
>>
>>
>> On Fri, Feb 26, 2016 at 11:16 PM, Thomas H.P. Andersen 
>> wrote:
>> > Hi maintainers,
>> >
>> > We have mirrors of git set up at github.com/gnome. Apparently
>> developers are
>> > mistaking these mirrors as upstream and send pull requests there.
>> Unless the
>> > maintainers actively keeps an eye on it these pull requests will go
>> > unnoticed.
>> >
>> > One way to deal with this is to add a pull request template to github
>> > telling the user that this is not the correct place for submitting
>> patches
>> > and a link to the relevant bugzilla page.
>> >
>> > The way to add a pull request template is by creating a file
>> > .github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github
>> are
>> > just mirrors such a file would have to go into upstream git.
>> >
>> > I volunteer to create template files for all our mirrored repositories
>> if
>> > there is interest. I understand that adding these files upstream may be
>> > controversial, but I think that being visible on github is helpful to
>> new
>> > developers, and this could be a way to avoid those lost patches.
>> >
>> > Tell me what you think.
>> >
>> > - Thomas
>> >
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
Cheers,
Alberto 

Re: Pull request template for github mirror

[Jehan Pagès]

Hi,

On Sat, Feb 27, 2016 at 12:10 AM, Lasse Schuirmann
 wrote:
> Is there any advantage of having those mirrors after all? Nobody really
> seems to care and I'm against adding a folder to trick a proprietary tool
> into not hurting us. It's read only anyway...
>
> (I have not followed all previous discussions regarding this though.)

About this point, is there any link to discussions which led to this
decision? What was the actual point of having read-only mirrors there?

Jehan

--
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Lasse Schuirmann]

Is there any advantage of having those mirrors after all? Nobody really
seems to care and I'm against adding a folder to trick a proprietary tool
into not hurting us. It's read only anyway...

(I have not followed all previous discussions regarding this though.)
On 27 Feb 2016 12:02 a.m., "Jehan Pagès"  wrote:

> Hello,
>
> Speaking as one of the GIMP developers (which does not mean I speak on
> behalf of the GIMP project here, but in my name). I certainly don't
> want us to start using github, and actually would not care if we
> stopped using it to mirror our repository. As you say yourself, this
> is very confusing and probably a lot of people would think that all
> these GNOME projects are actually hosted there as upstream, since
> nothing tells otherwise by looking at the github page!
>
> BUT if we really have to continue mirror the repos there, I would
> personally say that we may as well do it well and add such a file, if
> that is all it takes to stop people from creating pull requests.
> Isn't there more simply a way to just forbid pull requests? I see we
> already don't use the bug tracker nor the wiki. Isn't it possible to
> do the same for the pull request UI?
>
> Also another thing I was wondering is: who has the rights to close the
> pull requests? On the GIMP project for instance, we have 4 pull
> requests: https://github.com/GNOME/gimp/pulls
> I have (exceptionnally) pushed one of the commits separately, some
> time ago, another is not valid anymore, and the last 2 have also been
> made on the bugtracker by this contributor since then. Could someone
> with rights on the Github GNOME account close these 4 pull requests?
> Thanks.
>
> Jehan
>
>
> On Fri, Feb 26, 2016 at 11:16 PM, Thomas H.P. Andersen 
> wrote:
> > Hi maintainers,
> >
> > We have mirrors of git set up at github.com/gnome. Apparently
> developers are
> > mistaking these mirrors as upstream and send pull requests there. Unless
> the
> > maintainers actively keeps an eye on it these pull requests will go
> > unnoticed.
> >
> > One way to deal with this is to add a pull request template to github
> > telling the user that this is not the correct place for submitting
> patches
> > and a link to the relevant bugzilla page.
> >
> > The way to add a pull request template is by creating a file
> > .github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github
> are
> > just mirrors such a file would have to go into upstream git.
> >
> > I volunteer to create template files for all our mirrored repositories if
> > there is interest. I understand that adding these files upstream may be
> > controversial, but I think that being visible on github is helpful to new
> > developers, and this could be a way to avoid those lost patches.
> >
> > Tell me what you think.
> >
> > - Thomas
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Jehan Pagès]

Hello,

Speaking as one of the GIMP developers (which does not mean I speak on
behalf of the GIMP project here, but in my name). I certainly don't
want us to start using github, and actually would not care if we
stopped using it to mirror our repository. As you say yourself, this
is very confusing and probably a lot of people would think that all
these GNOME projects are actually hosted there as upstream, since
nothing tells otherwise by looking at the github page!

BUT if we really have to continue mirror the repos there, I would
personally say that we may as well do it well and add such a file, if
that is all it takes to stop people from creating pull requests.
Isn't there more simply a way to just forbid pull requests? I see we
already don't use the bug tracker nor the wiki. Isn't it possible to
do the same for the pull request UI?

Also another thing I was wondering is: who has the rights to close the
pull requests? On the GIMP project for instance, we have 4 pull
requests: https://github.com/GNOME/gimp/pulls
I have (exceptionnally) pushed one of the commits separately, some
time ago, another is not valid anymore, and the last 2 have also been
made on the bugtracker by this contributor since then. Could someone
with rights on the Github GNOME account close these 4 pull requests?
Thanks.

Jehan


On Fri, Feb 26, 2016 at 11:16 PM, Thomas H.P. Andersen  wrote:
> Hi maintainers,
>
> We have mirrors of git set up at github.com/gnome. Apparently developers are
> mistaking these mirrors as upstream and send pull requests there. Unless the
> maintainers actively keeps an eye on it these pull requests will go
> unnoticed.
>
> One way to deal with this is to add a pull request template to github
> telling the user that this is not the correct place for submitting patches
> and a link to the relevant bugzilla page.
>
> The way to add a pull request template is by creating a file
> .github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github are
> just mirrors such a file would have to go into upstream git.
>
> I volunteer to create template files for all our mirrored repositories if
> there is interest. I understand that adding these files upstream may be
> controversial, but I think that being visible on github is helpful to new
> developers, and this could be a way to avoid those lost patches.
>
> Tell me what you think.
>
> - Thomas
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Pull request template for github mirror

[Michael Catanzaro]

On Fri, 2016-02-26 at 23:16 +0100, Thomas H.P. Andersen wrote:
> I volunteer to create template files for all our mirrored
> repositories if
> there is interest. I understand that adding these files upstream may
> be
> controversial, but I think that being visible on github is helpful to
> new
> developers, and this could be a way to avoid those lost patches.

Thanks for volunteering, Thomas. This is a good idea. We are losing
contributions and contributors due to this issue. If we can solve it by
adding one file to each repo, we should do that. Without a fix like
this, I frankly think our presence on GitHub is causing more harm than
good.

Adding an extra file to each repo is hardly ideal, but it's not a big
deal either. This is a cost we can accept.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Pull request template for github mirror

[Thomas H.P. Andersen]

Hi maintainers,

We have mirrors of git set up at github.com/gnome. Apparently developers
are mistaking these mirrors as upstream and send pull requests there.
Unless the maintainers actively keeps an eye on it these pull requests will
go unnoticed.

One way to deal with this is to add a pull request template to github
telling the user that this is not the correct place for submitting patches
and a link to the relevant bugzilla page.

The way to add a pull request template is by creating a file
.github/PULL_REQUEST_TEMPLATE in the repository. As the repos on github are
just mirrors such a file would have to go into upstream git.

I volunteer to create template files for all our mirrored repositories if
there is interest. I understand that adding these files upstream may be
controversial, but I think that being visible on github is helpful to new
developers, and this could be a way to avoid those lost patches.

Tell me what you think.

- Thomas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list