[R-pkg-devel] Update timing of machines on CRAN?

[Andrew Robbins]

I can't help with providing servers, but if the primary issue with 
builder software maintenance is manpower I would be more than willing to 
contribute and I imagine others would be as well. Perhaps logistically 
challenging, but more than doable.

-Andrew

On 12/4/2023 5:11 PM, Uwe Ligges wrote:
> Thanks for your offer to providing us with capable multicore servers 
> and support staff for continuing support of recent Fedora systems.
>
> Best,
> Uwe Ligges
>
>
> On 04.12.2023 18:09, andrew--- via R-package-devel wrote:
>> I do think that its a reasonable ask that the test machines be 
>> running operating systems within their vendor support periods.
>>
>> -Andrew Robbins
>> ________________________________
>> From: R-package-devel <r-package-devel-bounces using r-project.org> on 
>> behalf of Josiah Parry <josiah.parry using gmail.com>
>> Sent: Monday, December 4, 2023 11:34 AM
>> To: Tomas Kalibera <tomas.kalibera using gmail.com>
>> Cc: R Package Development <r-package-devel using r-project.org>
>> Subject: Re: [R-pkg-devel] Update timing of machines on CRAN?
>>
>> Unfortunately, it is often important for us to pay attention to what
>> machines our code is being tested on.
>>
>> I think the point is more or less that we often find ourselves trying to
>> make super small adjustments for machines and builds that are used by a
>> number of users in the single digits. The vast majority of R programmers
>> are not on these arcane machines. We should strive to support the vast
>> majority of users who use *fairly* standard distributions such as Mac,
>> Windows, Ubuntu, Debian, and maybe even Centos. Getting a note for a
>> release which has reach EOL can be confusing and tough to know how to
>> handle.
>>
>> On Mon, Dec 4, 2023 at 10:17 AM Tomas Kalibera 
>> <tomas.kalibera using gmail.com>
>> wrote:
>>
>>>
>>> On 12/4/23 15:44, SHIMA Tatsuya wrote:
>>>> Thanks for your answer.
>>>>
>>>> Unlike Windows Server, which has a long support period, Fedora's
>>>> support period is usually about one year, so it is surprising that the
>>>> old Fedora continues to be used.
>>>> And, unlike Windows, Linux uses the distribution standard packages for
>>>> builds, which causes problems like the current Fedora machine that
>>>> continues to use the old Rust.
>>>
>>> The configuration currently at different CRAN machines is just a sample
>>> of what your users might have, just an example of a setting packages
>>> should be able to deal with. Some users might also still have FC36, 
>>> some
>>> might have another Linux distribution (possibly still supported), which
>>> has older software than that.
>>>
>>> I wouldn't recommend spending time tracking which version of which
>>> software CRAN systems currently happen to have, but rather making sure
>>> packages can deal with different versions (possibly with some in a
>>> restricted way, possibly making some hard requirements when necessary).
>>>
>>> Best
>>> Tomas
>>>>
>>>> Hope to see an update soon. Thanks to the staff for maintaining the
>>>> infrastructure.
>>>>
>>>> Best,
>>>> Tatsuya
>>>>
>>>> On 2023/12/01 23:43, Uwe Ligges wrote:
>>>>>
>>>>>
>>>>> On 01.12.2023 13:28, SHIMA Tatsuya wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I maintain the prqlr package that uses rustc for compiling, so I
>>>>>> regularly check the version of Rust on CRAN.
>>>>>> And I have noticed that the Rust version of Fedora has been stagnant
>>>>>> for the past few months and was wondering why, but upon
>>>>>> investigation I realized that this is because Fedora on CRAN is
>>>>>> currently Fedora 36 (out of support in May).
>>>>>> <https://cran.r-project.org/web/checks/check_flavors.html>
>>>>>>
>>>>>> It was quite a surprise to me that out of support Fedora is being
>>>>>> used, but what is the normal cycle for machines on CRAN to be
>>>>>> updated? And do we have any way of knowing that schedule?
>>>>>
>>>>> It depends on the maintainer who cares about these machine, the
>>>>> institution where it is hosted, the availability of technical staff,
>>>>> and the technical pressure.
>>>>>
>>>>> I could not even say when the machines I maintain will be updated.
>>>>> On one version of the retired winbuilder severs we kept the same OS
>>>>> version for almost 10 years.
>>>>>
>>>>> Best,
>>>>> Uwe Ligges
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Tatsuya
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-package-devel using r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>          [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>     [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Andrew Robbins
Systems Analyst, Welch Lab<https://welch-lab.github.io>
University of Michigan
Department of Computational Medicine and Bioinformatics


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20231205/3ccf5e3a/attachment.sig>