Hi!
On Tue, 14 Jun 2016, Rich Freeman wrote:
> 1. Developers wouldn't have access to all the ebuilds in the curated
> repositories. They would only have access to the ones they contribute
> to.
> 1a. You could accept a contributor into a small project and not have
> to give them access to the toolchain/etc. Of course, they're still
> messing with curated packages so you don't want just anybody in there.
> 2. Exherbo at least requires peer review for all commits I believe.
> So, even if you're committing to your "own" overlay you're still going
> to need review if your overlay is a curated one.
> 3. Just as with Gentoo if something is curated you can generally
> count on it to follow QA, and if it is in a non-official overlay then
> it is anything go and it is probably not to rely too heavily on things
> like sane version numbering, deps that don't just disappear, etc.
> 4. If somebody really does need to make a "tree-wide" change they're
> going to need access to a bazillion repos or they'll need to ask
> everybody else to commit it for them.
> 4a. Conversely, people who probably shouldn't be making "tree-wide"
> changes won't.
> 5. To the extent that repos contain closely-related packages you can
> probably make much more effective use of git branching and so on. You
> would still be limited by any dependency relationships outside the
> repo.
6. Arch teams would have access to any and all repos that they do
testing on -or- AT work woulkd have to be split between testing
and doing the actual commits.
I very much would not like the second option: it's more
coordination overhead, more space for miscommunication and
increases delays from request to commit (which can be very bad in
the case of security bugs).
Just my CHF0.021 (adjusted for inflation),
Tboas
--
printk("NULL POINTER IDIOT\n");
linux-2.6.6/drivers/media/dvb/dvb-core/dvb_filter.c
