| 1 |
On 2019-07-18 11:12, Kristian Fiskerstrand wrote: |
| 2 |
|
| 3 |
> Should we be more specific as to how not to enable it here? is it a |
| 4 |
> USE-flag? does it require a package mask for newer versions if it is |
| 5 |
> always used for the newer ones? |
| 6 |
|
| 7 |
Good point, this should explicitly say "do not emerge new versions". My |
| 8 |
own thoughts on the matter have been that since we are now in the |
| 9 |
process of stabilising syncthing-1.1.4 (i.e. the latest version which |
| 10 |
does not force the use of large blocks) and that I do not intend to push |
| 11 |
the 1.2.0 ebuild until stabilisation has been concluded, it would be up |
| 12 |
to individual users to mask newer versions should they insist on using |
| 13 |
~arch ebuilds. |
| 14 |
|
| 15 |
> Also cluster immediately made me think of server<>client relationship |
| 16 |
> and this only affecting server side, which probably doesn't fit well |
| 17 |
> with syncthing, but admittedly I don't use it so not familiar with the |
| 18 |
> nomenclature. |
| 19 |
|
| 20 |
I guess it is a bit subjective and/or based on one's experience, in my |
| 21 |
case "cluster" brings to mind a cluster of peers. Anyway, this is the |
| 22 |
wording from the official upstream statement so I would rather not |
| 23 |
change it unless there is a good reason for it - like the |
| 24 |
Gentoo-specific clarification you have suggested above. |
| 25 |
|
| 26 |
PS. For the record, I have already published this news item (a couple of |
| 27 |
hours ahead of schedule I am afraid, I didn't remember the exact time I |
| 28 |
submitted the RFC) so I'll include your comments in the second revision. |
| 29 |
|
| 30 |
-- |
| 31 |
MS |
Archives