[platform-dev] Changes in M1 and M3 rules starting with 4.31 stream

[Aleksandar Kurtakov via platform-dev]

Hey everyone,
On the last Eclipse PMC call we discussed the rules and how much they are
followed and also the increasing demand for less "freezes".
The current rules for test days, reminders, tagging and etc. are no longer
followed by the community in general and it requires extra effort from
releng side (which could be spent better).
With the above said the PMC agreed that:
All milestones (M1/M2/M3) will be lightweight and follow the same rules as
M2 has been lately - this is more or less Thursday build is contributed on
Friday without sign off bugs, development freeze for the week, etc.
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/RELEASE.md
is updated with corresponding changes.

Testing and testing work is still highly appreciated and we are encouraging
people to spend more time on stability work, test improvements and so on.
Having Tuesday of a given week dedicated for testing is just not fitting
with the current distributed, multi company community but if someone
can/want to still dedicate these days for testing everyone will be grateful.



-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] 4.31 development open

[Aleksandar Kurtakov via platform-dev]

Hello,



We are pleased to announce that the master branch is opened for 4.30
development.

You can subscribe to the build schedule here
<https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html>.


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Avoid code freezing in master?

[Aleksandar Kurtakov via platform-dev]

On Tue, Nov 28, 2023 at 12:07 PM Thomas Singer via platform-dev <
platform-dev@eclipse.org> wrote:

> Hi devs,
>
> Are there any plans to reducing code freeze periods in master? Maybe,
> for preparing releases it would be better to fork a release branch
> instead of locking the master?
>

Master is not locked for the release now. It's locked due to the amount of
things done to open the next stream.
There are no plans as for pretty much everyone releng is a "side" job. As
long as things are that way there could be no planning.
For any change to happen one should look into
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/1557
- find an item and automate, remove the need for it, etc.
Alternatively, one comes with totally new releng procedures and prove that
driving a release in the new way is working solution.

P.S. What I can and do (there is just so much time I can afford) for each
release is try to automate/fix/etc. 2-3 lowest hanging things per each
release and repeat on the next cycle.


>
> --
> Best regards,
> Thomas Singer
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Merge Eclipse News into make Eclipse Website

[Aleksandar Kurtakov]

On Wed, Jul 5, 2023 at 6:17 PM Jonah Graham  wrote:

> Hi folks,
>
> It seems that the new eclipse.dev domain name and redirects has taken out
> Eclipse News.
>
> Any thoughts on merging
> https://github.com/eclipse-platform/www.eclipse.org-eclipse-news into
> https://github.com/eclipse-platform/www.eclipse.org-eclipse?
>
> I know there have been lots of git repo merging recently which I am
> grateful for, but I haven't paid much attention to the process.
>
> Any volunteers to merge these repos, or any objection to doing this merge?
>

No objections and I really think this is good move. I can't spend the time
to help with it though.


