[DGD] Where did all the players go?

[Raymond Jennings]

Let's just say...I'm getting a lot of practice learning things that
more experienced people in release engineering take for granted.

On Mon, Dec 11, 2017 at 7:00 AM, Raymond Jennings <shentino at gmail.com> wrote:
> I'm actually struggling with this "upgrade in place" process myself
> with kotaka.  Trying my best to make it as idiot proof as possible,
> and also try to avoid as much hassle as possible for end user code.
>
> Add to this that some of kotaka is designed to be inherited and not
> just called...and you have an API maze to help your end users navigate
> if anything needs to change.
>
> On Mon, Dec 11, 2017 at 6:47 AM,  <bart at wotf.org> wrote:
>> I think this is a good idea.
>>
>> One of the stumbling blocks for people starting with DGD is the amount of
>> effort and knowledge it takes to actually get started. Packaging it such that
>> people can deploy DGD and a mudlib in a 'ready to go' way, and such that the
>> basic installation and running environment will be similar or identical for
>> such users can help a lot with that.
>>
>> While that was a different era, without the ease of pre-packaged containers,
>> creating a 'just download and run this' experience was one of the things I've
>> tried to create when I was maintaining Gurbalib. Its why it came with an
>> installer, included a version of DGD it was tested with, and in general tried
>> to just get someone running and focus on the mudlib and mud development.
>>
>> As you mention, keeping the mudlib uptodate this way is more difficult because
>> of user changes to that lib. I tried to do a few things to reduce this issue:
>>
>> - Make things 'pluggable', ie: Gurbalib's safun setup allowed for adding and
>> overriding afuns in a way that should not conflict with updates to the lib
>> (this is no longer the case in the current version)
>> - Strictly dividing the lib in a 'kernel', 'lib' and 'user' part. Only touch
>> the 'user' part (which included the safun dir)? You should be fine.
>> - Modified the 'lib' part? This should still be relatively easy, but requires
>> work for merging changes
>> - Modified the 'kernel' part? You are on your own.
>>
>> This worked somewhat, but, people find enough reason to modify the lib part to
>> still make this a lot of work for both the maintainer of the core
>> distribution, and the users. Additionally, it also meant a fair bit of extra
>> work to ensure lib upgrades always worked, or in cases where that was not
>> possible, at least ensure they pointed at the proper way to upgrade (requiring
>> specific inbetween versions for migrating data).
>>
>> At any rate, keeping a mudlib distribution uptodate and facilitating in-place
>> upgrades of muds using it is a pretty big challenge due to data conversion and
>> having to provide ways to upgrade user data, even when people do not modify
>> the core lib.
>>
>> Part of the issue here is this being a somewhat unusual approach for most
>> people. Understanding the in-place recompilation of code is already a bit of a
>> challenge, doing proper data conversion seems a bridge too far until people
>> gained significant experience with the system.
>>
>> Another part however is the sheer complexity of supporting in-place upgrades
>> even when people skip inbetween versions, and making it work with the wide
>> variety of things people tend to do once they start using some piece of code.
>> This complexity easily gets in the way of making progress with the lib because
>> of possibly breaking things for others.
>>
>> Regardless, a pre-packaged, 'download and run' distribution will imo remove
>> one of the major stumbling blocks, and seems like a really good idea.
>>
>> But... be prepared to also provide some form of support to those users, else
>> it will not get very far. That means helping users dealing with the more
>> unusual aspects of DGD and their first steps in modifying things to their need.
>>
>> Bart.
>>
>> On Sun, 10 Dec 2017 22:48:03 +0100, Felix A. Croes wrote
>>> DGD's development has always depended on user feedback.  In its
>>> heyday, 50% or more of bugreports and feature requests/suggestions
>>> came from users, with the remainder coming from myself and from muds
>>> that I was associated with.  Right now, that is less than 5%.
>>>
>>> One obvious reason is that users tend pick a version of DGD that
>>> works well enough for them, and then don't upgrade.  DGD is quite
>>> stable in its core feature set, so these users provide almost no
>>> feedback; more recent features are not picked up and go untested.
>>>
>>> This could be solved by releasing DGD as a package, which is kept up-
>>> to-date along with the remainder of the system.  But I think most people
>>> want DGD + a mudlib, and a package manager is a poor match for a mud,
>>> especially a persistent mud.
>>>
>>> For this reason, my thoughts are turning instead to a Docker container.
>>> The Docker image would provide a startup configuration for an "app",
>>> that being DGD plus a mudlib.  Inside the container, DGD would be
>>> kept up-to-date automatically without downtime using hotbooting.
>>> The same could be done for the mudlib, although this would be more
>>> tricky since local modifications would have to be handled somehow.
>>>
>>> Forcing Docker containers onto existing users is obviously nog going
>>> to work, but I'm looking at using this setup for the AC server.
>>>
>>> Regards,
>>> Felix Croes
>>> ____________________________________________
>>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>>
>> --
>> http://www.flickr.com/photos/mrobjective/
>> http://www.om-d.org/
>>
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd