Community
Participate
Working Groups
Vex proposal carves some behaviour out of the WTP Incubator.
Proposal document is posted in draft form.
We have a bit of a chicken and egg problem. The proposed parent project, Mylyn Docs, doesn't actually exist yet.
An item of concern has been brought up, that Vex might have to migrate back to CVS, which goes against the established direction that eclipse is heading with repos. I know there has been some discussion and that existing code for many projects in Mylyn is using CVS, howerver, something that is to be considered, the official eclipse stance for new projects and new code coming into projects is to either use SVN or GIT, with GIT being the preferred choice. See: http://www.eclipse.org/projects/project_provisioning_request.php The only options are SVN or GIT. Existing projects may continue to use CVS, however, new projects are required to use either SVN or GIT. So this brings us to VEX which is in the stages to move to the Wiki Docs project, and already is using GIT. If you were to try and migrate back to CVS, you would lose all the history from an IP standpoint that resides in the git repository. Also, keep in mind that CVS is being deprecated as a repository in general at eclipse. So now would be a good time to move code to GIT since restructuring is happening anyways. I would personally recommend keeping the Vex code in Git, and if you need a consolidate Update site, use b3 aggregrator to consume the P2 repository produced by the Vex build.
Who is suggesting you'll have to move to CVS?
Steffen, Holger and I had a very good conversation yesterday. We realized that Vex would be the first Mylyn project using Git.
(In reply to comment #5) > Steffen, Holger and I had a very good conversation yesterday. We realized that > Vex would be the first Mylyn project using Git. ...which is not true, since there is already a git repo mylyn/org.eclipse.mylyn.reviews.git
(In reply to comment #5) > Steffen, Holger and I had a very good conversation yesterday. We realized that > Vex would be the first Mylyn project using Git. Connect the dots for me... Does this mean that you'll be moving head with Vex in Git?
To clarify, Florian, Holger and I discussed whether Vex should be it's own sub-sub-project or if it would better fit as a component inside the Docs project. Overall we were leaning towards making it a component to reduce overhead and to increase collaboration around the framework and to build a larger community around documentation. One of the challenges that we identified for making Vex a component was that WikiText, which would be initial code contribution to the Docs project, is currently hosted in CVS. Since a project may only use a single SCM technology, moving forward, I see three options: * Vex becomes a sub-sub-project with an independent Git repository * Vex becomes a component and Vex code is migrated to CVS * Vex becomes a component and WikiText is migrated to Git Considering that CVS is deprecated and that moving to Git is just a matter of overcoming some technical challenges with the build and release process I think hosting Docs in Git sounds like a good option. In the end it's entirely up to the committers of the Docs project. David, do you have any thoughts on this?
(In reply to comment #8) > Since a project may only use a single SCM technology, moving forward, I see > three options: > * Vex becomes a sub-sub-project with an independent Git repository > * Vex becomes a component and Vex code is migrated to CVS > * Vex becomes a component and WikiText is migrated to Git I would think that the second option wouldn't be an option, just from an IP stand point. If you move back to CVS, you loose all the IP and commit history. > Considering that CVS is deprecated and that moving to Git is just a matter of > overcoming some technical challenges with the build and release process I think > hosting Docs in Git sounds like a good option. Correct, there are some minor issues. The most complex one is whether you continue to use the legacy MAP formats for your releases, or look at new ways in which git opens up. Also, I a project can have as many git repositories as they see. In the WTP Incbuator right now there are component level repositories in git, based on the nature of these projects. I would encourage if considering git, that one needs to relook at the way they store the code. You aren't constrained by the old ways any longer.
Also see bug 329561 for a general discussion about migrating Mylyn to Git.
I was contacted by the PI-Mod Project (http://www.pi-mod.de). They provide a DTD for the domain of technical writing in machine engineering under the MIT license. The DTD is actually used by some German companies. The project is very interested in using Vex as their default editor. So they asked if we would list them as "interested party" in the proposal. Wayne, could you please add them as "The PI-Mod Project"?
I tried updating the DocBook file, but the build failed. BUILD FAILED /home/wayne/Workspaces/Work/workspace/www/proposals/vex/build.xml:67: /home/wayne/Workspaces/Work/workspace/www/proposals/vex/lib/FOP not found. Thoughts?
(In reply to comment #12) > I tried updating the DocBook file, but the build failed. > > BUILD FAILED > /home/wayne/Workspaces/Work/workspace/www/proposals/vex/build.xml:67: > /home/wayne/Workspaces/Work/workspace/www/proposals/vex/lib/FOP not found. > > Thoughts? At this point just update the HTML. I haven't converted the script to maven. If you want the DocBook version to work, you'll need to download and make available to the build, Apache FOP.
Maybe I'll just take are run at removing the PDF-generation from the build file. If we're going to do this in DocBook, we should do it right.
(In reply to comment #14) > Maybe I'll just take are run at removing the PDF-generation from the build > file. If we're going to do this in DocBook, we should do it right. Remove the PDF generation, should work. Note the current build file will not output the eclipse formatted HTML, it still outputs the DocBook format HTML with the extra divs, etc.
For some reason, running just the HTML task is still invoking the fop task. I don't have cycles to debug this. As emotionally scaring as it is, I'll update both the HTML and DocBook files.
(In reply to comment #11) > I was contacted by the PI-Mod Project (http://www.pi-mod.de). They provide a DTD > for the domain of technical writing in machine engineering under the MIT > license. The DTD is actually used by some German companies. The project is very > interested in using Vex as their default editor. > > So they asked if we would list them as "interested party" in the proposal. > > Wayne, could you please add them as "The PI-Mod Project"? Done
(In reply to comment #2) > We have a bit of a chicken and egg problem. The proposed parent project, Mylyn > Docs, doesn't actually exist yet. FWIW, we can't announce this proposal until mylyn.docs exists.
(In reply to comment #18) > (In reply to comment #2) > > We have a bit of a chicken and egg problem. The proposed parent project, Mylyn > > Docs, doesn't actually exist yet. > > FWIW, we can't announce this proposal until mylyn.docs exists. That's fine. I'll spend some cycles later today to update the HTML generation ant script.
(In reply to comment #18) > (In reply to comment #2) > > We have a bit of a chicken and egg problem. The proposed parent project, Mylyn > > Docs, doesn't actually exist yet. > > FWIW, we can't announce this proposal until mylyn.docs exists. BTW, there is another way to run this. Use the XSL Tools plugins, and run an XSL Transformation using the XSL provided and the docbook as input to the xml.
(In reply to comment #8) > Considering that CVS is deprecated and that moving to Git is just a matter of > overcoming some technical challenges with the build and release process I think > hosting Docs in Git sounds like a good option. > > In the end it's entirely up to the committers of the Docs project. David, do you > have any thoughts on this? I'm all for having Docs in Git. What are the implications wrt the build process; will there be any problem including Docs in the build?
(In reply to comment #21) > (In reply to comment #8) > > Considering that CVS is deprecated and that moving to Git is just a matter of > > overcoming some technical challenges with the build and release process I think > > hosting Docs in Git sounds like a good option. > > > > In the end it's entirely up to the committers of the Docs project. David, do you > > have any thoughts on this? > > I'm all for having Docs in Git. What are the implications wrt the build > process; will there be any problem including Docs in the build? Depends on your build system. All three can now support git. There is a Git PDE Build Fetch Factory extension now. Paul Webster is using it with e4. Buckminster, Maven/Tycho, and PDE Build can work. Setup varies by build technology though.
(In reply to comment #21) > I'm all for having Docs in Git. What are the implications wrt the build > process; will there be any problem including Docs in the build? Other Mylyn sub-projects are hosted in Git as well such as Mylyn Builds. As Dave points out, it's sort of a solved problem, so it's mostly a matter of adapting the Mylyn build accordingly which will happen anyways.
Git source repository was requested for Mylyn Docs on bug 329844
Since we've decided to include Vex as a component of mylyn.docs, I am marking this proposal as withdrawn (i.e. WONTFIX). I'll expect to see a request for a restructuring (move) review to move the Vex code out of the incubator and into the mylyn.docs project.
(In reply to comment #25) > Since we've decided to include Vex as a component of mylyn.docs, I am marking > this proposal as withdrawn (i.e. WONTFIX). > > I'll expect to see a request for a restructuring (move) review to move the Vex > code out of the incubator and into the mylyn.docs project. Originally that was the original request. Do I have another form I need to fill out for the Restructuring Move Request?
(In reply to comment #26) > Originally that was the original request. Do I have another form I need to > fill out for the Restructuring Move Request? http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Information_for_Project_Leads#Restructuring_Reviews In the past, I have accepted a Bugzilla comment for move review documentation. We don't need a lot of information, we just need to know what needs to move, from where to where, and brief discussion of the motivation.
(In reply to comment #27) > In the past, I have accepted a Bugzilla comment for move review documentation. > We don't need a lot of information, we just need to know what needs to move, > from where to where, and brief discussion of the motivation. I'll do that once the provisioning of mylyn.docs is finished. This will make the definition of the technical stuff a little easier...
I don't recall marking this as WONTFIX on purpose. But I've undone it. What's the status on this?
We want to move right after Indigo.
(In reply to comment #25) > I'll expect to see a request for a restructuring (move) review to move the Vex > code out of the incubator and into the mylyn.docs project. After thinking this through a bit more, I don't think that a restructuring review applies here. Vex will be an entirely new project. It's really not a split up or restructuring of an existing project. It's really the creation of a new project with a move of some code. I'd like to post that proposal for community review per the standard rules. Are we good to go? http://www.eclipse.org/proposals/vex (I'll likely move this to http://www.eclipse.org/proposals/mylyn.docs.vex before making it public) (In reply to comment #29) > I don't recall marking this as WONTFIX on purpose. But I've undone it. Comment #25. Duh.
(In reply to comment #31) > (In reply to comment #25) > > I'll expect to see a request for a restructuring (move) review to move the Vex > > code out of the incubator and into the mylyn.docs project. > > After thinking this through a bit more, I don't think that a restructuring > review applies here. Vex will be an entirely new project. It's really not a > split up or restructuring of an existing project. It's really the creation of a > new project with a move of some code. > In my understanding, Vex should be on the same level as WikiText and HtmlText i.e. a component of mylyn.docs. As I understand the directory structure of mylyn.docs, the Vex plug-ins and features should go to http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.docs.git, no separation of plugins, tests, etc. as we have it now in WTP.
(In reply to comment #32) > (In reply to comment #31) > > (In reply to comment #25) > > > I'll expect to see a request for a restructuring (move) review to move the Vex > > > code out of the incubator and into the mylyn.docs project. > > > > After thinking this through a bit more, I don't think that a restructuring > > review applies here. Vex will be an entirely new project. It's really not a > > split up or restructuring of an existing project. It's really the creation of a > > new project with a move of some code. > > > In my understanding, Vex should be on the same level as WikiText and HtmlText > i.e. a component of mylyn.docs. As I understand the directory structure of > mylyn.docs, the Vex plug-ins and features should go to > http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.docs.git, no separation of > plugins, tests, etc. as we have it now in WTP. Okay That makes sense to me. Then it is just a restructuring if we're just moving some code from one project into another. I lost context. Carry on.
I have added a section with some criteria for deciding whether a component or project is the right fit: http://wiki.eclipse.org/Mylyn/Contributor_Reference#Creating_New_Components If... ...Vex does not require Incubation status ...Vex can be released following the Mylyn Docs release schedule (usually 2 releases per year + 4 service releases) ...it's sufficient to have a Vex component in Bugzilla associated with the Mylyn Docs milestone/versions (1.6.0 at the moment) ...then it would seem best to make Vex a component of the Mylyn Docs project. The code can still live in it's own Git repository. We could consider changing the namespace to org.eclipse.mylyn but it's fine with me to keep the current namespace, too.
(In reply to comment #34) > ...Vex does not require Incubation status > Does this mean a Release/Graduation and Restructuring Review instead of Creation Review for Vex? Mylyn Docs release scheduling and versioning for Vex are fine with me. How to (or who?) decide if Vex should become a component or a subproject? What's the next step for us Vex committers to move Vex to Mylyn Docs?
In terms of being a Mylyn, component vs. a subproject, my view is that it’s up to the Vex committers in terms of what will make it easiest for you to evolve Vex. The intention of http://wiki.eclipse.org/Mylyn/Charter#Scope is to have Mylyn "Tools" projects be independent projects so that their brand is "Hudson Connector" or "Vex", and that they don’t need to be called long-winded things like "Mylyn Docs Vex". But if you think it would be more convenient to have this as a component you could consider that. We want it to be easy to work in Mylyn subprojects and only impose the amount of process that corresponds to benefit to the subproject/componet (eg, being part of a coordinated releng/build and plan vs. having that be independent if the project benefits more from that). Steffen, as a side note, this is not the only case where we want to have a lightweight subproject that’s the overhead of a component but the visibility of the project, so it is a consideration for the Charter.
It's great to see renewed interest in this proposal. (In reply to comment #34) > ...Vex does not require Incubation status Steffen, does this mean that Vex cannot be in incubation under Mylyn Docs? > The code can still live in it's own Git repository. That makes sense to me. > We could consider changing the namespace to org.eclipse.mylyn but it's fine with me to keep the current > namespace, too. It could help to avoid confusion, otherwise it may appear as thought the project is under wtp.
(In reply to comment #36) > In terms of being a Mylyn, component vs. a subproject, my view is that it’s up > to the Vex committers in terms of what will make it easiest for you to evolve > Vex. The intention of http://wiki.eclipse.org/Mylyn/Charter#Scope is to have > Mylyn "Tools" projects be independent projects so that their brand is "Hudson > Connector" or "Vex", and that they don’t need to be called long-winded things > like "Mylyn Docs Vex". But if you think it would be more convenient to have > this as a component you could consider that. We want it to be easy to work in > Mylyn subprojects and only impose the amount of process that corresponds to > benefit to the subproject/componet (eg, being part of a coordinated > releng/build and plan vs. having that be independent if the project benefits > more from that). > > Steffen, as a side note, this is not the only case where we want to have a > lightweight subproject that’s the overhead of a component but the visibility of > the project, so it is a consideration for the Charter. Thank you for this clarification, Mik. I see Vex on the same level as WikiText and HtmlText. But I also like the notion of "lightweight subproject", mainly because our manpower is somewhat limited. (In reply to comment #37) > It's great to see renewed interest in this proposal. > > (In reply to comment #34) > > ...Vex does not require Incubation status > > Steffen, does this mean that Vex cannot be in incubation under Mylyn Docs? We will have to graduate. The paperwork has to be done anyway. And the graduated status will give us more flexibility. Plus we are already doing 1.0 milestones. > > We could consider changing the namespace to org.eclipse.mylyn but it's fine with me to keep the current > > namespace, too. > > It could help to avoid confusion, otherwise it may appear as thought the > project is under wtp. I didn't know this would be possible, but if it is ok for you, we should go with org.eclipse.vex. The project is known as "Vex" and short names are always better. Holger and me already started to get the paperwork (project plan, IP log etc.) done. This might take some days...
Just to make sure that we're clear: Vex as a project requires a proposal and creation review. Minimum of three weeks before we can provision. Vex as a component of Mylyn Docs requires a restructuring review. One week. Note that there is no formal concept of component in the EDP. A component is just a de facto concept within a project. The project has a single group of committers and access to the different "components" is managed by social convention.
So I would suggest two steps: 1. a creation review to get the code moved, do the renaming etc. get the stuff in place 2. a graduation with a 1.0 release based on the current feature set Mylyners, what do you think?
(In reply to comment #40) Also Igor and I think it would be the best that Vex will become a project of its own under Mylyn Docs (we have discussed this via Skype and e-mail). So this is the opinion of all of us Vex committers.
> (In reply to comment #40) > Also Igor and I think it would be the best that Vex will become a project of its > own under Mylyn Docs (we have discussed this via Skype and e-mail). So this is > the opinion of all of us Vex committers. Correct me if I'm wrong, I understand the options as follows. Either # Vex moves to Mylyn Docs as a component, (which involves a restructuring review) OR # Vex becomes its own project (which requires a creation review) I don't think that we have 3 levels of projects under Mylyn, ie. it doesn't make sense to have Mylyn -> Mylyn Docs -> Vex as projects -- however it does make sense to have Mylyn -> Mylyn Docs -> Vex if Vex is a component. Just to be clear on the proposal, is Vex proposing to become a project of its own under Mylyn, or a component under Mylyn Docs?
(In reply to comment #41) > (In reply to comment #40) > Also Igor and I think it would be the best that Vex will become a project of its > own under Mylyn Docs (we have discussed this via Skype and e-mail). So this is > the opinion of all of us Vex committers. That sounds good to me. You can submit the project proposal etc. independently from the Mylyn Docs project so there shouldn't be anything blocking that. (In reply to comment #42) > # Vex moves to Mylyn Docs as a component, (which involves a restructuring > review) OR > # Vex becomes its own project (which requires a creation review) > I don't think that we have 3 levels of projects under Mylyn, ie. it doesn't make > sense to have Mylyn -> Mylyn Docs -> Vex as projects -- however it does make > sense to have Mylyn -> Mylyn Docs -> Vex if Vex is a component. It's fine for Mylyn Docs to have sub-sub-projects. Mylyn Intent is an example of that: http://eclipse.org/projects/listofprojects.php . It seems to me that that would be a good fit for Vex and allow the project to maintain its own identity and involve more independently. > > Just to be clear on the proposal, is Vex proposing to become a project of its > own under Mylyn, or a component under Mylyn Docs?
(In reply to comment #43) (In reply to comment #42) > It's fine for Mylyn Docs to have sub-sub-projects. Mylyn Intent is an example > of that: http://eclipse.org/projects/listofprojects.php . It seems to me that > that would be a good fit for Vex and allow the project to maintain its own > identity and involve more independently. > > > > > > > Just to be clear on the proposal, is Vex proposing to become a project of its > > own under Mylyn, or a component under Mylyn Docs? That's just the main question we are discussing here. We (the Vex people) would prefer the sub-sub-project way as Steffen described it, if that would be OK for you David and Wayne.
(In reply to comment #44) > That's just the main question we are discussing here. We (the Vex people) would > prefer the sub-sub-project way as Steffen described it, if that would be OK for > you David and Wayne. You need to decide what's right for your needs. As a project, you have a distinct set of committers and project resources (you also have the overhead of managing a project). As a component, you will share the same set of committers, resources, releases, etc. as the project you're part of. Your call. I'll support you either way :-)
(In reply to comment #43) > It's fine for Mylyn Docs to have sub-sub-projects. Mylyn Intent is an example of > that: http://eclipse.org/projects/listofprojects.php . It seems to me that that > would be a good fit for Vex and allow the project to maintain its own identity > and involve more independently. Great, that sounds good -- it seems to be the most compatible with the existing project structure and independence sounds good.
(In reply to comment #45) > ... Your call. I'll support you either way :-) We (all four Vex committers) would like to become an independent sub-project under Mylyn Docs. Our project lead should be Florian Thienel.
Is the proposal [1] content correct? If updates are required, please let me know. We need to post the proposal for a minimum of two weeks before we can proceed with a creation review. [1] http://eclipse.org/proposals/vex
(In reply to comment #48) > Is the proposal [1] content correct? If updates are required, please let me > know. We need to post the proposal for a minimum of two weeks before we can > proceed with a creation review. > > [1] http://eclipse.org/proposals/vex I'm still working on it...
What is our status here? Can I expect the updated proposal document soon?
Created attachment 201439 [details] Proposal: Vex We are ready to go. ;-) Florian sent you following e-mail (12th July): --- Hi Wayne, please find attached the latest draft of the proposal. All Vex committers have reviewed the document and we think it's ready to go live now (but please have a look at it also and give me a signal if there are any issues left). Best Regards, Florian
Created attachment 201519 [details] Updated proposal There was some repeated text and the formatting in the lists used some non-existent styles (there was also some extra html, and body tags...
Uploaded to http://eclipse.org/proposals/mylyn.docs.vex/ Awaiting EMO(ED) approval to post.
(In reply to comment #53) > Uploaded to http://eclipse.org/proposals/mylyn.docs.vex/ > > Awaiting EMO(ED) approval to post. Thank you, Wayne.
(In reply to comment #53) > Awaiting EMO(ED) approval to post. Approved
It seems like enough time has passed. Are we ready to run the creation review this week?
(In reply to comment #56) > It seems like enough time has passed. Are we ready to run the creation review > this week? We are ready. Please schedule the review.
I've requested legal review of the trademark (sorry, I initated the request some days ago but neglected to make a note of it). Janet expects to have an answer for me my mid-week. We'll schedule the review once we have trademark approval.
Trademark review complete. Review is scheduled to run from Oct 6-12/2011.
Wayne, please add Werner Keil to the list of interested parties. (see http://www.eclipse.org/forums/index.php/mv/msg/235315/734594/#msg_734594)
Project creation review declared successful. I've sent a note to Florian regarding next steps. (In reply to comment #60) > Wayne, please add Werner Keil to the list of interested parties. We don't modify proposal documents after the creation review has started.