>
> Jonah
>
>
> ~~~
> Jonah Graham (he/him)
> Kichwa Coders
> www.kichwacoders.com
>
>
> -- Forwarded message -
> From: Matt Ward (@mward) 
> Date: Wed, 5 Jul 2023 at 10:42
> Subject: Re: Help Desk | broken redirection to eclipse.dev (#3358)
> To: 
>
>
> Matt Ward <https://gitlab.eclipse.org/mward> commented
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3358#note_1168040>:
>
>
> TL;DR: merge the content of
> https://github.com/eclipse-platform/www.eclipse.org-eclipse-news into
> https://github.com/eclipse-platform/www.eclipse.org-eclipse into a new
> /news directory and this should fix itself.
>
> The issue here is that for reasons of antiquity the Eclipse platform
> project ended up with 2 sites: e.o/eclipse and e.o/eclipse/news , with the
> news 'site' being a hack to allow all committers on the various platform
> related projects to contribute.
>
> While that has worked the newer tooling behind eclipse.dev is driven by
> the PMI which expects a single 'site' per project.
>
> —
> View it on GitLab
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3358#note_1168040>.
>
> You're receiving this email because of your account on gitlab.eclipse.org.
> Unsubscribe
> <https://gitlab.eclipse.org/-/sent_notifications/6ef5461c2b094e7c66c208ce31a2f49c/unsubscribe>
> from this thread · Manage all notifications
> <https://gitlab.eclipse.org/-/profile/notifications> · Help
> <https://gitlab.eclipse.org/help>
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Review practice

[Aleksandar Kurtakov]

On Thu, Mar 30, 2023 at 2:40 PM Sebastian Zarnekow <
sebastian.zarne...@gmail.com> wrote:

> Hi there,
>
> It might be my poor understanding of the current process, so I'm asking
> here on the mailing list:
>
> Are reviews a prerequisite for stuff that's supposed to be merged into
> platform?
>

Unfortunately, we are not in a position to have such a prereq (although I
would love this to be the case). Very few people do reviews and PRs stand
in the queue (https://github.com/pulls?user=eclipse-platform) longer than
acceptable thus the overall practice is that committers push things without
review when feeling comfortable about the stability of the patch. Of
course, this doesn't mean that things couldn't be done better or even that
there wouldn't be issues - it just means that's the only way to make
progress with current resources.
Help would be more than appreciated to review pending patches in the review
queue, agree on what "timely" reply/review means and eventually raise the
requirements.


>
> Best
> Sebastian
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Inactive committer cleanup

[Aleksandar Kurtakov]

Hey everyone,
There is https://github.com/eclipse-platform/.github/issues/92 on the
topic. If your name is on the list please state your intent to stay as a
committer on the issue.
Let's have any discussion also there.

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Allowing bundles to target Java 17 for 2022-06 release

[Aleksandar Kurtakov]

On Tue, Jan 24, 2023 at 9:22 PM Jonah Graham  wrote:

> +1 for moving to Java 17 for BREE.
>
> IIRC on past BREE upgrades various sub-parts of Platform held back on
> older versions. Is the proposal to remove those special cases for the move
> to Java 17?
>

Strictly speaking for eclipse.platform (
https://github.com/orgs/eclipse-platform/repositories) repositories this
used to be only SWT but I don't think we should preserve that exception.
I've sent this email deliberately to platform-dev as core parts of Equinox
are at 1.8 even now (for a reason AFAIK) and I'm not JDT committer to
influence that decision there. PDE on the other hand will have to follow
Platform as it will be forced by such a move.



>
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Tue, 24 Jan 2023 at 14:12, Aleksandar Kurtakov 
> wrote:
>
>> Hey everyone,
>> Our test dependencies (e.g. reddeer), our build tool (tycho) and etc.
>> already require Java 17 thus the whole releng is using Java 17 now with no
>> dependency on Java 11 anymore.
>> Due to that there are already test bundles that target Java 17 and use
>> Java 17 language features. Feel free to do so even more.
>> As automated Java 11 testing is impossible nowadays I think it's time for
>> us to allow bundles to go to Java 17 BREE after March release.
>> I welcome constructive discussion which should include how and who is
>> going to take care of Java 11 testing/verification if there is disagreement
>> for this move.
>>
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Allowing bundles to target Java 17 for 2022-06 release

[Aleksandar Kurtakov]

Hey everyone,
Our test dependencies (e.g. reddeer), our build tool (tycho) and etc.
already require Java 17 thus the whole releng is using Java 17 now with no
dependency on Java 11 anymore.
Due to that there are already test bundles that target Java 17 and use Java
17 language features. Feel free to do so even more.
As automated Java 11 testing is impossible nowadays I think it's time for
us to allow bundles to go to Java 17 BREE after March release.
I welcome constructive discussion which should include how and who is going
to take care of Java 11 testing/verification if there is disagreement for
this move.

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [equinox-dev] Eclipse and Equinox 4.27 (2023-03) M1 is available

[Aleksandar Kurtakov]

On Fri, Jan 6, 2023 at 8:26 PM Samantha Dawley  wrote:

> Hello,
>
> We are pleased to announce that 2023-03 M1 is available for download and 
> updates.
>
>   Eclipse downloads:
>   
> https://download.eclipse.org/eclipse/downloads/drops4/S-4.27M1-202301041800/
>
>   New and Noteworthy:
>   https://www.eclipse.org/eclipse/news/4.27/
>
>   Update existing (non-production) installs:
>   https://download.eclipse.org/eclipse/updates/4.27-I-builds/
>
>   Specific repository good for building against:
>   
> https://download.eclipse.org/eclipse/updates/4.27-I-builds/I20230104-1800/
>
>   Equinox specific downloads:
>   https://download.eclipse.org/equinox/drops/S-4.27M1-202301041800/
>
> Thank you to everyone who made this checkpoint possible.
>
>
Thanks Sam!

> Best Regards,
> Samantha Dawley
> Red Hat Eclipse Team
> ___
> equinox-dev mailing list
> equinox-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Master branch is open for 4.27 development

[Aleksandar Kurtakov]

Hello

We are pleased to announce that the master branch is open for 4.25
development.

You can subscribe to the build schedule here
<https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html>.


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 4.26 RC2 (2022-12) RC2 is available

[Aleksandar Kurtakov]

We are pleased to announce that 2022-12 RC2 is available for download
and updates.


Eclipse downloads:
https://download.eclipse.org/eclipse/downloads/drops4/I20221123-1800

Build logs and/or test results (eventually):
https://download.eclipse.org/eclipse/downloads/drops4/I20221123-1800/testResults.php

Software site repository:
https://download.eclipse.org/eclipse/updates/4.26-I-builds

Specific (simple) site repository:
https://download.eclipse.org/eclipse/updates/4.26-I-builds/I20221123-1800

Equinox downloads:
https://download.eclipse.org/equinox/drops/I20221123-1800



Thank you to everyone who made this checkpoint possible.


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Declare 4.26 RC2

[Aleksandar Kurtakov]

Hello,

Please sign off on issue 691 - Declare 4.26 RC2
<https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/691>

Current Candidate

Eclipse downloads:
https://download.eclipse.org/eclipse/downloads/drops4/I20221123-1800

Build logs and/or test results (eventually):
https://download.eclipse.org/eclipse/downloads/drops4/I20221123-1800/testResults.php

Software site repository:
https://download.eclipse.org/eclipse/updates/4.26-I-builds

Specific (simple) site repository:
https://download.eclipse.org/eclipse/updates/4.26-I-builds/I20221123-1800

Equinox downloads:
https://download.eclipse.org/equinox/drops/I20221123-1800

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Reusing generic editor features in JDT

[Aleksandar Kurtakov]

On Sat, Nov 19, 2022 at 11:25 AM Gayan Perera  wrote:

> Hi all,
>
> This is really good news. If we can phase out jdt.ui and may be make it a
> light weight UI layer just to support additional custom JDT protocol parts
> in LSP, the JDT.LS will heavily benefit since we don't need to always
> change both jdt.ui and jdt.ls when we need to implement a new feature.
>

This is my team's end goal but we are still far far from it! But the first
step is being made so the short term goal is to make jdt.ls.client being
basically usable with many(most?) bells and whistles missing but smth we
can use daily to identify what's missing.


>
> Best regards,
> Gayan.
>
> On Fri, Nov 18, 2022 at 12:43 PM Mickael Istria 
> wrote:
>
>> Hi all, hi Gayan,
>>
>> I'm reviving this old thread that is the most relevant place to share
>> some progress:
>> In https://github.com/rgrunber/eclipse.jdt.ls.client (there is a p2 repo
>> linked), you can see some progress on the topic of using JDT-LS in Eclipse
>> IDE.
>> Currently, it just starts JDT-LS externally, from a separate installation
>> as a separate process (similarly to what Wild Web Developer does with
>> LemMinX); but it already does a decent bit of work that way. In the code,
>> you can also find code that has tried to start JDT-LS in the same process
>> as the workspace, and this seems to be both tricky and technically
>> interesting; some issues were reported to JDT-LS about how this kind of
>> integration can be made to work, but this is not trivial. The first
>> iteration was then to keep the easier separate-process approach, but I (and
>> others are welcome to join) will try to keep investigating having JDT-LS in
>> the same process because I see major potential benefits in this.
>> Cheers,
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Adding new version of JNA library in orbit

[Aleksandar Kurtakov]

On Wed, Aug 31, 2022 at 9:11 AM Ed Merks  wrote:

> The platform is  pulling that directly from Maven:
>
>
>
> The generate maven dependency resolves to a much newer version:
>
>
>
> The versions are available here( with 5.21.1 being the latest):
>
>
>   https://repo1.maven.org/maven2/net/java/dev/jna/jna/
>
>
> The version would need to be changed here:
>
>
>
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/67bf36e6dcd414163905a05e72c30c66a5b5b164/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L178-L189
>
>
> So it's best to open an issue in that repository
>
>
>
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues
>

Submitting PR would be even better. I'm afraid that it's too late for
2022-09 release as the final build is supposed to literally happen today
and bumping JNA now will give zero time for other projects to adjust nor
any time for bugfixes. If there is PR submitted now we can do the license
check/approval and etc. and have the change in I-build (for 2022-12)
hopefully next week.


>
>
>
> On 31.08.2022 01:29, Muhammad Umair Sair wrote:
>
> Hi,
>
> I am facing issue on Linux with NativeLibrary. When HTTPS proxy is set, I
> am getting errors on terminal error stream with consistency
> from org.eclipse.equinox.internal.security.linux.unlockSecretService(..)
> and following call in this method gets stuck forever.
>
> Pointer secretService =
> fLibSecret.secret_service_get_sync(SecretServiceFlags.SECRET_SERVICE_LOAD_COLLECTIONS,
> Pointer.NULL, gerror);
>
> On investigation, I found that its a race condition between finalizer and
> NativeLibrary.getInstance(..). On second time call to get secret-1 library,
> the object from weak reference is gone/GCed in NativeLibrary.libraries but
> the NativeLibrary object itself is not finalized/GCed yet, so it gets
> ref.get()==null and goes for reloading the library which causes following
> errors in console. The reason is that the older library was not unloaded
> yet and we loaded it again.
>
> ~
> (java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot register
> existing type 'SecretService'
>
> (java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot add private
> field to invalid (non-instantiatable) type ''
>
> (java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753:
> g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE
> (instance_type)' failed
>
> (java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753:
> g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE
> (instance_type)' failed
>
> (java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot register
> existing type 'SecretBackend'
>
> (java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753:
> g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE
> (interface_type)' failed
>
> (java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753:
> g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE
> (interface_type)' failed
>
> (java:3835014): GLib-CRITICAL **: 02:47:42.753: g_once_init_leave:
> assertion 'result != 0' failed
>
> (java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753:
> g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE
> (instance_type)' failed
> ~~
>
> I was looking at jna project and they have moved away from using
> finalizers [1] and it is available is version 5.12.
>
> Can we add latest jna version in orbit for 2022-09?
>
> [1] https://github.com/java-native-access/jna/pull/1402
>
> Thanks,
> Umair Sair
>
> ___
> platform-dev mailing listplatform-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Committer disagreement resolution guidelines

[Aleksandar Kurtakov]

Hey everyone,
We have seen a number of heated discussions lately and after discussion at
the PMC meeting today we decided to write some guidance on how resolutions
should happen to prevent escalation. Please read it at
https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution
.
Also a reminder to keep an eye on the part regarding commit messages. This
one is equally important. Read at
https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#commit-messages
.

Please act accordingly so we can all have calmer and more friendly
environment to work in!

Best regards,
-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Merge equinox.aggrcon into ep.aggrcon

[Aleksandar Kurtakov]

Thank you, Ed!

On Wed, Jun 15, 2022 at 5:56 PM Ed Merks  wrote:

> FYI,
>
> I've completed the merge of equinox.aggrcon into ep.aggrcon and deleted
> equinox.aggrcon:
>
>
> https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=ec821e3df25d9cba7372336ff7fefaa7c86166c0
>
> I've confirmed that the new staging site contains the same number of IUs
> as before:
>
>https://download.eclipse.org/staging/2022-09/
>
> Cheers,
> Ed
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Merge SimRel equinox.aggrcon into ep.aggregator

[Aleksandar Kurtakov]

On Thu, Jun 9, 2022 at 1:58 PM Ed Merks  wrote:

> Hi,
>
> I don't see any good reason to keep equinox.aggrcon separate from
> ep.aggrcon given it contributes the same repository and is always
> changed in lock-step by the same person. Does anyone object if I merged
> these two at the start of the 2022-09 cycle?  I'll interpret silence as
> agreement.  :-P
>

Go for it. Every little bit is needed in bringing sanity to releases.


>
> Regards,
> Ed
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [ide-dev] New vscode light theme for eclipse

[Aleksandar Kurtakov]

On Mon, May 30, 2022 at 11:28 AM S A 
wrote:

> > Maybe it's the kind of refreshment we need for the IDE to look much
> leaner without really changing anything: shipping a different default
> layout, without toolbar, moving the run and perspective someplace else...?
>
> From what I've been told by developers using Eclipse for the first time,
> they would rather not use it because it's slow and unresponsive. A
> different UI layout might of course make a better first impression, but I
> doubt that impression will last.
>

Actually less visual widgets will most likely speed up the UI part if the
slowness is coming from it and not from the plugin logic.


>
> On Mon, 30 May 2022 at 10:34, Mickael Istria  wrote:
>
>> Thanks Gayan,
>>
>> I've evolved my local workbench to look a bit more like the one you
>> suggested, hiding toolbars, making it fullscreen by default... So far so
>> good.
>> Maybe it's the kind of refreshment we need for the IDE to look much
>> leaner without really changing anything: shipping a different default
>> layout, without toolbar, moving the run and perspective someplace else...?
>> We could even make it default in the SDK as long as it's not breaking any
>> form of functionality/extensibility (sure it's disruptive, but not worse
>> and also not too hard for users to restore to previous state).
>>
>> Cheers,
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Running the SWT maven build under windows

[Aleksandar Kurtakov]

Please rebase on master now .
https://github.com/eclipse-platform/eclipse.platform.swt/commit/0051f9bb765888d533b8ec28bb872d841e99e15f
should have improved the situation.

On Mon, May 2, 2022 at 10:07 AM Christoph Läubrich 
wrote:

> That would be great, because that is currently holding me back to
> provide a matrix verification action for Github that tests on
> linux/win/mac ...
>
> As we occasionally have some problems on win or mac I think that would
> be useful to have at least some basic testing/compilation for this
> platforms.
>
> Am 02.05.22 um 08:57 schrieb Aleksandar Kurtakov:
> >
> >
> > On Mon, May 2, 2022 at 9:27 AM Christoph Läubrich  > <mailto:lae...@laeubi-soft.de>> wrote:
> >
> > I'm using the follwoing build command from the jenkins ci
> verification
> > action:
> >
> > mvn --batch-mode -Pbuild-individual-bundles
> -DforceContextQualifier=zzz
> > -Dnative=${{ matrix.config.native }} -DskipJni -DskipRust
> > -Dcompare-version-with-baselines.skip=true
> > -Dmaven.compiler.failOnWarning=true install
> >
> > the problem is the ${{ matrix.config.native }}, I use:
> >
> > -> gtk.linux.x86_64 for linux
> > -> win32.win32.x86_64 for windows
> > -> cocoa.macosx.x86_64 for mac
> >
> > Linux build works, but win+mac aborts with the mentioned error.
> >
> > So I assume I either guessed the 'native' wrong or need to pass
> > additional parameters for windows/mac?
> >
> >
> > Ah, I misunderstood the question at first. So this is simplification of
> > the build process which I haven't completed fully (as Jenkins didn't
> > complain about it)
> > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189807
> > <https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189807> .
> > I'll finish it right now.
> >
> >
> >
> > Am 02.05.22 um 08:07 schrieb Aleksandar Kurtakov:
> >  >
> >  >
> >  > On Sun, May 1, 2022 at 8:00 AM Christoph Läubrich
> > mailto:lae...@laeubi-soft.de>
> >  > <mailto:lae...@laeubi-soft.de <mailto:lae...@laeubi-soft.de>>>
> wrote:
> >  >
> >  > I try to run the SWT build under windows but always get:
> >  >
> >  > Error: Cannot resolve project dependencies:
> >  > Error: You requested to install 'org.eclipse.equinox.p2.iu;
> >  > org.eclipse.swt.tests.fragments.feature.feature.group 0.0.0'
> > but it
> >  > could not be found
> >  >
> >  > so it seems I need to pass something special to the build
> > command...
> >  >
> >  >
> >  > I have described this in more details here:
> >  >
> > https://github.com/eclipse-platform/eclipse.platform.swt/issues/68
> > <https://github.com/eclipse-platform/eclipse.platform.swt/issues/68>
> >  >
> >   <
> https://github.com/eclipse-platform/eclipse.platform.swt/issues/68 <
> https://github.com/eclipse-platform/eclipse.platform.swt/issues/68>>
> >  > ___
> >  > platform-dev mailing list
> >  > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> > <mailto:platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>>
> >  > To unsubscribe from this list, visit
> >  > https://www.eclipse.org/mailman/listinfo/platform-dev
> > <https://www.eclipse.org/mailman/listinfo/platform-dev>
> >  > <https://www.eclipse.org/mailman/listinfo/platform-dev
> > <https://www.eclipse.org/mailman/listinfo/platform-dev>>
> >  >
> >  >
> >  > You have to always pass -Pbuild-individual-bundles when building
> > swt out
> >  > of the aggregator build.
> >  > --
> >  > Aleksandar Kurtakov
> >  > Red Hat Eclipse Team
> >  >
> >  > ___
> >  > platform-dev mailing list
> >  > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> >  > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> > <https://www.eclipse.org/mailman/listinfo/platform-dev>
> > ___
> >     platform-dev mailing list
> > platform-dev@eclipse.org <mailto:platform

Re: [platform-dev] Running the SWT maven build under windows

[Aleksandar Kurtakov]

On Mon, May 2, 2022 at 9:27 AM Christoph Läubrich 
wrote:

> I'm using the follwoing build command from the jenkins ci verification
> action:
>
> mvn --batch-mode -Pbuild-individual-bundles -DforceContextQualifier=zzz
> -Dnative=${{ matrix.config.native }} -DskipJni -DskipRust
> -Dcompare-version-with-baselines.skip=true
> -Dmaven.compiler.failOnWarning=true install
>
> the problem is the ${{ matrix.config.native }}, I use:
>
> -> gtk.linux.x86_64 for linux
> -> win32.win32.x86_64 for windows
> -> cocoa.macosx.x86_64 for mac
>
> Linux build works, but win+mac aborts with the mentioned error.
>
> So I assume I either guessed the 'native' wrong or need to pass
> additional parameters for windows/mac?
>

Ah, I misunderstood the question at first. So this is simplification of the
build process which I haven't completed fully (as Jenkins didn't complain
about it) https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189807
.
I'll finish it right now.

>
>
> Am 02.05.22 um 08:07 schrieb Aleksandar Kurtakov:
> >
> >
> > On Sun, May 1, 2022 at 8:00 AM Christoph Läubrich  > <mailto:lae...@laeubi-soft.de>> wrote:
> >
> > I try to run the SWT build under windows but always get:
> >
> > Error: Cannot resolve project dependencies:
> > Error: You requested to install 'org.eclipse.equinox.p2.iu;
> > org.eclipse.swt.tests.fragments.feature.feature.group 0.0.0' but it
> > could not be found
> >
> > so it seems I need to pass something special to the build command...
> >
> >
> > I have described this in more details here:
> > https://github.com/eclipse-platform/eclipse.platform.swt/issues/68
> > <https://github.com/eclipse-platform/eclipse.platform.swt/issues/68>
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> > <https://www.eclipse.org/mailman/listinfo/platform-dev>
> >
> >
> > You have to always pass -Pbuild-individual-bundles when building swt out
> > of the aggregator build.
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Running the SWT maven build under windows

[Aleksandar Kurtakov]

On Sun, May 1, 2022 at 8:00 AM Christoph Läubrich 
wrote:

> I try to run the SWT build under windows but always get:
>
> Error: Cannot resolve project dependencies:
> Error: You requested to install 'org.eclipse.equinox.p2.iu;
> org.eclipse.swt.tests.fragments.feature.feature.group 0.0.0' but it
> could not be found
>
> so it seems I need to pass something special to the build command...


> I have described this in more details here:
> https://github.com/eclipse-platform/eclipse.platform.swt/issues/68
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
You have to always pass -Pbuild-individual-bundles when building swt out of
the aggregator build.
-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Milestones for Releases

[Aleksandar Kurtakov]

On Mon, Apr 4, 2022 at 7:30 PM Sarika Sinha  wrote:

> Wanted to understand the milestone structure to be used in github.
>
> Every project will define their own milestones? I defined one for JDT
> Debug, but don’t know if that was the correct thing to do.
>
> Any easy query mechanism like Bugzilla to track which issues got resolved
> or are still open for a milestone  or release for Platform and JDT together?
>

Github has organization wide "Projects" (
https://github.com/orgs/eclipse-platform/projects?type=beta). Jetty project
uses it (https://github.com/eclipse/jetty.project/projects/) (successfully
IMHO) to manage their releases maybe we can do so too.
I never found the time to really try it so we need someone to try it out.


>
>
> Thanks & Regards,
>
> Sarika
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Customizing Github Organization Pages

[Aleksandar Kurtakov]

On Thu, Mar 31, 2022 at 5:15 PM Mickael Istria  wrote:

> Sorry, I missed the line between the 2 images, where you already
> explicitly answer my question before I even asked this. "we must open a
> helpdesk issue to update that information."; so OK, it's helpdesk only, too
> bad but we'll use it anyway.
>
> Before we open a ticket, we need to agree of how we want ot set those
> fields, here is a suggestion
> * Organization display name: Eclipse Platform
> * Email: platform-dev@eclipse.org
> * description: "Eclipse Platform is a framework for rich client
> applications in Java, powering the Eclipse IDE and other toolsets"
> * URL: https://www.eclipse.org/eclipse/ or
> https://projects.eclipse.org/projects/eclipse.platform ?
>

I think https://www.eclipse.org/eclipse/ is more informative for the
broader audience.


> * billing: webmas...@eclipse.org
>

I would guess this one is already handled by foundation and we should not
interfere.

Maybe setting the Twitter username to @EclipseJavaIDE

?
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Customizing Github Organization Pages

[Aleksandar Kurtakov]

I assume it's same as
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1098 so these
adjustments have to be mave via  helpdesk issues.

On Thu, Mar 31, 2022 at 5:06 PM Ed Merks  wrote:

> Mickael,
>
> Perhaps a picture would help me understand what you're referring to, if
> it's not already one of the things for which I had a screen capture.
>
> My assumption is that if it requires an admin page with admin access for
> the organization then only the foundation staff can admin it and they
> will do so via a helpdesk request.
>
> Regards,
> Ed
>
> On 31.03.2022 15:57, Mickael Istria wrote:
> > Hi Ed,
> >
> > While contributing a .github/README.md file seems like regular
> > Git/GitHub stuff that any committer can tackle, I do not see the links
> > to configure the organization (eg set links, names and so on). Are
> > those supposed to be accessible to committers? to project leads? Or do
> > we need to open an helpdesk ticket to get them modified?
> > If you don't know, I can open an helpdesk ticket to ask; I'm pretty
> > sure that if we're insistent and annoying enough (and I know we can
> > be!) the Foundation staff will consider just letting us access more
> > organization and repo settings ;)
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

On Thu, Mar 31, 2022 at 1:05 PM Aleksandar Kurtakov 
wrote:

>
>
> On Thu, Mar 31, 2022 at 12:07 PM  wrote:
>
>> cucumber is also honest about what to expect from a bug:
>> "Please bear in mind that this project is almost entirely developed by
>> volunteers. If you do not provide the implementation yourself (or pay
>> someone to do it for you), the bug might never get fixed. If it is a
>> serious bug, other people than you might care enough to provide a fix."
>> https://github.com/cucumber/cucumber-jvm
>>
>>
>> I would appreciate to see such honesty in eclipse too.
>>
>
> This is smth we can all do. E.g.
> https://github.com/eclipse-platform/eclipse.platform.swt/pull/13 should
> do it for SWT. I agree with you that we need this honesty too.
>
>
>>
>>
>> +1 for a common "eclipse IDE" tracker
>>
>> +1 for JIRA as bugtracker (like https://bugs.openjdk.java.net)
>>
>
> We use infrastructure that is supported by Eclipse Foundation so if/when
> that's an option we can discuss/vote among ourselves whether to use GH
> issues or hypothetical Jira instance.
>
>
>
>>
>> +1 for pinnning repos
>>
>
> I'll open a helpdesk about that as I don't seem to have permissions to pin
> them.
>

So we can't get the permission to pin repos but we can request which repos
to be pinned (https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1098).
I would personally wait for current discussions and actions calm down in
order to not lose infrastructure team time with pin this, unpin that while
we settle for project structure.


>
>
>>
>>
>>
>> https://github.com/eclipse/
>>
>> is like "what is this ???" - you don't even find eclipse-platform if you
>> don't know  its name.
>>
>>
>>
>> Jörg
>>
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

On Thu, Mar 31, 2022 at 12:07 PM  wrote:

> cucumber is also honest about what to expect from a bug:
> "Please bear in mind that this project is almost entirely developed by
> volunteers. If you do not provide the implementation yourself (or pay
> someone to do it for you), the bug might never get fixed. If it is a
> serious bug, other people than you might care enough to provide a fix."
> https://github.com/cucumber/cucumber-jvm
>
>
> I would appreciate to see such honesty in eclipse too.
>

This is smth we can all do. E.g.
https://github.com/eclipse-platform/eclipse.platform.swt/pull/13 should do
it for SWT. I agree with you that we need this honesty too.


>
>
> +1 for a common "eclipse IDE" tracker
>
> +1 for JIRA as bugtracker (like https://bugs.openjdk.java.net)
>

We use infrastructure that is supported by Eclipse Foundation so if/when
that's an option we can discuss/vote among ourselves whether to use GH
issues or hypothetical Jira instance.



>
> +1 for pinnning repos
>

I'll open a helpdesk about that as I don't seem to have permissions to pin
them.


>
>
>
> https://github.com/eclipse/
>
> is like "what is this ???" - you don't even find eclipse-platform if you
> don't know  its name.
>
>
>
> Jörg
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

On Thu, Mar 31, 2022 at 11:00 AM Ed Merks  wrote:

> See, you too are hoping that your opinion matters and that your opinion
> is included in the decision making process.  I expect we all would like
> that very much.
>

I wrote a lengthy reply already. Everyone's opinion matters and it has been
shown lately. E.g. stop autoclosing bugs change despite the fact that PMC
members and Project leads disagreed with the change.


> -1000 for merging in the absence of a cohesive plan that the committers
> agree is a good strategy for our project
>

One kind request here guys - please resist from +100, -1000, +1 and
etc. I've participated in the past  in one such conversation - if you veto
X, I'll veto Y and things didn't end well so let's try to not do it.


>
> On 31.03.2022 09:53, Christoph Läubrich wrote:
> > Am 31.03.22 um 09:42 schrieb Aleksandar Kurtakov:
> >>
> >>
> >> On Thu, Mar 31, 2022 at 10:35 AM S A
> >>  >> <mailto:simeon.danailov.andr...@gmail.com>> wrote:
> >>
> >> Please first finish the GitHub moves and let that settle for a month
> >> (or better, a fe months). There are enough new problems and
> >> disruptive changes already.
> >>
> >>
> >> The thing is in order to fix very old problems and some new we have
> >> to change things or we are going to add even more bandaid and make it
> >> even harder to fix later (as it has happened so many times).
> >
> > +100
> >
> > later is just another term for "probably never" in
> > software-development ;-)
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

Pruning" as
done in orchards seems to be quite good explanation of the workflow - the
roots are strong enough for X number of fruits, prune some branches that
have "defects" or even just growing in the wrong direction and preventing
others to see enough sunshine/air, create comfort for "master" (ecj,
swt...) branches as without them the whole tree would be compromised, look
for ways to "fertilize" ( direct maven usage) and so on. The most important
thing there is realizing that what looked promising in the spring may
happen to be broken by summer storms and requires significant changes in
the way you plan the tree's growth.

Please share your thoughts on all of the above as I fully agree with Ed -
we have to decide where we want to go? do we want to go to the same place?
and can we do it?


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

On Wed, Mar 30, 2022 at 7:33 PM Mickael Istria  wrote:

>
>
> On Wed, Mar 30, 2022 at 6:00 PM Andrey Loskutov  wrote:
>
>> Beside this, users don't want to "learn about project structure, question
>> how we organize things and etc." just to submit a bug.
>>  However, right now we move from one bugzilla instance to a not organized
>> / not managed list of individual repository bug trackers, where the poor
>> users have no clue at all how to find *anything* matching their own
>> understanding of "Eclipse IDE bug".
>> Ideally we should have *one* entry point, not because contributors
>> need that but because our users need that.
>> How we plan to manage that is another question, but since we don't want
>> to have complicated plans, let's assume we will manage it somehow.
>>
>
> This is a discussion we have once every 5 years, with the same rants, the
> same wishes, and the same (lack of) result. In any case, Platform !=
> Eclipse IDE. Eclipse IDE is mostly EPP or IDE Working Group lately; so I
> would suggest to bring this idea of those entities handling this story if
> they can do better than us (Eclipse project committers).
>
>
>>  Unfortunately, the "gigantic" github power was not enough so far to
>> provide a bug tracker per organization, so the trackers are always per
>> repository.
>>
>
> A bit like Bugzilla components.
>
>
>> Also there is no possibility to add a README for the organization that
>> would point to a bug tracker.
>>
>
> Wrong. you can see for example https://github.com/Microsoft/ which does
> include an organization README. And you can add such README to the .github
> repository of the organization, which already hosts a CODE_OF_CONDUCT and a
> CONTRIBUTING file.
>
>
>
>> So if the "only" proposed alternatives so far are:
>>  1) have N (> 20) bug trackers and let user find the right one (current
>> state).
>> 2) have N+1 bug trackers but designate one as the main entry point and
>> link that everywhere (including IDE).
>>  We as contributors will have exact same effort moving bugs from one bug
>> tracker to another one, but the users will have a single point and no need
>> to guess.
>>
>
> 1000% agreeing: one more tracker doesn't solve the problem of too many
> trackers (as a concretization of "1 more X doesn't resolve the problem of
> too many Xs").
>
> But there are good news: GitHub allows to disable issue tracker on
> repositories. So we can decide of 1 repository per org that's supposed to
> receive issue reports, and ask EF to disable issue trackers on all others;
> and then adapt the README, CONTRIBUTING and all other relevant files to
> reference that particular tracker. We may even start taking such a decision
> and implement it right now, migrating all issues to that "master" tracker,
> even before the particular repo trackers get disabled and the "master"
> tracker becomes the only one for the organization.
>

With organization wide documentation for issue tracker and etc. for end
users -  Why should we close issue trackers per repo? No one cared to
remove bugzilla components. Per repo issue trackers are useful for people
who have spent the time to investigate where/why their bug should go to and
allow more focused work.


> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

ugzilla, or something else.
>>
>> Dirk
>>
>>
>> Am 26.03.2022 um 09:42 schrieb Hannes Wellmann:
>>
>> At the moment it is not clear to me (maybe I have missed something) if I
>> should still use Bugzilla or instead the Github Issues of for
>> Eclipse-projects that were moved to Github?
>> IIRC to was not the plan to shutdown the associated Bugzilla now, but
>> does this also mean that bugs should still be reported there or should GH
>> issues be used for that as soon as a project was moved?
>> At the moment I have the impression both is used, which is IMHO not ideal
>> but probably hard to avoid in a transition phase.
>>
>> Thanks,
>> Hannes
>>
>>
>>
>>
>> ___
>> platform-dev mailing listplatform-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> ___ platform-dev mailing list
>> platform-dev@eclipse.org To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> ___
>> platform-dev mailing listplatform-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] SWT repositories moved to Github

[Aleksandar Kurtakov]

These Git repositories are now moved to GitHub:
https://github.com/eclipse-platform/eclipse.platform.swt and
https://github.com/eclipse-platform/eclipse.platform.swt.binaries .
Please immediately set you `upstream` repo url to use GitHub instead
of Gerrit
$ git remote set-url upstream
g...@github.com:eclipse-platform/eclipse.platform.swt[.binaries].git

Also update your development files (Oomph profiles, *.psf files...) to
adjust your workflow.



-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Aleksandar Kurtakov]

On Sat, Mar 26, 2022 at 10:42 AM Hannes Wellmann 
wrote:

> At the moment it is not clear to me (maybe I have missed something) if I
> should still use Bugzilla or instead the Github Issues of for
> Eclipse-projects that were moved to Github?
> IIRC to was not the plan to shutdown the associated Bugzilla now, but does
> this also mean that bugs should still be reported there or should GH issues
> be used for that as soon as a project was moved?
>

Use GH issues once repo moved. There is no plan to shutdown bugzilla
immediately from our side as there is way too much content in it and even
valid bugs . But foundation plans to do so see
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Gerrit/Gerrit-and-Bugzilla-deprecation-and-migration-plan
so there is no other choice .


> At the moment I have the impression both is used, which is IMHO not ideal
> but probably hard to avoid in a transition phase.
>

I don't see anyone willing to spend the time to triage existing bugs in
bugzilla and migrate them to GH issue when they make sense. Transitioning
everything makes no sense as it will recreate unmanageable pile in GH
issues. So new issues should go to GH issues, work on existing ones
continue using bugzilla till there is anything that makes sense and there
is someone to look at bz issues still.
This is not ideal but the only possible solution right now IMHO. Of course,
things can always be done far better in theory but reality puts a lot of
other constraints on us.


>
> Thanks,
> Hannes
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Github workflow

[Aleksandar Kurtakov]

On Thu, Mar 24, 2022 at 3:01 PM Sravan K Lakkimsetti <
sravankum...@in.ibm.com> wrote:

> >> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> >> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
>
>
>
> Here are my suggestions on this.
>
>1. All the commits should have an issue, created in the same
>repository, number associated with them
>   1.  #
>
> I don't think it is necessary to have issues for each commit(more of an PR
as it may be multiple commits). With Github PR and issue are practically
the same in terms of references (even share the same number sequence). If
the concern is that PR is not reopenable it's better to open an issue later
if there is an actual issue with the PR rather than create really empty
issues that just hold reference to PR.


>
>1.
>1. For root level issues like work spanning across multiple
>repositories, I would prefer root bugs to be created in
>   1. Platform in https://github.com/eclipse-platform/eclipse.platform
>   2. Equinox in https://github.com/eclipse-equinox/equinox.framework
>   3. Pde in eclipse.pde.ui
>   4. Jdt in https://github.com/eclipse-jdt/eclipse.jdt
>2. If issues span across multiple projects(organizations), my
>preference would be
>https://github.com/eclipse-platform/eclipse.platform
>
>
>
> Thanks
>
> Sravan
>
> *From:* platform-dev  *On Behalf Of *Mickael
> Istria
> *Sent:* 24 March 2022 17:40
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] Re: [platform-dev] Github workflow
>
>
>
> Hi, I'm putting a few answers here, but those could go to the document
> pointed out by Sravan (which by the way could be renamed to
> CONTRIBUTING.md)   I don't like forks and used to have branches on main
> repo - not recommended. ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi,
>
>
>
> I'm putting a few answers here, but those could go to the document pointed
> out by Sravan (which by the way could be renamed to CONTRIBUTING.md)
>
>
>
> I don't like forks and used to have branches on main repo - not
> recommended.
>
>
>
> Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing
> work. Your workspace is your fork.
>
>
>
> I don't like multiple commits in one PR and always use amend/force push -
> not recommended.
>
>
>
> That's *not* not recommended. It's just something that is up to the
> submitter, we shouldn't recommend anything here and let contributors build
> the workflow they prefer.
>
> What needs to be recommended is how we merge and keep a meaningful
> granularity for commits, not how contributors submit their PRs.
>
>
>
> I never use command line git and do everything from Eclipse - but some
> recommended to use git CLI.
>
>
>
> What typical commands do you have in mind? GitHub really is standard Git
> when it comes to push/fetch, the only thing to know is that reference to
> fetch/merge a PR is `pulls/123/head`, so there is no Git fanciness needed
> and EGit can be used for most operations. The only operation needed is the
> creation of a pull request and its review, that usually happens via an
> external tool (eg GitHub website).
>
>
>
> Egit support missing or not - not clear. What exactly is missing, why CLI
> is needed?
>
>
>
> There is decent support for GitHub in EGit. If anything is missing, it
> should be reported to EGit.
>
>
>
> It is unclear / undocumented how to *properly* refer to bugs in commits
> (full url? repo-name/id? just id?).
> It is unclear if we should now use dedicated github bug trackers *per
> repository* to report bugs, or will be there some higher level bug tracker
> for entire platform organization?
>
>
>
> I believe that is still to be determined, as we're growing collective
> experience here.
>
>
>
> Once the PR is created, I see that builds somehow triggered in equinox,
> but I neither get mails that they are stared nor they are finished.
>
>
>
> That's an interesting thought. I don't know whether there is some option
> to allow email notifications for votes.
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Github workflow

[Aleksandar Kurtakov]

 Review
> >>>  4. Keep committing on your fork branch
> >>>  5. PR is accepted
> >>>  6. Go to your fork and "Fetch upstream" [1]
> >>>
> >>>
> >> Yes, this is a PITA. :-(It's hard to keep something like the
> >> following up-to-date if you *also *have to go off into github and
> >> manually fetch each fork (if you have one) before Select All and
> >> to a Pull.
> >>
> >> I wondered if there were some way to make this easier with
> >> multiple configured remotes, but I don't understand that approach
> >> well enough
> >>
> >>> [1] Fetching upstream is currently a pain. I have started a
> >>> discussion here. Please also comment or upvote:
> >>> https://github.com/github/feedback/discussions/13221
> >>>
> >>> Cheers,
> >>>
> >>> Wim
> >>>
> >>> ___
> >>> platform-dev mailing list
> >>> platform-dev@eclipse.org
> >>>     To unsubscribe from this list, visithttps://
> www.eclipse.org/mailman/listinfo/platform-dev
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/platform-dev
> >>
> >>
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visithttps://
> www.eclipse.org/mailman/listinfo/platform-dev
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Github workflow

[Aleksandar Kurtakov]

On Tue, Mar 22, 2022 at 1:25 PM Lars Vogel  wrote:

> Sorry, if that was said before (I did not read all discussions in
> detail) but committers can create PR for the same repository without
> the additional fork.
>
> So a possible workflow is:
> 1.) Clone repo
> 2.) Create new local branch
> 3.) Push local branch to new branch in origin
> 4.) Create PR from new branch to master / main in the same repo
>
> This removes the need to sync your server fork.
>

