Those have always been considered as part of middleware (lipstick is a framework), Nemo UI/Glacier still sits on top outside mer core
2015-07-29 18:10 GMT+02:00 Timur Kristóf <timur.kris...@gmail.com>: > Hi, > > Just one question: how (if at all) does this change affect Nemo's UI and > its UI-related libraries (such as lipstick, mlite, ... etc)? > > Best regards, > Timur > > On Tue, 2015-07-28 at 15:22 +0100, David Greaves wrote: > > 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 > > > >
