[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Planning Meeting Notes - Mar 20, 2007
|
To emphasize on point #3 and especially after wednesday's
- try to keep the changes to the bare minimal, Breakage caused by
gratuitous refactorings are not acceptable.
- test your change before releasing.... it sounds like I'm stating the
obvious but it happened.
- test your change in the first build available even though there are
builds every 4 hours. If we don't test what's the point of building.
By the way I have witnessed these 3 problems in M6...
PaScaL
Kim
Moir/Ottawa/IBM@I
BMCA To
Sent by: "General development mailing list
eclipse-dev-bounc of the Eclipse project."
es@xxxxxxxxxxx <eclipse-dev@xxxxxxxxxxx>
cc
03/27/2007 05:43 Subject
PM Re: [eclipse-dev] Planning Meeting
Notes - Mar 20, 2007
Please respond to
"General
development
mailing list of
the Eclipse
project."
<eclipse-dev@ecli
pse.org>
Regarding tomorrow's discussion item, here are some suggestions to make the
next milestone less painful for us :-) I know that I could have done
things a lot better and I'm sure other people have suggestions too.
M6 was a difficult milestone.
There was a lot of pressure to get things in for the API freeze.
EclipseCon in early March meant that the focus was on presentation prep
versus development for a significant portion of the milestone cycle.
(1) Ensure warm up build is successful so Europeans can test on Monday.
-Move warm up build to Friday 8am so we can work together to solve build
issues on a work day instead of builds failing over the weekend.
(2) Submission guidelines during milestone week
My understanding of the process is
-Monday - make submission toward test candidate and fix issues identified
on the Monday builds
-Tuesday - test day
-Wednesday - only submit changes to address issues that were identified
during the test pass, major bugs and regressions. This allows us to
converge.
There were several notable exceptions to this. In particular, fixes were
released for several old bugs after the test pass. Why weren't they
submitted in time for Monday's build? It seems we have lost discipline in
this area. This introduces risk because it means that these fixes were not
addressed as part of the test pass.
(2) The process for requesting a rebuild when there isn't one on the build
schedule
-Ask your component lead if a if the bug is deemed worthy of inclusion in a
rebuild toward the milestone.
-Send a note to the mailing list requesting a rebuild. The releng team
will coordinate with other teams requesting rebuilds and send a message
with the rebuild time.
-Don't be shy. Sending a request to the mailing list for a rebuild is the
right thing to do. It seems that everyone wants to wait for someone else
to request a rebuild and then chimes in with their request :-)
(3) Simple errors that could have been avoided by preparing your submission
with a colleague, or coordinated submissions on a team.
-In the case of complicated submissions or a large patch, it is often a
good idea to have someone sitting with you when make the submission as a
sanity check. There are several examples where this could have avoided
problems (me included).
-If you remove a plugin from the build, please update the feature and any
plugins that have a dependancy on it. If you don't have commit rights on
the feature, open a bug with releng and we will take care of it.
-Coordinate with your team regarding who is responsible for making the
build submission to avoid miscommunication and errors.
Kim
Mike Wilson/Ottawa/IBM@IBMCA
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
To
eclipse-dev@ecl
03/27/2007 04:59 PM ipse.org
cc
Please respond to Subject
"General development mailing list of the Eclipse [eclipse-dev]
project." <eclipse-dev@xxxxxxxxxxx> Planning
Meeting Notes -
Mar 20, 2007
------------------
Discussion Topic
------------------
Rel Eng.:
- M6 retrospective
--------
Status
--------
Platform UI:
- trim:
- fast view manager
- BIDI:
- verification
- status handler:
- bug fixing
- testing
- selection dialog:
- testing
- commands:
- performance
- menu migration
- general performance work throughout the UI
- tabs:
- tab colouring
- bug fixing
Debug:
- M6 test pass, new & noteworthy
- bug fixing & triage
- analysis of performance test failures
JDT Core:
- verified all M6 bugs
- test pass on M6
- new and noteworthy
- reviewed API. This led to 3 last API changes:
- MethodReferenceMatch.isPolymorphic() was removed since it was added
after
3.2 and later deprecated
- a typo was fixed: JavaCore#setCompilanceOptions(String, Map) was renamed
to JavaCore#setComplianceOptions(String, Map)
- the visibility of RecoveredTypeBinding and RecoveredVariableBinding has
been changed to package default since they should not be used by clients
- bug fixing has resumed after M6 was declared
JDT UI:
- M6
- updated org.junit4 to JUnit 4.2
- investigated memory leaks
- improved organize import performance
- nearly finished swapping out old JUnit test runs to disk
- bug fixing
Platform/JDT Text:
- shipped 3.3 M6
- 3.3 M7 planning
- added word navigation on mouse down + drag
- investigated time to reproduce full build bug
- added code to prevent duplicate AST creation when open class file editor
- started to investigate gray/red performance tests
- bug fixing
- inbox tracking
Workspace:
- M6 finalization
- M7 planing
- show Compare Editor Structure in Outline view
- added Compare As Text to Binary Compae viewer
- other polish bugs
PDE:
- kicked off M7 with Product Editor Theme Week to make the product
editor/export 3.3-ready
- 14 bugs fixed in one day (may be a new record. we have to check
with Guinness)
- polish/bug fixing in the 'Add to Java search' area
- added performance tests, but may result in false red on the
Performance results page because the build.properties for the
backported tests was incomplete
User Assistance:
- started work on the display of intro when the new features with
intro content are installed
- testing and bug fixing
Rel. Eng.:
- M6 Milestone Madness
- released M6 plugins to basebuilder and running test builds
- added WPF port to build
- consuming additional Orbit bundles in build
- submitting M6 to Europa
- testing patching process
- bug triage
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