Lars, this workflow is good for small and/or private projects. But for
bigger communities it's better to stick to official  github recommendations
(
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models)
Shared repository model - "This model is more prevalent with small teams
and organizations collaborating on private projects." and I would not call
Eclipse being small team nor private project.)
Benefits from using a fork and branch in your fork has at least these
multiple benefits:
* your changes are independent and not create churn in the main project
* committers and contributors follow same procedures so better understand
each other
* put less burden on CI - every branch in main repo is scanned and checked
for compilability and test status



>
> Best regards, Lars
>
> On Tue, Mar 22, 2022 at 11:22 AM Rolf Theunissen
>  wrote:
> >
> > Hi,
> >
> > What comes to mind is 'origin' and 'upstream' repositories. Where
> 'origin' is your fork and the 'upstream' the forked repo.
> > Your workflow seems to fetch from 'upstream' (aka eclipse) and push to
> origin (aka me), after which a PR is made from 'orgin' back to 'upstream'.
> > With the right settings this might be able to set the default fetch and
> default push locations in EGit too.
> >
> >
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork
> >
> https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github
> >
> >
> > Op di 22 mrt. 2022 om 11:13 schreef Mickael Istria :
> >>
> >> Hi,
> >>
> >> On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman 
> wrote:
> >>>
> >>> Go to your fork and "Fetch upstream" [1]
> >>
> >> Why do you need to do that? Particularly if you never use master/main?
> >> FWIW, may workflow is
> >> $ git fetch eclipse master
> >> $ git checkout FETCH_HEAD
> >> [... do changes ...]
> >> $ git commit -m "My super fix (#123)"
> >> $ git push me HEAD:refs/heads/issue-123
> >> Create PR
> >> If needed, improve, rebase, `git push me --force HEAD:issue-123`
> >> Upon PR merge, just remove my issue-123 branch.
> >>
> >> This allows to not care about the master/main branch in my fork. I can
> even happily delete it, and it gives me more guarantee to keep in sync!
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Eclipse Platform project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] triggerWinGerrit

[Aleksandar Kurtakov]

On Mon, Mar 21, 2022 at 9:34 AM Christoph Läubrich 
wrote:

>  > Is it possible / permissible to allow all platform projects
>  > to use such a mechanism?
>
> If the project is already migrated to github you can configure an
> (additional) verification action using Github actions:
>
>
> https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources


As announced (https://www.eclipse.org/lists/platform-dev/msg03429.html) SWT
repos are scheduled to be moved next Monday - after that people can
experiment with GH actions .


>
>
> Am 20.03.22 um 16:57 schrieb Jonah Graham:
> > Hi folks,
> >
> > I recently came across triggerWinGerrit  (thanks Sarika).
> >
> > I can see https://ci.eclipse.org/releng/job/jdt-debug-win-gerrit-test/
> > <https://ci.eclipse.org/releng/job/jdt-debug-win-gerrit-test/> is
> > configured for triggerWinGerrit - but I can't find any mention of it
> > elsewhere.
> >
> > Is it possible / permissible to allow all platform projects to use such
> > a mechanism? For example SWT would really benefit because of all the
> > platform specific code. I really would like
> > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/192078
> > <https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/192078> to
> > run :-)
> >
> > Jonah
> >
> >
> > ~~~
> > Jonah Graham
> > Kichwa Coders
> > www.kichwacoders.com <http://www.kichwacoders.com>
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] SWT git repos moving to GitHub on March 28th

[Aleksandar Kurtakov]

Hi everyone
On March 28th SWT git repositories are to be moved to Github.
I've went through the gerrit queue (
https://git.eclipse.org/r/q/project:platform%252Feclipse.platform.swt+status:open)
and it's manageable already. There is a week to further finish some of them
so you don't have to redo them as PRs.

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Github migration and Gerrit reviews

[Aleksandar Kurtakov]

Hey everyone,
This is a kind request for everyone having open gerrits in the following
list https://git.eclipse.org/r/q/projects:platform+status:open to start
work towards finishing them immediately.
Migration to github is in progress with more and more repositories being
moved every day so finishing your gerrits, merging, abandoning, etc.
This will save time not only for releng and other committers to go through
the list manually but you may save yourself time by not having to redo them
as github PRs.

Thanks in advance to everyone that helps us with this task!

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] how long will repos remain on gerrit (read-only?)

[Aleksandar Kurtakov]

On Wed, Mar 16, 2022 at 11:31 PM Aleksandar Kurtakov 
wrote:

>
>
> On Wed, Mar 16, 2022 at 11:15 PM Jonah Graham 
> wrote:
>
>> Hi folks,
>>
>> How long will the gerrits for platform projects moving to GitHub be left
>> around? (Sorry if this is asked and answered somewhere else)
>>
>
> We will not let them stay after moving. Process is like
> https://git.eclipse.org/r/c/platform/eclipse.platform.team/+/185449 where
> it's abandoned with instruction how to move it to PR. As the repo becomes
> read only there is no difference whether it's open or abandoned, you can
> recreate it as PR although if not ready it is better to have it in your own
> fork.
> For how long gerrits will stay it's a question for EF. If the repo is
> archived - gerrits are gone. Webmaster team asks for when repo can be
> archived in gerrit which we try to delay for Eclipse TLP repos (doing
> better than Tycho migration!) but that's beyond us.
>

Link to moving issue with request for archiving
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/985


>
>
>>
>> I have various WIP gerrits[1] that I hope to come back to one day. Until
>> now I have considered gerrit a safe place to store such WIP (as I would my
>> own fork on GitHub).
>>
>> In addition, the review comments of the gerrits are very valuable when
>> trying to unravel an old issue.
>>
>> I ask because some projects that have migrated from gerrit to GitHub seem
>> to have lost their gerrit entries (Tycho[2]) while others still live on
>> gerrit (like LSP4E[3])
>>
>
> LSP4E seems to have missed the last step in the migration which should be
> fixed and become read-only soon.
>
>
>>
>> [1] https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/181035
>> or https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/170563
>> [2] https://git.eclipse.org/r/165496 for
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=564670 is no longer
>> available
>> [3] https://git.eclipse.org/r/admin/repos/lsp4e/lsp4e
>>
>> Thanks
>> Jonah
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>> _______
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] how long will repos remain on gerrit (read-only?)

[Aleksandar Kurtakov]

On Wed, Mar 16, 2022 at 11:15 PM Jonah Graham 
wrote:

> Hi folks,
>
> How long will the gerrits for platform projects moving to GitHub be left
> around? (Sorry if this is asked and answered somewhere else)
>

We will not let them stay after moving. Process is like
https://git.eclipse.org/r/c/platform/eclipse.platform.team/+/185449 where
it's abandoned with instruction how to move it to PR. As the repo becomes
read only there is no difference whether it's open or abandoned, you can
recreate it as PR although if not ready it is better to have it in your own
fork.
For how long gerrits will stay it's a question for EF. If the repo is
archived - gerrits are gone. Webmaster team asks for when repo can be
archived in gerrit which we try to delay for Eclipse TLP repos (doing
better than Tycho migration!) but that's beyond us.


>
> I have various WIP gerrits[1] that I hope to come back to one day. Until
> now I have considered gerrit a safe place to store such WIP (as I would my
> own fork on GitHub).
>
> In addition, the review comments of the gerrits are very valuable when
> trying to unravel an old issue.
>
> I ask because some projects that have migrated from gerrit to GitHub seem
> to have lost their gerrit entries (Tycho[2]) while others still live on
> gerrit (like LSP4E[3])
>

LSP4E seems to have missed the last step in the migration which should be
fixed and become read-only soon.


>
> [1] https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/181035
> or https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/170563
> [2] https://git.eclipse.org/r/165496 for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=564670 is no longer
> available
> [3] https://git.eclipse.org/r/admin/repos/lsp4e/lsp4e
>
> Thanks
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Freeze?

[Aleksandar Kurtakov]

It was announced in https://www.eclipse.org/lists/platform-dev/msg03361.html

On Mon, Feb 21, 2022 at 1:23 PM Wim Jongman  wrote:

> Is there now a freeze period? We get issues on this Gerrit.
>
> https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/190740
>
> Cheers, Wim
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects

[Aleksandar Kurtakov]

On Fri, Feb 18, 2022 at 9:23 AM Andrey Loskutov  wrote:

> May be I'm living in some parallel universe, but in my world Eclipse
> Platform is utterly under-resourced, and this is since years, and that's
> the main reson bugs aren't processed as it should be and therefore closed
> without any activity.
>

Everyone's experience varies depending on what they see in other projects
they work on.


