gmane.comp.ide.eclipse.devel

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 WebKitGT

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

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

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

Re: Planning Meeting Post-Notes - 2 May 2012

Brian de Alwis — 2012-05-03T13:45:01

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.

Re: Planning Meeting Post-Notes - 2 May 2012

Paul Webster — 2012-05-03T11:46:03

Some background:

The CBI based build starts off in a "aggregator" repo, which is the releng
starting point.  It contains the main pom file that controls  the build.
In this case,
http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/pom.xml?h=Juno_M6_R3It
also contains all of our repos, references as git submodules.  The
aggregator repo controls the build input for a given build.


The first module it defines is eclipse-parent,
http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/eclipse-parent/pom.xml?h=Juno_M6_R3which
contains tycho configuration.  Stuff like the environments to build,
the p2 repositories the build needs to consume, and other build level
configuration.

Then the rest of the modules describe what needs to be built.  For example
for platform UI, you get
http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/tree/pom.xml?h=Juno_M6_R3
That's basically a list of projects to build, like
http://git.eclipse.org/c/cbi/eclipse.platform.ui.git/tree/bundles/org.eclipse.core.commands/pom.xml?h

Re: Planning Meeting Post-Notes - 2 May 2012

Daniel Megert — 2012-05-03T11:05:59

Paul,

how are those POM files looking? Do you have some examples? I looked in 
the CBI Git repos and the pom.xml files there look quite simple and don't 
contain any additional data (maybe I did not see a real one?) i.e. they 
could simply be generated on the fly by the builder for most 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? If the 
former, it would probably make more sense to keep those POM files separate 
from the source and owned by CBI . The additional files could be generated 
or mixed in when running the build and it would allow the CBI releng 
people to change those files at will.

Dani


From:
Paul Webster <pwebster-cmaem7PIVQT44Nm34jS7GywD8/FfD2ys< at >public.gmane.org>
To:
"General development mailing list of the Eclipse project." 
<eclipse-dev-j9T/66MeVpFAfugRpC6u6w< at >public.gmane.org>, 
Date:
02.05.2012 21:08
Subject:
Re: [eclipse-dev] Planning Meeting Post-Notes - 2 May 2012



On Wed, May 2,

Re: Planning Meeting Post-Notes - 2 May 2012

Paul Webster — 2012-05-02T19:08:47

The CBI team will be running the CBI-based platform builds at the same
time, and once we merge their pom files into our repos they'll be working
against our repos (and the forks they are currently using  will
disappear).  Their goal is to converge so that what they can build with CBI
by Juno SR0 is the same [1] as what we will be contributing to SR0.

[1] for some value of the same.  It includes running their output through
the comparator against whatever p2 baseline we provide.  But of course it's
sensitive to changes in our repos.

Later,
PW

Re: Planning Meeting Post-Notes - 2 May 2012

Ian Bull — 2012-05-02T18:56:29

I know 'Built by Tycho' is not planned for SR0, but if we do add the POMs
(and other things) will we get feedback if this was done properly?
 Essentially we want to add these now so we don't need to touch all of the
bundles between SR0 and SR1, but without feedback (test compile for
example), are we confident that we won't be fixing the POMs post SR0
anyways?

Cheers,
Ian

Planning Meeting Post-Notes - 2 May 2012

John Arthorne — 2012-05-02T18:13:04

This is just a quick follow-up on the many discussion topics from this 
call:

1) The branches for the releng git project will be switched on Tuesday 
next week. An email will go to eclipse-dev beforehand with instructions on 
how to update your local clone once this happens. For details see: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=377235

2) For the pack200 issue, p2 team is investigating a change to the default 
settings so we don't have to ask all clients to change their jar-processor 
settings. If any action is required it will be announced here. For details 
see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378200

3) We ran out of time on discussion merging the CBI changes into our 
repositories before Juno. This mostly involves adding pom.xml and related 
metadata to our bundles to allow them to be built by Tycho. This would 
make it easier to get Juno-based CBI builds going. We will revisit this at 
next week's planning call. Please chime in if you have strong feelings on 
this either way.

4