| Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo |
Jad,
Excellent points as always.
re: Lyo Project Lead - feedback from Michael, Sam, Steve as Lyo project leads would be highly desirable since they have important institutional knowledge and motivating history, as well as being top developers. However, we have to recognize that sometimes people are no longer available to contribute and not put unrealistic expectations or dependencies on them - as well as have some confidence in our own decisions.
Given that the current Lyo project leads are no longer significantly involved, we may need to consider establishing a new project lead.
But before doing so, Sam, Michael, Steve, are any of you interested in continuing to actively participate as Lyo project lead, at least to guide our work? We would really appreciate that, but I know its asking a lot.
Re: Lyo documentation: There are actually three sources of Lyo documentation:
1. OSLC4J Docs - https://www.eclipse.org/lyo/- this is the Web application used for the OSLC4J SDK distribution. It is managed in a git repository accessible from http://git.eclipse.org/c/www.eclipse.org/lyo.git/ . This is documentation that is specific to a particular version of the OSLC4J SDK, providing access to JAR downloads, source repos and documentation - which is a link to the Eclipse Lyo Wiki https://wiki.eclipse.org/Lyobelow. There should not be much need to edit this repo/docs as it doesn't contain any specific OSLC4J or other Lyo docs, only the app for the Web page that makes the SDK available.
2. Eclipse Lyo Wiki - https://wiki.eclipse.org/Lyo- This is an eclipse Wiki for Lyo that can be edited through moderator approval. This should be used for broader collaboration around Lyo that should be done outside Bugzilla. For example, the Lyo project plans would be regularly updated here: https://wiki.eclipse.org/Lyo/ProjectPlans . This Wiki provides broad information about eclipse/Lyo and a place to collaborate on its development and use. It also provides the OSLC4J SDK documentation, but this documentation is not release specific.
3. OSLC Developer Guide - http://oslc.github.io/developing-oslc-applications/ - this site uses GitHub pages from the OSLC GitHub organization (https://github.com/OSLC/developing-oslc-applications ). This site and technology was probably chosen to provide a more flexible means of creating a developer guide helping users develop OSLC client and server applications using OSLC4J. This site provides introductory material as well as links to many OSLC resources, including the OSLC4J SDK, and the Integrating products with OSLC turotial on open-services.net.
There is some overlap and potential redundancy between these sites. as well as different technologies used that increase development overhead. We can consider how this documentation is impacted by the reorganization of the git repo contents and eclipse projects, and how we might organize and simplify the documentation to make it easier to develop and consume.
Major changes to OSLC4J SDK (e.g., update for configuration management support or OSLC 3.0) may require significant changes to the documentation. This will have to be addressed on the eclipse Wiki for Lyo, possibly using separate links to v2 and v3 documentation.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad El-Khoury <jad@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 02/15/2017 10:05 AM
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Jim,
My guess is that some of these changes will require involvement of the Lyo Project Lead (currently Michael Fiedler, Samuel Padgett, Steve Speicher). You think we can get them involved to make things proceed smoothly? See https://projects.eclipse.org/projects/technology.lyo/who
Regarding documentation, note that https://wiki.eclipse.org/Lyo& http://git.eclipse.org/c/www.eclipse.org/lyo.git/ refer to 2 different content:
1. https://wiki.eclipse.org/Lyois edited directly via the wiki pages.
2. Yet http://git.eclipse.org/c/www.eclipse.org/lyo.git/ reflects the Lyo page(s) under https://www.eclipse.org/lyo/
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx, www.kth.se
From: lyo-dev-bounces@xxxxxxxxxxx [mailto:lyo-dev-bounces@eclipse.org ] On Behalf Of Jim Amsden
Sent: 09 February 2017 15:15
To: Lyo project developer discussions
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
Jad,
Thanks for the feedback and the commitment to contribution.
As you concluded, mirroring the eclipse Git repositories doesn't really help because the eclipse.org process still applies, and the refactoring would have to be done within that process. The mirrors would be read-only.
It is up to the adapter developer where they want to build and govern their adapter. Could be internal private, private or public GitHub, or eclipse.org, either in Lyo or some other eclipse project. I would entertain any adapter development as part of eclipse/Lyo, especially if that development included or required significant changes to OSLC4J, or contributed some reusable adapter framework that would benefit the OSLC community.
Regarding documentation, https://wiki.eclipse.org/Lyo, is the place http://git.eclipse.org/c/www.eclipse.org/lyo.git/ is deployed. The problem with the eclipse wiki is the navigation sidebar is taken up by eclipse, Lyo doesn't seem to contribute to the sidebar. So there's no convenient TOC to help navigate the Lyo content.
GitHub wikies do allow creation of a custom sidebar. It might also be helpful to partition the documentation by the refactored repositories so that closely related information is in the same place.
Here's a rough draft action plan to effect this reorganization:
We should plan to do this refactoring after the OSLC4J 2.2.0 release so we are starting with updated dependencies and a solid basis for forking.
1. Review refactoring proposal with eclipse/Lyo community and update as needed
2. Review target environments and resolve any issues
1. Continue using eclipse.org for OSLC4J SDK
2. Use OSLC GitHub organization for samples and reference implementations
3. Use OSLC GitHub Wiki and optionally GitHub Pages for documentation, organized by repository
4. Use OSLC GitHub issues for change management
3. Get approval from the eclipse.org Technology PMC to perform the refactoring and repository migration
4. Create the GitHub repositories according to the adopted refactoring plan
5. Clone the eclipse.org Git repositories that are to be migrated to GitHub - history is retained at eclipse.org
6. Build and test each repository’s components in order to reach a known, stable state
7. Migrate eclipse/Lyo documentation to GitHub and GitHub Pages
Questions:
1. Where should OSLC4J documentation be deployed? Current documentation:
1. Tutorial: Integrating products with OSLC - http://open-services.net/resources/tutorials/ integrating-products-with- oslc/
2. OSLC Developer Guide - http://oslc.github.io/developing-oslc-applications/
3. Lyo Documentation - https://wiki.eclipse.org/Lyo
4. OSLC4J SDK https://wiki.eclipse.org/Lyo/LyoOSLC4J
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Jad El-Khoury <jad@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 02/09/2017 05:07 AM
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Hi Jim
(Congratulations on your Committer status!)
I jump to the last - but more important - question to re-highlight it to the community …
>I think the action we need from the eclipse/Lyo dev community is whether or not we want to do this refactoring activity. And then we can look at the mechanics of how to do it, and the details of what should be refactored where.
Yes, I plan to contribute to this activity, because I think it’s important to strengthen our OSLC community.
And for the details …
>Eclipse/Lyo uses Git controlled by eclipse.org, not GitHub. None of the current components of eclipse/Lyo are on GitHub.
I was thinking of the mirroring of the Eclipse repositories. For example, https://github.com/eclipse/lyo.core . Note thought that not all repositories are mirrored, so, we (at Lyo) ought to have somehow control over this.
But still, I assume this is controlled by eclipse.org governance process
>3. Adapter implementations
>These are often done privately, i.e., not as open source. Those that are are consumers and implementers of the OSLC4J SDK. Adapter development may exhibit enough variability that we need to keep this open and flexible.
So, should we not accept/promote adaptor implementations as part of Lyo?
As a general comment, I am glad to hear your thoughts about adapters requiring enough variability that they are not practically shareable. I share this view. Many people find this however problematic, since they would still expect tools to come with standard adaptor implementations.
>4. Restructuring Documentation
>OSLC4J documentation is managed through http://git.eclipse.org/c/www.eclipse.org/lyo.git/ .
We also have the Eclipse wiki https://wiki.eclipse.org/Lyo, which I assumed was the main entry point.
I found it quite cumbersome to use Eclipse Wiki, and if we can move such information to a better platform, it would be great.
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx, www.kth.se
From: lyo-dev-bounces@xxxxxxxxxxx[mailto:lyo-dev-bounces@eclipse. ] On Behalf Of Jim Amsdenorg
Sent: 07 February 2017 15:30
To: Lyo project developer discussions
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
Jad,
Thanks for the feedback.
1. Maintaining common community
Yes, we should do that. We already have multiple mailing lists and bug tracking systems for OSLC if you include OASIS OSLC Member Section and TCs, open-services.net and eclipse/Lyo. Most of these all come together through community member subscriptions. So as long as its easy to subscribe, and there is a central launching point like open-services.net for people to get involved, different systems and processes for maintaining different things shouldn't have a significant negative impact on community collaboration.
Anyone can choose to host an OSLC project of any sort on eclipse, and petition to have that project be part of eclipse/Lyo. This would be appropriate for projects that desired to exploit the eclipse.org governance process to manage their development work. But the process of doing that, and managing the project in the context of eclipse.org is much higher than creating a project on GitHub, and may not be necessary for many OSLC projects.
Eclipse/Lyo uses Git controlled by eclipse.org, not GitHub. None of the current components of eclipse/Lyo are on GitHub.
There are a number of OSLC projects on GitHub already that are not part of eclipse/Lyo including:
1.1 OSLC GitHub organization - https://github.com/OSLC
1.2 OSLC4JS - http://oslc.github.io/developing-oslc-applications/ oslc-open-source-node- projects.html
1.3 Id4mbse - https://github.com/ld4mbse
1.4 koneksys - https://github.com/koneksys
3. Adapter implementations
These are often done privately, i.e., not as open source. Those that are are consumers and implementers of the OSLC4J SDK. Adapter development may exhibit enough variability that we need to keep this open and flexible.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
4. Restructuring Documentation
Yes, this needs to be included too. Again, we need to reduce the overhead of developing and maintaining documentation. OSLC4J documentation is managed through http://git.eclipse.org/c/www.eclipse.org/lyo.git/ . Other eclipse/Lyo documentation has already migrated to GitHub pages at http://oslc.github.io/developing-oslc-applications/ . Individual projects might find the GitHub wiki an adequate place to put documentation linked from the GitHub project readme file.
One issue with the eclipse/Lyo documentation is that too many things are coupled together in the same documentation set. Refactoring the documentation could help separate these concerns making it easier to address key documentation update needs without getting bogged down into lots of other things.
I think the action we need from the eclipse/Lyo dev community is whether or not we want to do this refactoring activity. And then we can look at the mechanics of how to do it, and the details of what should be refactored where.
From: Jad El-Khoury <jad@xxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 02/07/2017 03:35 AM
Subject: Re: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
Sent by: lyo-dev-bounces@xxxxxxxxxxx
Hi Jim,
I like the proposal in the large. Some of these components will certainly benefit from a lightweight process if placed on GitHub.
But it would be nice to maintain a common community across both. (Common mailing lists, bug tracking(?), etc.)
Do we even know who has access to GitHub’s Lyo accounts today?
And, I just draw your attention to another set of contributions we need to consider. Namely, adaptor implementations that I don’t believe fall in the Samples nor Reference Implementations categories. For example, we have the repositories org.eclipse.lyo.adapter.magicdraw.git & org.eclipse.lyo.adapter. simulink
Besides structuring our repositories, I would also be nice if we can also put some effort in improving and structuring our documentation. I believe we currently have a number of variants of the Bugzilla tutorial at the moment.
I have otherwise some detailed comments, but I guess we can take that once we start executing.
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@xxxxxx, www.kth.se
From: lyo-dev-bounces@xxxxxxxxxxx[mailto:lyo-dev-bounces@eclipse. ] On Behalf Of Jim Amsdenorg
Sent: 03 February 2017 18:31
To: Lyo project developer discussions
Subject: [lyo-dev] Strawman Proposal for Refactoring eclipse/Lyo
In order to improve the usability of eclipse/Lyo contributions, and in particular OSLC4J as a means of developing OSLC client and server applications, eclips/Lyo might benefit from some refactoring to better separate concerns, different RIO implementation architectures, client and server development, etc. It may also be useful to consider moving some of the RIO and sample code to GitHub as these projects perhaps don't need, or are not sufficiently benefiting from the eclipse.org governance processes.
Attached is a draft proposal for this refactoring for consideration by the eclipse/Lyo community.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________ https://dev.eclipse.org/
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visitmailman/listinfo/lyo-dev