Hi all
We've been working on the Nemo/Mer merge on and off for some time now and wanted
to provide an update.
There's tl;dr; job if you're a maintainer: login to git.merproject.org so the
system 'sees' you and can grant permissions.
The goal of this task is to merge the middleware packages from Nemo into Mer
Core and to move the git hosting from various Nemo and Mer repositories
scattered around github and other services into mer-core on git.merproject.org
(g.m.o)
These are the main tasks:
* provide a mechanism to manage maintainer access rights
* create git repos on git.merproject.org
* ensure Mer OBS / webhooks point to g.m.o
* Improve visibility of Mer source/packages/maintainers
Improving Visibility
So, tackling the last point first there's a new "dashboard" here:
http://www.merproject.org/dash/index.html
(That url may well change)
The data shown is taken from :
* Maintainer file (see below) is the master for who has owner/master roles on
the git repos (when they move to Mer git)
* OBS _service files and other OBS data
* Mer gitlab
* Mer LDAP maps usernames to emails/real names
I'll add webhook data soon and it will master the mapping from git repo to OBS
packages
There are still some issues but it's best to get a first draft out.
Managing Maintainership
The approach taken for the maintainer rights is to create a text (yaml) file
that describes the access rights (developer/owner) for all the mer-core packages.
https://git.merproject.org/mer-core/Maintainers/blob/master/maintainers.yaml
This allows anyone to quickly find out who maintains a particular package and
also allows automation systems to apply these permissions to g.m.o
The commnity manages this file: anyone can submit a MR to it to change the
maintainership and if it's accepted by the mer-core maintainers the permission
changes will automatically be applied (well, eventually).
Purely for ease of management/comprehension the file format supports the notion
of teams and package-groups but these are not reflected in gitlab for various
reasons. The team/group names are pretty arbitrary and can be changed trivially
- they just provide some context for the grouping.
Creating git repos
We've replicated about 170 repos from github projects:
https://github.com/[nemomobile, nemomobile-packages, mer-packages]
What I've done (hopefully!) is to take the current/old Mer master branch and
rename it to master-premerge. Then I've set mer/master to be the github master.
In some cases where we've moved on from the old 'tarballs in git' there may be
no commits in common and we'll end up with an 'orphan' branch (google it)
Maintainers should check the repos to make sure I've not messed up :)
OBS
We'll be setting up webhooks for mer-core which should never need modifying. I
suspect that the OBS mer-core project will just have a few caretakers to handle
new packages on request.
Next Steps
* These maintainers should login to https://git.merproject.org/ :
amccarthy antseppa blam chriadam giucam hmallat jpetrell mikkoh monich mvogt
pgerdt phdeswer rbraakman rozhkov sletta spiiroin VDVsx Venemo Vesuri
* As development moves from github to mer-core the github repos should have a
redirection commit added (ie delete all files and create a README that sends
people to g.m.o)
David/lbt
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
--
To unsubscribe send a mail to :
<mailto:[email protected]>
