Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Review of mass changes
> and not every milestone as decided.

As I mentioned before, the deadline milestone for mass changes has not yet been decided. Currently it looks like M1 it will be,

So, anyone against setting M1 as the deadline?

Dani



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



Hi Lars,

Just a clarification in case there is a confusion - 2-3 mass changes per every M1 milestone and not every milestone as decided.

Thanks,
Manoj.


Lars Vogel ---06/21/2019 03:20:03 PM---Hi Manoj, > This also brings me to the question - as how many mass changes should we consider reason

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



Hi Manoj,

> This also brings me to the question - as how many mass changes should we consider reasonable to accept?

IMHO this depends on the project state. If for example JDT core would
accept 2-3 mass changes per milestone I think that would be very
beneficial.

In Platform we recently saw a huge amount of cleanup patches from
Carsten Hammer (thanks to Carsten for working on this) and thanks to
our very community orientated committers we integrated most of them
within a week or two after master was open again.

Therefore, I don't think we should put a max limit of this work.

I also assume that within platform code the opportunity for mass
changes is getting smaller, as the code base has already received a
lot of improvements (or "unless changes" depending on the point of
view ;-)).

I created two tiny mass changes ;-) for JDT core to test the suggested
process, please have a look and let me know what you think and if you
require cherry-picks for them. I suggest we do this discussion in the
Gerrits.

Best regards, Lars




On Fri, Jun 21, 2019 at 11:35 AM Manoj Palat <manoj.palat@xxxxxxxxxx> wrote:
>
> Hi All,
> This also brings me to the question - as how many mass changes should we consider reasonable to accept? I think 2 or 3 mass changes per milestone per component looks reasonable - both from the amount of code change and the committer's efforts. Let us come to a conclusion on this figure as well.
>
> Thanks Lars for bringing up the points. I have answered inline.
>
> eclipse-pmc-bounces@xxxxxxxxxxx wrote on 06/21/2019 12:03:06 PM:
> > From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
>
>
> > A small comment to the suggestion for JDT merges
> >
> > > @Dani:
> > > I would recommend the following strategy for JDT:
> > > 1) author merging the massive changes first into master
> > I think you mean committer here. Author may be a contributor
>
> 1) You are right, If author is a contributor, let him/her just submit the gerrit and then ask for commit after the tests are green [ and after he has a gerrit patch for BETA_JAVAn - see point 2].
>
> > > 2) then the author himself creating a gerrit (after conflict
> > resolutions, if any) for the BETA_JAVAn branch.
> > IMHO this might be the committer or the author. Reviewing a cherry-
> > picked commit might be more work for the committer than doing the
> > merge/cherry-pick directly.
>
> 2) I would still vote for the author - if not conflict resolutions would take away a major bandwidth of the author. And I would request all who submit to JDT to create the patch for the BETA_JAVAn branch as well simultaneously - to make sure there are not merge conflicts. we can cherry-pick the one from master if all's fine.
>
> Further, at least from JDT point of view:
>
> a) Let every mass change have a bug - its easy to track.
>
>
>
> > > 3) One of the committers working on the BETA_JAVAn branch can
> > commit in the next merge from master to BETA_JAVAn
> >
> > +1
> >
> > Manoj, later today I plan to create a simple patch for JDT.core and
> > add you as reviewer so that we can test the suggested process. I
> > hope that is OK for you.
>
> @Lars: Sure - will take a look. You have already using up one out of the total mass changes allowed :)
>
>
> > Best regards, Lars
> >
> > On Fri, Jun 21, 2019 at 6:36 AM Manoj Palat <manoj.palat@xxxxxxxxxx> wrote:
> > @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.
> >
> >
> > [image removed] 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
>
> >
> > _______________________________________________
> > 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 Platform project co-lead
> > CEO vogella GmbH
> >
> > Haindaalwisch 17a, 22395 Hamburg
> > Amtsgericht Hamburg: HRB 127058
> > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> > USt-IdNr.: DE284122352
> > Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://
> > www.vogella.com_______________________________________________
> > 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 Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
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


Back to the top