If you want central control of what's happening in the repository,
Subversion seems like the way to go.
Better to fix the design of the repository, so that it can't be
broken in the first place, than to try putting band-aids in place
to cover the gaps.
Wow, way out of scope.
Sure, a Portage that's inherently unbreakable would be nice.
And infinitely more difficult to carry out than what I was proposing.
Also, the two (QA inline in commit process vs. Perfect Portage) does
not preclude each other. While one may be better long term you
can still do the other to improve quality short term.
(Not that you would need to - if you had a QA step in the commit
process to make sure that ebuild dependencies were never broken,
why would you want to create a whole new Portage?
I was trying to say that a QA tool in form of a SVN pre-commit hook
seems like a perfect fit. The entire infrastructure to run an
external application to check a commit before carrying it out,
approve the commit, send appropriate error messages back to the SCM
client and display them to the user etc. is already in place (and
has been for years) in the Subversion server and any of the client
tools.
The amount of work involved between inventing a couple of rules that
committed ebuilds must obey to actually implementing an enforcement
of said rules is _very_ overcomeable with SVN.
I wasn't even proposing that Gentoo actually needs a QA tool inline
in the process, just saying that it can easily be done [with SVN] :-).
PS. I resent calling it a band-aid. It'd be a QA tool built on the
very well-thought-out foundation for quality assurance of commits that
SVN pre-commit hooks happens to be.
--
gentoo-dev@gentoo.org mailing list
