Re: [eclipse-pmc] Review of mass changes

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

> 2)
then the author himself creating a gerrit (after conflict resolutions,
if any) for the BETA_JAVAn branch. 
> 3)
One of the committers working on the BETA_JAVAn branch can commit in the
next merge from master to BETA_JAVAn

So, the sequence
would be: commit the change to BETA *before* merging?

An important thing
is to do master and BETA very close to each other to avoid that the change
gets conflicts again.

Dani



From:
       "Manoj
Palat" <manoj.palat@xxxxxxxxxx>
To:
       eclipse-pmc@xxxxxxxxxxx
Date:
       21.06.2019
06:36
Subject:
       [EXTERNAL]
Re: [eclipse-pmc] Review of mass changes
Sent
by:        eclipse-pmc-bounces@xxxxxxxxxxx

---

@Lars : Please find the outline of merge
strategy of JDT 

(1) JDT creates a BETA_JAVAn [where n=13 currently] for every Java release
and the merge from the master to the BETA branch is done regularly - in
terms of (1) periodically every milestone (2) regularly if there are major
changes in master and (3) if there are major changes in BETA_JAVAn itself.

(2) It should also be noted that the BETA_JAVAn will merge to master every
six months - and this merge is fixed to be done in M1 - in fact early M1
- mostly as one of the initial commits given the close release dates of
both Eclipse - immediately after March and September releases.

(3) BETA_JAVAn will continue to be available as a Patch on March and September
releases of Eclipse - Hence again it is required that the BETA_JAVAn is
in sync with master for a smooth patch update.

@Dani:
I would recommend the following strategy for JDT:
1) author merging the massive changes first into master
2) then the author himself creating a gerrit (after conflict resolutions,
if any) for the BETA_JAVAn branch. 
3) One of the committers working on the BETA_JAVAn branch can commit in
the next merge from master to BETA_JAVAn

We can start with this strategy and see how it goes, and then change accordingly.

Regards,
Manoj.


Lars Vogel ---06/20/2019
09:12:13 PM---What is the merge strategy in JDT? Do they merge master into
the feature branch on a regular basis?

From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx
Date: 06/20/2019 09:12 PM
Subject: [EXTERNAL] Re: [eclipse-pmc]
Review of mass changes
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

---

What is the merge strategy in JDT? Do they merge master into the feature
branch on a regular basis?

Daniel Megert <daniel_megert@xxxxxxxxxx>
schrieb am Do., 20. Juni 2019, 17:21: 
The milestone has not yet been decided.
Mickael, I would be fine with M1.

What would be better for JDT: Also getting the same change for the branch
or do the merge yourself along with all other changes?

Dani



From:        "Manoj
Palat" <manoj.palat@xxxxxxxxxx>
To:        eclipse-pmc@xxxxxxxxxxx
Date:        20.06.2019
06:55
Subject:        [EXTERNAL]
Re: [eclipse-pmc] Review of mass changes
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx

---

Hi All,

Thanks Sarika for bringing this point out.

A mass change which has proven benefits is always welcome and really appreciate
the time and effort of people who do that.

However, JDT changes themselve are massive and frequent due to the interplay
of three month release of Eclipse combined with the six month release cadence
of Java - sometimes the merging efforts themselves vie for being a subproject
of Eclipse :). 

Given these two factors, I totally agree especially from JDT projects pov,
M1 can be (and should be the only) the point in which such proven mass
changes can be incorporated.

Regards,
Manoj

"Sarika Sinha" ---06/20/2019 09:58:49 AM---There are few points
to be considered - 1. Problem is not with the trivial code changes, problem
is

From: "Sarika Sinha" <sarika.sinha@xxxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx
Date: 06/20/2019 09:58 AM
Subject: [EXTERNAL] Re: [eclipse-pmc]
Review of mass changes
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

---

There are few points to be considered -
1. Problem is not with the trivial code changes, problem is in managing
the merge conflicts either during this mass change by the contributor or
by other contributors after this mass change is released. (As I have seen
it happening this week where contributor is struggling to rebase the mass
change gerrits)
2. This merging turns to be an evil specially for JDT repositories where
new Java version work happens in a different branch (due to legal constraints).

I am OK with the mass changes in M1 but it should be a call of the component
based on the timeline and other feature development going on in parallel
like JDT.

Thanks & Regards,
Sarika

"Daniel Megert" ---06/20/2019 06:01:32 AM---Thanks Mickael, that's
a good approach which works fine with me. As for the review, yes a second
per

From: "Daniel Megert" <daniel_megert@xxxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx
Date: 06/20/2019 06:01 AM
Subject: [EXTERNAL] Re: [eclipse-pmc]
Review of mass changes
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

---

Thanks Mickael, that's a good approach which works fine with me.

As for the review, yes a second person besides the owner must give a code-review+1
(or+2), but for mass changes with (apparently) trivial code changes I would
be OK if only random samples are reviewed.

Dani



From: Mickael Istria <mistria@xxxxxxxxxx>
To: "eclipse-pmc@xxxxxxxxxxx"
<eclipse-pmc@xxxxxxxxxxx>
Date: 19.06.2019 18:53
Subject: [EXTERNAL] Re: [eclipse-pmc]
Review of mass changes
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx

---

Hi,

My 2c below ;)

About !longChain.isEmpty() vs longChain.size() > 0, I favor the first
one because isEmpty() is theorically a O(1) operation while size() is a
O(n). Of course, most of smart enough implementations have this optimized
and make size() a O(1), but there is usually no guarantee it is so. So
size() is more expensive that isEmpty() and should be preferred.
About readability, I understand the concern and I would like to suggest
an alternative for that case: longChain.isEmpty() == false, which seems
to have the qualities requested by all parties.

About requiring a review for mass changes, +1.
About not allowing mass change after some milestone, +1.

Cheers


-- 
Mickael Istria
Eclipse
IDE developer, for Red
Hat Developers
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc

_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc

_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc

[attachment "graycol.gif" deleted by Daniel Megert/Zurich/IBM]
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc


_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc

[attachment "graycol.gif"
deleted by Daniel Megert/Zurich/IBM] _______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc