docs: add DR-002-strat for Eclipse project structure decision#2926
docs: add DR-002-strat for Eclipse project structure decision#2926antonkri wants to merge 1 commit into
Conversation
github-project-automation
Bot
added this to
S-CORE Roadmap and TLC - Technical Lead Circle
|
The created documentation from the pull request is available at: docu-html |
| S-Core needs to decide how its modules are structured within the Eclipse Foundation and GitHub. | ||
| Two organisational models are under consideration: keeping all modules within one Eclipse project | ||
| (the current approach), or splitting each module into a separate Eclipse project. | ||
|
|
||
| The choice has implications for community governance, Committer nomination processes, GitHub | ||
| organisation management, and the long-term risk to the S-Core v1.0 release. |
There was a problem hiding this comment.
The dicision on wether S-CORE is a platform or a reference integration (i.e. *Supports the idea: "S-Core is a platform"* (e.g. same as Android) and *Supports the idea: "S-Core is a pure integration project"* (e.g. same as Yocto) respectively) was already discussed in DR-001-strat and should therefore be added to the context here.
IMO this DR should only focus on how we can "implement" this decision in a GitHub organization and according to the Eclipse Handbook.
| modules in one Eclipse project leads to the necessity of having a big number of Committers | ||
| with various areas of responsibility. | ||
|
|
||
| - Community management and building is more complicated due to the size of the project. |
There was a problem hiding this comment.
Why is this listed as a con here? No matter if we use separate GH orgs or one GH org the community that we need to be able to establish and steer is the same (according to DR 1 start).
| - S-Core becomes a "parent project" and all other S-Core relevant modules become sub-projects. | ||
| This would make it clear that the modules are part of the S-Core project and it would still | ||
| be easily possible to follow Eclipse project handbook rules for every sub-project, e.g. for | ||
| initial Committer nomination. |
There was a problem hiding this comment.
I dont see this as a mitigation - the cons here would still apply. I see it rather as the only possible option 2 because we already decided that we are targeting a consistent stack that needs central processes and management.
| **We proceed with Option 1 and initiate a Proof of Concept for Option 2.** | ||
|
|
||
| Rationale | ||
| ^^^^^^^^^ | ||
|
|
||
| - There are currently no major blockers that would make the switch to Option 2 obligatory. | ||
| - Switching the structure of the project and module repositories poses a high risk for the | ||
| S-Core v1.0 release, which is planned for the end of the year. |
There was a problem hiding this comment.
Does this DR establish Option 1 as the intended outcome or Option 2 (with a transition via Option 1)?
If Option 1 is the intended target I don't see the reason to do a PoC for Option 2.
2 participants
No description provided.