Dreamhack reinstallation dilemma

[sophie]

As most people here will know, I'm the maintainer of the Dreamhacks service which allows you to have a Dreamwidth development environment quickly and easily.

Some people will also know that lately the reinstallation script hasn't been working for some time. It's been broken ever since the move to git and GitHub, and I recently put a check in there so that anybody trying to use it won't accidentally end up with an unuseable 'hack. (By the way, if anybody does have an unuseable 'hack because of this, please feel free to let me know and I'll gladly reinstall you by hand!)

Although it should be fairly easy to get the reinstaller script working again, I've been running into some issues that I'm not entirely sure how to address. If you have a Dreamhack account, please read inside the cut as this could quite possibly affect you.

---

The point of the reinstaller script back in the Mercurial days was so that if you end up with a 'hack that you didn't know how to fix, it would be possible to easily get back to a working state by reinstalling your Dreamhack account as if you were a completely new user, without you having to worry about bothering anybody. You'd lose your work in the process unless you had backed it up, but you'd be pretty much guaranteed a working 'hack and being able to get back to somewhere you knew. A lot of people used it and I've heard from a lot of people that it was really helpful.

It worked because the previous setup procedure for Dreamhacks meant getting a completely fresh copy of the code straight from the official repository, so unless any bugs had been committed into the official codebase, it would be guaranteed to work as expected.

However, this isn't the case any more - the setup process for Dreamhacks now involves forking the official repository and setting up the Dreamhack to pull from that repository instead. As a result, if you've already pushed the commits that broke your Dreamhack to your own repository, a reinstall wouldn't help because it'd just pull the broken commits straight back down. It may not even fix a broken repository, depending on the situation; all in all, there's no guarantee any more that the reinstall process would get you to a known state any more. It would all depend on what you had pushed to the repo before you reinstalled.

I have an idea for how this might be fixable, but it would require a fair amount of code on my part and I want to be sure that it's worth it, so I thought I'd come to you guys for ideas!

My own idea involves something I've been planning for a while anyway - the ability to link Dreamhack SSH accounts with GitHub via OAuth. It would take some work, but with this in place it would be possible to have a reinstallation process that could (after making VERY clear what it would do) delete your dw-free/dw-nonfree repositories on GitHub and re-fork them automatically, either as part of the process or (more likely) as a separate script which you could run beforehand. The reinstallation could then proceed using these newly re-forked repositories, and the end result would be almost exactly the same as what you would have had under the old script - code that comes straight from the horse's mouth, as it were, and an almost-sure guarantee that you would get a working 'hack out of it, bar any bugs in the official codebase.

It's probable that something like this would be best implemented as two scripts - the reinstallation script as it is right now (or at least as it would be if it were working) that uses your current GitHub repositories, and a script you could run beforehand if you wanted to to do the deleting/re-forking. I think this would be the best way, personally, because the main reason to have the reinstall process is to make it quick, easy, and not require many spoons. While having two commands to run does take some more spoons, I believe that it's worth it to stop people from accidentally wiping out all their work (since people wouldn't normally expect a reinstallation on the Dreamhack machine to affect GitHub).

However, these are just my ideas. It's quite possible that people here have better ideas, and that's why I'm here. Do you have any ideas about how the reinstallation script should work? Is the process I've outlined too easy to accidentally activate, too difficult to work with, or something else? Things like that. The Dreamhack machine is your resource and I want to make it as easy as I can to hack on the code while not getting in your way. How can I do that in this case?

Comments

[swaldman]

My gut feeling on this is that it might be automating a bit too much.
It seems that there are two nearly separate things going on,

1. Nuking and re-forking the github repo
2. Producing a clean Dreamhack account with a clone of this repo.

Part 2 is something that we should absolutely have an updated script for.
Part 1... I'm not sure that it isn't best just to ask the user to do this. They already know how to fork from the main DW repo, because they had to do that when they started. So it should be very straightfoward to delete their own repo and re-fork. We could even provide instructions... but my gut instinct is that automating that away adds a lot of complexity (need for OAuth and so on) without much gain, and also risks making it harder for people to learn / understand what is going on.

Just my 2p - I'm probably not quite the target audience :-)

[sophie]

Well, part 1 and 2 would be being provided by two separate scripts in my proposal. The reinstall script itself would only cover part 2, while part 1 would be a separate script which you could optionally run (or not) before doing the reinstall process.

As for needing OAuth, I've been wanting OAuth support for some time now, because that allows for a whole load of other things too, like the possibility to have a script to let you create pull requests directly from the command line without needing to go to the website. So it wouldn't just be for this project.

Do these points make it any different for you?

[swaldman]

Well, if you want oauth anyway, that's certainly one less factor against.

I guess this is part of the "how much do we insulate people from git" discussion - and for me I kinda feel that if users don't know how to delete a repo on github and fork a repo on github (the latter being something they must have done anyway), they probably ought to learn?

Not a big deal, just a thought:-)

[sophie]

Fair point!

For me, I'm not coming at it from a "trying to insulate people from git" discussion as much as a "how to do this in a manner that conserves spoons". Deleting and re-forking on GitHub is fairly easy, true, and as you mention they would have knowledge of the forking part of it anyway. In fact, I've been going back-and-forth in my mind about how necessary the separate script is myself (vs. manually deleting and re-forking if you need to do that).

Certainly, I think more discussion is needed on this. I've given an overview of where I personally am coming from in a previous comment, and while nuking/re-forking is definitely destructive and not what most people would recommend, I think that it does have its advantages. Is it the best option? I'm still not entirely sure, but I'm leaning towards "Yes". (As a separate optional script, like I say.)

[cdybedahl]

As I understand your comment, the thing here is that this is not primarily a technical problem. The primary problem (or perhaps it's better to call it a task) is psychological. There are, as has been pointed out, several ways of solving the problem technically, with various sets of of pros and cons. Your suggested way, deleting and re-forking on Github, may not be the most elegant from a technical point of view, but I think it's the best from a psychological angle. I started out looking at this with my work eyes, where "never lose information!" is a high priority. But that's not relevant here. Here, it's a question of letting a user go "toss this mess and start over". From that point of view, nuke-and-refork is clearly superior to at least my suggested way of juggling branches. Partly because it's a more robust way of getting out of any possible git problem, but also -- and more importantly -- because it's a lot easier to understand, and that's important for a user who's feeling unsure. You can explain it in one short sentence ("We remove EVERYTHING and start over"). My method? Not so much with that, no.

Also, given this, I think that just having one script is the better choice. With the goal of making an unsure user feel safe(r), fewer options is better.