>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Donnerstag, 17. Februar 2022 um 21:12 Uhr
> *Von:* "Mickael Istria" 
> *An:* "Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> *Betreff:* Re: [platform-dev] Vote to stop bug auto-closing in all
> Eclipse platform projects
> > We all know that the root cause of this discussion is the 10+ years of
> under-resourcing for Eclipse platform.
>
> Eclipse Platform is not under-resourced. It's OK-resourced, and just like
> any project would benefit from more resources, but let's move the resources
> discussion away and focus on the community aspects of auto-closing bugs.
>
> > Do we expect big players to come back and sponsor teams of developers
> again as it was in 00ths? I doubt so. Perhaps, small companies and
> individuals from the community are the only hope.
>
> I don't get how it's related to the discussion about auto-closing bugs or
> not. And I also don't get how Alex's answer triggered that question.
>
>
>> And if yes, how auto-close could help to recruit new resources for
>> triaging (not even dreaming about bug fixing) from the community?
>
>
> Auto-closing is more likely to stimulate people in trying to contribute
> than just keeping the bug silent. At least, people can decide to reopen
> with more details, or to add other information (not useful anymore, was
> fixed), and that's a form of contribution already. Sometimes they reopen
> with frustration and this can trigger a new conversation with some
> committers to help them in contributing more.
> On the other hand, keeping the bugs open but silent brings no interaction
> and thus no new opportunity to recruit. It just make the project seem dead.
> ___ platform-dev mailing list
> platform-dev@eclipse.org To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects

[Aleksandar Kurtakov]

t;> contribute than just keeping the bug silent. At least, people can
> >> decide to reopen with more details, or to add other information (not
> >> useful anymore, was fixed), and that's a form of contribution
> >> already. Sometimes they reopen with frustration and this can trigger
> >> a new conversation with some committers to help them in contributing
> >> more.
> >> On the other hand, keeping the bugs open but silent brings no
> >> interaction and thus no new opportunity to recruit. It just make the
> >> project seem dead.
> >>
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/platform-dev
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> >
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects

[Aleksandar Kurtakov]

On Thu, Feb 17, 2022 at 11:42 AM Hannes Wellmann 
wrote:

> +1 to stop auto-closing.
>
> Nevertheless maybe it is useful to add an automatic reminder message, with
> a similar text as today but without automatically closing the bug.
> Then appropriated actions can still be taken.
>

Eclipse bugzilla bot can do that.


>
> *Gesendet:* Donnerstag, 17. Februar 2022 um 09:58 Uhr
> *Von:* "Andrey Loskutov" 
> *An:* "platform-dev" 
> *Betreff:* [platform-dev] Vote to stop bug auto-closing in all Eclipse
> platform projects
> Hi all,
>
> this is a follow up on PMC response
> https://www.eclipse.org/lists/platform-dev/msg03319.html
>
> As of today, this bug auto-closing is not active only for JDT project.
>
> The proposal is to switch "off" bug auto-closing for the all Eclipse
> platform projects, including Platform, JDT, PDE und Equinox.
> I don't think if we need an additional vote for PDE & Equinox, because the
> only active committers there are same as on the Eclipse platform.
>
> Therefore I would like to start voting to stop auto-closing bugs in
> bugzilla, github, gitlab (or whatever else bug trackers we might use in the
> future) for all Eclipse platform development.
>
> I think it is enough to post your +1 / 0 / -1 as a reply on this mailing
> list.
> Everyone is welcome to vote but binding votes are committers`votes.
> I would propose to conclude the vote by the end of the next week (25
> February).
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects

[Aleksandar Kurtakov]

On Thu, Feb 17, 2022 at 10:58 AM Andrey Loskutov  wrote:

> Hi all,
>
> this is a follow up on PMC response
> https://www.eclipse.org/lists/platform-dev/msg03319.html
>
> As of today, this bug auto-closing is not active only for JDT project.
>
> The proposal is to switch "off" bug auto-closing for the all Eclipse
> platform projects, including Platform, JDT, PDE und Equinox.
>
I don't think if we need an additional vote for PDE & Equinox, because the
> only active committers there are same as on the Eclipse platform.
>

This should happen per project as even if active committers are  Eclipse
platform committers too not every platform committer is PDE or Equinox
committer and this doesn't guarantee that the voting will have the same
conclusion.


>
> Therefore I would like to start voting to stop auto-closing bugs in
> bugzilla, github, gitlab (or whatever else bug trackers we might use in the
> future) for all Eclipse platform development.
>
> I think it is enough to post your +1 / 0 / -1 as a reply on this mailing
> list.
> Everyone is welcome to vote but binding votes are committers`votes.
> I would propose to conclude the vote by the end of the next week (25
> February).
>

-1
In my opinion having bugs open without anyone looking into them for years
is bad and even worse as it gives false sense of support which in reality
is not there. I would change my mind if/when I see active triaging going on.


>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] PMC: Bugzilla autoclosing ruling

[Aleksandar Kurtakov]

Hey everyone,
During yesterday's meeting we discussed the topic and here is the outcome:
* Autoclosing was never a rule enforced by PMC
* It has always been decision taken on Project level (probably even prior
to merging into 4 subprojects)
* JDT has never had bug auto closing enabled
* PMC strongly believes that this is a decision to be taken by committers
at a given time to enable/disable autoclosing of bugs as they see fit as
they are the people that SHOULD be monitoring/triaging/fixing/etc. bugs.

