cross-project-issues-dev http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/maillist.html cross-project-issues-dev en-us Sat, 18 May 2013 22:50:27 GMT Sat, 18 May 2013 22:50:27 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) cross-project-issues-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/maillist.html [cross-project-issues-dev] Orbit R-build has been promoted for Kepler, older builds to be removed soon http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09008.html http://download.eclipse.org/tools/orbit/downloads/drops/R20130517111416 Repository at: http://download.eclipse.org/tools/orbit/downloads/drops/R20130517111416/repository/ We're produced this R-build "early" so project's can start to use it as they produce ... http://download.eclipse.org/tools/orbit/downloads/drops/R20130517111416

Repository at:
http://download.eclipse.org/tools/orbit/downloads/drops/R20130517111416/repository/

We're produced this R-build "early" so project's can start to use it as they produce their RCs.
Assuming there are no blocking or serious regressions reported, we consider this the final "Orbit build" for Kepler.

I will begin to remove old I-build and S-builds and plan to remove them all by the Tuesday evening. If anyone needs another day or two to transition, please say so.

Thanks,

]]> Sat, 18 May 2013 22:40:55 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09008.html david_williams@xxxxxxx (David M Williams) Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09007.html Hi all, "I bet we won't notice the difference..." famous last words ;-) If I remember right it took us 2 month to work out the problems when switching from 1.x to 1.6 Nevertheless, we have changed the version used by Jubula. There is a (long) weekend of ...

Hi all,

"I bet we won't notice the difference..."  famous last words ;-) If I remember right it took us 2 month to work out the problems when switching from 1.x to 1.6

Nevertheless, we have changed the version used by Jubula. There is a (long) weekend of regression tests running. If all goes well the change will be commited on Tuesday.

- Achim

Quoting Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>:

Hi David,

Thanks for your quick cooperation ... I bet you will be happier with the
newest version anyway ... at least I hope!

I bet we won't notice the difference: log.error(..) is still the same as
always.

Anyway, can you just double-check [1] that the other, SLF4J related
plugins like ch.qos.logback.slf4j are also using the right version? Thanks.

Best regards,

Andreas

[1]
<http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins>

--
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





--------------------------------------------------------
BREDEX GmbH
Mauernstr. 33
38100 Braunschweig

Tel.: +49-531-24330-0
Fax:  +49-531-24330-99
http: www.bredex.de

GeschÃftsfÃhrer: Achim LÃrke, Ulrich Obst, Andreas Vogel
Amtsgericht Braunschweig HRB 2450

]]> Sat, 18 May 2013 10:08:02 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09007.html Achim.Loerke@xxxxxxx (Achim Loerke) Re: [cross-project-issues-dev] Libraty piggy-back CQs http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09006.html -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects We may also be able to do something with Maven build logs.

Wayne

On 05/17/2013 03:20 PM, Thomas Watson wrote:

Also using Import-Package allows for provider substitution.  You don't really know who the provider of the package dependency is by looking at a bundle manifest in isolation.

Tom



Inactive hide details for Wayne Beaton ---05/17/2013 02:06:35 PM---The issue is one of tracking who is using what third-party lWayne Beaton ---05/17/2013 02:06:35 PM---The issue is one of tracking who is using what third-party library. Right now, the tools that I use

From: Wayne Beaton <wayne@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 05/17/2013 02:06 PM
Subject: Re: [cross-project-issues-dev] Libraty piggy-back CQs
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx




The issue is one of tracking who is using what third-party library.

Right now, the tools that I use to scan the downloads directory almost do a good enough job to eliminate piggyback CQs altogether. Almost. The problem is that the tool only detects libraries that are actually distributed by the project. It works by file name alone. It fails to detect libraries that are pulled in from Orbit, for example.

I think that the solution is to scan bundles for references to third-party libraries, but I'll need some p2 magic to sort that out, I think. Bash just isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a definitive list of dependencies (including bundle and package imports?)

