gmane.comp.ide.eclipse.devel

Re: Planning Meeting Notes - 23 May 2012

Grant Gayed — 2012-05-23T14:49:39

SWT:
- RC1/RC2 testing and bug fixing
- still investigating for RC2: Bug 378846 - Eclipse Crashes while clicking 
button when a table has the focus
- CBI changes released for next build

Fw: swt weekly status

Curtis Windatt — 2012-05-23T14:28:51

----- Forwarded by Curtis Windatt/Ottawa/IBM on 2012/05/23 09:28 AM -----

From:
Grant Gayed/Ottawa/IBM
To:
Curtis Windatt/Ottawa/IBM< at >IBMCA, 
Date:
2012/05/23 09:27 AM
Subject:
swt weekly status


- RC1/RC2 testing and bug fixing
- still investigating for RC2: Bug 378846 - Eclipse Crashes while clicking 
button when a table has the focus

Planning Meeting Notes - 23 May 2012

Curtis Windatt — 2012-05-23T14:23:45

Planning Meeting Notes
23 May 2012

Discussion/Reminder:
  364078 - Build notes (Most teams should remove existing, obsolete 
buildnotes_*html files)

PDE:
- One bug for RC2 + CBI changes
Bug 378112 - Product editor should allow 256x256 window icon
- Documentation / Testing

Debug:
- One bug for RC2 + CBI changes
Bug 380243 - Installed JREs not found on the Mac without internet 
connection
- Testing

Releng:
Fixed several "polish-like" bug for releng
    378429     branding plugins should have same ID as build, not 
"buildtime"     
    376227     javax.el.source not found.
More significant, found "lost logs" ... will help committers track down 
failures on build.eclipse.org
    380185 overall unit tests console log going to wrong place
Still to do for RC2:
    380318  need to update Jetty contribution
Ongoing:
    Continue to improve/automate "unit test process"

Re: All Components: please apply CBI patches

Paul Webster — 2012-05-22T11:11:48

On Mon, May 21, 2012 at 4:05 PM, Paul Webster
<pwebster-cmaem7PIVQT44Nm34jS7GywD8/FfD2ys< at >public.gmane.org>wrote:

Addendum:

#1. Component leads should check the blocker bug for each project, to
review non-pom-file changes applicable to their repos (usually
build.properties, manifests, or tests).  Apply them if they can be
consumed, or ask questions about them on the bugs.  PDE doesn't require any
non-pom-file changes.

#2. If cherry-picking the change, you can add the remote and fetch the
appropriate branch.  This uses the eclipse.platform.ui repo as an example,
and I get the branch name for the fetch from the URL to the commit:

git remote add cbi
git://git.eclipse.org/gitroot/cbi/eclipse.platform.ui.git# for
platform ui
# you can do a git fetch cbi, but that will create all of the remote
branches under cbi/
# this only gets the one we're interested in
git fetch cbi refs/heads/R3_cbipoms:refs/remotes/cbi/R3_cbipoms
git log cbi/R3_cbipoms
git cherry-pick <the commit you care about>

I have EGit instructions if anyone would like them

PW

All Components: please apply CBI patches

Paul Webster — 2012-05-21T20:05:40

In our prep work to support the Eclipse Foundation  CBI initiative, the CBI
folks have prepared commits so we can accept their pom.xml file changes
upstream.

*Bug 379747* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=379747> - Pull
request for Platform from CBI
*Bug 379748* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=379748> - Pull
request for Equinox from CBI
*Bug 379749* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=379749> - Pull
request for PDE from CBI
*Bug 379750* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=379750> - Pull
request for JDT from CBI

Each component lead should look at the bugs for their projects, and apply
the commits listed in the above bugs.  You can either add the CBI forks as
remotes in your local git repo and cherry pick the commit or take a patch
from the web page.

They can go in any time now, but should be completed before tomorrow's
(Tuesday evening) I build.

Eclipse and Equinox Juno RC1 now available

David M Williams — 2012-05-19T22:46:18


p2 repo
http://download.eclipse.org/eclipse/updates/4.2milestones

Eclipse Downloads
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2RC1-201205182145/

Equinox Downloads
http://download.eclipse.org/equinox/drops/S-3.8RC1-201205182145/

Re: Planning Meeting Notes May 16, 2012

David M Williams — 2012-05-16T14:58:03

Sorry to be late with my status/discussion notes:

releng
   status For RC1,
          still one issue to complete equinox download page fix
          not sure test automation is working as desired?

  Discussion:
          For "build notes", do we want to remove them completely? Or leave
up to each team to remove, or keep current?
            See https://bugs.eclipse.org/bugs/show_bug.cgi?id=364078
          Build schedule for remaining RCs? Saturday, Sunday, Monday,
Tuesday Wednesday? 7 PM and 9 PM?




From:Michael Rennie <Michael_Rennie-G1DYhSM1WHTQT0dZR+AlfA< at >public.gmane.org>
To:"General development mailing list of the Eclipse project."
            <eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org>,
Date:05/16/2012 10:42 AM
Subject:[eclipse-dev] Planning Meeting Notes May 16, 2012
Sent by:eclipse-dev-bounces-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org



