| Re: [jaxrs-dev] Committer Conventions |
+1, this is a good compromise.Am Do., 5. Apr. 2018 um 22:40 Uhr schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:_______________________________________________+1
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen
Sent: Donnerstag, 5. April 2018 21:19
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Committer Conventions
Markus,
I was going to propose something very similar to that, our e-mails almost crossed. So here goes mine:
--
Why don’t we just agree on 1 week for “simple” fixes and 2 for “api” fixes? It would be up to the contributor to decide what kind of fix it is (and let’s just have 2 kinds please :).
Whoever misbehaves shall be responsible for picking up the tab at our next conference dinner ;)
--
— Santiago
On Apr 5, 2018, at 1:57 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
Santiago,
I fully understand you point. But on the other hand, unpaid contributors typically lose their personal drive if their work stays untouched for weeks (like in the open source motto "release early release often"). Also, I personally need to say that it is hard for me as an assignee to review PRs after two weeks of working on other things. It costs valueable time to again and again read the same discussion threads just because we forcefully suspended the discussion weeks. It is much easier to merge directly when the whole idea still is in my brain. ;-)
Looking at the work done right now, most of it are nobrainers / small fixes. I doubt that the risk you fear will ever happen, because complex PRs are not so often and you won't be on holidays so often. ;-)
So why not saying that committers can decide on their own when to merge, but we all agree that we should wait for two weeks if the API is "really" touched?
-Markus
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Santiago Pericas-Geertsen
Sent: Mittwoch, 4. April 2018 21:46
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Committer Conventions
Markus,
I’ve seen many cases where someone found a good reason not to accept a PR that other people did not see. I just don’t understand what is the rush in pushing a PR in one week. JAX-RS is mature API that does not really need that.
Sure, you can argue that simple fixes could be pushed faster (and we could have rules for that), but if someone submits a PR with a larger feature (say, a new proxy API), we should give everyone a chance to review it.
Sorry, still -1 on 1 week.
— Santiago
On Apr 4, 2018, at 2:04 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
(1) Minimum Length of review period before merge / close of PR
We should define an aboslute minimum review period so all interested committers had a fair chance to review / vote on each PR before it gets finally merged / closed. Current proposal is one week. A shorter period makes it unnecessarily hard for some committers to review (e. g. when on business travel). A longer period reduces overall agility of the project a lot, particularly when subsequent PRs are interrelated / ontop of each other, hence slows down authors.
Santiago: The problem with 1 week is that someone could easily be out on vacation etc. for that period. How would you feel is something you care about is proposed and merged before you get back? I think in needs to be more than a week.
Markus: I see your point and share the same feeling. But on the other hand, after contributing to lots of open source projects in the past decades, I need to say that I never had seen such a long minimum PR review time, and never really experienced that this was a _real_ problem. In the end, the idea we have at the EF is to speed up project performance tremendously, and this certainly means that the committers have to be much more agile in future. It might imply that we have to either clarify our intentions before we leave on vacation, or we have to live with the outcome, or we have to check our mails one per week. Comparing my industrial projects with my open source projects, I need to say that open source a bit means to give up control and let the sum of the other committers take care. If I have the fear that they all will vote +1 and I am the only -1 then maybe they simply are right.
-Markus
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
--