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/maintaine
> rs.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
>
>