Discussion Topics
- None

SWT
- various 3.8/4.2 RC1 bug fixes
- released launcher on Windows with support for large icons
- tested recent WebKitGTK 1.8 release, appears to have only introduced one
problem
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=379446 (fixed)
- CBI: will investigate changing tag names going forward

Debug
- Inbox triage
- No remaining work items for RC1

Ant
- No remaining work items for RC1

PDE
- Inbox triage
- Investigating one remaining performance bug for RC1 (
https://bugs.eclipse.org/365846 )

Michael Rennie_______________________________________________
eclipse-dev mailing list
eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev

Planning Meeting Notes May 16, 2012

Michael Rennie — 2012-05-16T14:29:50


Discussion Topics
 - None

SWT
 - various 3.8/4.2 RC1 bug fixes
 - released launcher on Windows with support for large icons
 - tested recent WebKitGTK 1.8 release, appears to have only introduced one
problem
 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=379446 (fixed)
 - CBI: will investigate changing tag names going forward

Debug
 - Inbox triage
 - No remaining work items for RC1

Ant
 - No remaining work items for RC1

PDE
 - Inbox triage
 - Investigating one remaining performance bug for RC1 (
https://bugs.eclipse.org/365846 )

Michael Rennie

Re: Enabled Pre-Receive Hook

Paul Webster — 2012-05-15T13:25:10

I've added a section on our pre-receive hook to
http://wiki.eclipse.org/Platform-releng/Git_Workflows#Branches_in_our_Platform_Repos

Work was done in:
*Bug 362363* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=362363> - Better
policy ... provide hooks to allow a committer to delete <userid>/branchname
branches

Enabled Pre-Receive Hook

Daniel Megert — 2012-05-15T07:20:09

Hi have enabled the pre-receive hook on almost all of our repositories 
(exceptions are platform.swt, platform.resources and jdt.core where I 
don't have commit rights). Let me know if you experience unexpected 
things.

Dani

Copyright updates

John Arthorne — 2012-05-11T14:07:29

This is a reminder for Eclipse project committers that now is a good time 
to be updating the copyrights on your source code, if you haven't already 
done so. This is often left until the end, but in past years we had some 
last minute problems due to copyright changes in RC3+, so it's safer to 
get the changes in early in the end game. You don't need a reviewer 
because it is just a comment change, but please check the changes yourself 
to make sure the copyright tool behaved properly.

Thanks to Tomasz Zarna we now have a copyright tool that works with Git. 
You'll need the latest Releng Tools plugin from 3.8 M7 or greater.

John

Planning Meeting Notes - 9 May 2012

Curtis Windatt — 2012-05-09T14:37:54

Planning Meeting Notes
9 May 2012

Discussion topics:
1) Please send status next week to Michael Rennie
2) What should build schedule be?
3) Does ANYONE (besides David) like unique names (date/time) in 
milestone/release zip files? (bug 378711)

SWT
- M7 test week went well
- Solaris-x86 machine is back, can compile our libraries on it again
- investigating loading of .png images from .ico files on Windows
- RC1 bug fixing

PDE
- RC0 test pass went well
- RC1 bug fixing (4 bugs being considered)
- Fixing documentation

Ant:
- inbox triage
- nothing planned for RC1

Debug:
- inbox triage
- one item planned for RC1 so far (https://bugs.eclipse.org/378040)

Releng:
 fixing builds
 fixing test running
 doing Juno aggregation

Re: Notice of a (quickly) coming change to our map file branches: Today, 5/8, 3 to 4 PM Eastern

Paul Webster — 2012-05-08T19:17:27

If you do have eclipse.platform.releng.maps.git checked out you can either
delete and re-clone your repo *or* you must reset your branches (do not
pull).

If you had master checked out you need:

git fetch
git checkout master
git reset --hard origin/master
git checkout R3_development

If you had R4_HEAD checked out:

git fetch
git checkout master
# if you have ever checked out master you must reset it, not merge:
git reset --hard origin/master
git branch -d R4_HEAD

Notice of a (quickly) coming change to our map file branches: Today, 5/8, 3 to 4 PM Eastern

David M Williams — 2012-05-08T18:25:26


https://bugs.eclipse.org/bugs/show_bug.cgi?id=377235

As discussed at last week's status meeting, now would be a good time to
change the names of the branches of our map repository, to follow the
typical naming conventions.

This will not effect many committers, since most do not update the map
files directly (just SWT, and me :) the rest being "autotagged".

BUT, this can effect those outside the Eclipse project if you use our map
files to "build from source" or for some other reason. You may need to
change your scripts.

Anyone who has cloned our eclipse.platform.releng.maps repository, will
need to be sure to "fetch all" and "re checkout" any branches they are
interested in.

See the bug for details, but in brief,

master --> R3_development
R4_HEAD --> master

We will be doing this in such a way as to "change history" so each file's
history is consistent with the branch it is in  (though, that would invalid
your ability to "check in changes" if you do not refetch and recheckout the
branches).

Sorry for the late notice to the community. Please comment in the bug, if
this impacts you in ways we did not anticipate, so we will learn from it.

Thank you,

Eclipse Juno M7 now available

David M Williams — 2012-05-04T22:44:32



New and Noteworthy
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M7-201205031800/eclipse-news-M7.html


Downloads
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M7-201205031800/

p2 repo
http://download.eclipse.org/eclipse/updates/4.2milestones

Thanks to everyone who made it possible,

Re: Planning Meeting Post-Notes - 2 May 2012

Daniel Megert — 2012-05-04T08:06:40

minutes on my laptop. Fastest I've heard so far is 7 minutes. Slowest was 
around 30 minutes.
cases.

Not bad!

Dani


eclipse-dev-bounces-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org wrote on 03.05.2012 17:39:36:

based on Maven/Tycho is that developers can run the build (or a portion of 
it) on their own box before making a commit.  Much better than 
takes long even without running any tests. This will give you a loooong 
time to pray ;-). 

