Community
Participate
Working Groups
Provision the Mylyn Docs Project as outlined under: http://wiki.eclipse.org/Mylyn/Restructuring#Docs . Project name: Mylyn Docs Project id: mylyn.docs Bugzilla product: Mylyn Docs Bugzilla components: HtmlText, Framework, WikiText
Wayne, let us know when the project exists and we'll submit the NPRR. Once that's done we'll provide instructions for moving bugs and migrating CVS (to git).
Mylyn Docs created in the Foundation Database. Please complete the NPPR (only once, please): http://www.eclipse.org/projects/project_provisioning_request.php?id=mylyn.docs Note that the committer list in the NPPR must match the committer list on the restructuring document http://wiki.eclipse.org/Mylyn/Restructuring
We (the Vex committers) are currently not on this committer list. Does it make sense to add us on this level, or will there be a separate list for the Vex component, once it has moved to Mylyn?
Thanks Wayne! David, can you submit the NPPR? This has to be done by the project lead. Please note the discussion about Cvs vs. Git on bug 328390. My understanding is that we committers move with the code, i.e. we can do that as part of the Vex move/creation proposal.
(In reply to comment #3) > We (the Vex committers) are currently not on this committer list. Does it make > sense to add us on this level, or will there be a separate list for the Vex > component, once it has moved to Mylyn? There will be a separate list for the Vex subproject.
(In reply to comment #5) > ... the Vex subproject. > At ESE Steffen, Florian and I talked about if Vex should be a subproject or a component in Mylyn Docs. We agreed that a component would be simpler and better than a subproject because of less administration costs. Also it will be still possible to split WikiText and Vex in separate subproject as soon it is required.
(In reply to comment #6) > (In reply to comment #5) > > ... the Vex subproject. > > > At ESE Steffen, Florian and I talked about if Vex should be a subproject or a > component in Mylyn Docs. We agreed that a component would be simpler and better > than a subproject because of less administration costs. Also it will be still > possible to split WikiText and Vex in separate subproject as soon it is > required. Just so we're clear... There is no formal concept of a "component"; components are more conventions within a project. A project has a single group of committers who all have equal access to all code contained within the project. If this is what we really want, then the Vex project proposal that I have sitting in my inbox needs to be changed into a move review. FWIW, I have accepted bugzilla comments as documentation enough for a move review (i.e. don't knock yourself out). Is the scope for mylyn.docs broad enough to include Vex? Was David Carver included in this discussion?
(In reply to comment #7) > ... > Was David Carver included in this discussion? Not yet. @Dave and @David (Green): what do you think? Should Vex contained or a subproject in Mylyn Docs?
Just for completeness... Contained: less administrative overhead, less overall control. Sub-project: more administrative overhead, more overall control. Regardless of what you choose now, we can change later. Subprojects can be rolled into the parent, the parent can be broken out into subprojects.
(In reply to comment #8) > (In reply to comment #7) > > ... > > Was David Carver included in this discussion? > > Not yet. @Dave and @David (Green): what do you think? Should Vex contained or a > subproject in Mylyn Docs? I leave it to Florian, Holger and Ian to be decide. My current role on Vex is mainly as mentor, user, and release engineer. I don't have any other day to day involvement in the project, except for being the one to bring it over into the Incubator originally from Sourceforge.
(In reply to comment #9) > Just for completeness... > > Contained: less administrative overhead, less overall control. > > Sub-project: more administrative overhead, more overall control. > > Regardless of what you choose now, we can change later. Subprojects can be > rolled into the parent, the parent can be broken out into subprojects. Holger left the decision also to me, and so I will. And I choose "contained". It is the variant with the least impact on our work at the moment. We are only three people (+ a very helpful release engineer) that do Vex only in their freetime. Therefor we want to minimize the effort for all things that keep us from coding. Parts of Vex (e.g. the layout engine) might definitely be useful for WikiText and also other projects. Other parts (which genuinely constitute Vex as visual XML editor) might go into a separate subproject at a later point in time, when our code is in better shape and when there are hopefully more people working on it. So Holger, Igor and me will be very pleased to become part of the WikiText subproject (with the option to factor out some parts some time AND a very strong preference for Git ;-) ).
Sounds fine to me. You'll need to do a move review. See my thoughts on Comment #7. We may have to wait until the dust settles on the Mylyn restructuring.
Hi Wayne, I have two questions: 1. WikiText and HtmlText are listed as "components" of Mylyn Docs (see http://wiki.eclipse.org/Mylyn/Restructuring#Docs). Does this mean that Vex should be contained in Mylyn Docs and not in WikiText? Mylyn Docs makes more sense to me... 2. Vex is still in the Incubation phase but the subproject Mylyn Docs which contains WikiText and HtmlText is not (as far as I know). Could Vex in Incubation be part of a (sub)project which is not in the Incubation phase? Best regards, Holger
(In reply to comment #13) > 2. Vex is still in the Incubation phase but the subproject Mylyn Docs which > contains WikiText and HtmlText is not (as far as I know). Could Vex in > Incubation be part of a (sub)project which is not in the Incubation phase? I guess the other question would be whether Mylyn Docs has to be Incubation initially anyways until it graduates? At least Mylyn Builds and Versions were marked as Incubating. Wayne, is there any chance to graduate these projects before Indigo?
(In reply to comment #14) > I guess the other question would be whether Mylyn Docs has to be Incubation > initially anyways until it graduates? At least Mylyn Builds and Versions were > marked as Incubating. Wayne, is there any chance to graduate these projects > before Indigo? As I've been creating these new projects, I've been marking them as incubating. We can graduate them with a Release/Graduation Review as soon as you're ready (i.e. everything is place, builds are running, etc.). Keeping them as initially incubating allows for a little "fumble room" while we get everything up-to-speed. So, IMHO, there is every chance to graduate these projects before Indigo. I'll help you where I can, but it's up to you to drive it.
(In reply to comment #13) > Hi Wayne, > > I have two questions: > > 1. WikiText and HtmlText are listed as "components" of Mylyn Docs (see > http://wiki.eclipse.org/Mylyn/Restructuring#Docs). Does this mean that Vex > should be contained in Mylyn Docs and not in WikiText? Mylyn Docs makes more > sense to me... > > 2. Vex is still in the Incubation phase but the subproject Mylyn Docs which > contains WikiText and HtmlText is not (as far as I know). Could Vex in > Incubation be part of a (sub)project which is not in the Incubation phase? > > Best regards, Holger Components have become a de facto thing; there is no formal notion of component in the EDP. If a project wanted to have some notion of components in components, and they could make it make sense to their own developer and the community, there's really nothing to stop that. However, I think the real answer you're looking for is that it makes far more sense to me that Vex, WikiText and HtmlText all be sibling "components" in the Mylyn Docs project. Since there is no formal notion of component in the EDP, the "incubation" marker is for projects only. That is, there is no formal notion of an "incubating component" in the EDP. You can bring the incubating code into a mature project as part of a Restructuring Review, and just not include that new code in your "release" distribution until you're ready. Does that make sense?
(In reply to comment #4) > Thanks Wayne! David, can you submit the NPPR? This has to be done by the project > lead. Please note the discussion about Cvs vs. Git on bug 328390. NPPR sumbitted, requested Git repository. (In reply to comment #15) > (In reply to comment #14) > > I guess the other question would be whether Mylyn Docs has to be Incubation > > initially anyways until it graduates? At least Mylyn Builds and Versions were > > marked as Incubating. Wayne, is there any chance to graduate these projects > > before Indigo? > > As I've been creating these new projects, I've been marking them as incubating. > We can graduate them with a Release/Graduation Review as soon as you're ready > (i.e. everything is place, builds are running, etc.). Keeping them as initially > incubating allows for a little "fumble room" while we get everything > up-to-speed. > The intention will be to graduate Mylyn Docs as soon as possible. (In reply to comment #16) > However, I think the real answer you're looking for is that it makes far more > sense to me that Vex, WikiText and HtmlText all be sibling "components" in the > Mylyn Docs project. Makes sense to me!
Created attachment 183405 [details] nppr as sumbitted
Tom, where is the code located that should be migrated to the Mylyn Docs git repository?
(In reply to comment #19) > Tom, where is the code located that should be migrated to the Mylyn Docs git > repository? You'll find the source at /cvsroot/technology/org.eclipse.remus/bundles/org.eclipse.mylyn.htmltext
To amend the NPPR: * The project's Bugzilla product should be called "Mylyn Docs" * A news group is not needed. The Mylyn Docs project can share the org.eclipse.mylyn news group. * A website is not needed. The Mylyn Docs project can share the Mylyn website. * The project mailing list should be named "mylyn-docs-dev@eclipse.org" The single git repository should be located in /gitroot/mylyn/org.eclipse.mylyn.docs with the following amalgated content: /cvsroot/technology/org.eclipse.remus/bundles/org.eclipse.mylyn.htmltext /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.confluence.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.confluence.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext-feature /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.help.sdk /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.help.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.mediawiki.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.mediawiki.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.sdk-feature /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.tasks.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.tests /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.textile.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.textile.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.tracwiki.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.tracwiki.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.twiki.core /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.twiki.ui /cvsroot/tools/org.eclipse.mylyn/org.eclipse.mylyn.wikitext.ui David, can you confirm or correct this?
Thanks Steffen, your amendment looks good. Is there anything else that I need to do here?
Not that I know of. Once the project is fully provisioned the plan etc. needs to be updated but that's for later. Webmasters, please feel free to go ahead with the steps outlined in comment 21 and let us know if we should clarify anything.
I think the best way to handle the Git import is for me to create the repo and you can import the data you want. The import tooling is really meant to import a 'single' CVS module into a single git repository. Once I have committers to provision I'll get this under way. -M.
Thanks. That sounds good. David, I'll assign this to you. I won't have write access to the repository since I am not a committer.
CVS repository has been migrated to Git. I'm marking this as resolved. Migration of bugs is tracked on bug 332298.
