Bugzilla – Full Text Bug Listing
| Summary: | JDT UI root planning bug for 4.20 release | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Noopur Gupta <noopur_gupta> |
| Component: | UI | Assignee: | Noopur Gupta <noopur_gupta> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | akurtakov, fabrice.tiercelin, kalyan_prasad, sarika.sinha |
| Version: | 4.20 | ||
| Target Milestone: | 4.20 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=572064 | ||
| Whiteboard: | |||
|
Description
Noopur Gupta
Proposing: - Work on Java 17 support in JDT UI - Work on JUnit 5.8 support (based on its release date): includes new features like declarative test suites @All: Please list your items by March 12, 2021, to be included in the 4.20 plan. (In reply to Noopur Gupta from comment #0) > > The proposed items will be evaluated and approved based on the JDT Charter > guidelines to be included in the plan for 4.20 release. This troubles me a bit as it's unknown how much time one will be able to spend on during given time frame. Requiring approval (by whom?) to add something to the plan sounds duplicating the gerrit reviews as a committer reviews and approves it to get into master. I am probably misinterpreting this but it was brought to my attention as a possibly unclear and/or questionable practice. So if this is just about things in the plan but features coming from others or developed due to changed resources capability/planning without being in/added to the plan shouldn't be ruled out as long as there are committers willing to take care of them. (In reply to Alexander Kurtakov from comment #3) > (In reply to Noopur Gupta from comment #0) > > > > The proposed items will be evaluated and approved > Requiring approval (by whom?) to add > something to the plan sounds duplicating the gerrit reviews as a committer > reviews and approves it to get into master. This is meant as "evaluated and discussed" among the contributors to provide any early feedback on the proposal and include them in the plan before the Gerrit part comes in. > I am probably misinterpreting this but it was brought to my attention as a > possibly unclear and/or questionable practice. So if this is just about > things in the plan but features coming from others or developed due to > changed resources capability/planning without being in/added to the plan > shouldn't be ruled out as long as there are committers willing to take care > of them. This is the release planning that we have been doing all along which is being done via a root bug now to bring in the transparency. The idea is to plan ahead for big items that any contributor is thinking of adding to 4.20 and include them in the release plan. As always, the plan needs to evolve as we progress, taking into account the changed resources for example. (In reply to Noopur Gupta from comment #4) > (In reply to Alexander Kurtakov from comment #3) > > (In reply to Noopur Gupta from comment #0) > > > > > > The proposed items will be evaluated and approved > > Requiring approval (by whom?) to add > > something to the plan sounds duplicating the gerrit reviews as a committer > > reviews and approves it to get into master. > This is meant as "evaluated and discussed" among the contributors to provide > any early feedback on the proposal and include them in the plan before the > Gerrit part comes in. > > > I am probably misinterpreting this but it was brought to my attention as a > > possibly unclear and/or questionable practice. So if this is just about > > things in the plan but features coming from others or developed due to > > changed resources capability/planning without being in/added to the plan > > shouldn't be ruled out as long as there are committers willing to take care > > of them. > This is the release planning that we have been doing all along which is > being done via a root bug now to bring in the transparency. The idea is to > plan ahead for big items that any contributor is thinking of adding to 4.20 > and include them in the release plan. As always, the plan needs to evolve as > we progress, taking into account the changed resources for example. OK, I'm glad that I misunderstood it and adding new features later in the game would not be blocked. (In reply to Noopur Gupta from comment #1) > Proposing: > > - Work on Java 17 support in JDT UI > - Work on JUnit 5.8 support (based on its release date): includes new > features like declarative test suites Also: - Bug 571009: Move junit.runtime BREE to JavaSE-1.8 or above Plan bugs have been created for Java 17 support and junit.runtime BREE update. Bug for JUnit 5.8 support to be created after it is released. Here are some planned cleanups: - "valueOf() rather than instantiation" (Bug 572234) - "Map.entrySet() rather than Map.keySet() and value search" - "Int primitive rather than wrapper" - "Remove unchecked exceptions from throws clause" (In reply to Fabrice Tiercelin from comment #8) > Here are some planned cleanups: > - "valueOf() rather than instantiation" (Bug 572234) > - "Map.entrySet() rather than Map.keySet() and value search" > - "Int primitive rather than wrapper" > - "Remove unchecked exceptions from throws clause" Can you please create a top-level bug for new clean up options in 4.20 as discussed in bug 572234? I create it here: Bug 572340 (In reply to Fabrice Tiercelin from comment #10) > I create it here: Bug 572340 Thanks! |