minutes on my laptop. Fastest I've heard so far is 7 minutes. Slowest was 
around 30 minutes. Incremental builds will obviously take far less time 
than this in many cases.
easy it is: CBI platform build.
many others who have provided valuable feedback and testing.
from this list, visit

Re: Planning Meeting Post-Notes - 2 May 2012

Andrew Ross — 2012-05-03T15:39:36

On 05/03/2012 09:53 AM, Daniel Megert wrote:
Dani,

For what it's worth, my (CBI) platform build from scratch takes about 15 
minutes on my laptop. Fastest I've heard so far is 7 minutes. Slowest 
was around 30 minutes. Incremental builds will obviously take far less 
time than this in many cases.

If you haven't had a chance yet, it's worth trying to see how darned 
easy it is: CBI platform build 
<http://wiki.eclipse.org/CBI/Eclipse_Platform_Build>.

Special thanks to Paul, Igor, and Thanh for their great work and to the 
many others who have provided valuable feedback and testing.

Andrew

Re: Planning Meeting Post-Notes - 2 May 2012

akurtakov — 2012-05-03T14:08:45

The difference is that with a proper maven build one can build/run
tests only in e.g. platform.team or whatever you choose easily.
Resulting in testing only the component you work on or parts that
might be affected. Being able to easily select what to test is
crucial.

Alex

_______________________________________________
eclipse-dev mailing list
eclipse-dev< at >eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev

Re: Planning Meeting Post-Notes - 2 May 2012

Brian de Alwis — 2012-05-03T19:00:55

You don't have to rebuild the world — by providing a pointer to p2 repo with the pre-built components (i.e., the latest I-build), you can just build one component at a time, or a tree of components.  So I can build the entire platform.ui, or just org.eclipse.e4.demo.contacts, with the dependencies coming from the I-build.

Brian.

Re: Planning Meeting Post-Notes - 2 May 2012

David M Williams — 2012-05-03T15:10:27

can run the build (or a portion of it) on their own box before making a
commit.  Much better than commit-and-pray.

This is possible with PDE build too, basically an "on demand" HEAD build,
either on Hudson or on your own machine. Its just no one has ever focused
on it before. But, we (Platform Team) could do that right now, with the
changes I (and Kim before me) have made to run on build.eclipse.org. (But,
I'll admit, I don't know what you mean by "a portion of it", there's no
easy way (with PDE N-build) to say "build just JDT UI", for example ...
though, I'm sure there could be :) given some "operational definition" as
to what that would mean). Not  to mention, I'm sure all platform developers
have good targets defined in their PDE runtime targets and essentially are
"building all the time" in their workspace :)

I'm not trying to "argue" the merits of one versus the other ... I just
didn't want myths about PDE to get started.





From:Brian de Alwis <briandealwis-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To:"General development mailing list of the Eclipse project."
            <eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org>,
Date:05/03/2012 09:46 AM
Subject:Re: [eclipse-dev] Planning Meeting Post-Notes - 2 May 2012
Sent by:eclipse-dev-bounces-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org



On 3-May-2012, at 7:05 AM, Daniel Megert wrote:
bundles (I guess). Is the information stored in the pom.xml, more
frequently changed by the builder team or by the committers that own the
source?

We want the poms to be committed.  One of the advantages to being based on
Maven/Tycho is that developers can run the build (or a portion of it) on
their own box before making a commit.  Much better than commit-and-pray.

Brian.[attachment "smime.p7s" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
eclipse-dev mailing list
eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev

Re: Planning Meeting Post-Notes - 2 May 2012

Daniel Megert — 2012-05-03T13:53:28

on Maven/Tycho is that developers can run the build (or a portion of it) 
on their own box before making a commit.  Much better than 

This might work for smaller things, but the SDK build is quite big and 
takes long even without running any tests. This will give you a loooong 
time to pray ;-).

Dani


eclipse-dev-bounces-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org wrote on 03.05.2012 15:45:01:

<eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org>, 
bundles (I guess). Is the information stored in the pom.xml, more 
frequently changed by the builder team or by the committers that own the 
source?
on Maven/Tycho is that developers can run the build (or a portion of it) 
on their own box before making a commit.  Much better than 
commit-and-pray.
_______________________________________________
from this list, visit