LUMIERA.clone/doc/devel/rfc/GitSubmoduleTransistion.txt
Ichthyostega 051cb31e28 clean-up: re-classify essential RfCs
The RfC documents were written to complement discussions of the Lumiera developers;
yet since the time where ''Ichthyo'' is working basically alone on the project,
this kind of discussions have ceased. During the following years, some ideas
promoted by the existing RfC documents became rather detached from the
actual state of development in the code base.

Many of the existing RfC documents require some commentary to place them
into context, and some of the decisions taken in the early stage of the
project should be **re-assessed**. This includes the decision to reject
some proposals, which initially might have seemed desirable, yet could not
be reconciled with the understanding of the matter and topic in question,
as was gained through the ongoing analysis and development.
2025-10-08 00:48:13 +02:00

114 lines
3.2 KiB
Text

Design Process : Submodules
===========================
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2008-04-09_
|*Proposed by* | ct
|====================================
Use Git Submodules to organize the project
------------------------------------------
We planned this long time ago when the project started, this proposal is for to
work out the details and define a turnover point in time.
Description
~~~~~~~~~~~
There is a `git-filter-branch` command which helps in doing the dirty work
isolating commits which touch certain dirs. This can moderately easily be used
to create a new repository with a rewritten history containing only sub parts
of the original history.
The basic idea is that one developer who wants to works on a certain subsystem
clones the ``official'' master and then updates and tracks only the development
state of a certain subsystem.
Tasks
^^^^^
* what shall be in the master repository?
** boilerplate files, license, build infrastructure
** the _admin_ dir with supplemental scripts
* define which submodules shall be defined?
** _doc/devel_
** _doc/user_
** _wiki_
** _uml_
** _src/backend_
** _src/proc_
** _src/gui_
** _src/lib_
Not yet decided:
* _tests_ move them into the `"src/$subsystem"` as symlink?
* _src/tool_
Pros
^^^^
* better isolation of single subprojects
* one who is interested on one subproject can track a master and only
following certain subproject updates
* smaller/faster updates/downloads
Cons
^^^^
* needs some more Git-fu to be used by the developers
* we will host considerably more Git repositories (bigger list in gitweb),
this is not a problem but might look more confusing
Alternatives
^^^^^^^^^^^^
Go as we do currently with one big repository per developer. The decision to
use submodules is not urgend and it can be transfered at any time. The
turnaround should just be planned and be scheduled to one day to minimize the
confusion and merging issues.
Rationale
~~~~~~~~~
When all people get used to it it allows a cleaner more sane work flow and well
isolated, less conflicting commits.
Conclusion: Dropped
-------------------
The extended usage of Git Submodules for parts of the code base is not desirable.
Comments
--------
.State -> Parked
We concluded that that submodules are not yet needed with exception for the
./doc folder. Parked for now.
ct:: '2008-07-26 09:09:57'
.State -> Dropped
Git Submodules were a highly anticipated feature at the time when the
Lumiera project started -- yet the actual implementation was generally
perceived as a disappointment, since the tooling failed to provide that
kind of seamless integration into everyday Git usage as was desirable.
There remains one area however, where the Lumiera project might revisit
the idea of using Submodules: our _Website_ -- which might become a portal
to integrate several rather loosely coupled efforts eventually, notably
the public front-end, including some images, a user documentation section,
the technical documentation and possibly a knowledge base maintained
separately.
Ichthyostega:: '2025-09-25'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]