[M3devel] Some M3 maintenance questions

[Rodney M. Bates]

On 03/05/2015 08:58 AM, Olaf Wagner wrote:
> On Sun, 01 Mar 2015 17:26:19 -0600
> "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
>
>> I don't seem to have access to cm3-bugs.elegosoft.com, to update trac.
>> I have asked michael? to give it to me.
>
> OK. I spoke with Michael about you and M3 at Elego, but I haven't
> seen an answer from him, so I don't know if he got back to you.
>

Not yet.

>>>> 1) Olaf, are you intending to continue hosting the web pages?
>>>
>>> Elego can do still do that if no one else volunteers. I cannot
>>> guarantee more that a couple of minutes administration time per
>>> week though. We're rather short of ressources currently.
>>>
>>>> 2) How can I update these?  There appear to be copies of some/many of them
>>>>       in the cm3 repository, but these are not served from there as web pages,
>>>>       AFAIK,
> [...]
>
>> I can log in to birch.  Poking around, I find that
>> birch.elego.de, modula3.elegosoft.com, hudson.modula3.com, and www.opencm3.net
>> are the same machine.  I find I also have a password on this machine as well.  Is
>> this the way you want it?  I had to supply it to do a dry run of ship-cm3-www.  It
>> is doing rsync birch-to-birch, so I suppose I can generate a new key pair on birch
>> to allow me to access the same machine would obviate needing this password.
>
> Yes, it's all the same VM currently, but it will probably be migrated
> to other servers and services separated.
>
> Yes, you can install any new key you like there.

Done.  I also changed the password.  Do you want me to delete password login
altogether?

>
>>> The shipping scripts can (could?) be found in the packages:
>>>
>>> ./work/cm3-ws/birch.elegosoft.com-2012-04-11-01-34-27/cm3/www/ship-cm3-www
>>> ./work/cm3-ws/birch.elegosoft.com-2012-04-11-01-34-27/cm3/doc/ship-cm3-www-doc
>>
>> I also found copies of these is a number of places, most significanly,
>>
>> /home/m3/work/cm3-ws/birch.elegosoft.com-2012-08-27-02-27-31/cm3/...
>>
>> The scripts are the same, but presumably other stuff is more up-to-date here.
>>
>> There are a _lot_ of differences in this directory that are not shipped to the web
>> directory.  I don't feel like shipping any of it without careful looking, to be
>> sure it is what we want on the web.
>
> Hm, I cannot really explain these offhand. Perhaps its best to ship
> to a sibling directory and then do a diff -r -b -B old new.
>

There is not enough disk space to create a sibling directory, but I have been
diffing directly between the likely place to ship from and the shipped web files.
Looking at just the first file that differs (about-cm3.html), I find the web
version is CVS version 1.14.2.2, in branch release_CM3_5_8_6, and dated 2010-04-29,
whereas the head and just about everywhere I look is version 1.14, dated 2007-05-15.
So the release branch versions are not merged back to the head.  I will work on
figuring out how many files this applies to and get them merged into the git head,
as appropriate.

>>> I'm afraid that the Hudson installation on our server is out of order
>>> for quiet a long time. I don't know of any adaptation even for the
>>> source checkout from Github.
>>>
>>> I think some other public server should be used now for builds and
>>> tests. The old scripts could be adapted, but most people prefer to
>>> do these things in their own way. I used shell in 2010, but many
>>> scripts have been rewritten in python after that.
>>
>> Does anybody have a server to suggest here?  I think a couple of my own machines
>> would have enough storage, RAM, CPU, and possibly network capacity for the builds
>> themselves if run only in overnight hours.  But I definitely do not have the
>> networking capacity for the web pages.  This would be for on AMD64_LINUX, and maybe
>> LINUXLIBC6.
>
> I don't really know one offhand now. As far as I know Github does not
> have it's own build service. But Mike has suggested that if you don't
> find a suitable service, we can continue to host the CI server. But
> he wants to abandon the old and outdated Hudson and install a current
> Jenkins system. That would be much easier to maintain, too.
>
>>> You could transfer these jobs to another Hudson or Jenkins system
>>> (the config.xml files should suffice for that), adapt the source
>>> checkout to the Github repository and try to get some builds
>>> running. If you really plan to do that, I offer to help with
>>> all the advice and knowledge I have by answering your questions.
>>
>> With some help, I could take this on.  I have looked briefly at hudson/jenkins.
>> It looks like there is enough info there to get things going.
>
> Look at Jenkins, this is the current free open source variant.
>

I've started looking at it.  I has some hudson->jenkins conversion instructions.

>> The most daunting part for me is mediocre network access.  My latency has recently
>> improved enough so that command-line character echo has gone from just about
>> unusable to marginally usable.
>
> That's annoying of course. Excuse my curiosity: where are you located?

Tallgrass prairie, in the flint hills of eastern Kansas, where I have wanted
to live for decades.  But I am just barely out of reach of two land-line and one
ground-level radio internet services, in one case, by just 200 feet, and by
regulatory, not technical limitations.  Fortunately, my satellite ISP has recently
improved the round-trip latency from ~1.5 sec to ~.8 sec. which is just marginally
usable for command-line access.

>
> Olaf
>

-- 
Rodney Bates
rodney.m.bates at acm.org