We also put effort into setting up multiple
repositories. Hence, I want to be sure a single repo is what
we want :)
The original structure was beneficial when I
had multiple students with multiple theses working on
Californium. Now, with an established team and better
processes, I totally buy that we can still maintain multiple
focus areas in the code. A big share of the effort so far
actually went into the distributed POM definition and
artifacts, which we probably can continue using almost
unchanged. And I read your messages more or less as +1s for
having a single repo.
For now, we could keep tools and actinium
separate and break the version linking.
Again, first let’s release 1.0.1 and then do
the refactoring. I would create a “unification” branch in
the parent repo (“californium”), add the complete code base
there, and do the POM adjustments.
I wondered the same: Can we somehow keep and
merge the current commit logs? My guess would be to use
rebase to chain all commits from the different repos…
Should we proceed like this?
Ciao
Matthias
I mainly
agree with Kai.
If projects have same release/life cycle, this probably make
sense to regroup it. I don't see any problem for
element-connector, core and scandium. For actinium and
tools, it's hard to say for me as I don't really know those
projects.
About commit logs visibility, if we avoid merge and use
rebase (interactive), we can have a readable repository.
What about current history if we merge repository ?
Simon
Le 13/01/2016 18:31, Hudalla Kai
(INST/ESY) a écrit :
Having multiple repositories has required a
lot of effort to maintain consistent versioning and
build process. I think we could still have clearly
distinguishable discussions around issues and PRs, e.g.
by using appropriate tags for the individual modules.
Regarding the separate commit logs, I do not really see
the big advantage of that. On the other hand, having a
single repository (and build) would make it easier to
detect problems/incompatibilities/API breaks changes in
one module introduce in other modules. We could still
produce multiple artifacts but I think overall
management of the code base would be much easier if we
only had one code repository. We could also still have
different committers have different “focus” areas in the
code base based on the sub-modules (e.g. core,
element-connector, scandium etc).
However, if we stick with the different
repos we should definitely use the same branching
strategy for all of them, otherwise I think we will have
a hard time maintaining consistency between them.
Do you mean having everything from
element-connector to Actinium in a single repo?
I see the point of reducing the
maintenance effort. However, it would also convolute
the development tracks. I found it actually quite nice
that Scandium has had its own track, with separate
DTLS-specific issues, discussions, etc. (also commit
logs). Also forking out the Actinium development as we
did over the last months was quite convenient (I still
have to merge it back into the Eclipse repo).
Simon, Kai, how do you feel about this
from the Scandium perspective?
Ciao
Matthias
Since all the project are
released on the same life-cycle, why not first
merging everything in the same git repo?
I
would make having 3 branches more sustainable.
Julien
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev