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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
