Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 05 20:47
    ericdriggs commented #7454
  • Feb 11 03:56
    dependabot[bot] labeled #7472
  • Feb 11 03:56
    dependabot[bot] opened #7472
  • Feb 11 03:56

    dependabot[bot] on maven

    Bump json-smart from 1.3.1 to 1… (compare)

  • Feb 11 03:55
    dependabot[bot] labeled #135
  • Feb 11 03:55
    dependabot[bot] opened #135
  • Feb 11 03:55

    dependabot[bot] on maven

    Bump json-smart from 1.1.1 to 1… (compare)

  • Dec 08 2021 10:05
    supersache opened #7471
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:51
    l7rf1i82 commented #7464
  • Oct 01 2021 12:49
    l7rf1i82 commented #7464
  • Sep 30 2021 08:21
    l7rf1i82 closed #528
  • Sep 30 2021 08:21
    l7rf1i82 commented #528
  • Sep 29 2021 08:05
    l7rf1i82 opened #528
  • Sep 10 2021 06:34
    codeMonkey404 opened #671
  • Jun 19 2021 01:40
    kingjon3377 opened #527
  • Jun 19 2021 01:35
    kingjon3377 opened #526
  • Jun 04 2021 01:23

    dependabot[bot] on maven

    (compare)

  • Jun 04 2021 01:23
    dependabot[bot] closed #7456
  • Jun 04 2021 01:23
    dependabot[bot] commented #7456
John Vasileff
@jvasileff
@Voiteh looks like you've made a lot of progress. I haven't had a lot of time to work on this in a couple weeks, but I do have most of the renaming work done (I think), but the IDE isn't quite working yet with the renames. Renaming is done primarily with mv commands and regular expressions, so can be applied on top of other work
I hadn't considered the approach of rebuild a new branch by excluding commits (as opposed to using rollbacks.) I think we really need a volunteer to work with Eclipse to see what's acceptable from an IP standpoint.
Using rollback commits may be cleaner from an IP standpoint, because at least we would be building on the approved Eclipse "root" commit, and the new changes would be obvious. And, the full test suite for all projects could be run after each rollback, which could possibly help.
But the approach you have been taking would create a cleaner result. I just really don't know what's best or acceptable for Eclipse.
John Vasileff
@jvasileff
Either way, great work. Even if in the end we decide to go with a rollback approach, the work you've done to resolve conflicts and make things compile will be invaluable
Wojciech Potiopa
@Voiteh
Some commits were having changes which requires to manually copy the code to correct place in com.redhat.ceylon packages
so rollabacking would require additional effort to include the code again
John Vasileff
@jvasileff
Yeah, I thought about that. Really hard to rollback pre-rename commits on a post-rename branch
Wojciech Potiopa
@Voiteh
That is a bit of nuts
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.