| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Jul 29, 2004, at 11:33 AM, Cory Visi wrote: |
| 5 |
|
| 6 |
> Theory aside, it really sounds like your two examples and everyone |
| 7 |
> else's |
| 8 |
> follow-ups have do to with the QA time on portage releases. |
| 9 |
|
| 10 |
The amount of time between portage releases is a factor in people |
| 11 |
supporting this, no doubt. |
| 12 |
|
| 13 |
> The real problem is not that these utilities are part of portage |
| 14 |
> releases, but that |
| 15 |
> portage releases take too long to come out. |
| 16 |
|
| 17 |
Unless someone can give me a valid reason why this functionality must |
| 18 |
be bundled, then no, that isn't the problem- the problem is that they |
| 19 |
- -are- bundled with portage. |
| 20 |
|
| 21 |
These utilites are specific to our tree, and should be correct for the |
| 22 |
tree *at that moment*. I really am not fond of the notion that, while |
| 23 |
the ebuild may be correct, the portage version's bundled utilities are |
| 24 |
broke so the ebuild misbehaves. |
| 25 |
|
| 26 |
> Is moving them into the portage tree so every developer can have at it |
| 27 |
> the |
| 28 |
> right solution? Will QA on these "base" utilities be neglected? |
| 29 |
|
| 30 |
The scripts in question are rather simple. The bash functions too, are |
| 31 |
simple, and rarely changes between releases. In other words, |
| 32 |
maintaining them isn't a pita, far from it. |
| 33 |
If they are split out of portage and into the tree, it doesn't |
| 34 |
automatically mean that there isn't going to be any QA applied- if that |
| 35 |
were true, eclass's would be a colossal failure, and would be bundled |
| 36 |
with portage. |
| 37 |
|
| 38 |
Besides, it's not like having this code in portage has somehow |
| 39 |
protected them from bugs. :) |
| 40 |
|
| 41 |
> How can we |
| 42 |
> assure the same type of care with these utilities is taken as with |
| 43 |
> portage |
| 44 |
> releases? |
| 45 |
|
| 46 |
Again, look at our eclasses. The amount of damage a dumb dev could do |
| 47 |
is staggering, yet we have little to no problems w/ them. Why? |
| 48 |
Because releasing a fix is pretty much instantaneous, and any dev in |
| 49 |
that herd can do it. Somebody makes a mistake in an eclass, we can fix |
| 50 |
it right then and there, and only wait a max of an hour for the fix to |
| 51 |
hit the mirrors. |
| 52 |
With a portage release, it takes quite a bit longer. |
| 53 |
|
| 54 |
In terms of who has access to modify this code, I already talked with |
| 55 |
genone regarding this. We use the same type of access control we do on |
| 56 |
eclassess- "soft" access control, fex we break your knees if you commit |
| 57 |
to them and aren't a member of the herd. |
| 58 |
|
| 59 |
If the threat of bodily harm isn't enough, we implement access control |
| 60 |
in cvs. |
| 61 |
|
| 62 |
> I'm not against this move, I just want to discuss these issues. |
| 63 |
Valid issues :) |
| 64 |
Hopefully I've addressed the issues you raised adequately. |
| 65 |
~brian |
| 66 |
-----BEGIN PGP SIGNATURE----- |
| 67 |
Version: GnuPG v1.2.4 (Darwin) |
| 68 |
|
| 69 |
iD8DBQFBCUTXvdBxRoA3VU0RAmKpAJ9mIzToYO+fwBmCeeMhP5BWxDvxpwCbBso4 |
| 70 |
TUrxn1bATGYqMPg1yKdF20k= |
| 71 |
=lDQh |
| 72 |
-----END PGP SIGNATURE----- |
| 73 |
|
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives