| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Andrew Gaffney wrote: |
| 5 |
> That's not the issue. The issue is that there should *already* be a |
| 6 |
> releng liason, but nobody from releng seems to know anything about this |
| 7 |
> project. |
| 8 |
> |
| 9 |
|
| 10 |
I dunno . . . does releng really need to be involved, except if these stage4 |
| 11 |
tarballs were to be included on regular 200X.X media? |
| 12 |
|
| 13 |
I simply don't see why this has to be a releng project -- I'm surprised anyone |
| 14 |
thinks it should be. Give releng a break; they have enough hard work to do. |
| 15 |
That's my mindset, anyway. Seems to be that any project could roll up a stage4 |
| 16 |
release for their stuff (LAMP, GNAP type stuff comes to mind immediately) using |
| 17 |
existing stages, since they've already been validated, else releng wouldn't have |
| 18 |
released 'em in the first place. |
| 19 |
|
| 20 |
The potentially tricky issue I see is the question of support -- supposing one |
| 21 |
project screws up their canned stage -- who takes the blame? Who takes the QA |
| 22 |
hit? Probably there should be some central guidelines/plans/docs on the stage4 |
| 23 |
process, so that it can be adhered to and be beneficial for more than one project. |
| 24 |
|
| 25 |
I'm still getting used to this new definition of "stage4" -- on the forums at |
| 26 |
least, the concept of stage4 has been around for years, though its definition |
| 27 |
refers to canned backups of one's current system. ;) |
| 28 |
-----BEGIN PGP SIGNATURE----- |
| 29 |
Version: GnuPG v1.4.5 (GNU/Linux) |
| 30 |
|
| 31 |
iD8DBQFFEZzJrsJQqN81j74RAv4IAJ93bRpfuLvJ7vrmquYi+cETE/J+VgCghXZv |
| 32 |
hIokAc23Y7BZfacMFe70wmI= |
| 33 |
=hAV2 |
| 34 |
-----END PGP SIGNATURE----- |
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives