| Re: [jaxrs-dev] Committer Conventions |
There is no way to technically enforce this. But I don't think that this is really required. That's the way votes work at Apache. And it is working well in practice. Sure, the person that started the vote has to count the individual votes afterwards and MAY have to check if non-committters also voted. However, this should be easy. We know each other. And we currently get only about 3-4 reviews per pull request and this won't be much different for votes on the list. ;-)Am Di., 10. Apr. 2018 um 20:06 Uhr schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:_______________________________________________How will you technically count "only committer votes" on a public mailing list? Do you write them up in Excel and check back with the Eclipse Foundation's official committer list?
The PR review tool guarantees this. But how to solve this in a *public* mailing list?
-Markus
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Dienstag, 10. April 2018 19:38
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Committer Conventions
Not sure I understand. Only committer votes are counted. So why do you mention "anybody"?
My point was just that the one/two week rule described above shouldn't just apply to pull request reviews but also to votes carried out on the mailing list.
Am Di., 10. Apr. 2018 um 19:25 Uhr schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:
The question is: Do we want anybody to vote on something that only has impact upon committers?
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Dienstag, 10. April 2018 08:42
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Committer Conventions
Well, back then, when I proposed to define rules for voting I actually had votes on the mailing list in mind. IMO pull request reviews are actually some special case of a vote. But for topics that cannot be expressed in a pull request, explicit votes on the mailing list make a lot of sense. I'm for example planning to start a vote on the branch protection settings right after the initial discussion.
Am Mo., 9. Apr. 2018 um 22:41 Uhr schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:
There are votes on the mailing list?
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Samstag, 7. April 2018 09:04
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Committer Conventions
By the way: IMO we should apply this rule not only to pull request but also to other votes on the mailing list.
Am Sa., 7. Apr. 2018 um 08:04 Uhr schrieb Christian Kaltepoth <christian@xxxxxxxxxxxx>:
+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
--
--
_______________________________________________
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
--
_______________________________________________
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