> for me verification of a change I made/pushed happens on the next business day (when it's in I-build) not waiting for
>the milestone week and this week is for mundane releng tasks and tests improvements.
JDT has always been a laggard (for lack of better word) in this case. We always verified bugs as a co-ordinated activity among
committers during the milestone week. Of course, now that the number of people doing this is becoming ever so small, I am
thinking about instant verification thus spreading the involvement of the community and reducing the stress on the people who
actively do the verification.
Now that I am here commenting on this, we should also keep in mind that the RC cycles are much shorter now and that perhaps
was decided based on the cushion we have in the form of two heavy and well-paced out milestones upfront.
Regards,
Jay
From: eclipse-dev <eclipse-dev-bounces@xxxxxxxxxxx>
On Behalf Of ?????????? ????????
Sent: 03 May 2022 11:17
To: General development mailing list of the Eclipse project. <eclipse-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [eclipse-dev] Lightweight M1 for September release
On Mon, May 2, 2022 at 6:01 PM Andrey Loskutov <loskutov@xxxxxx> wrote: I would be against this proposal. I would rather (once
again) raise the awareness of the active committers about "eating your own dog food" and use the
This Message Is From an External Sender
|
This message came from outside your organization.
|
|
|
I would be against this proposal.
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.
We have too many regressions that only found by users after release, so having a week where people hold on for a moment with hacking and try to test the product should help
our users.
This is especially important for M1 because many "mass changes" that silently break untested code happen usually there.
I fully agree with you about the need for more people to use the latest I-build. I don't see how having the milestone week increases that number though. From what I can see, milestone week is just a period when people don't work on Platform.
If a large number of you think that having the milestone week is helping let's keep it. I have to admit that I don't use the milestone week in the way it was designed - for me verification of a change I made/pushed happens on the next business
day (when it's in I-build) not waiting for the milestone week and this week is for mundane releng tasks and tests improvements.
IMHO we should separate the two discussions - increasing usage of I-builds and how much of current release steps work as designed.
I believe that having rules that can't be enforced just reduces the trust/belief in the rest of the rules, thus undermining the whole system. The reality is that we can't tell anyone - do more tests now, review more patches, do manual testing
now etc. Contributors do it whenever it fits them, their organization cycle, etc. and we need more automation that happens on every I-build to catch things rather than a dedicated milestone week and hope that someone else but few of the usual suspects test
it (and these few do it in the rest of the time too).
Gesendet: Donnerstag, 28. April 2022 um 11:59 Uhr
Von: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
An: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Betreff: [eclipse-dev] Lightweight M1 for September release
We had the lightweight M2 release process for a couple of years already and there are no problems that came out of M2 builds . Thus I would like to propose the following:
Use the same lightweight release process for M1 starting with the next release cycle.
This means no milestone week with all the associated limitations coming from it.
If that process is good enough for M2 I see no reason to have a heavier one for earlier milestone release.
P.S. Let's keep this discussion about the M1 release process and discuss further process enhancement if/when we do the change for M1. Step-by-step approach is always best and
allows some progress to be made rather than striving for the next big thing/change.
_______________________________________________ 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