I lilke the idea of *staging and then move to 'main' or to 'community' repo*.
But just to make sure it is clear, let me quote you:
> *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.*"
Does it mean that *everybody *that asks for write access in 'community'
will be accepted to git push to it? In case of an 'yes', this is the piece
that I don't like - I'd vote to everybody continue sending patches to
'community' except some approved ones.
Another quote ref. staging repo:
> *We might want autopurge packages that has not been moved to 'main'
> or'community' repo*"
It might be great! But i think we'll need to keep track of packages purged
just in case someone requests a package that were in staging for a period
and was purged - Or any other way to avoid that we fall in a loop adding
package and purging it over and over again (nowadays there are packages in
testing being used for users and, it may happen that, once we purge it, the
user will miss the package and request *new [old]* package).
> *We could also give maintainers git push access to only the packages*
> *they maintain, but I think that would complicate things more than*
I agree with you - I wouldn't vote to use this.
About the 'staging' repo: I like this name but I also like NetBSD's idea of
*wip* (stands for *w*ork *i*n *p*rogress). Maybe staging could be called
On Fri, Jul 17, 2015 at 11:59 AM, Natanael Copa <ncopa_at_alpinelinux.org>
> 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
> 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?
> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
> Help: alpine-devel+help_at_lists.alpinelinux.org
Alan Messias Cordeiro
*The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait
another year until the one arises you are looking for. -- A. Tanenbaum,
"Introduction to Computer Networks"*
Received on Fri Jul 17 2015 - 15:57:40 GMT