mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Mark Smith ([staff profile] mark) wrote in [site community profile] dw_dev2016-12-27 05:14 pm
Entry tags:

Simplification & deprecation

Historically we've had a policy of trying to actively support people who might be running the DW code somewhere and that has influenced how we've built things, such as making many things options in the codebase and also maintaining support for legacy configurations and systems that we might not use in's production environment.

Since there's not (and never much has been) people seriously running DW code for any major service, I would rather for us to focus our limited development resources on our own development needs. To be totally clear, we will continue to maintain Dreamwidth the open source platform and people are very welcome to use it. You just might have to either do some of your own development or use a production environment that closely mirrors ours.

Some examples of what this update means:

* Perlbal is no longer used at DW HQ and we're removing all support for it
* MogileFS is on its way out (to be replaced by either simple on-disk storage or Amazon S3)
* Master-Master support is deprecated and will be removed
* Configuration options are being cleaned up and some things will become non-optional (i.e. compression, etc)
* No more support for 32 bit systems (think this is gone already tho)

My goal here is to make Dreamwidth development faster and easier for actually developing on We'll still have to make it possible (and easier!) for people to run DW (if nothing else for our own developers!) but the number of at-scale-production-configurations supported is going down.

As always, comments welcome!
brainwane: The last page of the zine (cat)

[personal profile] brainwane 2016-12-29 07:18 pm (UTC)(link)
I do not hack on Dreamwidth and only have a passing familiarity with the nuts and bolts of the architecture, so I had not realized how much effort y'all had been putting into supporting forkers/competitors. (And, I speculate, into making it easier for feature improvements and bug fixes to (under ideal conditions) flow back and forth between LJ and DW.) Your new suggested approach sounds like a good one to me, as a way to make the lives of actually-existing and likely-to-exist Dreamwidth developers easier and more productive.

The extreme version of this approach, as I see it, is: "You can only expect to run the software in this one configuration because we have taken out all the options we don't use for". So, how far are you interested in going in that direction? Or, to put it another way, what options do you think should still remain optional?
alierak: (Default)

[personal profile] alierak 2016-12-30 04:34 am (UTC)(link)
I'm not an authority on the subject, but I see us supporting two configurations for the foreseeable future: a very simple one for development, and then whatever we actually use in production. For example, userpics in production are currently in MogileFS; as Mark says this will probably switch to Amazon S3. But for development environments, it may be that just putting userpics on disk on the same server you've got running everything else is just fine. There will likely continue to be a difference between getting the basic functionality to work in dev, and making it scale for real.