On 10/10/2017 07:16 AM, Bryan Richter wrote:
> Hi all,
>
> Here's another long email! (When I said my emails would become more
> irregular, I guess that could mean *more* frequent...)
>
> This email is about what to do now that I've reset the code base
> and starting doing deploys again. In short, let's continue making a
> world where more people support FLO software (and other goods). More
> specifically, some of you will need to reset your code repository, and
> there is plenty of directions for current work. I'll highlight a few
> of them, including the valuable task of reincorporating a lot of the
> hard work that went into the pre-reset branch.
>
> First, the nitty-gritty. For all three of you so affected, the reset
> will probably require a manual reset on your end, too. Make sure you
> don't have *anything* you want saved, in particular unrecorded files,
> and then run the following set of commands.
>
> git status
> # ^ Double check that there are no unsaved changes or files
> git checkout master
> git fetch origin
> git reset --hard origin/master
>
> So, what about new development? Let me start by demonstrating how to
> see what, exactly, got left out in the reset.
>
> Current master—the new master—has about half of the "abandoned"
> commits from the old master. You can see which ones got cherry-picked
> in with the following arcane whispers:
>
> git cherry master master-pre-reset -v | grep ^-
>
> To see which commits have *not* been included, use the following,
> almost identical incantation:
>
> git cherry master master-pre-reset -v | grep ^+
>
> You can use that last command for a rough approximation of what got
> left out. I don't think we should do any more cherry picking, but we
> can use these lists as guides.
>
> One obvious thing left out is Sass. I *think* we can safely add it
> back. But I'm not sure. And I want to proceed much more delicately.
> For instance, the very first thing that should be done with it is to
> rewrite an existing Cassius file as Sass. No improvements, no Susy,
> just a rewrite. Don't change defaultLayout, either. At most, create a
> sibling function for the page being rewritten.
>
> Another little chunk to bite off is the navigation panel. Start
> with: What is its purpose? What user stories do we want to satisfy
> with it?
>
> As for me: My current inability to build for production makes it
> apparent that we should bake that functionality into our ops stack. I
> will start by reading up on Docker+tools and NixOps, which are the top
> two contenders in my mind for taming deployment. I know Salt is using
> docker-compose for some things, which is why I say 'Docker+tools'.
>
> Also, I gave up on one approach to testing the website without
> actually talking to stripe.com, but there are two others to try. I'd
> like to use Haskell's new 'backpack' system, so I will read up on
> that.
>
> I want to say something about what happened to the pre-reset master.
> It was a systematic mistake. We bit off too much both in formulating
> governance, formulating development policy, and (re)formulating
> software architecture. Some people worked very hard on some of those
> things, and got burned. For my part of the failure, I apologize.
>
> But I think the organization is stronger for it. I absolutely cherish
> the real-world experience I get in collaborating with all of the
> highly-skilled, passionate volunteers in this project. I hope that
> being part of this project continues to reward all of us in that way.
>
> Peace,
>
> -Bryan
> aka chreekat
>
> p.s. Please pretend I didn't say anything about replacing Yesod in my
> previous email. :) I may harbor dreams of such a thing, but I don't
> think it is realistic in any short time frame.
>
>
Thanks Bryan!
I was able to get the cherry commands to work after running this extra
command to get the master-pre-reset tag:
git fetch --tags
Perhaps someone can make a working doc that lists the output with some
notes and details so we can make a plan for the merging.
Anyway, I think the new specs/stories approach is going to be massively
helpful. To make it work best, we should have tests that correspond to
specs whenever appropriate.
Overall, I agree that there's nothing like real-world mistakes and
failures to be a good learning experience if we take full advantage of
it and can afford the mistakes. I think we're on a better track going
forward, but it's got some challenges just ahead, so we'll want to be
careful in really getting steady from here.
signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev
