[tools.mylyn] Eclipse Mylyn restructuring review

changed due date to October 05, 2022

changed due date to October 19, 2022

@mmilinkovich we need your approval for this Eclipse Mylyn restructuring review:

The EMO is scheduling a restructuring review for the Mylyn TLP and its subprojects. As far as we can tell, these have been inactive for quite some time and the PMC seems to be dysfunctional. The proposal would be to collapse all projects into one the Eclipse Mylyn project and move it under the Eclipse Tools TLP.

Some people have demonstrated interest in trying to get the Mylyn projects back to life, so the EMO will be designating a new Project team to help during the bootstrapping process.

Approved

changed the description

added restructuring label

Great! I volunteer to lead the technical restructuring effort if no one else steps up.

I'm unsure whether I should state my intention to contribute to this: I have already said that in the cross-project-issues... but just in case

FWIW https://projects.eclipse.org/projects/mylyn.docs/ is functional, so how would that affect us? I would prefer the project to not be merged into mylyn until bringing it back to live proves to be successful?

I agree. Mylyn Docs is functional and mature. There are some subprojects within Mylyn Docs that are pretty much ready for retirement though. In any case I would like to help out keeping the EPUB code alive.

Would you recommend Mylyn Docs become a project under Tools TLP, or keep the Mylyn TLP?

I don't mind it either way as long as it's not merged in a yet-to-prove-being-alive project.

