Re: Please merge the three pull requests on GitHub
- From: Alexandre Franke <afranke gnome org>
- To: Andrew Miloradovsky <miloradovsky gmail com>
- Cc: Planner-Dev-List <planner-dev-list gnome org>
- Subject: Re: Please merge the three pull requests on GitHub
- Date: Wed, 19 Apr 2017 15:56:06 +0200
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?
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.
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.
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.
--
Alexandre Franke
GNOME Hacker & Foundation Director
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]