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