| 1 |
On 11/03/2013 05:05 AM, Rich Freeman wrote: |
| 2 |
> On Sun, Nov 3, 2013 at 12:03 AM, Ben de Groot <yngwin@g.o> wrote: |
| 3 |
>>> |
| 4 |
>> |
| 5 |
>> We already have an existing policy, which is option 1. |
| 6 |
> |
| 7 |
> Citation? |
| 8 |
> |
| 9 |
> I've been masking live ebuilds with option 2 ever since QA filed a bug |
| 10 |
> telling me to - I don't think that policy was written down either. |
| 11 |
> |
| 12 |
> What is written down is: |
| 13 |
> "Live" cvs.eclass ebuilds are generally only intended for the |
| 14 |
> convenience of developers and should always be masked with a ~[arch] |
| 15 |
> keyword. [1] |
| 16 |
> |
| 17 |
> That would be none of the above - half the tree is "masked" with ~arch |
| 18 |
> keywords. I'm not suggesting that this is the right way to do it - |
| 19 |
> only that there certainly is nothing approaching a clear policy on the |
| 20 |
> matter. |
| 21 |
> |
| 22 |
> Rich |
| 23 |
> |
| 24 |
> [1] - http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1&style=printable |
| 25 |
> |
| 26 |
|
| 27 |
I feel that we need some way for live ebuilds to be unmasked. For |
| 28 |
instance, there are openstack ebuilds are available that track stable |
| 29 |
branches in git. These are very useful as they tend to get bugs before |
| 30 |
a release is made. Backporting patches is no fun. I could see 9999 |
| 31 |
packages getting p.masked but not something like 2013.1.2.9999. |
| 32 |
|
| 33 |
-- |
| 34 |
-- Matthew Thode (prometheanfire) |
Archives