Of course, this doesn't help us if a project isn't distributing OSGi bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink wrote:
    Hi

    Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too.

    Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library?

    Currently I see
    20 Guava 10.x PB CQs
    2 Guava 11.x PB CQs
    0 Guava 12.x PB CQs
    4 Guava 13.x PB CQs
    0 Guava 14.x PB CQs

    With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy.

       Regards

           Ed Willink




    On 17/05/2013 19:20, Wayne Beaton wrote:
      I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it.

      The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page.

      CQs are       version-specific. You need a CQ for each version of a library that project code uses.

      It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference.

      HTH,

      Wayne

      [1]       http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire

      On 05/17/2013 02:31 AM, Ed Willink wrote:
        Hi Wayne

        Can you clarify the policy on library piggy-back CQs?

        For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too.

        Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon.

        Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries?

           Regards

               Ed Willink
        _______________________________________________
        cross-project-issues-dev mailing list
        cross-project-issues-dev@xxxxxxxxxxx 
        https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 

      --
      Wayne Beaton
      Director of Open Source Projects,       The Eclipse Foundation
      Learn about       Eclipse Projects
      EclipseCon France 2013


      _______________________________________________
      cross-project-issues-dev mailing list
      cross-project-issues-dev@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

      No virus found in this message.
      Checked by AVG -       www.avg.com
      Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13





    _______________________________________________
    cross-project-issues-dev mailing list
    cross-project-issues-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013

GIF image

GIF image

PNG image

]]> Fri, 17 May 2013 19:36:04 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09006.html wayne@xxxxxxx (Wayne Beaton) Re: [cross-project-issues-dev] Libraty piggy-back CQs http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09005.html Hi Wayne Can you clarify the policy on library piggy-back CQs? For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injec...

Also using Import-Package allows for provider substitution.  You don't really know who the provider of the package dependency is by looking at a bundle manifest in isolation.

Tom



Inactive hide details for Wayne Beaton ---05/17/2013 02:06:35 PM---The issue is one of tracking who is using what third-party lWayne Beaton ---05/17/2013 02:06:35 PM---The issue is one of tracking who is using what third-party library. Right now, the tools that I use

From: Wayne Beaton <wayne@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 05/17/2013 02:06 PM
Subject: Re: [cross-project-issues-dev] Libraty piggy-back CQs
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx




The issue is one of tracking who is using what third-party library.

Right now, the tools that I use to scan the downloads directory almost do a good enough job to eliminate piggyback CQs altogether. Almost. The problem is that the tool only detects libraries that are actually distributed by the project. It works by file name alone. It fails to detect libraries that are pulled in from Orbit, for example.

I think that the solution is to scan bundles for references to third-party libraries, but I'll need some p2 magic to sort that out, I think. Bash just isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a definitive list of dependencies (including bundle and package imports?)

Of course, this doesn't help us if a project isn't distributing OSGi bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink wrote:
    Hi

    Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too.

    Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library?

    Currently I see
    20 Guava 10.x PB CQs
    2 Guava 11.x PB CQs
    0 Guava 12.x PB CQs
    4 Guava 13.x PB CQs
    0 Guava 14.x PB CQs

    With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy.

       Regards

           Ed Willink




    On 17/05/2013 19:20, Wayne Beaton wrote:
      I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it.

      The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page.

      CQs are       version-specific. You need a CQ for each version of a library that project code uses.

      It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference.

      HTH,

      Wayne

      [1]       http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire

      On 05/17/2013 02:31 AM, Ed Willink wrote:
        Hi Wayne

        Can you clarify the policy on library piggy-back CQs?

        For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too.

        Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon.

        Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries?

           Regards

               Ed Willink
        _______________________________________________
        cross-project-issues-dev mailing list
        cross-project-issues-dev@xxxxxxxxxxx 
        https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev 

      --
      Wayne Beaton
      Director of Open Source Projects,       The Eclipse Foundation
      Learn about       Eclipse Projects
      EclipseCon France 2013


      _______________________________________________
      cross-project-issues-dev mailing list
      cross-project-issues-dev@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

      No virus found in this message.
      Checked by AVG -       www.avg.com
      Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13





    _______________________________________________
    cross-project-issues-dev mailing list
    cross-project-issues-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

GIF image

GIF image

]]> Fri, 17 May 2013 19:21:01 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09005.html tjwatson@xxxxxxx (Thomas Watson) Re: [cross-project-issues-dev] Libraty piggy-back CQs http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09004.html -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailma... The issue is one of tracking who is using what third-party library.

