Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-scm@g.o
From: Robert Buchholz <rbu@g.o>
Subject: Re: Splitting gentoo-x86 repository for easier consumption
Date: Sat, 11 Apr 2009 17:47:09 +0200
On Saturday 11 April 2009, Maciej Mrozowski wrote:
> Let's look at tree - one thing can be said about each package - it
> belongs to some herd or (doesn't, and it's with status maintainer
> wanted or maintained by individual developers).
> So creating separate repository for each herd is the most obvious
> (and naive) idea.
>
> Pros are the following:
> - project members  taking care of some herd (or belonging to herd?)
> receive (and have access) (only) to repository they are interested
> in, resulting in smaller pulls/pushes
> - some level of isolation - gives possibility to restrict access (for
> example: "only toolchain and arch teams allowed here")
> - some testing overlays could now just track their tree counterparts
> - merging stuff from testing to tree could be semi-automatic and
> trivial - alternative projects - like hardened - can just have
> separate branches when appropriate - for easy merges with "main tree"

Why would hardened have an easier job branching off multiple single 
repos than one large repository?


> - profile can be (should be actually) separated in another repository
> and developed easier

The whole modle of profiles (and keywords, for that matter) is worked 
out so we do not need branches. We keep ebuilds in one tree and define 
visibility for the "branches" (from a user's PoV). Do you really think 
actually branching off makes it easier for anyone? Who would push 
changes to the 50.. something profiles? Does ~sh get more usable if 
maintainers don't push trivial updates to that branch anymore?

> Some cons:
> - projects are now more dependant on other projects and its
> responsiveness, unless access is granted to all repositories for
> every developer - needs some basic tools to 'glue' final repository
> and ready it for rsync - possibly needs better multiple repositories
> support in Portage (not sure though)
> - profile no longer there
> - to fully benefit from git - robbat2 would need to propose his slim
> manifest format as GLEP (or in case of lack of time - quite possible
> - get someone else to do it) and get it implemented by someone.
> - probably not easy way to migrate from monolithic gentoo-x86 to
> split sub- repositories retaining complete history
> - not settled yet what to do with orphaned/proxy maintained packages
> and herd- switching

We have been over the "splitting" by category/feature/herd part before 
and had not reached a consensus.

Personally, I do not see overall tree QA improving.
Long before I joined Gentoo a decision was made deliberately to give 
write access for each directory to each developer. And it allows me to 
responsibly fix bugs that others cannot currently handle, and I can 
tell others to commit fixes to the ebuilds that carry my name in 
metadata.xml. It also allows for easy tree migration efforts (big 
renames, or the recent use dependency changes), keywordings and it 
allows the security team to mess around with other people's kittens if 
they slack.



Robert
Attachment:
signature.asc (This is a digitally signed message part.)
References:
Splitting gentoo-x86 repository for easier consumption
-- Maciej Mrozowski
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Splitting gentoo-x86 repository for easier consumption
Next by thread:
Re: Splitting gentoo-x86 repository for easier consumption
Previous by date:
Re: Splitting gentoo-x86 repository for easier consumption
Next by date:
Re: Splitting gentoo-x86 repository for easier consumption


Updated Jun 17, 2009

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.