Re: Please merge the three pull requests on GitHub

[Andrew Miloradovsky <miloradovsky gmail com>]

On 04/19/2017 01:56 PM, Alexandre Franke wrote:
> On Wed, Apr 19, 2017 at 11:46 AM, Andrew Miloradovsky
> <miloradovsky gmail com> wrote:
> > Hello, Planner developers!
> Hi Andrew!
>
>
> > Several months ago I had a not very pleasant experience
> > in an attempt to contribute to GNOME, namely Planner:
> I’m sorry to hear that and I hope we can improve the situation.
>
>
> > I wanted to commit a fix for a strange issue which happened to me on a
> > distribution.
> > It was somewhat hard to reproduce but the patch was, IMO, very
> > reasonable nevertheless.
> > I was told by the port maintainers to better commit the fix upstream. --
> > Of course!
> Sounds good.
>
>
> > I noticed that many GNOME projects have a mirror on GitHub,
> > and tried to open a pull request, in hope it will be merged, sooner or
> > later.
> > Alas, that PR was automatically closed and I was sent into the
> > documentation,
> > which basically told me to go fuck myself...
> I’d be very interested in fixing said documentation, can you point us
> to the problematic page?
The GH bot's reply send us to https://www.gnome.org/get-involved/
Then we go here https://wiki.gnome.org/Newcomers/
And then here https://wiki.gnome.org/Newcomers/SubmitPatch
Where, reaching the step 4, we realize that we have to send a patch set,
and the review process is fully manual, nothing even close to the pull
requests mechanism exists. Or... the manual is simply outdated and we
have to look for a more efficient submission method somewhere else. At
least that were my thoughts.
> > Recently I checked how much Planner progressed during these months,
> > and what happened to the "open-closed" PR's on GitHub, by the way...
> > I understand that GitHub is a questionable enterprise -- convenient,
> > but hosting FOSS projects there is not very wise in the long run.
> The GNOME repositories you see at GitHub are mere mirrors. They are a
> convenience for some, but most GNOME maintainers don’t pay attention
> to them.
Now I know it.
> > OTOH, by the nature of Git, it shouldn't matter where the submitted
> > patches are hosted,
> > even if that's hell.
> Yes and no. I agree that the distributed nature of git allows for one
> to host their branches wherever they want, but the workflow in place
> should be taken into account by a contributor. I am willing to review
> branches hosted on any third party, I don’t care what the host is, but
> if you want to make my life as a maintainer easier (and increase the
> chance of your patches being properly reviewed), then you should use
> bugzilla which is where we do code reviews at the moment.
Yes I do! But the process of using Bugzilla feels like a step backward.
> > All that being said: for God's sake, somebody,
> > just forget all those ideological considerations for a moment,
> > merge the PR's, or at least leave a comment why you wouldn't!
> > Showing some activity on GH by not ignoring those "open-closed" PR,
> > I'm sure, may spark the interest for further contributions! Next time,
> > I promise to use Bugzilla or whatever in-house GNOME tools I'm supposed
> > to use.
> You have to realize I was not even aware that those PR existed. The
> mirrors are maintained by scripts and the PR are automatically closed…
> by scripts too.
>
> To be honest, PR would be disabled by the GNOME sysadmins if that was
> a possibility on GitHub.
>
>
> On Wed, Apr 19, 2017 at 3:17 PM, Alexánder Alzate Olaya via
> planner-dev-list <planner-dev-list gnome org> wrote:
> > Well, it seems like you are not having into account that the GNOME
> > Github mirror is not maintained by any planner developer. Actually, and
> > I'm not sure here, I think it is automatically "maintained".
> Yep.
>
>
> > As anywhere, there are rules in GNOME projects, and for most GNOME
> > contributors there is a basic rule: "Patches solve issues" and the
> > issue tracker is bugzilla.gnome.org, so, how do you pretend to solve an
> > issue which is not being tracked? how do you track those changes?
> I second this.
>
>
> > Contributing in your case is pretty straightforward:
> >
> > 1 - Create a [GNOME Bugzilla](https://bugzilla.gnome.org/) account.
> > 2 - Checkout if the issue you are referencing is already being tracked.
> > 3 - File a bug if there is not such issue.
> > 4 - Attach any patch you considere solves the issue.
> Yeah, that’s the general (and ideal) workflow.
>
> That being said I had a quick look at your PR (now that I have been
> made aware of it) and it looks quite trivial. I’ll have a deeper look
> when I get a chance.
Yes, the change is quite trivial, although, if I remember correctly,
wasn't very obvious.