!can You check them I don't seem to understand everything there. I'm in 1/3 of the list...
https://github.com/eclipse/ceylon/blob/master/dist/BUILD.mdbut trying to clone the repository I'm having this error
error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: the remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed
@fill0llif try cloning using git protocol:
It worked, thanks!
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
!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.
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
! 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
mvcommands and regular expressions, so can be applied on top of other work
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.
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).
Determine TODO list of items necessary for an initial release to be made (IP, website, infrastructure, governance, etc.)