Community
Participate
Working Groups
After I fixed bug 362032, I compared the docs from 3.8 and 4.3 I-builds. After ignoring lines matching the regexp ... (<!-- Generated by javadoc|<META NAME="date" CONTENT=|<b>Eclipse Platform</b><br>Release).* ..., there are still differences in about 20 files that look like missing updates in the master branch. Paul, shall I go ahead and commit the missing updates to master? (This will end up in 4.2.1 as well as 4.3, as I understand it.)
Yes please. I think javadoc fixes are fine for 4.2.1 PW
Sorry, this is not only about Javadoc as I initially thought. I found quite a few fixes that went into the stable stream of org.eclipse.ui.workbench (R3_7, R3_8) but didn't make it into master. Just to name a few: Bug 307201: 7ca7e5cfd216c0c6160fdc0c82e4964e48cccd8d Bug 309716: a5a593e93e39b07d11ffff30368938ddff226b48 Bug 227289: b0d098d18d5b55eeae63548b56081e8c7eeb5fb8 revert of Bug 201301: b7477c9a6fa5d9072c9b321cfae3a111822bd79b Bug 224703: f1909e88e09656e960a61709de5c8d5ab9c9a4a8 ... In the EGit History view, all these commits contain "master" and "origin/R3_8_maintenance" in the "Branches:" section, so it looks like someone already tried to merge these differences, but something went wrong. Marking as critical, since we don't know if we're missing critical fixes in the master branch. Someone has to make a diff between master and R3_8_maintenance of org.eclipse.ui.workbench and take over the missing pieces, such that the only remaining differences are e4-related.
This should be looked at for SR1.
I'm not doubting there's some issues, but let's review some terminology and the state of things (to clear up my confusion, if nothing else). First, I don't see a R3_8 tag or R4_2 tag for this repo. Am I missing it? Second, for 3.8, this repo, eclipse.platform.ui, used branch R3_development while 4.2 used master (directly, no "integration"). So, 1. Who is supposed to make the tags? 2. In remarks such as "few fixes that went into the stable stream of org.eclipse.ui.workbench (R3_7, R3_8) but didn't make it into master. Just to name a few: Bug 307201: 7ca7e5cfd216c0c6160fdc0c82e4964e48cccd8d What was really compared? I did a compare of master and R3_development and they seemed the same. Not sure if the fixes had already been "caught up", or if something else is being compared. Just trying to clarify. Thanks,
(In reply to comment #4) > First, I don't see a R3_8 tag or R4_2 tag for this repo. Am I missing it? How about: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tag/?id=R3_8 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tag/?id=R4_2
(In reply to comment #4) > What was really compared? I did a compare of master and R3_development and they > seemed the same. I guess your repo is not in sync with eclipse.org. I compared master of org.eclipse.ui.workbench with origin/R3_8_maintenance (or origin/R3_development, it's almost the same). Note that local branches are only up-to-date in EGit after you've switched to the branch and then did a Pull. E.g. if you have master and R3_development in your workspace and do a Pull, then you can NOT use the plain name of the other branch to perform a comparison. You have to use origin/<branchname> or first switch to the other branch and pull that one first.
Thanks for the persistent, patient clarifications. As a result, I discovered I had an old "git-hub" version of that repo in my workspace. Sheesh.
(In reply to comment #2) > Sorry, this is not only about Javadoc as I initially thought. I found quite a > few fixes that went into the stable stream of org.eclipse.ui.workbench (R3_7, > R3_8) but didn't make it into master. All of the fixes that went into 3.8 R3_development should be accounted for (unless they were workbench specific fixes). But yes, there are fixes that went into 3.6 and 3.7 that are not currently in master, like the ones listed in comment #2 I was able to find specific bugs that were re-opened to be re-included in master, but wasn't able to find a bug that listed the comparison still to be done except bug 359616 comment #2 and bug 328935 PW
Defered to 4.3
*** Bug 396203 has been marked as a duplicate of this bug. ***
Done: Bug 270007: 1d1287d1196cdf0718c8b0777b9fa14550e417cb Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=77ffe2da1b8b790d0516a8fc6cd170b3d25b6560 Bug 344654 - [EditorMgmt] Editors should be able to treat large files specially (e.g. deny opening huge files) - says doesn't apply to 4.x because no EditorManager. PW
Additional fixes needed: Bug 270007: 3c6a66556bd1b3b5d5c8f045f4cc3229c731277c
Created attachment 242346 [details] Log of Eclipse 3.5-3.7 fixes to check Still a manual process, but basically: check if it's in the 2 streams that were open at that time: 3.x: 45eed8f13946561bfe2192d7e7177ed5d3b68200..R3_7 4.x: v20110711-1709..R4_1 If there isn't a commit equivalent in each, then look at the 3.x change and check the code in HEAD PW
I'd like to finish the analysis in RC1, even if we defer the fixes as appropriate. PW
These bugs are missing from the 4.x Stream code: Bug 126429 Bug 340268 Bug 323431 Bug 340342 Bug 340656 Bug 297375 Bug 339227 Bug 338843 Bug 327396 Bug 333417 Bug 72556 Bug 335543 - possibly missing from e4 copy of this class as well Bug 313899 - missing from both regular and e4 copy Bug 188700 Bug 188652 Bug 333689
Created attachment 242815 [details] Log of Eclipse 3.5-3.7 fixes to check v2 As far as I got
I'm deferring this to 4.4.1. There's still a number of bugs to be checked. PW
Bug 117746 is a very important fix which should be applied with high priority.
A ClassCastException has been reintroduced into Luna as a result of Bug 428779. This problem had been previously fixed by Bug 315532.
(In reply to Kevin Milburn from comment #19) > A ClassCastException has been reintroduced into Luna as a result of Bug > 428779. This problem had been previously fixed by Bug 315532. This is not related to this bug report here. Can you please open a new bug with steps to reproduce the CCE? Thanks.
It seemed appropriate to flag it here as it's related to this task that the original code (from 3.6) was introduced into the 4.4 branch, while missing the subsequent bug that fixed the problem it created. Paul has already created Bug 438919 to track the problem.
(In reply to Paul Webster from comment #15) > These bugs are missing from the 4.x Stream code: > > Bug 126429 > Bug 340268 > Bug 323431 > Bug 340342 > Bug 340656 > Bug 297375 > Bug 339227 > Bug 338843 > Bug 327396 > Bug 333417 > Bug 72556 > Bug 335543 - possibly missing from e4 copy of this class as well > Bug 313899 - missing from both regular and e4 copy > Bug 188700 > Bug 188652 > Bug 333689 The short summary after going over the list: The following bugs seem to be not valid for 4.x: Bug 338843 and Bug 72556 The following bug has been already ported to 4.x: Bug 333417 The following bugs waiting for the CLA form of the contributor: Bug 439988, Bug 335543, Bug 188700, Bug 440328 The following bugs are minor and we don't want to port it to the 4.4.1 (however some of them have been pushed to the 4.5): Bug 340656, Bug 339227, Bug 188652 The rest of the bugs I'm going to push to the 4.4.1 branch in the next week after verifying ones in the master build Daniel
(In reply to Daniel Rolka from comment #22) > The following bugs seem to be not valid for 4.x: > Bug 338843 and Bug 72556 Bug 72556 is still valid. I just tried this out by adding a few mnemonics to EGit's uitext.properties like this: CommitEditorPage_SectionBranches=Bran&ches ({0}) CommitEditorPage_SectionMessage=Mess&age StagingView_Committer=&Committer: StagingView_Author=&Author: Alt+C and Alt+A always go to the commit editor even if the Git Staging view has focus. In the plugin.xml editor, "Extension Points" tab, the &Delete button also has a mnemonic that shows the bug. > The following bugs waiting for the CLA form of the contributor: > Bug 439988, Bug 335543, Bug 188700, Bug 440328 There's no need for a CLA or anything. The code has already been included in Eclipse, and there's no re-checking required when moving it to a different branch. You can just add "Signed-off-by: <author>" to the commit to satisfy the automated checks that don't work for this workflow.
(In reply to Markus Keller from comment #23) > > The following bugs waiting for the CLA form of the contributor: > > Bug 439988, Bug 335543, Bug 188700, Bug 440328 > > There's no need for a CLA or anything. The code has already been included in > Eclipse, and there's no re-checking required when moving it to a different > branch. You can just add "Signed-off-by: <author>" to the commit to satisfy > the automated checks that don't work for this workflow. Daniel wants to upload Gerrit patches and there the tests are stronger than for direct push. Plus, even with direct push, it won't work if the author is not a committer, i.e. Daniel would have to replace the author with his own name. Just adding a signed-off would not allow to work around that check/restriction.
Moving to 4.4.2. Daniel, is there more planned than the remaining 3 open dependent bugs.
(In reply to Dani Megert from comment #25) > Moving to 4.4.2. > > Daniel, is there more planned than the remaining 3 open dependent bugs. There is still the list from the Comment 16 that we have to review. I started to work on it, but I switched to another item on my list. I'm going to return to the bug in 4.4.2, but I will work on it in the meantime Daniel
Just found bug 305231 that also didn't make it into E4. Fixed in master with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=32e112b3c317749aad3ff71974f96381196ebe1e
(In reply to Markus Keller from comment #27) Sorry, right link: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3d5377790b611a321b0b757bae1119d032fb99fe
I moved the bug to 4.5 since the patch for the Bug 74073 is not a trivial fix and it is too risky for 4.4.2 Daniel
(In reply to Daniel Rolka from comment #29) > I moved the bug to 4.5 since the patch for the Bug 74073 is not a trivial > fix and it is too risky for 4.4.2 > > Daniel I have detached the bugs that are too risky for 4.4.2 and we will try to work on it separately during 4.5. I will close the current umbrella bug since the vast majority of depended bugs get closed Daniel
(In reply to Daniel Rolka from comment #30) > I have detached the bugs that are too risky for 4.4.2 and we will try to > work on it separately during 4.5. I think you should update the target milestone for this then.
See comment #16 I don't think this bug is close to done. The dependent bugs that are closed are only as far as I got checking through the attached list. The rest of that work still has to be done (whether you do it on this bug or move the attachment to another umbrella bug is up to you). PW
(In reply to Paul Webster from comment #32) > See comment #16 > > I don't think this bug is close to done. The dependent bugs that are closed > are only as far as I got checking through the attached list. The rest of > that work still has to be done (whether you do it on this bug or move the > attachment to another umbrella bug is up to you). > > PW The bugs on this bugs (In reply to Paul Webster from comment #32) > See comment #16 > > I don't think this bug is close to done. The dependent bugs that are closed > are only as far as I got checking through the attached list. The rest of > that work still has to be done (whether you do it on this bug or move the > attachment to another umbrella bug is up to you). > > PW Daniel, please go through the list from comment 16 and identify those >= 'major' and missing. We should focus on those.
Last comment is from 2014 and I don't think anyone is still working on this. Please reopen if that is not true.
