by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 03:21
    kingjon3377 opened #7465
  • Jun 02 17:07
    baberrehman edited #7464
  • Jun 02 17:01
    baberrehman opened #7464
  • May 25 15:03

    jvasileff on master

    Use https in CMR for maven cent… Merge pull request #7463 from V… (compare)

  • May 25 15:03
    jvasileff closed #7463
  • May 25 15:03
    jvasileff commented #7463
  • May 21 15:25
    Chocohead commented #7463
  • May 06 10:32
    davidfestal commented #7463
  • Apr 27 18:37
    Voiteh opened #7463
  • Apr 27 18:34
    Voiteh opened #7462
  • Apr 25 15:11
    Voiteh commented #7454
  • Apr 25 15:09
    Voiteh commented #7454
  • Apr 24 21:48
    momomo commented #7454
  • Apr 24 21:46
    momomo commented #7454
  • Apr 24 18:28
    Voiteh edited #7461
  • Apr 24 18:16
    Voiteh commented #7454
  • Apr 24 17:30
    momomo commented #7454
  • Apr 13 21:37
    Voiteh edited #7461
  • Apr 08 19:44
    Voiteh edited #7461
  • Apr 02 17:53
    Voiteh opened #7461
Wojciech Potiopa
@Voiteh
as we don't know if all our effort is not useless as Eclipse may not accept other package naming
John Vasileff
@jvasileff
I hate that the Eclipse foundation transfer work was not done independent of new, breaking dev work
Wojciech Potiopa
@Voiteh
than org.eclipse.ceylon
In my opinion we should release without Eclipse (if we can) as it doesn't give us any value (I don't see it)
John Vasileff
@jvasileff
There's such a strong technical argument though for allowing use of the redhat name, that hopefully they would agree. There just isn't enough activity to support a breaking release right now
Well, anyone can put up a non-official release on GitHub, in fact that's exactly what I did with the Maven-url fix build
But representing that as official, or trying to have the website point to a non-Eclipse build I'm sure would cause problems
Wojciech Potiopa
@Voiteh
Do anyone knows how to contact responsible person from Eclipse foundation ?
We are mostly stuck because of this transition
John Vasileff
@jvasileff
I do not. I think the first step for anyone interested in being a liaison would be to reach out to Stéphane Épardaud (FroMage) as I think he did most of the work with Eclipse
Wojciech Potiopa
@Voiteh
I saw him active on this chat few hours ago :D
Wojciech Potiopa
@Voiteh
I'll try to contact him and handle Eclispe things but I would require some assistance in this, what should I ask and how much information i can share with Eclipse
John Vasileff
@jvasileff
I'm not sure I understand the question correctly, but there's nothing we would not want to share. Ceylon is an Eclipse project, so we are all on the same team
I think the known issues are, broadly:
  1. Resolve concerns with use of the *.redhat.com package namespace where necessary to maintain backwards compatibility. Most of the necessary usage is internal, but may be exposed to end users in some cases.

  2. Resolve (possible) IP concerns with unwanted commits that are present in the "root" Eclipse foundation commit. Technical challenges remain, but we can perhaps a) build a new branch by cherry-picking commits we want to keep, or b) accept the current "root", and revert commits we don't want to keep. There are technical downsides to both (e.g. difficulty of revert pre-rename commits, difficulty of future inclusion of currently unwanted commits).

  3. Determine TODO list of items necessary for an initial release to be made (IP, website, infrastructure, governance, etc.)

