Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 21 08:49
    ShalokShalom commented #7454
  • Sep 21 08:48
    ShalokShalom commented #7454
  • Sep 21 08:47
    ShalokShalom commented #7454
  • Sep 21 08:46
    ShalokShalom commented #7454
  • Sep 21 08:45
    momomo commented #7454
  • Sep 21 08:44
    ShalokShalom commented #7454
  • Sep 21 08:43
    ShalokShalom commented #7454
  • Sep 21 08:20
    luolong commented #7454
  • Sep 20 13:49
    ShalokShalom commented #7454
  • Sep 20 13:36
    momomo commented #7454
  • Sep 20 13:30
    ShalokShalom commented #7454
  • Sep 20 13:18
    momomo commented #7454
  • Sep 20 13:17
    momomo commented #7454
  • Sep 20 12:51
    ShalokShalom commented #7454
  • Sep 20 11:17
    Voiteh commented #7454
  • Sep 19 16:51
    ShalokShalom commented #7454
  • Sep 19 15:53
    msx80 commented #7454
  • Sep 19 15:31
    momomo commented #7454
  • Sep 19 15:30
    momomo commented #7454
  • Sep 19 15:29
    momomo commented #7454
fill0llif
@fill0llif
Wojciech Potiopa
@Voiteh
If anyone could give me a hand here eclipse/ceylon#7460 we could finish before end of march
There is 115 commits left
fill0llif
@fill0llif

If anyone could give me a hand here eclipse/ceylon#7460 we could finish before end of march

I just pick a commit on the _old/master branch straight from github and review it, right? And then put the info in the list, like every other commit that has already been reviewed there, right? Does it require me some specific knowledge? I believe it would get me a certain amount of time anyway

Wojciech Potiopa
@Voiteh
Well it would be good to have some knowledge of what happening in the code but for me it is not always the case. Those commits I mark with ! as when I'm not sure what is there and is it introducing backward compatiblity break. Most of commits are readable if You know Java. Dev team also made most of them obvious through the commit message and metadata on github tickets with labels and description.
If You don't know what happening in the commit just take next one, it sometimes is understadable after reviewing few what was happening in the first one, again from commit message or reference to the ticket
Wojciech Potiopa
@Voiteh
13 commits left !
Pedro Lamarão
@pedrolamarao
Thanks your your hard work!
Wojciech Potiopa
@Voiteh
I guess I finished
there are bunch of commits marked with !
that I'm not sure what they does as no refernce to issue or detail description is present
there is also one with !!! that it needs to be changed before relase (version changes from 1.4.0 to 1.3.4 needs to be done)
@jvasileff If You could look into it, would be perfect
Wojciech Potiopa
@Voiteh

So I created release branch https://github.com/Voiteh/ceylon/tree/release/1.3.4 and successfully merged content from _old/master up to 4c45a73508 with exclusions of

 - breaking changes

and

! not sure

I used patches as change carriers, but this is not good way as after few I got lost which one has been applied and which one not. Still the code compiles. I compiled simple program with it and it runs .
It is around half the way. Begging with a130339d4athere starts problems, with merge. It may be that some changes was ignored in previous commits

Wojciech Potiopa
@Voiteh
Ok this time I merged up to d2fb43c73c this is pre last commit before eclipse-renaming ant clean dist finishes succesfully for merge. I used Intellij and cherry picking. Rest must be merged manually :/
Wojciech Potiopa
@Voiteh
Up to 44b9436cfd 11 to go
Wojciech Potiopa
@Voiteh
@jvasileff Do we need to do the same work in sdk ? I looked into some commits and there were changes in api for ceylon.interop.persistance probably we should exclude those commits from release?
Roland Tepp
@luolong
I suppose, yes. Similar work needs to be done for SDK
Wojciech Potiopa
@Voiteh
ok I'll take care of that after finish with with ceylon repo
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