Right now, the tools that I use to scan the downloads directory almost do a good enough job to eliminate piggyback CQs altogether. Almost. The problem is that the tool only detects libraries that are actually distributed by the project. It works by file name alone. It fails to detect libraries that are pulled in from Orbit, for example.

I think that the solution is to scan bundles for references to third-party libraries, but I'll need some p2 magic to sort that out, I think. Bash just isn't going to cut it.

Does anybody know what p2 magic we can use to query a bundle for a definitive list of dependencies (including bundle and package imports?)

Of course, this doesn't help us if a project isn't distributing OSGi bundles...

Wayne

On 05/17/2013 02:35 PM, Ed Willink wrote:
Hi

Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too.

Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library?

Currently I see
20 Guava 10.x PB CQs
2 Guava 11.x PB CQs
0 Guava 12.x PB CQs
4 Guava 13.x PB CQs
0 Guava 14.x PB CQs

With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy.

    Regards

        Ed Willink




On 17/05/2013 19:20, Wayne Beaton wrote:
I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it.

The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a library that project code uses.

It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference.

HTH,

Wayne

[1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire

On 05/17/2013 02:31 AM, Ed Willink wrote:
Hi Wayne

Can you clarify the policy on library piggy-back CQs?

For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too.

Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon.

Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries?

    Regards

        Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013

PNG image

PNG image

]]> Fri, 17 May 2013 19:05:57 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09004.html wayne@xxxxxxx (Wayne Beaton) Re: [cross-project-issues-dev] Libraty piggy-back CQs http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09003.html -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailma... Hi

Thanks; that's clear but is hardly sensible. I have a handful of PB CQs to raise and I suspect many other projects must do too.

Since we are strongly encouarged to track the latest Orbit version, shouldn't there be an auto-PB CQ for any project that has a PB CQ for an Orbit library?

Currently I see
20 Guava 10.x PB CQs
2 Guava 11.x PB CQs
0 Guava 12.x PB CQs
4 Guava 13.x PB CQs
0 Guava 14.x PB CQs

With M7 changing the preferred Guava release to 12 that makes for 20 out of 20 projects in breach of IP policy.

    Regards

        Ed Willink




On 17/05/2013 19:20, Wayne Beaton wrote:
I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it.

The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a library that project code uses.

It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference.

HTH,

Wayne

[1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire

On 05/17/2013 02:31 AM, Ed Willink wrote:
Hi Wayne

Can you clarify the policy on library piggy-back CQs?

For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too.

Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon.

Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries?

    Regards

        Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6332 - Release Date: 05/17/13


PNG image

]]> Fri, 17 May 2013 18:35:27 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09003.html ed@xxxxxxx (Ed Willink) Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09002.html Looks right to me ... but ... to be honest, I know a whole lot less about it than just about anyone else :) (e.g not sure you need &quot;all three&quot; fragments ... but, no idea how it is normally shipped/configured). So, I've passed on your question to the origin... Looks right to me ... but ... to be honest, I know a whole lot less about it than just about anyone else :)
(e.g not sure you need "all three" fragments ... but, no idea how it is normally shipped/configured).
So, I've passed on your question to the original bug, and added you to CC in case some of the people discussing it there have any comments.
Bug 407797 - inconsistent mixture of org.slf4j.api and ch.qos.logback.slf4j

Thanks again,




From:        Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx,
Date:        05/17/2013 02:07 PM
Subject:        Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx



Hi David,

> Thanks for your quick cooperation ... I bet you will be happier with the
> newest version anyway ... at least I hope!

I bet we won't notice the difference: log.error(..) is still the same as
always.

Anyway, can you just double-check [1] that the other, SLF4J related
plugins like ch.qos.logback.slf4j are also using the right version? Thanks.

Best regards,

Andreas

[1]
<http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins>

--
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_________________________ ______________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
]]> Fri, 17 May 2013 18:35:23 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09002.html david_williams@xxxxxxx (David M Williams) Re: [cross-project-issues-dev] Kepler dates, IP Logs, and reviews http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09001.html _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Versi... The contribution review tool is intended to assist a project in identifying IP contributions that come through Bugzilla.

