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:
All core packages and all the package that we can provide 2 year
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'.
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
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?
Received on Fri Jul 17 2015 - 16:59:16 UTC