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