If your project is using Git and is pushing commits that are correctly annotated with author information, then this tool will be of no interest to you.

Its main value at this point is mostly historical for most projects.

I'll add a link to the IP Log generator from the project page.

HTH,

Wayne

On 05/17/2013 02:26 AM, Ed Willink wrote:
Hi

Found it. It's lurking on the left of
http://eclipse.org/projects/tools/ip_contribution_review.php, so if you ignore the rubbish from
http://eclipse.org/projects/tools/ip_contribution_review.php you get the good old review.

    Regards

        Ed Willink

On 17/05/2013 07:18, Ed Willink wrote:
Hi

What has happened to the old (very good) IP tool?

It gave me a good auto-generated log for MDT/OCL that I could easily review.

http://eclipse.org/projects/tools/ip_contribution_review.php is hard to find (no link from portal or project page) and gives me a list of over 600 bugs to review. No way. There have been zero IP contributions so I expect to do the job in 10 minutes not 10 hours.

If there really is a change in diligence then please threshold it at resolution after Juno, since all pre-Juno bugs have been IP logged and approved.

    Regards

        Ed Willink


On 26/04/2013 19:24, The Eclipse Foundation wrote:
Kepler approaches.

I'm starting to get IP Log review requests for the upcoming release. In at least two cases, I'm pretty sure that the submitter thought that the release date was in May. To be clear, here are the dates:

May 24/2013 - Deadline to submit IP Logs for Kepler releases
June 5/2013 - PMC-approved Review materials submitted to EMO
June 12/2013 - Kepler Uber Release review
June 26/2013 - Kepler release

The IP Logs are not due for another month. It's still a little early, but it's perfectly acceptable to submit your IP log for review in advance of the actual required-by date. Just keep in mind that the log needs to accurately reflect the content that you're releasing; if you anticipate receiving any contributions from folks who are not committers, it might be a good idea to hold off for a while.

While I'm at it, I'd like to make a plea to everybody to please try and honour the dates specified. There are a few projects that make a habit of submitting the required materials late; this causes a lot of stress for everybody involved. If you haven't started thinking about your IP Log and review documentation, now might be a good time to do so.

I need to have you PMC-approved review documentation before EOB on June 5/2013. You can either do what we've been doing for years and submit this information as a presentation, document, PDF, or whatever. Or you can just enter review information directly in the release record in the Project Management Infrastructure. A few of you have already started doing the latter; my sense is that it is an easy way to assemble and provide this information. Please let me know if you think otherwise, or if there is anything that we can do to improve it.

The PMC approval part is important. Get it approved. This may take some time. Plan to engage your PMC at least a full week in advance of the June 5 deadline. PMC members, please make sure that the document is complete and that you are satisfied with its content before providing your approval. When I look at the extremely short (or non-existent) "outside contributions" sections on some IP logs, I grow concerned that some projects aren't doing enough to court the community and grow diversity.

Please use the Release Review checklist to make sure that you've done all the necessary bits:

http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist

Note that this checklist has been around for a long time. There should be nothing new or surprising here.

I've noticed that a lot of projects do not have plans posted. This is an important and necessary part of the development process. Plan information can be entered directly in the release record in the Project Management Infrastructure. Providing a project plan in a standard format is required. Wrestling with XML is no longer required. It's easy. Please make this happen.

Note that planning should happen at the beginning of a release cycle. PMCs, please impress the importance of this on your projects.

Thanks,

Wayne
--
Wayne Beaton on behalf of the Eclipse Foundation
EclipseCon France 2013


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6275 - Release Date: 04/26/13




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6329 - Release Date: 05/16/13




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013
Title: Kepler dates, IP Logs, and reviews
Kepler approaches.

I'm starting to get IP Log review requests for the upcoming release. In at least two cases, I'm pretty sure that the submitter thought that the release date was in May. To be clear, here are the dates:

May 24/2013 - Deadline to submit IP Logs for Kepler releases
June 5/2013 - PMC-approved Review materials submitted to EMO
June 12/2013 - Kepler Uber Release review
June 26/2013 - Kepler release

The IP Logs are not due for another month. It's still a little early, but it's perfectly acceptable to submit your IP log for review in advance of the actual required-by date. Just keep in mind that the log needs to accurately reflect the content that you're releasing; if you anticipate receiving any contributions from folks who are not committers, it might be a good idea to hold off for a while.