So if the project you work on has autoclosing bugs enabled/disabled and you
want to change it the process should be:
* Start discussion/vote on your project list
* Everyone is welcome to vote but binding votes are committers`votes
* Successful vote to change the strategy should lead to
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues requesting so

This should help the community to adjust things according to the current
state of the project, committers, priorities, etc. without waiting for
resolution from people that are not actively working on a given subproject.

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Several repositories moved to Github

[Aleksandar Kurtakov]

Sravan opened
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24
to track the conversion. Please watch this issue.

On Tue, Feb 15, 2022 at 10:06 AM Aleksandar Kurtakov 
wrote:

> Several of the repositories have been moved to Github. These are:
> * eclipse.platform.releng.aggregator
> * eclipse.platform.releng
> * eclipse.platform.releng.buildtools
> * eclipse.platform.images
>
> The last two are not part of the aggregator build so shouldn't have that
> broad effect, also old repositories for them are still not cleared.
> New repositories can be found here https://github.com/eclipse-platform/ .
> Please switch your git remotes accordingly and submit patches using Github
> PRs instead of Gerrits.
> As there are many repositories there are no plans to send such
> announcements per repository but rather periodically so please keep an eye
> if you're committer and please help us with finishing this migration.
> Especially with cleaning up Gerrit queues.
>
> *NOTE: *Current Git repositories used are kept correct in PMI
> https://projects.eclipse.org/projects/eclipse.platform/developer
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Several repositories moved to Github

[Aleksandar Kurtakov]

Several of the repositories have been moved to Github. These are:
* eclipse.platform.releng.aggregator
* eclipse.platform.releng
* eclipse.platform.releng.buildtools
* eclipse.platform.images

The last two are not part of the aggregator build so shouldn't have that
broad effect, also old repositories for them are still not cleared.
New repositories can be found here https://github.com/eclipse-platform/ .
Please switch your git remotes accordingly and submit patches using Github
PRs instead of Gerrits.
As there are many repositories there are no plans to send such
announcements per repository but rather periodically so please keep an eye
if you're committer and please help us with finishing this migration.
Especially with cleaning up Gerrit queues.

*NOTE: *Current Git repositories used are kept correct in PMI
https://projects.eclipse.org/projects/eclipse.platform/developer

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Fwd: [Bug 305081] [api] IInstallableUnit#getFilter is marked noReference

[Aleksandar Kurtakov]

On Thu, Feb 10, 2022 at 12:55 PM Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> +1 to stop auto close, because it negates a lot of human effort invested
> in each bugzilla record. It is strange to expect any new contributors while
> we just through their work to the trash bin.
>

I would bring that for voting at the PMC. Honestly, I don't see the
difference between ignoring bugs and auto closing them as no one will look
into it but this is my own opinion so I respect others opinion here. I'm a
bit disappointed that we don't see real effort in improving the situation
with bugs and gerrits though.


>
> I wonder what Committer Representative role stands for if the message
> could be claimed as "just not important".
>


Just in case someone missed it
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/679 and move to
github is a game changer which is far more important than whether bugs are
opened or closed in a tool that is up for shutting down.


>
> Regards,
> AF
>
> 2/10/2022 1:35 PM, Ed Merks пишет:
>
> Please consider the opinions of your committers and contributors as at
> least relatively important.   We're explaining to you what is important to
> us and why we feel that way.  We don't really so much appreciate our
> opinions being dismissed as not important to you.   We have higher
> expectations from our PMC leads.
>
> If the disease is "lack of triage", we feel that unfortunately the "auto
> triage close cure" is even worse than that disease.  We're asking you to
> please stop sending the patients home with a robot.   We might not do a
> good job curing the patients and we could and should definitely discuss how
> to improve our cure rate and our patient satisfaction statistics, but in
> the meanwhile please stop making the problem worse with a robot.  And
> please don't characterize what we say as "just not important" because
> that's just plain disrespectful.
> On 10.02.2022 10:52, Aleksandar Kurtakov wrote:
>
>
>
> On Thu, Feb 10, 2022 at 11:43 AM Rolf Theunissen <
> rolf.theunis...@gmail.com> wrote:
>
>> I fully agree. In fact, I consider any bug that is closed and marked as
>> 'stalebug' as open.
>>
>> Also, back in the day there seemed to be a different triage process, and
>> correct me if I am wrong, but it seems that bugs that are marked as being
>> triaged are not auto-closed. At least some very old bugs do not get
>> auto-closed.
>> I know that it is hard to manage the huge back-log of issues. But there
>> seems also hardly any focus on new incoming bugs, they are ignored until
>> they are finally automatically closed, which gives a really bad impression
>> on the overall quality of the projects.
>>
>
> You nailed it! It's pointless discussion whether bugs are autoclosed or
> not aka stay open without anyone looking into it or being closed without
> anyone looking into it. What's important is who will triage and fix bugs,
> look into gerrits and etc.? I'm very interested in the later discussion and
> until we improve on it, discussing the former is just non-important to me.
>
>
>>
>> Rolf
>>
>> Op do 10 feb. 2022 om 08:23 schreef Alex Blewitt > >:
>>
>>> I agree. It’s happened to many bugs I raised over the years even when
>>> they are provably still valid, and it gives a really bad impression to end
>>> users for limited gain.
>>>
>>> Alex
>>>
>>> Sent from my iPhone 
>>>
>>> > On 10 Feb 2022, at 06:49, Christoph Läubrich 
>>> wrote:
>>> >
>>> > +1 for disabling this.
>>> >
>>> >> Am 10.02.22 um 07:45 schrieb Andrey Loskutov:
>>> >> Yes, please.
>>> >> I believe PMC once decided it would be a great idea to have less bugs
>>> open, so I would ask PMC to discuss the success of this practice once
>>> again, we should be able to reiterate on our processes.
>>> >> I've complained https://www.eclipse.org/lists/jdt-dev/msg01419.html
>>> already (no result), Stephan too (before he silently quit)
>>> https://www.eclipse.org/lists/eclipse-pmc/msg03833.html, I know other
>>> committers not happy with this practice, and we receive constant feedback
>>> from users that this *is* a bad practice.
>>> >> It doesn't help anyone, just creates bad impression for remaining few
>>> users who take time to fill bug reports.
>>> >> Am 10. Februar 2022 07:23:49 MEZ schrieb Ed Merks >> >:
>>> >>> Can we please turn off this "Genie" that does this to open bugs? I've
>>> >>> asked 

Re: [platform-dev] Fwd: [Bug 305081] [api] IInstallableUnit#getFilter is marked noReference

[Aleksandar Kurtakov]

On Thu, Feb 10, 2022 at 11:43 AM Rolf Theunissen 
wrote:

> I fully agree. In fact, I consider any bug that is closed and marked as
> 'stalebug' as open.
>
> Also, back in the day there seemed to be a different triage process, and
> correct me if I am wrong, but it seems that bugs that are marked as being
> triaged are not auto-closed. At least some very old bugs do not get
> auto-closed.
> I know that it is hard to manage the huge back-log of issues. But there
> seems also hardly any focus on new incoming bugs, they are ignored until
> they are finally automatically closed, which gives a really bad impression
> on the overall quality of the projects.
>

You nailed it! It's pointless discussion whether bugs are autoclosed or not
aka stay open without anyone looking into it or being closed without anyone
looking into it. What's important is who will triage and fix bugs, look
into gerrits and etc.? I'm very interested in the later discussion and
until we improve on it, discussing the former is just non-important to me.


>
> Rolf
>
> Op do 10 feb. 2022 om 08:23 schreef Alex Blewitt :
>
>> I agree. It’s happened to many bugs I raised over the years even when
>> they are provably still valid, and it gives a really bad impression to end
>> users for limited gain.
>>
>> Alex
>>
>> Sent from my iPhone 
>>
>> > On 10 Feb 2022, at 06:49, Christoph Läubrich 
>> wrote:
>> >
>> > +1 for disabling this.
>> >
>> >> Am 10.02.22 um 07:45 schrieb Andrey Loskutov:
>> >> Yes, please.
>> >> I believe PMC once decided it would be a great idea to have less bugs
>> open, so I would ask PMC to discuss the success of this practice once
>> again, we should be able to reiterate on our processes.
>> >> I've complained https://www.eclipse.org/lists/jdt-dev/msg01419.html
>> already (no result), Stephan too (before he silently quit)
>> https://www.eclipse.org/lists/eclipse-pmc/msg03833.html, I know other
>> committers not happy with this practice, and we receive constant feedback
>> from users that this *is* a bad practice.
>> >> It doesn't help anyone, just creates bad impression for remaining few
>> users who take time to fill bug reports.
>> >> Am 10. Februar 2022 07:23:49 MEZ schrieb Ed Merks > >:
>> >>> Can we please turn off this "Genie" that does this to open bugs? I've
>> >>> asked about this before and I really don't like it.  This time I want
>> to
>> >>> really make it stop.  I think such a behavior creates a really bad
>> >>> impression, i.e., that we manage bugs so poorly that we need a bot
>> that
>> >>> times them out automatically because we just can't be bothered to
>> manage
>> >>> this properly.  Yes, of course I know there is much time involved in
>> >>> triage, but that's exactly the point.  I triaged all the p2 bugs some
>> >>> time ago to reduce it to the ones that are open so these are
>> legitimate
>> >>> issues that should not be auto-closed...
>> >>>
>> >>> Regards,
>> >>> Ed
>> >> --
>> >> Kind regards,
>> >> Andrey Loskutov
>> >> https://www.eclipse.org/user/aloskutov
>> >> Спасение утопающих - дело рук самих утопающих
>> >> ___
>> >> platform-dev mailing list
>> >> platform-dev@eclipse.org
>> >> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>> > _______
>> > platform-dev mailing list
>> > platform-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse Project is Frozen?

[Aleksandar Kurtakov]

It's being open for few days already
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/862

On Wed, Feb 9, 2022 at 3:38 PM Thomas Watson  wrote:

> We are having issues with the Equinox framework gerrits also.  Perhaps we
> need an issue opened with the foundation to help?
>
> Tom
> --
> *From:* platform-dev  on behalf of
> Aleksandar Kurtakov 
> *Sent:* Wednesday, February 9, 2022 7:30 AM
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] Re: [platform-dev] Eclipse Project is Frozen?
>
> On Wed, Feb 9, 2022 at 3:21 PM Andrey Loskutov  wrote:
> Alex, do you plan to update all jenkins files we have in the platform? We
> have same problem most likely in other platform repositories. ‍ ‍ ‍ ‍ ‍ ‍ ‍
> ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
>
>
> On Wed, Feb 9, 2022 at 3:21 PM Andrey Loskutov  wrote:
>
> Alex,
>
> do you plan to update all jenkins files we have in the platform? We have
> same problem most likely in other platform repositories.
>
>
> When some gerrit verification works so I can be sure that it fixes it yes.
> Unfortunately https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190614
> didn't trigger the gerrit rebuild again. I wouldn't mind some help there
> though.
>
>
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Mittwoch, 09. Februar 2022 um 13:52 Uhr
> *Von:* "Aleksandar Kurtakov" 
> *An:* "Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> *Betreff:* Re: [platform-dev] Eclipse Project is Frozen?
>
>
> On Wed, Feb 9, 2022 at 2:32 PM Ed Merks  wrote:
>
> Hi,
>
> I don't understand why there is currently a code freeze:
>
> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190598
>
> With 2022-03 M2, Friday, February 4, 2022  in the past and 2022-03 M3,
> Friday, February 25, 2022 more than two weeks in the future, why is
> something frozen today.  Perhaps something is configured?
>
>
> It's fix needed in Jenkinsfile to fetch correct script after
> releng.aggregator moved to github.
> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190614 should be it.
>
>
>
> Regards,
> Ed
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___ platform-dev mailing list
> platform-dev@eclipse.org To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse Project is Frozen?

[Aleksandar Kurtakov]

On Wed, Feb 9, 2022 at 3:21 PM Andrey Loskutov  wrote:

> Alex,
>
> do you plan to update all jenkins files we have in the platform? We have
> same problem most likely in other platform repositories.
>

When some gerrit verification works so I can be sure that it fixes it yes.
Unfortunately https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190614
didn't trigger the gerrit rebuild again. I wouldn't mind some help there
though.


>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Mittwoch, 09. Februar 2022 um 13:52 Uhr
> *Von:* "Aleksandar Kurtakov" 
> *An:* "Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> *Betreff:* Re: [platform-dev] Eclipse Project is Frozen?
>
>
> On Wed, Feb 9, 2022 at 2:32 PM Ed Merks  wrote:
>
>> Hi,
>>
>> I don't understand why there is currently a code freeze:
>>
>> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190598
>>
>> With 2022-03 M2, Friday, February 4, 2022  in the past and 2022-03 M3,
>> Friday, February 25, 2022 more than two weeks in the future, why is
>> something frozen today.  Perhaps something is configured?
>
>
> It's fix needed in Jenkinsfile to fetch correct script after
> releng.aggregator moved to github.
> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190614 should be it.
>
>
>>
>> Regards,
>> Ed
>>
>> _______
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___ platform-dev mailing list
> platform-dev@eclipse.org To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse Project is Frozen?

[Aleksandar Kurtakov]

On Wed, Feb 9, 2022 at 2:32 PM Ed Merks  wrote:

> Hi,
>
> I don't understand why there is currently a code freeze:
>
> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190598
>
> With 2022-03 M2, Friday, February 4, 2022  in the past and 2022-03 M3,
> Friday, February 25, 2022 more than two weeks in the future, why is
> something frozen today.  Perhaps something is configured?
>

It's fix needed in Jenkinsfile to fetch correct script after
releng.aggregator moved to github.
https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190614 should be it.


>
> Regards,
> Ed
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] CI Bot not Working?

[Aleksandar Kurtakov]

Noticed it this morning and filed
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/862

On Mon, Feb 7, 2022 at 1:57 PM Ed Merks  wrote:

> Hi,
>
> Since at least last Friday, CI Bot doesn't get automatically added, so
> Gerrit builds don't kick off anymore.  E.g.,
>
> https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190518
>
> Is this a general problem others have noticed too or it it specific to p2?
>
> Regards,
> Ed
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse.org-planning-council] Unsigned Content?

[Aleksandar Kurtakov]

omph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
>>> Why?  Because
>>> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor,
>>> IProfile, Map) knows the profile, but the certificate
>>> checker doesn't know to check that profile but rather checks the self
>>> profile.  I imagine the p2 director will have such problems too, or perhaps
>>> it will not fail but also might not actually check the correct profile...
>>>
>>
>> Such feedback is really welcome. Can you please open a dedicated bug for
>> this issue and add me as CC ?
>>
>> I wonder though if n projects have to duplicate the effort n times if
>>> that will be n times the work.
>>>
>>
>> The effort of consuming upstream artifacts from Maven is equivalent to
>> the effort of consuming artifacts from Orbit. So there is no extra effort
>> involved for consumers, they just change a version in their .target and
>> that's all.
>> "Downstream" projects can also directly consume bundles provided by their
>> "upstream" ones in a plain p2 way. For example, a project that need mockito
>> can just take Mockito from Platform instead of Orbit, without playing with
>> Maven dependencies. It's actually already a common and efficient: may
>> target files don't reference Orbit and pick the libs that's provided by
>> their "upstream".
>>
>>
>>> Also, might we end up with n versions of each such bundle?
>>>
>>
>> We already do have N versions of several libs, split across multiple
>> repositories (eg some older projects don't rebuild against latest Orbit and
>> still include older libs). p2 -during SimRel aggregation or installation on
>> user end- does take care of picking the best and tries to avoid multiple
>> versions when this can be avoided.
>> Consuming libs from Maven instead of Orbit doesn't really change the
>> problem/solution in the end.
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> eclipse.org-planning-council mailing list
> eclipse.org-planning-coun...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Unsigned Content?

[Aleksandar Kurtakov]

On Fri, Dec 17, 2021 at 11:27 AM Ed Merks  wrote:

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

Thanks, that would be a priority after vacation.


>
> On 17.12.2021 09:44, Mickael Istria wrote:
>
>
>
> On Fri, Dec 17, 2021 at 9:11 AM Ed Merks  wrote:
>
>> Here is what happens when the installer tries to install
>> org.mockito.mockito-core into a Platform SDK IDE:
>>
>> java.lang.NullPointerException
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311)
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63)
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1)
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126)
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83)
>> at
>> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63)
>> at
>> org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254)
>> at
>> org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105)
>> at
>> org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50)
>> at
>> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80)
>> at
>> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48)
>> at
>> org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46)
>> at
>> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549)
>> at
>> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345)
>> at
>> org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905)
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851)
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779)
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760)
>> at
>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638)
>> at
>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600)
>> at
>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
>> Why?  Because
>> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor,
>> IProfile, Map) knows the profile, but the certificate
>> checker doesn't know to check that profile but rather checks the self
>> profile.  I imagine the p2 director will have such problems too, or perhaps
>> it will not fail but also might not actually check the correct profile...
>>
>
> Such feedback is really welcome. Can you please open a dedicated bug for
> this issue and add me as CC ?
>
> I wonder though if n projects have to duplicate the effort n times if that
>> will be n times the work.
>>
>
> The effort of consuming upstream artifacts from Maven is equivalent to the
> effort of consuming artifacts from Orbit. So there is no extra effort
> involved for consumers, they just change a version in their .target and
> that's all.
> "Downstream" projects can also directly consume bundles provided by their
> "upstream" ones in a plain p2 way. For example, a project that need mockito
> can just take Mockito from Platform instead of Orbit, without playing with
> Maven dependencies. It's actually already a common and efficient: may
> target files don't reference Orbit and pick the libs that's provided by
> their "upstream".
>
>
>> Also, might we end up with n versions of each such bundle?
>>
>
> We already do have N versions of several libs, split across multiple
> repositories (eg some older projects don't rebuild against latest Orbit and
> still include older libs). p2 -during SimRel aggregation or installation on
> user end- does take care of picking the best and tries to avoid multiple
> versions when this can be avoided.
> Consuming libs from Maven instead of Orbit doesn't really change the
> problem/solution in the end.
>
>
> _

Re: [platform-dev] Unsigned Content?

[Aleksandar Kurtakov]

On Fri, Dec 17, 2021 at 10:11 AM Ed Merks  wrote:

> Comments below.
> On 17.12.2021 07:46, Aleksandar Kurtakov wrote:
>
>
>
> On Fri, Dec 17, 2021 at 8:01 AM Ed Merks  wrote:
>
>> Has the platform decided to bypass Orbit to produce IUs directly from
>> some other sources?   I'm not sure how the multiple versions of such IUs
>> on the release train will be (or even can be) coordinated across
>> projects if the general new approach is that each project produces such
>> things purely for its own purpose from whatever sources it deems fit.
>>
>> Also, the artifacts are not signed, which is the reason that I noticed:
>>
>>
>> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23-I-builds/index.html
>>
>> Note that once an unsigned version of some specific artifact ID is out
>> there is the wild (in someone's bundle pool), it's extremely hard to
>> stamp it out unless a new version with a new artifact ID is created to
>> supersede it.
>>
>> Perhaps the platform has decided that PGP signatures are now deemed to
>> be fully secure and fully feature complete such that signatures are
>> obsolete?  This is not the expectation I have based Planning Council
>> discussions.
>>
>
> Platform is not contributing these to release train so no issue for
> release train for now!
>
> That appears to be the case given these particular IUs are not on the
> current train.
>
> The feature org.eclipse.test relies on PGP on purpose as this is our proof
> and example how PGP works and is on par with jarsigner as far as signing
> requirements for third party dependencies are considered
> https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md#securing-third-party-artifacts
> .
>
> A proof of concept is arguably useful.
>
> Here is what happens when the installer tries to install
> org.mockito.mockito-core into a Platform SDK IDE:
>
> java.lang.NullPointerException
> at
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311)
> at
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63)
> at
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1)
> at
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126)
> at
> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83)
> at
> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63)
> at
> org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254)
> at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105)
> at
> org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50)
> at
> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80)
> at
> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48)
> at
> org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46)
> at
> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549)
> at
> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345)
> at
> org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760)
> at
> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638)
> at
> org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600)
> at
> org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> Why?  Because
> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor,
> IProfile, Map) knows the profile, but the certificate
> checker doesn't know to check that profile but rather checks the self
> profile.  I imagine the p2 director will have such problems too, or perhaps
> it will not fail but also might not actually check the correct profile...
>

If p2.director fails please open a bug about it and it will be ha

Re: [platform-dev] Unsigned Content?

[Aleksandar Kurtakov]

On Fri, Dec 17, 2021 at 8:01 AM Ed Merks  wrote:

> Has the platform decided to bypass Orbit to produce IUs directly from
> some other sources?   I'm not sure how the multiple versions of such IUs
> on the release train will be (or even can be) coordinated across
> projects if the general new approach is that each project produces such
> things purely for its own purpose from whatever sources it deems fit.
>
> Also, the artifacts are not signed, which is the reason that I noticed:
>
>
> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23-I-builds/index.html
>
> Note that once an unsigned version of some specific artifact ID is out
> there is the wild (in someone's bundle pool), it's extremely hard to
> stamp it out unless a new version with a new artifact ID is created to
> supersede it.
>
> Perhaps the platform has decided that PGP signatures are now deemed to
> be fully secure and fully feature complete such that signatures are
> obsolete?  This is not the expectation I have based Planning Council
> discussions.
>

Platform is not contributing these to release train so no issue for release
train for now!
The feature org.eclipse.test relies on PGP on purpose as this is our proof
and example how PGP works and is on par with jarsigner as far as signing
requirements for third party dependencies are considered
https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md#securing-third-party-artifacts
. Updating mockito and friends to newer versions so they work with latest
Java versions is a task we couldn't have completed if we had gone through
Orbit as this literally doubles the work involved.
This was a topic for next Planning Council meeting but as it's already
bringed here: Yes, Eclipse PMC has decided that we are going with PGP
signatures and it's fullfilling the given requirements (
https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes). There is just not
enough manpower to keep releng uptodate and fix bugs at the same time. So
from now on things like Jetty updates and other third party updates will go
with PGP signing only from Eclipse TLP. It's not a decision taken lightly -
it's total exhaustion amongst people doing that work and lack of interest
from others to heavily engage in either sharing the burden of the releng
process or at least look into the new approach and point issues in it.
So the possible paths I see are:
* Simrel accepts PGP signatures
* Simrel stays with old Platform that doesn't contain third party PGP
signed dependencies
* Someone steps up to do all the needed work in the old way
* Someone points how a real exploit with PGP signing but can't happen with
jarsigning

The topic is something I have planned to bring to the next Planning Council
meeting in January. Eclipse Platform doesn't plan to push any third party
updates for content in Simrel for limited period to give some time for
Planning Council to discuss and decide. I seriously wanted to delay this
discussion after Christmas to not interrupt the discussions during
vacations, which already started or start today for quite a few people
including me.


>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>

On behalf of Eclipse PMC
-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse/SWT source repositories?

[Aleksandar Kurtakov]

On Thu, Dec 9, 2021 at 2:56 PM Thomas Singer  wrote:

> Thanks all of you for the quick replies.
>
> > https://git.eclipse.org/c/
>
> This seems to be outdated with the last commit in April.
>
> >
> https://git.eclipse.org/r/admin/repos/platform/eclipse.platform.swt.binaries
>
> This page helps and this is the clone URL:
>
> https://git.eclipse.org/r/platform/eclipse.platform.swt.binaries
>
> What a struggle!
>
> Is it planned to move the repositories to GitHub?
>

There is a plan [1]. Execution is quite slow and I don't expect it to go
quite fast as part of the plan is to move repositories one by one after
cleaning their respective gerrit queues. First step is to move the
aggregator build repository as it's almost never used by anyone else but
releng thus provides least disruptive learning experience and is the
hardest one to port so when we switch it doing the rest should not block on
any potential technical issue.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577322


>
> --
> Cheers,
> Tom
>
> On 2021-12-09 13:30, Alex Blewitt wrote:
> > https://git.eclipse.org/c/
> >
> > Alex
> >
> > Sent from my iPhone 
> >
> >> On 9 Dec 2021, at 12:22, Thomas Singer  wrote:
> >>
> >> Hi,
> >>
> >> Where can I find the source code repositories for Eclipse, especially
> for org.eclipse.swt/swt.binaries? The eclipse.org website is extremely
> confusing and even Google did not help me.
> >>
> >> Thanks in advance.
> >>
> >> --
> >> Best regards,
> >> Thomas Singer
> >> =
> >> syntevo GmbH
> >> www.syntevo.com
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse-dev] Master open for 4.23 development

[Aleksandar Kurtakov]

Thanks Sravan!

On Mon, Nov 29, 2021 at 7:25 AM Sravan K Lakkimsetti <
sravankum...@in.ibm.com> wrote:

> We are pleased to announce that master branch is open for 4.22 development.
>
> You can subscribe to build schedule here
> <https://www.eclipse.org/eclipse/platform-releng/buildSchedule.html>.
>
> Thanks and Regards,
> Sravan
>
> Sravan Kumar Lakkimsetti
> IBM India Pvt Ltd,
> Embassy Golf Links Business Park, C Block,
> Off Indiranagar-Kormangla Inner Ring Road,
> Bangalore - 560071, India
>
> ___
> eclipse-dev mailing list
> eclipse-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [equinox-dev] RFC: Eclipse TLP migration to Github

[Aleksandar Kurtakov]

On Fri, Oct 15, 2021 at 9:09 AM Christoph Läubrich 
wrote:

> As I'm always advocated to use Github +1 implied by nomination ;-)
>
> I'd just like to recomment to use the migration process to also merge
> some of the related repositories eg, everything relate to jdt in one
> repository (same for pde, platform, equinox) as this cluttering of code
> makes it hard to create consistent PRs across repository boundaries of
> related code.
>

While I sympathize the goal it's impossible to happen without significant
investment on releng and tests improvement sides as it's clearly a
non-option to have multi hours verification jobs for each commit. That's
why we hope to go for "in between" approach as described in the document.
Aka merge few repositories (low hanging fruit) and leave the rest for when
we are confident it would not hurt us in CI times and etc. Merging down to
4 repos only is out of question for now.


>
>
> Am 14.10.21 um 21:20 schrieb Aleksandar Kurtakov:
> > Hey everyone,
> > We (Eclipse PMC) have been discussing migration to Github so we try to
> > get closer to the bigger developer community and at the same time
> > enhance the tooling we use daily.
> > We have prepared a document [1] listing why, what, when, how according
> > to our best knowledge but we are looking for your comments, ideas, etc.
> > so together we choose the best path forward for Eclipse IDE development
> > process.
> >
> > P.S. All communication channels are fine - comments on the document,
> > mailing list discussions and even calls to discuss things.
> >
> > [1]
> >
> https://docs.google.com/document/d/1dFAGX2P5cKnmfppyGhTqUIt0iGAHaRXm1BW7_hVufBw/edit?usp=sharing
> > <
> https://docs.google.com/document/d/1dFAGX2P5cKnmfppyGhTqUIt0iGAHaRXm1BW7_hVufBw/edit?usp=sharing
> >
> >
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
> > ___
> > equinox-dev mailing list
> > equinox-...@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev
> >
> _______
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] RFC: Eclipse TLP migration to Github

[Aleksandar Kurtakov]

Hey everyone,
We (Eclipse PMC) have been discussing migration to Github so we try to get
closer to the bigger developer community and at the same time enhance the
tooling we use daily.
We have prepared a document [1] listing why, what, when, how according to
our best knowledge but we are looking for your comments, ideas, etc. so
together we choose the best path forward for Eclipse IDE development
process.

P.S. All communication channels are fine - comments on the document,
mailing list discussions and even calls to discuss things.

[1]
https://docs.google.com/document/d/1dFAGX2P5cKnmfppyGhTqUIt0iGAHaRXm1BW7_hVufBw/edit?usp=sharing

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Change in release dates for 2021-12 Simrel

[Aleksandar Kurtakov]

Hi fellow committers,
There is a change in 2021-12 SimRel dates [1] notably moving the release 1
week earlier - December 08, 2021 . This is needed as last year's December
release showed a major issue in our planning - no one available to fix
brown-paper-bag bugs due to the Christmas holidays.
Eclipse TLP plan has been updated accordingly [2] - please consult it and
plan accordingly.

We (Eclipse Planning Council) are very sorry for any disturbance this would
create but is badly needed to allow projects to better support their users!


[1] https://wiki.eclipse.org/Category:SimRel-2021-12
[2]
https://www.eclipse.org/projects/project-plan.php?planurl=https://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_22.xml#release_milestones

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [cross-project-issues-dev] CVS support plugin discontinuation

[Aleksandar Kurtakov]

On Fri, Sep 17, 2021 at 7:52 PM Jonah Graham  wrote:

> Hello folks,
>
> I am reaching out to you because I *may* need to take this on. But before
> I do I want to confirm a couple of things:
>
> - Can the CVS features be released as needed and live in their own p2 site
> going forward and that p2 site contribute to SimRel?
>

I can't think of a reason this does not work out.


> - Can the Platform team still "host" the features/git repo/p2 site for
> them? (As opposed to having to spin up a new project?)
>

I don't see an issue with having a separate git repo owned by the platform.


>
> I think my options are to:
> 1) either split CVS features out of the repo[1] and fixup the build/etc so
> that it can build independently
>
That is  the best long term solution.


> 2) create a mirror of the CVS features of the last release and host that
> somewhere internal
> 3) simply tell users to point at old release p2 sites to install CVS into
> their newer Eclipse.
>
> The advantage of (1) is that, if needed, future fixes can actually be done
> - and done in the open source easily, but that would require a Yes to my
> two questions.
>
(1) is the best option IMHO too. We can have a call or whatever else chanel
you would like to chat about the future changes.


>
> Thanks
> Jonah
>
> [1]
> https://git.eclipse.org/r/plugins/gitiles/platform/eclipse.platform.team/
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Fri, 17 Sept 2021 at 10:04, Aleksandar Kurtakov 
> wrote:
>
>> Hey everyone,
>> CVS is dead technology but we still lose precious releng time in making
>> sure versions are changed so it's updated clean from previous release,
>> useless bits are still built on every patch review, tests are not run and
>> so on. All that for nothing as we don't know whether there is any user left
>> and whether the plugin is even still functional.
>>
>> With all that said, Eclipse TLP PMC is planning to have 4.22/2021-12
>> release be the last one containing CVS support . It's a standalone feature
>> not included in Eclipse SDK  nor in any EPP (AFAIK) thus it shouldn't
>> affect many people (if anyone!). Being standalone, building it separately
>> should be easy in case anyone is willing to preserve it.
>> If you're still using CVS and depend on this plugin availability please
>> raise your voice now and contact us on platform-dev@eclipse.org to plan
>> and organize the split of CVS feature and you taking over release duties
>> for it.
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-...@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse-dev] Moving to Jenkinsfile (was Re: ATTENTION: Turn off of git protocol)

[Aleksandar Kurtakov]

On Wed, Jun 30, 2021 at 2:05 PM Mickael Istria  wrote:

> At the moment, if we opt for the "multi branch pipeline" integration
> between Gerrit and Jenkinsfile, we'd lose the ability to retrigger a build
> with a "please rebuild". People who need a rebuild would have to follow the
> link to Jenkins and click the build button.
> I personally don't see that as a blocker for adoption of Jenkinsfile. What
> do others think?
>

THis doesn't sound like a problem for me.

> ___
> eclipse-dev mailing list
> eclipse-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] ATTENTION: Turn off of git protocol

[Aleksandar Kurtakov]

It is quite likely that you'll start seeing gerrit verification builds and
other jenkins jobs failing with "

Command "git fetch --tags --force --progress --
git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git
refs/changes/21/180221/4" returned status code 128:*18:15:40* stdout:
*18:15:40* stderr: fatal: read error: Connection reset by peer"

This is due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=574076. Fix is
as simple as changing to https url as done here
https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/jobConfigHistory/showDiffFiles?timestamp1=2021-05-07_05-05-43=2021-06-25_12-29-31
.
Unfortunately this would be quite time consuming to figure out every single
place where git:// url is used so keep an eye and fix your Jenkins jobs
accordingly.

I want to start another conversation as it seems good timing:
Isn't it time to start using Jenkinsfile for each git repository and use
that to trigger gerrit builds?
That would make our scripts easier to grep and find/automate such changes
in the future. If there are few others interested in helping out and
finding out such work beneficial I would like to discuss with them how we
can best handle this change.

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] most performant way to paint a (platform-specific) pixel-array

[Aleksandar Kurtakov]

On Thu, Apr 22, 2021 at 9:04 AM Erdal Karaca 
wrote:

> Maybe, you could also use WebGL (and many fancy libs) using an embedded
> browser. There is an ongoing effort to integrate chromium into SWT.
>

WebGL worked when I tested it with webkit and I assume same is true for
IE/Edge and Safari.
Regarding chromium don't hope too much on it - there was no interest in
contributing it to SWT proper so builds are gone for the June release and
even code will be removed after that so if someone really wants to see it
progressing some serious amount of resources should be put on it. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572010


>
> Am Do., 22. Apr. 2021 um 07:54 Uhr schrieb Christoph Läubrich <
> lae...@laeubi-soft.de>:
>
>> Hi Michael,
>>
>> sadly jogl is badly maintained (a new release is promised for month,
>> only a RC is available but not on maven and so on)...
>>
>> That's exactly the issue here, I have had a bug in jogl I think a year
>> ago (or even more?) and there was a fix that *probably* would solve
>> this, but as today the fix is not officially released. So this is kind
>> of dead-end for me, if one has finally a working example and needs to
>> hope that nothing changes (os update, new lib/swt release) thats not
>> usable for me.
>>
>>
>> Am 21.04.21 um 20:15 schrieb Michael Keppler:
>> > I know that we use jzy3d and jogl in an Eclipse product (to render 3D
>> > charts). Isn't that an OpenGL implementation running on SWT? I'm not
>> > into graphics programming, so I'm not sure if that actually provides
>> > some value for you. :)
>> >
>> > Ciao, Michael
>> >
>> > ___
>> > platform-dev mailing list
>> > platform-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> > https://www.eclipse.org/mailman/listinfo/platform-dev
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Download SWT jars

[Aleksandar Kurtakov]

On Thu, Apr 8, 2021 at 5:39 PM Thomas Singer  wrote:

> Hi all,
>
> Where on eclipse.org it is possible to find the SWT jars? It looks like
> it's now only possible to download the full bundles of Eclipse IDEs.
>

Platform release page has them
https://download.eclipse.org/eclipse/downloads/drops4/R-4.19-202103031800/
. Going to https://download.eclipse.org/eclipse/downloads/index.html one
can see latest release and I-build pages and get respective SWT jars from
there.


>
> Thanks in advance.
>
> --
> Tom
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Aleksandar Kurtakov]

r concern...): Is this level of complexity that
> is inherent to any multi threaded solution for bundle activation and class
> loading worth the few milliseconds that can be shaved.
> >
> >
> > I looked at a few reviews on the matter of workspace initialization, and
> my impression is that it depends: in some cases, refactorings to use an
> OSGi service do not increase complexity, they sometimes happen to better
> separate concerns and thus improve maintainability/simplicity. But
> sometimes, it's indeed slightly more complex.
> > I have the impression those are similar to any change and should be
> treated individually like we do for all other changes, as there is not
> clear sign that things get systematically simpler/harder, better/worse,...
> when using services.
> >
> >>
> >> But in the end, I'm not a committer on the platform and only a consumer
> that tries to maintain a complex framework across various versions of
> Eclipse in a backward- and forward-compatible way. In the end I can only
> voice my opinion and try to understand the solution such that I know how to
> best use it such that the code is still fine with Eclipse 4.8, 4.20, and
> all versions inbetween.
> >
> >
> > Platform usually try to capture new patterns in migration guide and
> documentation. But for sure, if you want to still write code that targets
> Eclipse 4.8, you won't be able to use newer APIs and patterns, eg your
> plugin will keep calling ResourcePlugin.getWorkspace early in Activator and
> Eclipse Workbench will not start faster when your plugin is installed. But
> as long as you stick to 4.8 and verify you don't rely on APIs that don't
> get deprecated/removed, it should work with 4.20 even if some refactorings
> about internal Activator have been happening; 4.20 should not work worse
> than 4.8.
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Eclipse Platform project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse PMC statement on SWT Chromium support

[Aleksandar Kurtakov]

The Eclipse Project PMC has agreed that the time spent on
building/infrastructure/reviews/bug triaging for Chromium support in SWT,
in its current form, is not providing benefits for the open source
community. Setting aside how demotivating it is to work on something that
isn't useful, we simply do not have the resources to dedicate to something
which can not be used in real applications. The security concerns in the
current Chromium support are eroding SWT credibility since part of the
project has a hard requirement on a library with many CVEs.

Thus the following steps will be taken:
* We will stop building and publishing the Chromium support libs for M1
(2021-04-09) unless a patch is contributed by that time, which
provides support for a recent, CVE-free Chromium version.
* The code and disabled builds will be kept until the end of the current
release cycle (2021-06-16) to provide an opportunity for the community to
step in if there is interest in keeping support for it.

We absolutely want to see the SWT ecosystem grow (but not at the cost of
putting at risk regular builds, and the motivation of people working on
it). Thus we would support efforts to improve SWT extensibility so that
alternative Browser implementations can be provided without the need for
changes in SWT codebase or involvement of Platform rel. eng.  That is, we
want it to be possible to contribute new browser support by an
independently driven project. Who would like to help?

P.S. Removal is to be handled via
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572010

-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Has the time come?

[Aleksandar Kurtakov]

On Tue, Mar 16, 2021 at 7:14 AM Sravan K Lakkimsetti <
sravankum...@in.ibm.com> wrote:

> Hi,
>
>
>
> For the website I am not completely sure on what this entitles. The
> current build page(and its contents) for platform is of 5.5
> GB(approximately). I don’t think I would want this kind if data on GitHub.
>

Sravan, I think by website it's ment
https://git.eclipse.org/c/www.eclipse.org/eclipse.git/ . This is not much
edited content which could use a lot of help on bringing it uptodate.


>
>
> Thanks
>
> Sravan
>
> *From:* Mickael Istria 
> *Sent:* 16 March 2021 00:54
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] Re: [platform-dev] Has the time come?
>
>
>
> Hi,
>
> I'm in favor of moving the website if it seems straightforward. For the
> website, we could even use GitHub issues and shut down the bugzilla
> component as I don't think there is much substance in the tracked issues.
> But I think it would be necessary to have PMC agreeing first.
>
> On Monday, March 15, 2021, Wim Jongman  wrote:
> > Hi,
> > Before this stalls again, do we have a team?
> >
> > I see Rolf, Mickael, Sravan, and myself on the wiki page.
> > What is the first step? I am happy to execute it. Shall I attempt to
> port the platform website to Git?
> >
> > https://wiki.eclipse.org/Platform-releng/Migration_To_GitHub
> >
> > Cheers,
> > Wim
> >
> >
> >
> > On Thu, Mar 11, 2021 at 5:50 PM Wim Jongman 
> wrote:
> >>
> >> I think the move to GitLab is for projects that stay on the foundation
> infra.
> >>
> >> On Thu, Mar 11, 2021 at 5:05 PM Jonah Graham 
> wrote:
> >>>
> >>>
> >>> On Thu, 11 Mar 2021 at 11:00, Ed Merks  wrote:
> >>>>
> >>>> I'm not sure if anyone mentioned the "forced" migration to gitlab?
> >>>>
> >>>> Does it make sense to migrate anything to github if it will
> subsequently need to be migrated to gitlab anyway?
> >>>>
> >>>> I'm just asking...
> >>>
> >>> This is news to me. I have not heard anything about leaving github.
> >>>
> >>>>
> >>>> On 11.03.2021 16:55, Wim Jongman wrote:
> >>>>
> >>>>
> >>>> On Wed, Mar 10, 2021 at 5:27 PM Mickael Istria 
> wrote:
> >>>>>
> >>>>>  I'd advise starting by evaluating for instance migration of PDE to
> GitHub:
> >>>>
> >>>> How about starting with the websites. In 99% of the cases, the
> websites don't need to dance with Gerrit, but ATM is required.
> >>>> The websites are ideal for casual contributions, especially with the
> 5-minute deployments that the webmasters have built, there is instant
> gratification.
> >>>>
> >>>> It would also help us. We can update websites super fast with the GH
> workflow.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> platform-dev mailing list
> >>>> platform-dev@eclipse.org
> >>>> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >>>>
> >>>> ___
> >>>> platform-dev mailing list
> >>>> platform-dev@eclipse.org
> >>>> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >>>
> >>> ___
> >>> platform-dev mailing list
> >>> platform-dev@eclipse.org
> >>> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
>
> --
>
> Mickael Istria
>
> Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> developer, for Red Hat Developers
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_=DwMFaQ=jf_iaSHvJObTbx-siA1ZOg=BbJ1i82pNJnkXoEbqK7sZDkJsrJ7wkY_no7y0H4rMzE=T7_hdZMo1FCpmh1Hd_Fk27bGkdxK1Z8I2HmW0w2BkCU=vrsgPNCGTjnXy_Yv-9AXfraL0ZN1qz-Wga4__sSvEpo=>
>
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Manual fix in swt .classpath file required

[Aleksandar Kurtakov]

In order to simplify SWT project structure a bit I've merged common and
common_j2se source folders [1]. This requires that whoever has it setup in
the workbench removes common_j2se source folder from the project
configuration or simply replaces .classpath with .classpath_[gtk,mac,win].
Sorry for the inconvenience but every such little step helps with
onboarding new people and increases our chances to get more hands on.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571962
-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Has the time come?

[Aleksandar Kurtakov]

On Thu, Mar 11, 2021 at 6:01 PM Ed Merks  wrote:

> I'm not sure if anyone mentioned the "forced" migration to gitlab?
>
> Does it make sense to migrate anything to github if it will subsequently
> need to be migrated to gitlab anyway?
>

Where is this coming from? I thought that gitlab is an option for projects
not wanting to go to github. If this is not true we need clearer statement
as most people I communicate with understood it that way.


> I'm just asking...
>
>
> On 11.03.2021 16:55, Wim Jongman wrote:
>
>
>
> On Wed, Mar 10, 2021 at 5:27 PM Mickael Istria  wrote:
>
>>  I'd advise starting by evaluating for instance migration of PDE to
>> GitHub:
>>
>
> How about starting with the websites. In 99% of the cases, the websites
> don't need to dance with Gerrit, but ATM is required.
>
> The websites are ideal for casual contributions, especially with the
> 5-minute deployments that the webmasters have built, there is instant
> gratification.
>
> It would also help us. We can update websites super fast with the GH
> workflow.
>
>
>
>
>
> ___
> platform-dev mailing listplatform-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Has the time come?

[Aleksandar Kurtakov]

On Wed, Mar 10, 2021 at 4:56 PM Wim Jongman  wrote:

> Maybe we can skip adding features completely for one or two releases and
> have all hands focusing entirely on the releng process.
>

This is what some of us have been doing for years  with the clear goal to
be able to have predictable builds, shorter build times, support for newer
JVMs and etc. But the process is not good enough. TBH I am not confident we
can move on as easily as people think. Please try to replicate the build
locally incl. reports generation, download pages and etc. - you will notice
many discrepancies - pick one, open bug about it with proposal how to
improve it and be ready to work on it.
Nothing is set in stone - if we are about to merge repos - please propose
exact things to do. I don't believe that big bang let's break everything
will produce any good rather that constant improvements allow for better
understanding of technical issues, requirements, implementation and etc. to
be more robust if every step is questioned regularly.


>
> On Wed, Mar 10, 2021 at 3:42 PM Christoph Läubrich 
> wrote:
>
>> +1 for move to github, we should take the opportunity to merge several
>> repos, this cluttering of code is just a mess.
>>
>>
>> Am 10.03.21 um 15:37 schrieb Wim Jongman:
>> > Hi,
>> >
>> > Can we discuss the move to GitHub again?
>> >
>> > Cons:
>> > * No Gerrit -> best review system ever
>> >
>> > Pros:
>> > * All the developers are there.
>> > * No Gerrit -> easy entry for new devs
>> >
>> > Cheers,
>> >
>> > Wim
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Gerrit Spam

[Aleksandar Kurtakov]

On Mon, Jan 25, 2021 at 4:09 PM Jonah Graham  wrote:

> Turning on "Silent Start Mode" omits the build started messages, but
> the build completed messages will still come through.
>

In this case I'm in favor of the proposal.


>
> HTH
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Mon, 25 Jan 2021 at 09:06, Alex Blewitt  wrote:
>
>> This is added by the Gerrit Trigger.
>>
>> https://plugins.jenkins.io/gerrit-trigger/
>>
>> There’s a ’silent’ mode, which presumably suppresses that message, but I
>> don’t know if it also suppresses the build succeed/failed messages either.
>>
>> Alex
>>
>> On 25 Jan 2021, at 13:30, Wim Jongman  wrote:
>>
>> Hi,
>>
>> I can do without the "Build started" messages from Gerrit.
>>
>> Do I have supporters for this? Otherwise, I don't want to waste the
>> webmaster's time asking for a solution.
>>
>> Cheers,
>>
>> Wim
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse.org-planning-council] 2021-06, 2021-09, 2021-12 schedule - Change December release date?

[Aleksandar Kurtakov]

On Mon, Jan 11, 2021 at 3:28 PM Wim Jongman  wrote:

> You asked for opinions. My opinion is that the schedule pain is not in the
> december release but in the march release,
>

So do you actually propose release cycles to be Jan/Apr/Jul/Oct ?


>
> On Mon, Jan 11, 2021 at 2:22 PM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Mon, Jan 11, 2021 at 3:19 PM Wim Jongman 
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> Assuming everyone starts again Jan 2, there are about 10 workdays for
>>> March M1. I prefer combining March M1 and M2 over shortening December.
>>>
>>
>> How would that help the goal to have some time for reaction between
>> December release and Christmas?
>>
>>
>>>
>>> Cheers,
>>>
>>> Wim
>>>
>>>
>>> On Mon, Jan 11, 2021 at 1:03 PM Aleksandar Kurtakov 
>>> wrote:
>>>
>>>> Planning council discusses moving one week earlier the 2021-12 release
>>>> so there is time for reaction (if there is need for it) before Christmas.
>>>> Personally I think the proposal makes sense and the best way is by
>>>> shortening the December cycle, that way it will be more like the March one
>>>> (which loses M1 time due to Christmas vacations).
>>>> Let me know if there are objections/proposals/opinions with reasons
>>>> behind them so I can present the Eclipse TLP opinion on the next meeting.
>>>>
>>>> On Mon, Jan 11, 2021 at 1:56 PM Mélanie Bats 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Le 06/01/2021 à 16:49, Jonah Graham a écrit :
>>>>> > Thanks folks for the discussion this morning/afternoon.
>>>>> >
>>>>> > As mentioned in the meeting we will continue this discussion once we
>>>>> > have dates.
>>>>>
>>>>> I prepared the schedule for 2021-06, 2021-09 and 2021-12.
>>>>> Please review it on the wiki and confirm that it is okay for you by
>>>>> answering to this email:
>>>>> * https://wiki.eclipse.org/Category:SimRel-2021-06
>>>>> * https://wiki.eclipse.org/Category:SimRel-2021-09
>>>>> * https://wiki.eclipse.org/Category:SimRel-2021-12
>>>>>
>>>>> For the 2021-12, if we follow the classical pattern we will have
>>>>> mostly
>>>>> the same release date as the one this year.
>>>>> If we would like to have one week between the GA and the holidays, we
>>>>> can reduce M1 dev period for this release by one week and then release
>>>>> on December 8th.
>>>>>
>>>>> 2021-12 M1  Friday, October 08, 202110/01 to 10/08
>>>>> *2 weeks from 2021-09 GA*
>>>>> 2021-12 M2  Friday, November 5, 202110/22 to 10/29
>>>>>   3 weeks from M1
>>>>> 2021-12 M3  Friday, November 19, 2021   11/12 to 11/19
>>>>> 3 weeks from M2
>>>>> 2021-12 RC1 Friday, November 26, 2021   11/19 to 11/26
>>>>> 1 week from M3
>>>>> 2021-12 RC2 Friday, December 3, 202111/26 to 12/03
>>>>>   1 week from RC1
>>>>> Quiet period12/03 to 12/07
>>>>> 2021-12 GA  Wednesday, December 8, 2021
>>>>> 5 days from RC2
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Best regards,
>>>>> --
>>>>> Mélanie Bats
>>>>> CTO
>>>>> +33 7 87 69 42 84
>>>>> +33 5 34 57 16 29
>>>>> @melaniebats
>>>>>
>>>>> *Obeo*
>>>>> 25 Boulevard Victor Hugo - Colomiers - France
>>>>> http://www.obeo.fr
>>>>> ___
>>>>> eclipse.org-planning-council mailing list
>>>>> eclipse.org-planning-coun...@eclipse.org
>>>>> To unsubscribe from this list, visit
>>>>> https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>>>
>>>>
>>>>
>>>> --
>>>> Alexander Kurtakov
>>>> Red Hat Eclipse Team
>>>> ___
>>>> platform-dev mailing list
>>>> platform-dev@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>>>
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse.org-planning-council] 2021-06, 2021-09, 2021-12 schedule - Change December release date?

[Aleksandar Kurtakov]

On Mon, Jan 11, 2021 at 3:19 PM Wim Jongman  wrote:

>
> Hi,
>
> Assuming everyone starts again Jan 2, there are about 10 workdays for
> March M1. I prefer combining March M1 and M2 over shortening December.
>

How would that help the goal to have some time for reaction between
December release and Christmas?


>
> Cheers,
>
> Wim
>
>
> On Mon, Jan 11, 2021 at 1:03 PM Aleksandar Kurtakov 
> wrote:
>
>> Planning council discusses moving one week earlier the 2021-12 release so
>> there is time for reaction (if there is need for it) before Christmas.
>> Personally I think the proposal makes sense and the best way is by
>> shortening the December cycle, that way it will be more like the March one
>> (which loses M1 time due to Christmas vacations).
>> Let me know if there are objections/proposals/opinions with reasons
>> behind them so I can present the Eclipse TLP opinion on the next meeting.
>>
>> On Mon, Jan 11, 2021 at 1:56 PM Mélanie Bats 
>> wrote:
>>
>>> Hi all,
>>>
>>> Le 06/01/2021 à 16:49, Jonah Graham a écrit :
>>> > Thanks folks for the discussion this morning/afternoon.
>>> >
>>> > As mentioned in the meeting we will continue this discussion once we
>>> > have dates.
>>>
>>> I prepared the schedule for 2021-06, 2021-09 and 2021-12.
>>> Please review it on the wiki and confirm that it is okay for you by
>>> answering to this email:
>>> * https://wiki.eclipse.org/Category:SimRel-2021-06
>>> * https://wiki.eclipse.org/Category:SimRel-2021-09
>>> * https://wiki.eclipse.org/Category:SimRel-2021-12
>>>
>>> For the 2021-12, if we follow the classical pattern we will have mostly
>>> the same release date as the one this year.
>>> If we would like to have one week between the GA and the holidays, we
>>> can reduce M1 dev period for this release by one week and then release
>>> on December 8th.
>>>
>>> 2021-12 M1  Friday, October 08, 202110/01 to 10/08
>>> *2 weeks from 2021-09 GA*
>>> 2021-12 M2  Friday, November 5, 202110/22 to 10/29
>>> 3 weeks from M1
>>> 2021-12 M3  Friday, November 19, 2021   11/12 to 11/19
>>> 3 weeks from M2
>>> 2021-12 RC1 Friday, November 26, 2021   11/19 to 11/26
>>> 1 week from M3
>>> 2021-12 RC2 Friday, December 3, 202111/26 to 12/03
>>> 1 week from RC1
>>> Quiet period12/03 to 12/07
>>> 2021-12 GA  Wednesday, December 8, 2021
>>> 5 days from RC2
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> --
>>> Mélanie Bats
>>> CTO
>>> +33 7 87 69 42 84
>>> +33 5 34 57 16 29
>>> @melaniebats
>>>
>>> *Obeo*
>>> 25 Boulevard Victor Hugo - Colomiers - France
>>> http://www.obeo.fr
>>> ___
>>> eclipse.org-planning-council mailing list
>>> eclipse.org-planning-coun...@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [eclipse.org-planning-council] 2021-06, 2021-09, 2021-12 schedule - Change December release date?

[Aleksandar Kurtakov]

Planning council discusses moving one week earlier the 2021-12 release so
there is time for reaction (if there is need for it) before Christmas.
Personally I think the proposal makes sense and the best way is by
shortening the December cycle, that way it will be more like the March one
(which loses M1 time due to Christmas vacations).
Let me know if there are objections/proposals/opinions with reasons behind
them so I can present the Eclipse TLP opinion on the next meeting.

On Mon, Jan 11, 2021 at 1:56 PM Mélanie Bats  wrote:

> Hi all,
>
> Le 06/01/2021 à 16:49, Jonah Graham a écrit :
> > Thanks folks for the discussion this morning/afternoon.
> >
> > As mentioned in the meeting we will continue this discussion once we
> > have dates.
>
> I prepared the schedule for 2021-06, 2021-09 and 2021-12.
> Please review it on the wiki and confirm that it is okay for you by
> answering to this email:
> * https://wiki.eclipse.org/Category:SimRel-2021-06
> * https://wiki.eclipse.org/Category:SimRel-2021-09
> * https://wiki.eclipse.org/Category:SimRel-2021-12
>
> For the 2021-12, if we follow the classical pattern we will have mostly
> the same release date as the one this year.
> If we would like to have one week between the GA and the holidays, we
> can reduce M1 dev period for this release by one week and then release
> on December 8th.
>
> 2021-12 M1  Friday, October 08, 202110/01 to 10/08
> *2 weeks from 2021-09 GA*
> 2021-12 M2  Friday, November 5, 202110/22 to 10/29  3
> weeks from M1
> 2021-12 M3  Friday, November 19, 2021   11/12 to 11/19
> 3 weeks from M2
> 2021-12 RC1 Friday, November 26, 2021   11/19 to 11/26
> 1 week from M3
> 2021-12 RC2 Friday, December 3, 202111/26 to 12/03  1
> week from RC1
> Quiet period12/03 to 12/07
> 2021-12 GA  Wednesday, December 8, 2021
> 5 days from RC2
>
> What do you think?
>
> Best regards,
> --
> Mélanie Bats
> CTO
> +33 7 87 69 42 84
> +33 5 34 57 16 29
> @melaniebats
>
> *Obeo*
> 25 Boulevard Victor Hugo - Colomiers - France
> http://www.obeo.fr
> ___
> eclipse.org-planning-council mailing list
> eclipse.org-planning-coun...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Reminder: Master is still closed

[Aleksandar Kurtakov]

Hey everyone,
Let me remind you that master is still closed but we have started the
process to open 4.19 stream. As a result of that any further fix for 4.18
(if needed) should go into R4_18_maintenance branch.

Please test thoroughly our 4.18 release and stay tuned for the announcement
of opening master for 4.19 development.

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 2020-12 (4.18) RC2 is available

[Aleksandar Kurtakov]

We are pleased to announce that 2020-12 RC2 is available for download
and updates.

Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.18RC2-202012021800/

New and Noteworthy:
https://www.eclipse.org/eclipse/news/4.18/

Update existing (non-production) installs:
https://download.eclipse.org/eclipse/updates/4.18milestones/

Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18RC2-202012021800/

Equinox specific downloads:
https://download.eclipse.org/equinox/drops/S-4.18RC2-202012021800/



Thank you to everyone who made this checkpoint possible.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] 4.18 RC2 milestone week reminders

[Aleksandar Kurtakov]

Hi all,

We are scheduled to promote and contribute 4.18 RC2 to the simrel on
Friday the 5th of December.

Don't forget to consult the endgame plan regarding release candidates:
https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_18.php

Here is the schedule:

Wednesday 2nd December -- Release Candidate 2 build
Thursday 3rd December -- 1-day test pass against RC2 and sign-off
Friday 4th December -- 4.18 RC2 Promotion and contribution to SimRel

Note in particular the end game plan section concerning RC2, reproduced
here:

Release candidate containing fixes for the majority of known
outstanding defects that we intend to fix for 2020-12 (4.18). At the
end of RC2 build, there should not be any open defects tagged 4.18.
All fixes submitted must have a project lead or PMC vote on the bug
report, and the fix must be reviewed by an additional committer (any
committer other than the one who made the fix). A positive review from
a project lead or PMC member means implicit approval and no vote is
needed on the bug report. Ongoing changes to documentation, tests or
examples do not require approval.

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 2020-12 (4.18) RC1 is available

[Aleksandar Kurtakov]

We are pleased to announce that 2020-12 RC1 is available for download
and updates.

Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.18RC1-202011251800/

New and Noteworthy:
https://www.eclipse.org/eclipse/news/4.18/

Update existing (non-production) installs:
https://download.eclipse.org/eclipse/updates/4.18milestones/

Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18RC1-202011251800/

Equinox specific downloads:
https://download.eclipse.org/equinox/drops/S-4.18RC1-202011251800/



Thank you to everyone who made this checkpoint possible.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse and Equinox 2020-12 (4.18) M3 is available

[Aleksandar Kurtakov]

Now with correct URLs!


We are pleased to announce that 2020-12 M3 is available for download
and updates.

Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.18M3-202011190730/

New and Noteworthy:
https://www.eclipse.org/eclipse/news/4.18/

Update existing (non-production) installs:
https://download.eclipse.org/eclipse/updates/4.18milestones/

Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18M3-202011190730/

Equinox specific downloads:
https://download.eclipse.org/equinox/drops/S-4.18M3-202011190730/



Thank you to everyone who made this checkpoint possible.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] 4.18 RC1 milestone week reminders

[Aleksandar Kurtakov]

Thanks to Andrey who rightfully pointed out I don't know which is the
current Month! Dates corrected below.

Hi all,

We are scheduled to promote and contribute 4.18 RC1 to the simrel on Friday
the 27th.

Here is the schedule:

Wednesday 25 Nov -- API and feature freeze, Release Candidate build

Thursday 26 Nov -- Bug verification and Sign-off 4.17 RC1

Friday 27 Nov-- 4.17 RC1 Promotion and contribution to SimRel

Please note the following excerpt from the freeze plan:

RC1

All fixes submitted must have a project lead or PMC vote on the bug report,
and the fix must be reviewed by an additional committer (any committer
other than the one who made the fix). A positive review from a project lead
or PMC member means implicit approval and no vote is needed on the bug
report. Ongoing changes to documentation, tests or examples do not require
approval.



Thanks


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] 4.18 RC1 milestone week reminders

[Aleksandar Kurtakov]

Hi all,

We are scheduled to promote and contribute 4.18 RC1 to the simrel on Friday
the 27th.

Here is the schedule:

Wednesday 25 Oct -- API and feature freeze, Release Candidate build

Thursday 26 Oct -- Bug verification and Sign-off 4.17 RC1

Friday 27 Oct -- 4.17 RC1 Promotion and contribution to SimRel

Please note the following excerpt from the freeze plan:

RC1

All fixes submitted must have a project lead or PMC vote on the bug report,
and the fix must be reviewed by an additional committer (any committer
other than the one who made the fix). A positive review from a project lead
or PMC member means implicit approval and no vote is needed on the bug
report. Ongoing changes to documentation, tests or examples do not require
approval.



Thanks
-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 2020-12 (4.18) M3 is available

[Aleksandar Kurtakov]

We are pleased to announce that 2020-12 (4.18) M3  is available for
download and updates.

Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.18-202011190730/

New and Noteworthy:
https://www.eclipse.org/eclipse/news//

Update existing (non-production) installs:
https://download.eclipse.org/eclipse/updates/4.18milestones/

Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18-202011190730/

Equinox specific downloads:
https://download.eclipse.org/equinox/drops/S-4.18-202011190730/



Thank you to everyone who made this checkpoint possible.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] 4.18 (2020-12) M3 milestone reminders

[Aleksandar Kurtakov]

Next week is the milestone week for 4.18 M3.



Monday: Last day of development (and even then, no "big changes").

After Monday 18:00 ET, no feature work or unrelated fixes are allowed --
only regression fixes.



Tuesday: All-day test pass. Nobody should develop or fix anything.
Literally spend the entire day testing.



Wednesday: Fix day with a focus on fixing regressions found during the test
day (Tuesday). No unrelated fixes. Review and thoroughly test all commits.

- The last Wednesday build is the release candidate every team signs off on
Thursday.

- The "New and Noteworthy" entries are due on Wednesday evening:

Git repo: ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git

Gerrit: ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git

Live website: https://www.eclipse.org/eclipse/news/4.18/



Thursday: Sign-off after re-testing, or at least confirming no changes have
been made to your component's code since the last time the component was
tested well.



Friday: Build is officially declared and made available.

- The master branch stays closed until the milestone is officially
released. (That is, it is not enough that your component has signed off.)


Regards,


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox contribution towards SimRel for 4.18 M2 (2020-12 M2)

[Aleksandar Kurtakov]

Hi all,

Eclipse and Equinox contribution towards SimRel for 4.18 M2 (2020-12
M2) has been done using the
buildhttps://download.eclipse.org/eclipse/downloads/drops4/I20201028-1800/



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Signoff 4.18 M2

[Aleksandar Kurtakov]

Hi,



Please provide your Go/ No Go in *Bug 568366*
* - Declare 4.18 M2*



Thanks,
-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 4.18 M2 reminders

[Aleksandar Kurtakov]

Hi,



We have M2 contribution on October 30, 2020.

Please keep a watch on test failures so that we can submit a good build for
simrel.


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Unit test fragment

[Aleksandar Kurtakov]

.


On Tue, Oct 20, 2020 at 2:07 PM Andrey Loskutov  wrote:

> Hi,
>
> Before we propose to use whatever technology in a broader scope, could we
> please make sure that existing use of that technology *works*?
>

We use the fragments way in Linux Tools
https://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/ and it
helped us significantly to get better unit tests. So doing it that way
helps a lot but of course it's not a panacea.


>
> AFAIK org.eclipse.tests.urischeme tests are not executed/running at all,
> see https://bugs.eclipse.org/bugs/show_bug.cgi?id=565673.
>

This is due to the convoluted way tests are executed in nightly builds. If
you look at
https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/24051/consoleFull
the tests are executed via maven (aka in all gerrits) . So the tests run in
some cases just not in the nightly/published test results.


>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> > Gesendet: Dienstag, 20. Oktober 2020 um 12:17 Uhr
> > Von: "Karsten Thoms" 
> > An: "platform-dev@eclipse.org" 
> > Betreff: [platform-dev] Unit test fragment
> >
> > Dear all,
> >
> > As discussed in yesterday’s SDK meetup I would like to see some real
> unit tests for platform related internals. Many non-trivial functionality
> is buried in private methods and are hard to test just from API. In order
> to add tests on a more fine grained level when solving bugs I would like to
> see that such methods are opened up to package private. This would allow us
> to provide test cases in the same package as the class under test. However,
> this would require that the project hosting the tests is a fragment.
> >
> > Matthias Becker pointed me to project org.eclipse.tests.urischeme that
> is such an example. I would see something similar for tests of UI classes.
> Something like org.eclipse.ui.tests, but as a fragment for plain unit
> tests. I could imagine a fragment „org.eclipse.ui.unittests“. Would this be
> feasible? If this would be in general OK then I would open a bug to track
> this and provide an example.
> >
> > ~Karsten
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Unit test fragment

[Aleksandar Kurtakov]

On Tue, Oct 20, 2020 at 1:18 PM Karsten Thoms 
wrote:

> Dear all,
>
> As discussed in yesterday’s SDK meetup I would like to see some real unit
> tests for platform related internals. Many non-trivial functionality is
> buried in private methods and are hard to test just from API. In order to
> add tests on a more fine grained level when solving bugs I would like to
> see that such methods are opened up to package private. This would allow us
> to provide test cases in the same package as the class under test. However,
> this would require that the project hosting the tests is a fragment.
>
> Matthias Becker pointed me to project org.eclipse.tests.urischeme that is
> such an example. I would see something similar for tests of UI classes.
> Something like org.eclipse.ui.tests, but as a fragment for plain unit
> tests. I could imagine a fragment „org.eclipse.ui.unittests“. Would this be
> feasible? If this would be in general OK then I would open a bug to track
> this and provide an example.
>

It would be nice to have one test fragment per bundle not one bundle and
one fragment as it would complicate even more the fragile system we have
for tests in nightly builds. So converting existing bundles to fragments
sounds better option to me.


>
> ~Karsten
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] SWT - supported Linux versions

[Aleksandar Kurtakov]

I stop discussions on the topic here. Discussion should be at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=567906

On Thu, Oct 15, 2020 at 7:00 PM Thomas Singer  wrote:

> We build SWT on our own using just these 2 SWT repositories. Will that
> version be correct in this case, too? In other words, this would mean
> that the 'official 4.16 version' somewhere is stored in these SWT
> repositories.
>
> --
> Best regards,
> Thomas Singer
>
>
> On 2020-10-15 17:20, Aleksandar Kurtakov wrote:
> > On Thu, Oct 15, 2020 at 6:13 PM Gregor Schmid  wrote:
> >
> >>
> >> Hi all,
> >>
> >> the number 4.940 in version.txt has only just become meaningless - see
> >> the recent discussion about "Inconsistent version change in SWT 4.18"
> >> and the associated closed bug report
> >>
> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=567789
> >>
> >> In that discussion Tom mentioned the Manifest file as an alternative
> >> and I'm investigating that. Thanks Aleksandar, for moving that
> >> forward.
> >>
> >> So I'm also curious about the Implementation-Version in the Manifest
> >> file. Does that have a well-defined meaning?
> >
> >
> > It should be the version as specified in the OSGi manifest -
> >
> https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/META-INF/MANIFEST.MF
> > . I notice that it is wrong with my patch so I have to look further at
> what
> > needs fixing.
> >
> >
> >> Is it documented
> >> somewhere? Is it reliable?
> >>
> >
> > It's 100% reliable as we have tools that verify that OSGi metadata is
> good
> > and bumped when a change happens.
> >
> >
> >>
> >> If not, wouldn't it be a good idea to have both "4.18" and "2020-12"
> >> added to the Manifest file and/or as constants at some well-defined
> >> location like the Library class or the version.txt file?
> >>
> >
> > I wouldn't mind having eclipse sdk version (4.18) in the manifest too. It
> > is the best place according to me for such metadata. Just have to play
> with
> > the build system to make sure it's fetched from the main build and not
> > hardcoded to prevent shipping wrong content.
> >
> >
> >>
> >> My suggestion to use a map to deduct the user-visible version from
> >> whatever inconsistent version number is embedded in the code was
> >> actually a joke. If that's the only way, so be it, but from a software
> >> engineering standpoint I still vote for something predictable :-).
> >>
> >> Best regards,
> >>  Greg
> >>
> >> Thomas Singer  writes:
> >>
> >>> Hi Aleksandar,
> >>>
> >>> Do you mean
> >>>
> >>>> Manifest-Version: 1.0
> >>>> Ant-Version: Apache Ant 1.10.9
> >>>> Created-By: 11.0.2+9 (Oracle Corporation)
> >>>> SWT-OS: linux
> >>>> SWT-WS: gtk
> >>>> SWT-Arch: x86_64
> >>>> Implementation-Version: 3.113.0
> >>>
> >>> Should I find there something like "4.16"? The version.txt still shows
> >>> "version 4.940". It's all a little bit confusing.
> >>>
> >>> --
> >>> Best regards,
> >>> Thomas Singer
> >>>
> >>>
> >>>
> >>> On 2020-10-15 16:04, Aleksandar Kurtakov wrote:
> >>>> Thomas, would you please look at
> >>>>
> >>
> https://ci.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/1815/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/swt-I20201015-1352-gtk-linux-x86_64.zip
> >>>> and the swt.jar/manifest.mf in it. If this works for you I'll push and
> >> it
> >>>> will be available starting tomorrow build.
> >>>>
> >>>> On Thu, Oct 15, 2020 at 4:06 PM Aleksandar Kurtakov <
> >> akurt...@redhat.com>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Oct 15, 2020 at 3:28 PM Thomas Singer 
> >> wrote:
> >>>>>
> >>>>>> Hi Aleksander,
> >>>>>>
> >>>>>> Thanks for the link. Now the problem remains how to map between the
> >>>>>> content of the version.txt inside the org.eclipse*.jar to the
> >>>>>> Eclipse/SWT vers

Re: [platform-dev] SWT - supported Linux versions

[Aleksandar Kurtakov]

On Thu, Oct 15, 2020 at 6:13 PM Gregor Schmid  wrote:

>
> Hi all,
>
> the number 4.940 in version.txt has only just become meaningless - see
> the recent discussion about "Inconsistent version change in SWT 4.18"
> and the associated closed bug report
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=567789
>
> In that discussion Tom mentioned the Manifest file as an alternative
> and I'm investigating that. Thanks Aleksandar, for moving that
> forward.
>
> So I'm also curious about the Implementation-Version in the Manifest
> file. Does that have a well-defined meaning?


It should be the version as specified in the OSGi manifest -
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/META-INF/MANIFEST.MF
. I notice that it is wrong with my patch so I have to look further at what
needs fixing.


> Is it documented
> somewhere? Is it reliable?
>

It's 100% reliable as we have tools that verify that OSGi metadata is good
and bumped when a change happens.


>
> If not, wouldn't it be a good idea to have both "4.18" and "2020-12"
> added to the Manifest file and/or as constants at some well-defined
> location like the Library class or the version.txt file?
>

I wouldn't mind having eclipse sdk version (4.18) in the manifest too. It
is the best place according to me for such metadata. Just have to play with
the build system to make sure it's fetched from the main build and not
hardcoded to prevent shipping wrong content.


>
> My suggestion to use a map to deduct the user-visible version from
> whatever inconsistent version number is embedded in the code was
> actually a joke. If that's the only way, so be it, but from a software
> engineering standpoint I still vote for something predictable :-).
>
> Best regards,
> Greg
>
> Thomas Singer  writes:
>
> > Hi Aleksandar,
> >
> > Do you mean
> >
> >> Manifest-Version: 1.0
> >> Ant-Version: Apache Ant 1.10.9
> >> Created-By: 11.0.2+9 (Oracle Corporation)
> >> SWT-OS: linux
> >> SWT-WS: gtk
> >> SWT-Arch: x86_64
> >> Implementation-Version: 3.113.0
> >
> > Should I find there something like "4.16"? The version.txt still shows
> > "version 4.940". It's all a little bit confusing.
> >
> > --
> > Best regards,
> > Thomas Singer
> >
> >
> >
> > On 2020-10-15 16:04, Aleksandar Kurtakov wrote:
> >> Thomas, would you please look at
> >>
> https://ci.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/1815/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/swt-I20201015-1352-gtk-linux-x86_64.zip
> >> and the swt.jar/manifest.mf in it. If this works for you I'll push and
> it
> >> will be available starting tomorrow build.
> >>
> >> On Thu, Oct 15, 2020 at 4:06 PM Aleksandar Kurtakov <
> akurt...@redhat.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Thu, Oct 15, 2020 at 3:28 PM Thomas Singer 
> wrote:
> >>>
> >>>> Hi Aleksander,
> >>>>
> >>>> Thanks for the link. Now the problem remains how to map between the
> >>>> content of the version.txt inside the org.eclipse*.jar to the
> >>>> Eclipse/SWT version. For example, my version.txt contains the
> >>>> information "version 4.940". Which is the corresponding Eclipse/SWT
> >>>> version?
> >>>>
> >>>
> >>> Frankly, this questions I can't easily answer. I've opened
> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=567906 to use
> >>> Implementation-Version in the manifest for that.
> >>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Thomas Singer
> >>>>
> >>>>
> >>>> On 2020-10-15 13:38, Aleksandar Kurtakov wrote:
> >>>>> On Thu, Oct 15, 2020 at 2:27 PM Thomas Singer 
> >>>> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> How can I find out which Eclipse/SWT release is supposed to support
> >>>>>> which platforms, especially which Linux versions? Thanks in advance.
> >>>>>>
> >>>>>
> >>>>> https://www.eclipse.org/swt/faq.php#gtkstartup - lists the mapping
> >>>> between
> >>>>> gtk and swt versions.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>

Re: [platform-dev] SWT - supported Linux versions

[Aleksandar Kurtakov]

Thomas, would you please look at
https://ci.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/1815/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/swt-I20201015-1352-gtk-linux-x86_64.zip
and the swt.jar/manifest.mf in it. If this works for you I'll push and it
will be available starting tomorrow build.

On Thu, Oct 15, 2020 at 4:06 PM Aleksandar Kurtakov 
wrote:

>
>
> On Thu, Oct 15, 2020 at 3:28 PM Thomas Singer  wrote:
>
>> Hi Aleksander,
>>
>> Thanks for the link. Now the problem remains how to map between the
>> content of the version.txt inside the org.eclipse*.jar to the
>> Eclipse/SWT version. For example, my version.txt contains the
>> information "version 4.940". Which is the corresponding Eclipse/SWT
>> version?
>>
>
> Frankly, this questions I can't easily answer. I've opened
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=567906 to use
> Implementation-Version in the manifest for that.
>
>>
>> --
>> Best regards,
>> Thomas Singer
>>
>>
>> On 2020-10-15 13:38, Aleksandar Kurtakov wrote:
>> > On Thu, Oct 15, 2020 at 2:27 PM Thomas Singer 
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> How can I find out which Eclipse/SWT release is supposed to support
>> >> which platforms, especially which Linux versions? Thanks in advance.
>> >>
>> >
>> > https://www.eclipse.org/swt/faq.php#gtkstartup - lists the mapping
>> between
>> > gtk and swt versions.
>> >
>> >
>> >>
>> >> Cheers,
>> >> Tom
>> >> ___
>> >> platform-dev mailing list
>> >> platform-dev@eclipse.org
>> >> To unsubscribe from this list, visit
>> >> https://www.eclipse.org/mailman/listinfo/platform-dev
>> >>
>> >>
>> >
>> >
>> > ___
>> > platform-dev mailing list
>> > platform-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>> >
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] SWT - supported Linux versions

[Aleksandar Kurtakov]

On Thu, Oct 15, 2020 at 3:28 PM Thomas Singer  wrote:

> Hi Aleksander,
>
> Thanks for the link. Now the problem remains how to map between the
> content of the version.txt inside the org.eclipse*.jar to the
> Eclipse/SWT version. For example, my version.txt contains the
> information "version 4.940". Which is the corresponding Eclipse/SWT
> version?
>

Frankly, this questions I can't easily answer. I've opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=567906 to use
Implementation-Version in the manifest for that.

>
> --
> Best regards,
> Thomas Singer
>
>
> On 2020-10-15 13:38, Aleksandar Kurtakov wrote:
> > On Thu, Oct 15, 2020 at 2:27 PM Thomas Singer 
> wrote:
> >
> >> Hi all,
> >>
> >> How can I find out which Eclipse/SWT release is supposed to support
> >> which platforms, especially which Linux versions? Thanks in advance.
> >>
> >
> > https://www.eclipse.org/swt/faq.php#gtkstartup - lists the mapping
> between
> > gtk and swt versions.
> >
> >
> >>
> >> Cheers,
> >> Tom
> >> ___
> >> platform-dev mailing list
> >> platform-dev@eclipse.org
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/platform-dev
> >>
> >>
> >
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] SWT - supported Linux versions

[Aleksandar Kurtakov]

On Thu, Oct 15, 2020 at 2:27 PM Thomas Singer  wrote:

> Hi all,
>
> How can I find out which Eclipse/SWT release is supposed to support
> which platforms, especially which Linux versions? Thanks in advance.
>

https://www.eclipse.org/swt/faq.php#gtkstartup - lists the mapping between
gtk and swt versions.


>
> Cheers,
> Tom
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>

-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Advertising 1 "trivial" bug a week

[Aleksandar Kurtakov]

On Tue, Oct 13, 2020 at 2:24 PM Mickael Istria  wrote:

> So it's already time for the conclusions:
>
> 3 tweets were sent with equivalent wording and different bugs; they
> received a roughly similar amount of reactions (between 25 and 40
> likes/RTs).
> Only the 1st one attracted a new contributor who got a patch merged.
> However, both other bugs got totally ignored, no reaction took place on
> Bugzilla.
>
> My guess is that the next issues are less trivial and require some
> pre-existing understanding of some Eclipse Plugin development. I believe
> that the technical bar to fix the issues is already too high for the
> @EclipseJavaIDE twitter audience.
>
> Negative side: Eclipse SDK doesn't have many really trivial issues in the
> pipe; or at least not in an easily identifiable way. Finding 3 "affordable"
> issues required some triaging effort from several contributors, and the
> result is not so positive for at least 2 of them. The "bugday" and
> "helpwanted" keywords don't help here.
> If we want to continue such a campaign, I believe we need more trivial
> fixes. But this experiment has highlighted that the backlog doesn't contain
> enough easy fixes and that finding one is taking a lot of time and energy
> to some contributors. The approach of digging for an easy enough fix is too
> expensive IMO. So regularly spending this time in finding 1 easy bug and
> planning such tweets on a regular basis is IMO not profitable/sustainable;
> and should be discarded for the moment.
> Positive side: However, we also had a "demonstration by example" (with the
> very poor reliability of such demonstrations ;) that going social on
> simplest bugs can attract new contributors. That's quite important to know
> that.
>
> My proposal to carry on on this topic is that instead of planning tweets
> and crawling the backlog for a trivial fix (which may not exist), we
> instead switch to a "push" model, where some experienced contributor who
> identifies a trivial fix should immediately share a Bugzilla link
> with @EclipseJavaIDE owners so they then plan an #easyFix tweet for it and
> hopefully attract a new contributor like it happened with this campaign.
>

Did we manage to get more interest from the person that fixed the first
issue? IMHO this is important when we evaluate the importance of the
program.


> What do you think?
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse and Equinox 2020-12 (4.18) M1a is available

[Aleksandar Kurtakov]

We are pleased to announce that 2020-12 M1a is available for download
and updates.

Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.18M1a-202010120320/

New and Noteworthy:
https://www.eclipse.org/eclipse/news/4.18/

Update existing (non-production) installs:
https://download.eclipse.org/eclipse/updates/4.18milestones/

Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18M1a-202010120320/

Equinox specific downloads:
https://download.eclipse.org/equinox/drops/S-4.18M1a-202010120320/



Thank you to everyone who made this checkpoint possible.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse and Equinox 2020-12 (4.18) M1 is available

[Aleksandar Kurtakov]

On Fri, Oct 9, 2020 at 12:07 PM laksono  wrote:

> I saw ARM binaries in the repository. Is ARM now officially supported?
>

ARM on linux is here since 4.17 release.  It's fully functional with some
small limitations like system password manager integration. Officially
supported combinations are listed at
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_17.xml#target_environments
and ARM is not there.In order to make it "officially" supported we need the
ARM community to step up and do basic verifications checks for our
milestones, RCs and releases.
Try and enjoy using it!


>
> Laksono Adhianto
>
>
> On Fri, Oct 9, 2020 at 1:37 AM Aleksandar Kurtakov 
> wrote:
>
>> Hi,
>>
>> We are pleased to announce that 2020-12 M1 is available for download and 
>> updates.
>>
>>  Eclipse downloads:
>>  
>> https://download.eclipse.org/eclipse/downloads/drops4/S-4.18M1-202010071800/
>>
>>  New and Noteworthy:
>>  https://www.eclipse.org/eclipse/news/4.18/
>>
>>  Update existing (non-production) installs:
>>  https://download.eclipse.org/eclipse/updates/4.18milestones/
>>
>>  Specific repository good for building against:
>>  
>> https://download.eclipse.org/eclipse/updates/4.18milestones/S-4.18M1-202010071800/
>>
>>  Equinox specific downloads:
>>  https://download.eclipse.org/equinox/drops/S-4.18M1-202010071800/
>>
>>
>>
>> Thank you to everyone who made this checkpoint possible.
>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev