Community
Participate
Working Groups
Please enable gerrit on your repos. Instructions: https://wiki.eclipse.org/WTP_Gerrit_Access
Hello Team, Any update on this ? Thanks Vaninder
Carl, can you approve the Gerrit setup for WTP commons?
I heard from Carl that this bug requires merging the four webtools.common repos into one. This is a pretty difficult task in general and has a lot of different ways to do it. Over the weekend I came up with a script that would accomplish it. https://gist.github.com/robstryker/e4fcf32cac3fc5cff7f6d8e31b138566 The gist outlines what it's doing, how it's resolving conflicts, how it's handling tags and branches, etc. I knew when writing it there's a chance nobody even pays attention to it, but, if merging the four repos is really a requirement of getting gerrit set up, then I think this should be given some real discussion here. I can modify the script if we have issues with how it's doing stuff, and I'll have nick boldt assisting me in adding a pom and getting it building in an example job ASAP... WTP has friends. We want to help :D
Hotbug request: 1. Affiliation: Red Hat / Eclipse m2e-WTP / Fuse Tooling 2. Which release: in a 3.8.x stream and if possible integrated in a Neon.3 patch release. 3. Reasons of high priority: - This bug is a regression compared to Neon.2 which is affecting several products including the Eclipse projects m2e-wtp. - There is no workaround working for every cases. - When bug encountered the application is frozen Please note that 2 mails has been sent to wtp-pmc mailing-list: https://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg02350.html
@aurelien: are you sure this is the bug for hotbug? or was that Bug 511793 ?
effectively, stupid of me Thanks for having reported the hotbug request on the right one
https://github.com/robstryker/webtools.common.all This is a branch created with my script. It merges tags and branches that are common to multiple branches. Downside is it rewrites history and changes old sha's.
(In reply to Rob Stryker from comment #3) > I heard from Carl that this bug requires merging the four webtools.common > repos into one. Why is that?
I suspect it's just that he already has plans to merge the four repos, and doesn't want to enable gerrit against 4 individual repos that will soon disappear? So better to merge the repos first, and then enable gerrit on just the one? You'd have to ask him for more information, but it makes sense to me.
> that will soon disappear? Sorry, I mean 'that soon won't receive many patches or updates". I think the plan is to leave the repos existing as legacy.
The script to generate the new repo, and apply some patches, are here: https://github.com/robstryker/webtools.common.all.create/ Victor and I have validated the script functions as intended. It then applies the two patches listed. We can add to the patch list if necessary, or remove some from it and apply them post-merge. One patch is the critical dependency graph issue, which I guess can be applied post-merge. The other is all the pom.xml necessities to make the repo usable. The pom.xml patch has a complication in it: in order to get the stuff to build, we needed to have the wst validation tests depend on jst. We recognize this is verboten, but I think the best thing to do is solve that issue immediately post-merge. I think the issue here is that the test already depends on the jst layer being there, so either the test is misplaced and belongs in the jst layer, or there already is an effective dependency from wst on jst in this test case, and so making it explicit should not be an issue. https://bugs.eclipse.org/bugs/show_bug.cgi?id=515948 As part of this process, Victor strongly recommends (and I concur) adding the R3_8_maintenance branch to repos that do not have it and are currently building out of master. This will ensure the 3.8 branch is complete. Older branches do not need to be complete / buildable, and will instead stay as an accurate representation of the state of the repo at merge-time.
I think the requirements are overevaluated. There is no reason to make the move to Gerrit requiring such refactorings. Can't we solve the issues separately and get this one moving forward ASAP. Contributing to those parts of WTP has been a nightmare for years compared to other Eclipse.org project.
(In reply to Mickael Istria from comment #12) > I think the requirements are overevaluated. There is no reason to make the > move to Gerrit requiring such refactorings. Can't we solve the issues > separately and get this one moving forward ASAP. Contributing to those parts > of WTP has been a nightmare for years compared to other Eclipse.org project. We're moving ahead now with the merge, as soon as we get infrastructure support we need, expected in the next week. Gerrit will come immediately thereafter.
(In reply to Rob Stryker from comment #13) > We're moving ahead now with the merge, as soon as we get infrastructure > support we need, expected in the next week. Gerrit will come immediately > thereafter. It's been a couple of weeks since you wrote this. Is anything still a blocker? At this point, wouldn't it be more efficient to first move to Gerrit (takes a few hours for webmaster) and then consider refactorings?
Still nothing on this topic? Should we get in touch with EMO to enforce this change? It's been requested for years, and the overall message of the Community/Foundation is to strongly recommend Gerrit or other review software; why would WTP be the exception there? It has prevented some people to efficiently contribute to the project, I don't think ignoring or delaying this is acceptable if WTP wants to remain a relatively sustainable project.
Mickael, the merge of WTP Common repositories just happened before RC1. Now that RC1 is declared, we are ready to request that Gerrit be enabled on the webtools.common repository.
(In reply to Carl Anderson from comment #16) > Mickael, the merge of WTP Common repositories just happened before RC1. > Now that RC1 is declared, we are ready to request that Gerrit be enabled on > the webtools.common repository. Is it done?
Webmaster, Please enable Gerrit on the following repository: gitroot/webtools-common/webtools.common.git
@Webmaster: We have a lot of people requesting this. Any chance it can move ahead?
Done! Your committers will need to update their URLs for this repo to: ssh://committer_id@git.eclipse.org:29418/webtools-common/webtools.common or https://committer_id@git.eclipse.org/r/a/webtools-common/webtools.common Committers can push directly to master and bypass code review by pushing to refs/heads/master Contributors and committers must push to refs/for/master to trigger code review. -M.
