| 1 |
Ciaran McCreesh <ciaranm@×××××××.org> wrote: |
| 2 |
> Supporting this would be a huge policy violation, and not so merely as |
| 3 |
> a technicality. |
| 4 |
|
| 5 |
How's that? I agree that this timely response clause will mean ion-3 will |
| 6 |
never go stable. That's the only thing i could envision to be a policy |
| 7 |
violation. |
| 8 |
|
| 9 |
> I suggest simply removing ion support from the main |
| 10 |
> tree, and sticking it in an overlay that comes with a big warning |
| 11 |
> telling users that they cannot expect any level of QA for those |
| 12 |
> packages. |
| 13 |
|
| 14 |
Care to expand on "no QA"? Tuomo fixed several QA warnings upstream (missing |
| 15 |
strlen, etc. includes) when i told him (there will be patches on our side |
| 16 |
until the next _rc). |
| 17 |
Additionally i'd like to point out the bit where he says he don't want this |
| 18 |
license to hinder distributions who just stick with upstream, which our policy |
| 19 |
explicitly recommends. That's why i'm trying to reach a compromise on those |
| 20 |
USE patches we apply. That's why the next build will tell ppl to bug me first. |
| 21 |
|
| 22 |
In general: i don't think forking is an option. I won't be maintaining a fork |
| 23 |
myself to begin with. If the general feeling is that ion is unacceptable in |
| 24 |
the tree, i'll mask it pending removal. |
| 25 |
-- |
| 26 |
Regards, Matti Bickel |
| 27 |
Encrypted/Signed Email preferred |
Archives