While I'm at it, I'd like to make a plea to everybody to please try and honour the dates specified. There are a few projects that make a habit of submitting the required materials late; this causes a lot of stress for everybody involved. If you haven't started thinking about your IP Log and review documentation, now might be a good time to do so.

I need to have you PMC-approved review documentation before EOB on June 5/2013. You can either do what we've been doing for years and submit this information as a presentation, document, PDF, or whatever. Or you can just enter review information directly in the release record in the Project Management Infrastructure. A few of you have already started doing the latter; my sense is that it is an easy way to assemble and provide this information. Please let me know if you think otherwise, or if there is anything that we can do to improve it.

The PMC approval part is important. Get it approved. This may take some time. Plan to engage your PMC at least a full week in advance of the June 5 deadline. PMC members, please make sure that the document is complete and that you are satisfied with its content before providing your approval. When I look at the extremely short (or non-existent) "outside contributions" sections on some IP logs, I grow concerned that some projects aren't doing enough to court the community and grow diversity.

Please use the Release Review checklist to make sure that you've done all the necessary bits:

http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews#Checklist

Note that this checklist has been around for a long time. There should be nothing new or surprising here.

I've noticed that a lot of projects do not have plans posted. This is an important and necessary part of the development process. Plan information can be entered directly in the release record in the Project Management Infrastructure. Providing a project plan in a standard format is required. Wrestling with XML is no longer required. It's easy. Please make this happen.

Note that planning should happen at the beginning of a release cycle. PMC's, please impress the importance of this on your projects.

Thanks,

Wayne
--
Wayne Beaton on behalf of the Eclipse Foundation
EclipseCon France 2013

PNG image

]]> Fri, 17 May 2013 18:27:57 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09001.html wayne@xxxxxxx (Wayne Beaton) Re: [cross-project-issues-dev] Libraty piggy-back CQs http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09000.html -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation Learn about Eclipse Projects I believe that the Contribution Questionnaire page in the wiki [1] answers this. If it is unclear, either take a crack at clarifying it yourself or let me know I can take another run at it.

The short version is that you need CQ for any library that project code uses directly. You do not require a CQ for any library that is used indirectly via another Eclipse project. I spelled this out in more detail on the wiki page.

CQs are version-specific. You need a CQ for each version of a library that project code uses.

It doesn't matter where project code comes from. If a tool like Xtext generates project code (i.e. code that goes into your source code repository, or dynamically-generated code that gets distributed in compiled form) that uses a library, this is considered a direct reference.

HTH,

Wayne

[1] http://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire

On 05/17/2013 02:31 AM, Ed Willink wrote:
Hi Wayne

Can you clarify the policy on library piggy-back CQs?

For MDT/OCL we initially used Guava indirectly through Xtext and so might not need a PB CQ although we did raise one since Xtext auto-generates source code for us with direct calls to the Injector class. Subsequently we have some manually written code that exploits Guava too.

Our PB CQ has not updated from version 10, although Guava in Orbit is charging along through 11, 12 with 14 on the horizon.

Are we at fault through not raising more PB CQs? Do I misunderstand the policy? Is the policy inappropriate for major evolving libraries?

    Regards

        Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon France 2013

PNG image

]]> Fri, 17 May 2013 18:20:58 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09000.html wayne@xxxxxxx (Wayne Beaton) Re: [cross-project-issues-dev] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08999.html Hi David, I bet we won't notice the difference: log.error(..) is still the same as always. Anyway, can you just double-check [1] that the other, SLF4J related plugins like ch.qos.logback.slf4j are also using the right version? Thanks. Best regards, Andreas... Hi David, > Thanks for your quick cooperation ... I bet you will be happier with the > newest version anyway ... at least I hope! I bet we won't notice the difference: log.error(..) is still the same as always. Anyway, can you just double-check [1] that the other, SLF4J related plugins like ch.qos.logback.slf4j are also using the right version? Thanks. Best regards, Andreas [1] <http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins> -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ]]> Fri, 17 May 2013 18:04:35 GMT http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08999.html andreas.sewe@xxxxxxx (Andreas Sewe)