Staying subproject of Mylyn keeps the door open for merging (I believe we don't need so many projects!) when Mylyn is (hopefully) reborn.

I agree with Alex.

I don't think merging subprojects is a good idea at all at this stage. We already get a lot of work converting the sources to Github, reviving the builds, and making a new release.

I propose that the priority should be to make a new team for the projects that require it. If Mylyn docs is working then we should not restructure it.

In the long run, I suggest that the Mylyn projects that are alive should stay subprojects (under Tools/Mylyn). The others should be closed, stay subprojects under Tools/Mylyn, or merged into Tools/Mylyn. This is not to be done right now.

@jograham yes, for now, I recommend keeping it in the Mylyn TLP.

To be explicit this is the project structure you are proposing:

Eclipse Foundation
- Tools TLP
  - Eclipse Mylyn
    - Eclipse Mylyn Docs
      - Eclipse Visual Editor for XML
      - Mylyn Docs Intent
    - Mylyn Builds
    - Mylyn Commons
    - Mylyn Context
      - Model Focusing Tools
    - Mylyn Incubator
    - Mylyn Reviews
      - R4E (Review for Eclipse)
    - Mylyn Tasks
    - Mylyn Versions

I am +1 on that. And +1 on revisiting merging/closing projects in the future.

@jograham yes, for now, I recommend keeping it in the Mylyn TLP.

I think the EF folk use TLP to mean top-level project, i.e. one that is not under anything else. I don't know if there is a name for such a project type at the foundation, but Nebula is an example of such a project as it has sub-projects and lives under the Technology TLP.

Yes. Mylyn has its own TLP named Mylyn. I propose to keep it like that for now.

It does feel like we are having a difference of terminology around what a "TLP" is.

To be clear I am very happy with the project structure in #371 (comment 1017645) - but going forward we simply stop calling Mylyn a TLP as that has special meaning in the EDP.

I believe Mylyn became a TLP (like Tools, Technology, etc..) a couple of years ago. If this is not the case, then I apologize for the noise.

I believe Mylyn became a TLP (like Tools, Technology, etc..) a couple of years ago. If this is not the case, then I apologize for the noise.

Yes the above is correct.

But I really don't understand the purpose of this review then. This restructuring review was initially stated to collapse Mylyn and move it under Tools which you said yes to (#371 (comment 1017350)) Thank you for stepping up.

Following @akurtakov comments my understanding is that we don't want the projects to be collapsed (which I also agree with).

@mmilinkovich (in above comment) and Gunnar (in mylyn-pmc mailing list) have approved the restructure.

Is the plan now to cancel this restructuring review and leave the project structure as it is today?

I apologize for the noise.

I am helping with the noise - sorry about that. I just want to understand if the Tools PMC will be getting responsibility for Mylyn as the review says in the initial description.

Yes, I get it now. I did not read the whole body of the issue because I assumed it was about replacing project leads and committers. Moving the same structure to Tools is fine as long as it does not cause extra work reviving the project.

I think moving to Tools TLP is unneeded and it will be at least some extra work compared to keeping current structure. If, once things are up and running, Mylyn doesn't want to have its own PMC and the related responsibilities, I am sure the Tools PMC will welcome them with open arms!

I think replacing the project team is great (for the projects that need it). I don't think that needs a restructuring review though. IIUC the PMC + EMO can just do that, especially as the PMC is responsive enough with Gunnar.

The restructuring review that I was asked to approve said "The proposal would be to collapse all projects into one the Eclipse Mylyn project and move it under the Eclipse Tools TLP." Am I correct in believing that is no longer the intent? Assuming so I withdraw my approval and await a re-statement of what I am being asked to approve.

If there is no desire to disband the Mylyn top-level project and move the project under Tools, then I am uncertain as to whether a restructuring review is even required. Perhaps what is needed instead is a reboot of the Mylyn PMC, which has been dysfunctional for quite some time.

I think we should combine all projects into one, an exception could be Eclipse Mylyn Docs. With the small number of team members, there is no reason to separate responsibility for each part.

For example, I can commit to Mylyn Common, Mylyn Tasks and Mylyn Incubator, but not Mylyn Reviews, Mylyn Versions and Mylyn Build.

We can start by adding the new team to all projects and then merge projects one by one as we see fit.

I'm a bit worried that we take a lot of extra releng work when we move everything in one project from the start.

WDYT?

Merging projects doesn't mandate merging the git repos. So all git repos can stay the way they are but projects merged so there being a single team.

As @akurtakov states, restructuring the project will have no effect on the structure of the git repositories. I'm fairly certain that it should also have no impact on the CI instance.

The one important thing that collapsing the project hierarchy will give us is one single team of committers having uniform privileges on all of the repositories (which is not the case right now). That is, I think that just collapsing the project will make it easier on everybody.

From the EMO's perspective, the Eclipse Mylyn TLP ceased operating as a proper TLP some time ago and it's long past time to revoke the charter and shut down the TLP. We need to restructure the project; it's really only a matter of deciding the timing of the restructuring.

I believe that the EMO can effect this restructuring review without impacting the day-to-day work. This is complicated a bit by the stated intention to migrate respositories to GitHub, but we can make it work.

I recommend that we decide what we're going to do and move quickly so what we can get on to the work of moving to GitHub.

Here's my take:

We'll move Eclipse Mylyn (mylyn) to a Tools subproject (tools.mylyn)
To keep things simple, we'll take the union of all existing Eclipse Mylyn subproject committers as committers on the new "Tools" Mylyn.
We'll add new committers identified during this restructuring review to the new "Tools" Mylyn. I assume that we'll also need to identify some new project leads (correct me if I'm wrong).
We'll change ownership of all repositories under all Mylyn subprojects to the new "Tools" Mylyn.
We'll change ownership of all Bugzilla products and categories to the new "Tools" Mylyn.
We'll change ownership of the CI instance to the new "Tools" Mylyn.
Any new repositories the team decides to create (e.g., GitHub repositories) will be configured so that they are owned by the new "Tools" Mylyn.
The project leads may, at their leisure, retire committers who are no longer active.

So... I think that all we need is a list of who the new committers and project leads will be. We'll also need approval from the Tools PMC.

I'm thinking that just merging Mylyn Docs into the new project, and having all of its repositories just accessible to the whole team is the easiest way to go. Please correct me if I'm wrong.

Again, I'm pretty sure that we can do this without interrupting day-to-day work for more than a minute or two.

I agree with Wayne here. Keeping Mylyn as a TLP would just create too much overhead for a small team.

I'm thinking that just merging Mylyn Docs into the new project, and having all of its repositories just accessible to the whole team is the easiest way to go. Please correct me if I'm wrong.

I think that would work just fine. It would be practical to separate WikiText and EPUB into two separate Git repositories. But that is a different story.

Tools PMC (me speaking as chair) would be glad to welcome the project!

Regarding merging committers/projects (me speaking as mylyn.docs committer) - that is fine as long as it doesn't break real code work.

I agree with all your comments.

Next technical steps after reorg.

Open a Github Repo github.com/ Move to Github
Close Eclipse Git and Gerrit
Fix the builds
Close the forum (make it read only)
Open GitHub Discussions
Close Bugzilla
Open GitHub Issues
Create an Oomph Dev Environment setup (with the help of Ed)

From this point on, we can start the maintenance work.

Will bugzilla be migrated or do we want manual triage and reentry of existing bugs on github issues?

Prio 1 should be fixing the special depedencies Prio 2 a github issue connrctor to eat our own dogfood?

I agree with all your comments.

Next technical steps after reorg.

Open a Github Repo github.com/ Move to Github

Close Eclipse Git and Gerrit

Fix the builds

Close the forum (make it read only)

Open GitHub Discussions

Close Bugzilla

Open GitHub Issues

Create an Oomph Dev Environment setup (with the help of Ed)

From this point on, we can start the maintenance work.

We have unit tests using http://ci.mylyn.org where we have different Versions of Bugzilla, Jenkins, Hudson and Gerrit instances. Should we redeploy this service to a different URL or do we need to change the unit tests?

For local testing, we have a Vagrant setup. I have developed a not yet released version with Ansible and Docker.

Do we have the possibility to use such a setup for CI builds within Eclipse? Otherwise I would have to see if I can deploy and publish this within my domain.

Frank, we can ask the webmasters if they can provide this testing setup. We would need to have access to some server to run this on. I'm afraid that this is not something they provide.

@wbeaton were do we go from here?

... I mean, what are the next steps to follow up on #371 (comment 1017982)

@wjongman if you agree we'll follow the steps listed by @wbeaton in his previous comment:

We'll move Eclipse Mylyn (mylyn) to a Tools subproject (tools.mylyn)

To keep things simple, we'll take the union of all existing Eclipse Mylyn subproject committers as committers on the new "Tools" Mylyn.

We'll add new committers identified during this restructuring review to the new "Tools" Mylyn. I assume that we'll also need to identify some new project leads (correct me if I'm wrong).

We'll change ownership of all repositories under all Mylyn subprojects to the new "Tools" Mylyn.

We'll change ownership of all Bugzilla products and categories to the new "Tools" Mylyn.

We'll change ownership of the CI instance to the new "Tools" Mylyn.

Any new repositories the team decides to create (e.g., GitHub repositories) will be configured so that they are owned by the new "Tools" Mylyn.

The project leads may, at their leisure, retire committers who are no longer active.

@mmilinkovich can I safely assume your original +1 covers this plan? it should be aligned with the original proposal.

In the meantime, we can ask @webmaster to address the question from Frank:

We have unit tests using http://ci.mylyn.org where we have different Versions of Bugzilla, Jenkins, Hudson and Gerrit instances. Should we redeploy this service to a different URL or do we need to change the unit tests?

For local testing, we have a Vagrant setup. I have developed a not yet released version with Ansible and Docker.

Do we have the possibility to use such a setup for CI builds within Eclipse? Otherwise I would have to see if I can deploy and publish this within my domain.

Yes, let's go.

We'll move Eclipse Mylyn (mylyn) to a Tools subproject (tools.mylyn)
To keep things simple, we'll take the union of all existing Eclipse Mylyn subproject committers as committers on the new "Tools" Mylyn.
We will announce on the mailing list that a new team will be formed and who wants to retain their commit rights
.. etc

I can lead the initial effort to move to Github, fix the builds, etc.. Maybe @fbecker wants to lead as well?

the initial set of committers at least include @fbecker, @wjongman, @mmeijerbq4, @tresheim, and @lbettini

@webmaster please initiate the requested changes:

We'll move Eclipse Mylyn (mylyn) to a Tools subproject (tools.mylyn)

To keep things simple, we'll take the union of all existing Eclipse Mylyn subproject committers as committers on the new "Tools" Mylyn.

We'll add new committers identified during this restructuring review to the new "Tools" Mylyn. I assume that we'll also need to identify some new project leads (correct me if I'm wrong).

We'll change ownership of all repositories under all Mylyn subprojects to the new "Tools" Mylyn.

We'll change ownership of all Bugzilla products and categories to the new "Tools" Mylyn.

We'll change ownership of the CI instance to the new "Tools" Mylyn.

Any new repositories the team decides to create (e.g., GitHub repositories) will be configured so that they are owned by the new "Tools" Mylyn.

The initial set of committers will be: @fbecker, @wjongman, @mmeijerbq4, @tresheim, and @lbettini

@mdelgado624 please consider my candidacy for committer role [1],

https://www.eclipse.org/lists/cross-project-issues-dev/msg19380.html

I think we're 85% of the way there:

tools.mylyn has been resurrected and it's committers are a union of all currently active mylyn.* committers plus those identified by @mdelgado624 above.
All existing Mylyn Git repos have been transferred to tools.mylyn
Ditto the downloads/archives areas
Mailing list associations have been updated
The Mylyn project on the PMI has been renamed to 'Tools.mylyn'

I've asked the RelEng team to take a look at the CI permissions.

While I've 'deactivated' all of the existing mylyn.* committers on the associated mylyn.* projects and marked those projects as inactive, I've left the Mylyn 'TLP' for the EMO team in case there is something special required.

There are 2 outstanding issues:

Bugzilla: Does the project really want to 'merge' the nearly 14K current bugs into a single tools.mylyn product, or should they simply be marked as 'wontfix' and then the project can start over?
What should happen to all of the existing mailing lists as this seems like a lot of channels for a single project:

mylyn-intent-dev
mylyn-announce
mylyn-dev
mylyn-integrators
mylyn-docs-dev
mylyn-builds-dev
mylyn-versions-dev
mylyn-context-dev
mylyn-commons-dev
mylyn-tasks-dev
mylyn-incubator-dev
mylyn-vex-dev
context-dev

Just a couple of other comments:

I presume that 'mylyn' is a Trademark of the Foundation, so the mylyn.org domain should be transferred to the Foundation. That can be coordinated with webmaster whenever is convenient.
For the 'external' unit test service we could provision a project vserver that the project could use. These are provided 'as-is'(ie: installed) to the project and it'd be up to the committers to configure everything and maintain it. Webmasters involvement would be limited to deleting and re-provisioning the vserver should something happen to it. So ansible/chef/puppet would be your friends :) . This can also be coordinated separately from this issue.

I think the original intent / use case for mylyn was interacting with bugzilla from the IDE. I see triage of outstanding bugs, at least from mylyn.tasks as one of the areas where I can add most value. Wholesale closure is too hard a message. So triage and manual reassign to tools.mylyn or close wontfix maybe the way forward.

Reply to 1. comment As far as I know Mylyn.org is only use to get the list of available test instances of Gerrit, Bugzilla, Hudson and Jenkins. Here a mail with some more details https://www.eclipse.org/lists//mylyn-dev/msg02496.html. So I think it's fine if we have a publicly available URL and don't necessarily need our own domain.

Reply to 2. comment Actual I work to provide a Multipass Ansible Docker Swarm setup for a local test environment. The goal is that I have the same test instances as from http://mylyn.org/cgi-bin/services (maybe at first without Gerrit and Hudson). For the vserver we then only need some changes to use Docker and not a Docker Swarm (switch from run services to run containers)

Please close all the bugzillas as CLOSED MOVED with a comment:

Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub [1].

[1]

Also, +1 for merging all the mailing lists to one mylyn-dev. We want all people together on one list.

Ok I've posted closure notices for all of the Mylyn mailing lists directing people at mylyn-dev, and the lists have been tagged for cleanup.

All 13907 bugs have been moved into the z_Archived component and those that were new/reopened were closed(moved) with the comment requested. A Github organization for Mylyn was preemptively created(github.com/eclipse-mylyn) so the project can begin transitioning to Github at it's convenience.

I think that's it from an infra perspective at this time. Once the project has completed it's move to Github we can close the forums, unless you'd really like that done now.

Nice! Thank you.

@mward I see that @afedorov3un is missing as a committer and @fbecker as a project lead as well. They were not part of my original request. Can you please add them to the mylyn project?

Done.

Matt, I have no access to the GitHub org.

https://github.com/eclipse-mylyn

Pretty sure that's an artifact of there being no repos present(it was created as a placeholder), so the sync tool is essentially 'no-op-ing'. Just for grins I've added the org to the PMI to see what happens.

When do you expect this to take effect so that we can push the repos?

I think there is some confusion here.

Currently all of the Mylyn repos are still on the Foundations Gerrit instance. The permissions on those repos have been updated so that they belong to the 'new' tools.mylyn project.

Given the effort being put in to getting this project restarted it seemed best to leave the repos mostly 'as is' so that things like the builds should still 'just work', which would hopefully help keep the required effort in check.

The Github org was created as a placeholder, and so that I could insert a URL into the comment when the outstanding open bugs were closed.

Once the project is 'ready'(however you choose to define that) we can start moving the code repos to Github.

We don't have to wait for this. I want to start moving the repos to GH in parallel so that we can modify the cb/cd infra. Can you make the PL's owner/manager of the eclipse-mylyn org?

I've imported all of the existing Mylny repos to Github. Committers that have added their Github IDs to their Eclipse.org accounts will receive access in an hour or so when the sync tool runs.

I also added a pointer to this new location to the original repos.

Let me know once you've cut over to Github and I'll archive the Eclipse.org Gerrit repos.

I am happy to share my years of experience as a Mylyn Committer. I will continue to work for this project.

I commenting the way to join this effort?

changed the description

mentioned in issue eclipsefdn/helpdesk#1840 (closed)

assigned to @webmaster

marked the checklist item EMO (ED) approval as completed

marked the checklist item EMO (ED) approval as incomplete

This is an answer to #371 (comment 1026168) where I found the question if I also want to lead.

Yes, I can try, but there are areas where I also need support.

Hopefully I will have a little more time to contribute in the near future.

How can we coordinate the next steps?

In the meantime, I'm trying to get the setup for Mylyn testing switched to multipass and Ansible so we can at least test locally again.

marked the checklist item EMO (ED) approval as completed

mentioned in issue eclipsefdn/helpdesk#2238 (closed)

I see no repositories in https://github.com/eclipse-mylyn and at the same time https://git.eclipse.org/r/mylyn/org.eclipse.mylyn.docs.git is gone. What am I supposed to do to work on an issue for 2022-12?

[tools.mylyn] Eclipse Mylyn restructuring review

Restructuring To-Do list

Designs

Child items ...

Activity

[tools.mylyn] Eclipse Mylyn restructuring review

Restructuring To-Do list

Is blocked by

Activity