Re: [embed-cdt-dev] Eclipse Common Build Infrastructure

[Liviu Ionescu <ilg@xxxxxxxxxx>]

In case the message was not clear enough, the next milestone is the 2020-03 and 2020-06 releases.

Joining SimRel is not an immediate concern, I just want to be sure that some decision we make now will not make joining SimRel more difficult in the future.

Also adding the Arm packages is planned for the 2020-09 release, if possible, not for now, but again, it is better to plan for this by now.



> On 22 Jul 2020, at 21:57, Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> wrote:
> 
> However I have concerns that we can engage the upcoming 2020-09... more realistic ... 2020-12

since I don't know yet how much effort will SimRel require, I don't have a target date, I just want to learn how to do it, and when ready, join it.

> I would think about another package inside the EPP project "Eclipse for Embedded Development", it looks more natural than forking EPP.

when ready, yes, we'll add a package there, but for the initial tests it might be faster to use the existing fork.

not to mention that I don't know how we'll test the Arm configurations; wouldn't that be easier with a fork of EPP?

> For the p2 URLs I don't think that we need to choose between developers and users. Usually projects support two structures:
> * the first is developers-oriented that can contain a lot of intermediate integration builds
> * the second is users-oriented that typically contains releases only.
> As a part of release procedure there is a Jenkins script to promote the binaries from the first to the second location.
> Also we can have composite update sites that will redirect users to a right internal structure.

I understand what you are saying, but I still don't know what would be a better way to organise the folders.

For the release URL, is the 'updates/neon' ok?

https://download.eclipse.org/embed-cdt/updates/neon


The workflow that I used in the last years included a pre-releases in v4-neon-updates-test, and give some users the chance to beta-test.

For this purpose, is the new 'updates/neon-test' url ok?

Those two URLs will be visible for the users, and are critical, since once we define them, they have to remain unchanged for long term.

The URLs for developers are less critical; I am open to any other suggestions.


> Please fulfill the https://projects.eclipse.org/projects/iot.embed-cdt/developer to let us understand the project resources better, this is especially important for those who does not have committer rights.

I don't know what I am expected to enter there. :-(

The developer information was planned to be part of the new web site.

---

Any other suggestions? 

When the Jenkins maintainers will fix the database/LDAP/etc and I'll be able to use it, I would like to start work on the builds, and for this I would need at least a go/no go from Jonah, preferably with suggestions to improve things.



Liviu