1 |
Hi Thomas, |
2 |
|
3 |
Usually, our main "requirement" was presence of the active maintainer. As you |
4 |
are, apparently, its maintainer, I say all the decisions are up to you ;). Can |
5 |
you keep the old version in the tree (it is not broken after all, as I |
6 |
gather?) and provide a new one in the overlay for a time being? May be the |
7 |
upstream will come to its senses and you will be able to reintroduce newer |
8 |
version to the tree later? Or, even simpler, what's the problem with just |
9 |
keeping the new version unstable until new "unbroken" one is introducedor the |
10 |
"new way"becomes accepted? |
11 |
|
12 |
George |
13 |
|
14 |
On Sunday 28 July 2013 21:25:53 Thomas Kahle wrote: |
15 |
> Hi, |
16 |
> |
17 |
> what are our current heuristics to decide if a package goes into main |
18 |
> tree or stays in the science overlay? Two years ago I spent a lot of |
19 |
> time to get my beloved Macaulay2 tree ready and we even had a stable |
20 |
> version (getting old now). Stabilising a new version is blocked among |
21 |
> other things because the build system does not respect a custom AR (bug |
22 |
> 474784) and RANLIB (bug 474788). Even if its not too hard, I'm not |
23 |
> going to fix those. This would be just ridiculous. I probably know all |
24 |
> the users of Macaulay2 on Gentoo personally. None of them want to use a |
25 |
> different ar. So, should I treeclean M2 and move it back to overlay |
26 |
> only? |
27 |
> |
28 |
> Cheers, |
29 |
> Thomas |