Date: Fri, 17 Jul 2015 16:59:16 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] reorganize the repositories
Message-ID: <20150717165916.5f26f656@ncopa-desktop.alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

The 'main' repository has grown big.

I feel that we have more packages than we can maintain for 2 years. I
don't mind that we have tons of packages, but there are many packages
that I only want give best-effort support for security fixes instead of
supporting it for 2 years.

Too many files/dirs in a directory is not good for performance also.

So the idea is to split main, or reorganize the repositories as:

- main
  All core packages and all the package that we can provide 2 year
  support for.

- community
  All the extra packages that community maintains. This repository will
  be available in stable releases but we only provide best-effort
  support for bug and security fixes. None of the packages in 'main'
  repository can depend on anything in 'community'.

- staging
  This is basically current 'testing', but we rename it to make it
  clear that packages are not supposed to stay here forever. We might
  want autopurge packages that has not been moved to 'main' or
  'community' repo. Once a package is tested and confirmed to work, it
  can be moved to either community or main.

We would have a gitolite group, 'maindevs' and another 'communitydevs'.
People in community group may git push to 'community' repo but not
'main' repo. This is so that maintainers can push packages themselves,
without needing to send patches, like they currently do. The recent
move to gitolite makes this possible.

We could also give maintainers git push access to only the packages
they maintain, but I think that would complicate things more than
needed.

Other alternatives is that we introduce categories ala gentoo, and the
bsd ports, but I would prefer avoid this. We'd need to decide what
package belongs in what category. They can often fit into many.

What do you think?

Other ideas?

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---