Great, keep it going and thanks for the hard work!
2015-07-28 15:22 GMT+01:00 David Greaves <da...@dgreaves.com>: > 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: > mer-general+unsubscr...@lists.merproject.org> > >
