| Re: [escet-dev] Eclipse ESCET v0.2 plans |
|
Hai Dennis,
The idea is still to release pretty much everything of the code wirtten in the rijkswaterstaat project to here. However, I am not the person that controls what code goes first. Plc code generator should go first, was decided.
That's fine, except it's not finished, let alone tested in practice, documented, etc. In fact, from reports that I heard last week of previous efforts, it may be even less finished than I thought it was.
I am working on this thing now; I don't see other options currently.
As for release plans, I think it would be useful to take a few steps back.
We should start with properly setting up our communications within the project. A handful of people read this, about half of the project members involved in the project, and with the long-term deciding people pretty much completey missing afaik. Discussion
here doesn't serve much purpose for the long term project plans currently, so that needs to be fixed first imho.
Secondly, I feel the current approach is a bit too small. You seem to have a good grasp of what to aim for, but I think not everybody has thought that far. As a result, the discussion isn't quite happening. In other words, deciding for 0.2, without knowing
how long it takes before 0.2 finishes, or what we will do in 0.3, 0.4, etc, makes deciding unnecessary hard imho.
I consider the path in front of us is all dark ahead. We brought some lights in the form of ideas that we should do, or code that has been written, but asking what lights to use to get to the 0.2 bridge is difficult without having a more global view of
how many bridges we wil aim for, or how long it takes before we will reach the next bridge. I think it will be simpler to make decisions if we have some basic decisions about the road ahead in general first, and then discuss and decide about sprinkling some
of the lights further down the road, 1 or 2 or perhaps 3 bridges ahead. In that way the road ahead isn't completely black, there are some small lights along the road that we can adjust later, or add some more lights/additions at the darker spots, etc.
A general property of the road that should be decided project-wide is whether we aim for time-based releaes (fixed number of time steps between bridges), or feature-based releases (number of lights between the bridges), or some mix of both.
Also, I think we should try to make a multi-release plan instead of just for 0.2, at least as a sketch. In that way we can write a trajectory of development steps and probably get more balanced releases.
Last but not least, I just wrote the above without discussing it with others in the project. As such, these are just my ideas how toproceed. First thing to do is to agree project wide how to go about setting up a release plan, perhaps.
Albert
From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Tuesday, April 20, 2021 18:52 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans
Hi Albert,
The Eclipse IDE gets 4 releases a year these days. But that is of no consequence. We can decide ourselves how often we want to release as a project, and how often we want to update to new Eclipse IDE versions.
Do your statements mean that you don't want to contribute anything to Eclipse ESCET v0.2 from the work that was done at Rijkswaterstaat? Do you have an overview of what was done there and you want to contribute to the Eclipse ESCET project at some point? I
imagine in the end you want to contribute as much as possible back, to ensure there aren't two versions that will diverge more and more?
What do you want to work on for this release besides the rail generator?
Regarding #63 (rail generator): see my comments on that issue.
Regarding the application framework helper. That is not so much for use in Eclipse ESCET. That was more meant for the work I'm doing in my day job, where we simply want to make it easier to consume CIF functionality. Splitting the applicatoin from the 'library'
as I proposed would not be much more than moving some code from some of the application's main functions to some static methods. I was proposing very small changes there. It would still use the options from the option framework, etc. Really separating everything
may be good as well, but is much more work, and should probably be done tool by tool. Note that some functionality, such as CIF to CIF transformations (I think), are already plain Java.
For the rail generator: it can just be plain Java if that suits our current needs. It is not meant to be used by end users for now anyway, I think.
Dennis
Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: dinsdag 20 april 2021 17:54 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] Eclipse ESCET v0.2 plans
Hello Dennis,
Pascal wondered how often there is a release. I know it was once a year, but remember hearing it was more often now, but not sure.
My guess is that we as project can decide that (at least wrt new additions).
Pascal is currently deeply buried in work, it took more than a week to get a very short reply. So at this point, I don't expect further input from him.
I got agreement for the things I already mentioned. There was also the wish for a new plc code generator to be added, but that is still quite wip, so I cannot promise that to be ready. (And even if it is finished, likely it is better to first have it used for
a while rather than adding code of such complexity that has never been practically used.)
Ferdie is doing the simulator fixes (or have been done already). I haven't looked at other fixes that we may have. We don't have many though.
Yesterday I added the rail program code in a branch (issue 63). Wrote some things in the issue that should be dealt with.
At least the Chi diagrams will be done after that (I should have them somewhere iirc, otherwise the rail input language is compatible so can be done quickly), diagrams of cif and tooldef would be nice too I think, but let's see. Wiring the generator into the
build process may be more complicated.
For mcrl2, likely we should ask Michel, he might have other things to be added.
I fully agree with splitting the functionality from the application framework, although I had a slightly different idea about it. I was/am splitting code in a generic library part, the application functionality, and the IO application part. This works well
for algorithmic code where you have very little interaction with the user. For applications with more interactions, your helper idea could be useful.
For example, the rail diagram generator doesn't quite need the application framework at all, and Eclipse integration isn't of much use either. Pure plain Java would be mostly sufficient already.
From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, April 19, 2021 18:05 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans
Hi Albert,
> As for other things, I'll discuss that with Pascal.
Did you discuss this already? It would be great to finalize the scope of the release, such that we can also disucss the release date.
Dennis
Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: zaterdag 10 april 2021 17:36 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] Eclipse ESCET v0.2 plans
Hi all,
I've created a whole bunch of issues in GitLab for the v0.2 release.
> I have 3 fixes for the CIF simulator, 2 of them based on old issues. Will dig up the details next week.
I think you can add these directly to GitLab without discussing here. Note that I created several issues for known bugs as well, so maybe
it is now already there.
> I also have written a railroad diagram generator (a nice
constraint solver puzzle) that can be added under the assumption I get permission.
Please
add a GitLab issue for this as well, once you know.
Permission from whom?
> As for other things, I'll discuss that with Pascal.
OK, let us know here on the list what your ideas are. Depending
on how much it is and what it is, this may also influence the discussion regarding the release date for v0.2. We should have this discussion after the scope of the release is clear.
>
One thing that's going to come up often is author of the contributions. Obviously, for code that I wrote, it's simple. For code and patches written by PhD students, it may be simple too but let's discuss that to be sure. My
idea here is, that they wrote that code while being employed by the university, so the university owns that code. The university also has a general agreement with Eclipse, and I commit under the same agreement that would be sufficient?
I
don't know. I think we should ask the Eclipse Foundation legal team about this, just to be sure. Could you ask this question to license@xxxxxxxxxxx with CC to this list?
> Is
there stuff on the todo list of the initial contribution that fell off, which may be useful to do?
Yes, there is. I put most of it in GitLab issues for v0.2. There are some issues in the old issue system that have only a title without details, no example models
to show the issue, not enough details for me to understand what it is about, and/or I'm not sure it is still relevant. It concerns:
Some of the other things that remain are quite a bit of work. I propose to delay them till a next release. We can't do everything at once after all. This includes:
The remaining issues appear to me to be either obsolete or random ideas that we could always recreate should they become relevant
(again).
Dennis
Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: dinsdag 6 april 2021 10:11 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] Eclipse ESCET v0.2 plans
Is there stuff on the todo list of the initial contribution that fell off, which may be useful to do?
At least there is documentation that needs to be written iirc.
Albert
From: Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Sent: Sunday, April 4, 2021 09:47 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans
I have 3 fixes for the CIF simulator, 2 of them based on old issues. Will dig up the details next week.
I also have written a railroad diagram generator (a nice constraint solver puzzle) that can be added under the assumption I get permission.
As for other things, I 'll discuss that with Pascal.
One thing that's going to come up often is author of the contributions. Obviously, for code that I wrote, it's simple. For code and patches written by PhD students, it may be simple too but let's discuss that to be sure.
My idea here is, that they wrote that code while being employed by the university, so the university owns that code. The university also has a general agreement with Eclipse, and I commit under the same agreement that would be sufficient?
Albert
From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Beek, Bert van <D.A.v.Beek@xxxxxx>
Sent: Friday, April 2, 2021 15:07 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] Eclipse ESCET v0.2 plans Hi Dennis,
I have been thinking about this already before you send us this email, but your suggestions cover my ideas for the full 100% and even add more, so I really have nothing more to add. Thanks! Bert > On 1 Apr 2021, at 17:41, Dennis Hendriks <dh_tue@xxxxxxxxxxx> wrote: > > Hi all, > > We've released our first release v0.1. I think we should look at the next steps, i.e. release v0.2. I propose to first identify the big parts that we want to work on for this release. > > To kick off the discussion, I'll indicate my ideas here: > > Dependencies, product, build, etc: > • Include JDK in product again, using JustJ Java releases. Less installation steps. All users have the same Java version. > • Update to Eclipse 2021-03. To keep current and to enable using JustJ. > • Update to latest Java LTS release (currently Java 11). There are no JustJ releases for Java 8. Also Java 8 is (mostly) end of life. > • Use the new Eclipse CBI macOS notarization service, add entitlements, package as .dmg file. > • Customize welcome screen, with links to help, examples, different tools, web links, changelog, etc. > • Crash report should indicate where to report issues. > • Add test code coverage reports to build. > > Website/documentation: > • Generate multiple HTML pages instead of a single HTML page. More stable URLs, not so long pages, etc. > • Website landing pages separate from AsciiDoc-generated documentation. Landing page should be attractive and allow easy navigation, etc. > • Improve documentation style, enable syntax highlighting, etc. > • Reconsider project metadata and project home page, also in relation to the website. Reduce text there and refer to (various parts of) the website instead. > > Other: > • Address known bugs and performance issues. This includes some of the issues in the old TU/e issue tracker, and some new ones I encountered myself more recently. > • Make it easier to use/call CIF functionality from code. E.g. separate CIF applications from their functionality, helper functions to allow running code even if not invoked from application framework context, etc. > > Let me know what you think of these ideas. Also, I'm curious what you want to have in and work on for the next release. > > Dennis > _______________________________________________ > escet-dev mailing list > escet-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://eur02.safelinks.protection.outlook.com/?url=""> _______________________________________________ escet-dev mailing list escet-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://eur02.safelinks.protection.outlook.com/?url=""> |