This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Holger,
On Sun, Apr 23, 2017 at 01:04:56PM +0200, Holger Freyther wrote:
> for the topic of making "releases" I wondered if we want to explore
> using "repo" to tie the different Osmocom repositories into a single
> "release". Below is an example "default.xml" that would make up a
> release. The default.xml would be maintained in a git repository that
> we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I would still suggest that the "release" tags should also be made in all
the individual repositories. Otherwise, while looking at git history in
an individual repository during development/review, it is not obvious
which patches are in which release or not.
So having the specific 'git commit' IDs into repo and bypassing release
tags inside the individual git repositories, you are taking this
information out of the individual repositories. I don't generally think
that's a good idea.
So if at all, I believe 'repo' should refer to tags inside the
inidvidual repositories [not sure at possible], or the
repository-individual tags should be auto-generated in the same process
when generating a new xml file in repo.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)