Wojciech Potiopa
@Voiteh
Yeah that was the qiestion about. By IP you mean Intellectual Property?
John Vasileff
@jvasileff
Yes. (and perhaps other concerns like prophanity in comments)
Enrique Zamudio
@chochos
But I worked so hard on that prophanity! How dare you erase my life's work!
John Vasileff
@jvasileff
I don't believe you @chochos, it seems to flow freely in your code lol
Wojciech Potiopa
@Voiteh
I found a nice way of merging renamed files. If You git for a project is configured like
git config diff.renames true
git config diff.renamelimit 0
It finds renamed files and tries to merge them rather than subjecting old ones to be deleted and new ones as added
more into this here: https://stackoverflow.com/questions/22582605/git-merge-branches-with-different-directory-structures
Roland Tepp
@luolong
:+1:
Stéphane Épardaud
@FroMage
Guys, sorry to spoil the fun, but I'm sure Eclipse will not accept a release with non-eclipse package names
They told us that much from the start
We would not have renamed it otherwise
As for using the redhat package name for an independent release we would have to check that with our legal department first :(
I think it'd be really great if you could resume work on the Eclipse master branch, that would give you a better standing
Especially if Red Hat complains at the package name if you do another release, because in both cases you'll have to rename
Wojciech Potiopa
@Voiteh
In this case we should concentrate to provide minimal amount of changes and concentrate to provide only what has been finished and all breaking changes that were planed to be included. All other stuff should be excluded
Stéphane Épardaud
@FroMage
That's up to you
Wojciech Potiopa
@Voiteh
I think we should create release/1.4.0 branch from master and revert commits which are WIP and include minimal BC changes and fixes, so that we could work on it togather
Wojciech Potiopa
@Voiteh
we could have another issue like #7460 for tracking what commits we exclude/include
Roland Tepp
@luolong
:+1:
John Vasileff
@jvasileff

That’s too bad. My intention was to help create a backwards compatible release with minimal changes, primarily motivated by the Maven https issue, but also to create a base to (potentially) build on for additional preservation work, such as Java 9+ compatibility.

But, I didn’t realize that a making a compatible release within the Eclipse Foundation was totally out of the question. I’m not interested in forking the project (i.e. new website, branding, etc.), and I’m also not interested (at least for now) in spending time on a compatibility breaking release. IMHO, that would be much less valuable.

We do at least now have a working GitHub Actions build (https://github.com/eclipse/ceylon/actions?query=workflow%3Aintegration-build), so perhaps I’ll add a branch in my GitHub account to build the full 1.3.3 release + maven https url patch. I’m not sure what else there is left for me to do/offer at this point.

Wojciech Potiopa
@Voiteh
Alone I have no chance to prepare the release...
Wojciech Potiopa
@Voiteh
but I will try...
Kiti-nomad
@kiti-nomad
加油
Wojciech Potiopa
@Voiteh
@FroMage #7263 do You know if support for Java 9 has been compleated ? Should we include this into 1.4.0 ?
Stéphane Épardaud
@FroMage
according to this issue it was
Wojciech Potiopa
@Voiteh
I looked in all the commits of master branch and they seems all fine we need to decide what else would we want to have in 1.4.0
There are few other issues labeled with Breaking change
https://github.com/eclipse/ceylon/labels/breaking%20change I don't see in most of them the agreement that we wan't them to be included. Only #7409 this I see as includable.
momomo
@momomo
@Voiteh At this point I would not be too concerned with breaking changes. Is that more important than giving it a fresh start, even if that might break backwards compatibility for the few that have projects depending on it? The alternative is they might never have an update and would still continue to live with the version they are running now.
If mistakes were made in the language before, like Gavin has hinted, this might be an opputonity to fix them. I also don't know why so fuck focus was put into making ceylon code compile to javascript. i personally would not consider using it or any other language for that purpose.
Wojciech Potiopa
@Voiteh
@momomo We have minor version change so it would be good to include all the breaking changes into the release, that we agree on. Then in 1.4.x fixes we would just improve what would need to be, as bugs naturally occures. We are trying to give it a fresh start. As for JS, this wild beast need to be tamed somehow. I work in my daily job with Typescript and it's quirky . Kotlin - limited typing. Dart - didn't checked.
MikhailMalyutin
@MikhailMalyutin
@momomo Absolutely agree. It is almost impossible to force frontent javascript developer to use other language than javascript or at least Typescript. We use ceylon in production but in JVM backend only. Modern JS frontend is a very unstable thing, a lot of JS frameworks is created and died. Compiling to JS must be optional expererimental feature, most developers will never use it. But for JVM and backend development ceylon language was very good.
momomo
@momomo
Yes, it must have been an immense job and waste of time working on that. The best thing this project could do is to strip it bare, to a minimum to maintain and let community then build libraries for it. This is the best for maintainance later. Everything that is not essential I would recommend to just hit delete. If you don't, you will always have to maintain those parts for refactoring, always run those tests, always go into those code pieces that are irrelevant and just update minor things to make them continue to compile and test.
It is a time waster. I have lots of code, even for things i've rewritten in new better ways, and old projects. When my code base change, I still always have to go in and ensure those libraries and project doesn't get destroyed. So even when my code is improving, changing it now, i have to take into consideration all those old projects and libraries that I might or might not need in the future. But I keep thinking I might return to those projects but they do cost additional time.
momomo
@momomo
And i would do much better if I just was able to discard them.
Wojciech Potiopa
@Voiteh
Let's concentrate on this release first. Then we can think what we want to remove etc. Maybe we could find someone to maintain JS part.
Wojciech Potiopa
@Voiteh
Someone needs to review what is essential for release on IDE's part and on SDK. I can give more details if anyone interested
momomo
@momomo

I found this thread with Gavin commenting:

https://news.ycombinator.com/item?id=8437363

He traded off features in ceylon because they could not be ported to JS. What a mistake. Probably the biggest thing is to even having that as a priority or on the list at all.