Agreeing mostly with what Lakshmi has mentioned here and additionally, M1 testing is period is a time I (like many others) focus solely on what others have done rather than the work
assigned, do focussed verification and testing both at unit level as well as at a larger level. I have found these days very useful despite using I-builds thanks to the focussed effort.
Open to the point that the freeze period can be reduced to may be three days starting from Tuesday [or two days if things are fine and no rebuild requested].
My two cents…
Regards,
Manoj
From:
eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Lakshmi P Shanmugam <lshanmug@xxxxxxxxxx>
Date: Tuesday, 10 May 2022 at 7:10 PM
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] Lightweight M1 for September release
For me, M1 milestone testing is necessary, as a lot of changes go in for M1, so the testing day helps in catching and fixing any regressions early. Finding them
during M3 testing could be too late to address them for the release. The dedicated
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
For me, M1 milestone testing is necessary, as a lot of changes go in for M1, so the testing day helps in catching and fixing any regressions early. Finding them during M3 testing could be too late to address them
for the release. The dedicated milestone testing day is useful, it allows to go through and verify the bugs fixed in the component and also test the new features and SDK in different areas.
I use I-builds regularly but as Sarika said that helps in testing only the usual workflows. So, having more committers and community adopt I-builds will also help test different workflows and find issues early.
Regarding the milestone week, I believe it’s more of a stabilisation period than code-freeze period where code changes happen till Monday and we focus on testing and regression fixing on Tuesday and Wednesday, so
unrelated code-changes are not allowed. Since Thursday and Friday are mostly waiting for test results, sign-off and release of milestone, maybe we can try to improve/reduce that and open the master early when possible
(when there are no rebuild requests).
Thanks & Regards,
Lakshmi
From:
eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Sarika Sinha <sarika.sinha@xxxxxxxxxx>
Reply to: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Date: Monday, 9 May 2022 at 4:04 PM
To: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] Lightweight M1 for September release
For me, Freeze period is more like a time to sit back and look at the features/bugs which went in. To understand and try out the released stuff.
Else we are always busy with our work (development/review). I take fresh I builds every alternate
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
For me, Freeze period is more like a time to sit back and look at the features/bugs which went in. To understand and try out the released stuff. Else we
are always busy with our work (development/review).
I take fresh I builds every alternate day but then I test only the features which come in my normal work flow and rest is still untouched.
Thanks & Regards,
Sarika
From: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx> on behalf of Александър Куртаков <akurtakov@xxxxxxxxx>
Date: Friday, 6 May 2022 at 3:07 PM
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] Lightweight M1 for September release
On Fri, May 6, 2022 at 12:01 PM Wim Jongman <wim.jongman@xxxxxxxxx> wrote: > Oomph is wonderful technology to get people bootstrapped for working
on the project. I still feel it is underestimated by the core developers how this can
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
> Oomph is wonderful technology to get people bootstrapped for working on the project. I still feel it is underestimated by the core developers how this can really lower the boundary
for new developers,
I second that. We have developers working on BIRT and WindowBuilder in 15 minutes.
Oomph is wonderful technology and no one of the "core" developers ever was against its usage or setups (AFAIR) so please help us by fixing setups, writing help docs and etc.
Just understand that it's not helpful for people actually assembling the bits, fixing/improving maven/tycho builds, preparing docker images for build machines, keeping Jenkins jobs
working - in order to do that work proper one (I at least) needs as pristine and minimal environment as possible BUT this doesn't mean underestimating Oomph in any way.
AFAIK, Ed already provides an Oomph setup that installs the nightly for the platform SDK, select the platform SDK product. Just run update every day and you are good to go. Even
there is a page on the wiki which tells you how to do it.
Oomph is wonderful technology to get people bootstrapped for working on the project. I still feel it is underestimated by the core developers how this can really lower the boundary
for new developers, but also power users could make a (customized) setup that runs in 1 click that gives a fully bootstrapped environment, e.g. latest nightly all additional plugins used and all projects cloned.
The argument that it would help more if committers and others would use the I-builds regularly helps more than having freeze-weeks during milestones
is pretty convincing for me. But I agree that it would be good if as many people as possible would use the I-builds.
I think the I-builds would be simpler to use (and then used more) if they could be consumed via Oomph. I'm thinking of a Product version like 'Nightly'
that one can select besides 'Latest' or 'Latest Released'.
But I'm not sure if this is feasible (without too much work) since the Products are assembled by EPP and the I-builds only handle the Eclipse-SDK.
But maybe the Nightly could simple consist of the latest (milestone) release repos plus the current I-Build repo of the Eclipse-SDK.
Gesendet: Montag, 02. Mai 2022 um 17:52 Uhr
Von: "Mickael Istria" <mistria@xxxxxxxxxx>
An: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Betreff: Re: [eclipse-dev] Lightweight M1 for September release
I would rather (once again) raise the awareness of the active committers about "eating your own dog food" and use the milestone week to actually try
the latest greatest nightly builds.
I agree that committers, and more, need to use the nightly builds and that it is a critical part of the project quality process. However, do we need
a dedicated milestone week for that? Would there be some other/better way of achieving that result? And if we have some guarantees that all active committers are using nightly builds anyway, do we need a milestone/freeze week or can we assume that most developers
using latest build is enough to find most issues? If not, what is missing for us to find such issues as part of our daily work?
_______________________________________________ eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse-dev
