Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Aaron Wolf]

On 12/13/2017 11:28 AM, Bryan Richter wrote:



Two comments:

> Buffers can't exist in a system that has no account balances. The
> volatility gets pushed to the question of "Does the patron have enough
> money in their actual bank account."
> 

I want it to go through a User Story / consent / design process, but
sometime we'll discuss this. There's no technical requirement of a
buffer, it's a UX and system-design question. It relates to whether
signing up for crowdmatching should actually serve to invite and match
further new patrons. It may be unnecessary or early optimization.
Anyway, it can be dropped from this topic now.

>> I'll stop here except to reiterate: what about doing budget calculations
>> at the time of pledging? I thought that would be effectively the only
>> thing needed. Then the crowdmatch and payment events would be at most
>> just extra checks to be triple-sure to respect budgets…
> 
> Yeah, doing them at pledge time is probably going to be required.
> 

That sounds like what David said too when I talked to him about this. He
had a moment last weekend to at least look at things and think about
Snowdrift code stuff. This could be a good place to hand off a little
coding task(s) to him if you can delineate clearly. He understands the
issues pretty well and may be able to help or at least discuss the
implementation…



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Aaron Wolf]

On 11/15/2017 05:24 AM, Jason Harrer wrote:
> After thinking about it for awhile, I'd like to propose an alternate
> recommendation for the crowdmatch step under budget calculations.  I
> will start off saying that your approach will be far simpler to
> implement and less resource-intensive than mine, however I'm still
> proposing my recommendation based on prior conversations that were made
> pertaining to letting the patron decide what projects are their
> priorities (note: I'm not suggesting that we set that up now, rather I
> believe my recommendation would better accommodate that functionality
> should you decide to implement the patron prioritization /later,/ so it
> may be beneficial to look at and possibly set up the alternate approach
> now to prepare for future changes).
> 
> The idea is to set up one or two temporary "tables" (not sure if it
> would be preferred to do this via postgresql or simply have two mapped
> lists via Haskell, so I will use the term "tables" to represent whatever
> this agreed-upon structure ultimately is).
> 
> The first "table" would hold the calculated pledged dollar amounts per
> project (at this point, the calculation assumes no one has exceeded
> their limit).
> 
> Then, the automation will review each patron to determine if any exceed
> their limit.  If so, the system needs to drop a/multiple pledge[s] to
> get the user under their limit.  I recommend the logic to drop the
> multiple pledges be a separate function that is called from the primary
> logic (thus allowing you in the future, should you decide to go down
> that path, to easily switch out the logic from a LIFO/FIFO function to a
> patron prioritization function or any other type of function that you
> think of later) and adjust the temporary "table" pledged dollar amounts
> accordingly.
> 
> Optionally, as an addition to the last paragraph, the logic could store
> the dropped pledges in a second temporary "table".  The idea behind the
> second "table" is this:  Once all of the adjustments to the project
> calculated pledged amounts are made across all the patrons, this may
> reduce down the pledged amounts of enough projects that a patron pledged
> to that we might actually be able to add some pledges back in, should we
> want to go down that road.  The con is obviously complexity:  This would
> mean a second pass to review the dropped pledges and determining if
> adding a pledge back in would impact other patrons, so there'd be a LOT
> of additional calculation needed to ensure that adding back pledges
> doesn't cause other issues.  The pro, though, is that we could be
> getting additional funds to the projects.
> 
> Obviously, the call is yours, but I wanted to put the idea out there for
> you to ponder upon.
> 
> - Jason (JazzyEagle)
> 

Two general points to clarify re: Jason's thoughts:

1. Pledges to one project should only ever make that *same* project lose
pledges due to budget issues. We avoid a wide range of complexities if
we never let projects interact where pledge to one directly drops
pledges to another.

2. The buffer requirement for new pledges removes a wide range of
expensive calculations and volatility. A patron who hit their limit will
need to drop enough to have a good buffer left in their budget or
increase their budget substantially before they can add *any* pledge
back. So, we can avoid all scenarios where someone is almost at their
budget and then comes back active but is again immediately approaching
their budget. Every time a budget is hit, reinstatement will require a
buffer so we don't get pulsing adds and drops of pledges.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Brainstorm for implementing multiple projects

[Aaron Wolf]

On 11/07/2017 04:34 AM, Bryan Richter wrote:
> Hi all,
> 
> Here are some initial ideas for implementing multiple projects in the
> crowdmatch library. (This is not about the website.) Please take some
> time to read this and provide any feedback or fresh ideas, since I
> dreamed this up on my own, and I could use some second opinions.
> 
> Thanks!
> 
> ---
> 
> 
> Having multiple projects means it becomes more complicated to see if
> someone has gone over their budget. We'll need to account for that.
> 

We discussed this a while back. I'm going to summarize again here some
basic (maybe obvious) factors.

We only need to check for budget-limits at the time of new pledges, and
any budget limits hit will only affect the patrons of the project that
received the new pledge.

While this may eventually be computationally intense, it won't be too
extreme early on. The process as I'd expect would be to check the budget
status of all the existing patrons to one project when that project
receives a new pledge. It could be done in some sensible order such as
oldest patron first. As soon as a single patron is determined to go over
their budget, their pledge is deactivated and no further budget checking
is needed. If the checking gets through all the patrons without issue,
then nobody is over budget.

> Crowdmatching and payment processing both become more complicated,
> too. Besides checking budget limits (which will have a life of their
> own for the sake of early warnings), crowdmatching will have to group
> by project when calculating crowd size.
> 
> The existence of a pledge will need to change from being a Maybe field
> in the User row to being a Maybe field in the Pledge list. It stays
> a Maybe so that one table handles the whole relationship: pledge
> status and pending donation.
> 
> Here's the plan for handling spending limits: Don't charge more
> than the limit, and don't allow a crowdmatch that is greater than
> the limit. Note what's left out: we do not consider the pending
> balance (if any) when doing a crowdmatch, but only the spending limit
> itself. In the possible case that a crowdmatch of, say, $3 causes a
> user's balance to be $11, they can pay $10 this month, and $4 next,
> and that's fine.
> 
> We need is to extend the calculations to be per-project, hitting the
> pledge table instead of the user table.
> 
> -  Tasks for enabling multiple projects
> -  Dev tasks
> -  Modify tests to assume multiple projects
> -  Create new Project table (id, handle, donations_received)
> -  Create new Pledge table,   user <*--*> project
> -  Deprecate pledge_since

Why deprecate pledge_since? Certainly we don't want to lose the
information about how long someone has been a patron. Also, my idea (not
sure it's strictly the best though) to check in order from oldest to
newest pledge would seem to use some information like this.

> -  Implement budget limit calculations (below)
> -  Deploy tasks
> -  Migrate pledges and pending donations
> -   insert into pledge (project, user, since, pending_donation)
> select 1, u.id, u.pledge_since
> from user u
> -  Budget calculations
> -  During crowdmatch
> -  Drop pledge LIFO, recalculate, and repeat until nobody exceeds 
> their limit
> -  Continue with crowdmatch
> -  When patron views a page
> -  Change nothing, just show warnings
> -  During payment processing
> -  Only charge up to the limit, leaving any extra in the patron's 
> account.
> 

Are you suggesting that staying pledged but over-budget between
crowdmatches will happen? That trade-off may be necessary, but we should
clarify.

From the front-end perspective, the assumption is that a patron is
notified of hitting their budget *before* the crowdmatch happens so that
they can choose to adjust their budget or their set of pledges prior to
the crowdmatch (unless the budget was hit with too little time before
the crowdmatch).

Overall, this does bring up a ton of questions. There needs to be some
understanding between front-end design and dev here. Front-end has to
work with that is practical for dev, of course.

### concerns

If multiple patrons hit their budgets at the same time (say they pledge
to the same set of projects), who gets dropped first?

If a patron with a dropped pledge decides to drop a different pledge in
order to reinstate the dropped one, I guess any patrons who also support
the same two projects would be budget-wise unaffected since they would
just reduce their level for one and increase for the other. I guess it
would be unlikely for their to be multiple patrons all close to their
budgets at the same time if the set of projects they support are really
different sets, right?

BUFFER: to keep things from being too volatile, we've had this concept
for a long time that there should be some buffer remaining in a patron's
budget in order to add a new 

Re: [Snowdrift-dev] Go to Definition?

[Aaron Wolf]

In general, please anyone on this thread:

If you clarify suggestions that can be good for new contributors with
little or no qualifications, submit merge-request changes to the
TEXTEDITORS.md document.

While we can't take on every issue in the Haskell ecosystem, we
certainly have an interest in lowering the barriers to productive
contributions from volunteers.

Thanks!



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Life in the post-October Rest world

[Aaron Wolf]

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

Re: [Snowdrift-dev] [Snowdrift-design] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 08/05/2017 08:07 AM, Bryan Richter wrote:
> On Tue, Aug 01, 2017 at 07:37:59AM -0500, Jason Harrer wrote:
>> Not sure how the dev list got removed, but adding it back in at this point.
>>
>> It sounds like there was consensus on this overall limit (just not project
>> limits).  That being said, I'm going to open up a ticket on GitLab so we on
>> the Dev team can track adding that in.  This is a requirement before we can
>> get the Dashboard page finished.
> 
> Can you explain why it's a requirement?
> 
> As far as I understand it, the page simply has to say that a limit
> exists.
> 
> My point, that I'm making here and elsewhere, is that implementing an
> automatic cutoff is not a necessary step for alpha. The process can
> remain manual for the time being.
> 
> There are a lot of other manual things I'd rather automate first.
> 
> 

I agree with Bryan. The requirement is that the limit actually is
respected, not that it be in the code per se. Since we face little
real-world risk of hitting the limit during alpha and will know for sure
if we're approaching it, we're fine. No extra requirement needed for alpha.

For beta, it will matter more because people could then pledge to
multiple projects and thus approach their limit with fewer patrons in
the system.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [Snowdrift-design] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

I want to add one clarification (to the note I just sent):

The remaining concern from a communication standpoint is that people not
believe that they get to stick to a budget limit and bypass the matching
pledge. Either they are matching or they aren't donating at all.

But I no longer think there's any problem with system-wide vs
budget-category / per-project budgets. As long as users understand that
they are in or out of the crowdmatching, I have no other worries about
their perceptions.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [Snowdrift-design] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 07/30/2017 09:07 AM, Stephen Michel wrote:
> Here's what I remember from the discussions a few months back:
> 
> On Sun, Jul 30, 2017 at 1:32 AM, Jason Harrer 
> wrote:
>>
>> There are two major concerns with this part of the prototype:
>>
>> 1) This goes against the philosophies that Aaron has talked about
>> numerous times, all the way back to when I first started on the
>> project 3-4 years ago.  He was strongly against the concept of
>> applying a cap/limit at all.
> 
> The objection was against a *per-project* limit, not a site-wide limit,
> which I think everyone agrees is necessary to make people comfortable
> with pledging (even if the "pledge amount explosion" scenario is not
> very likely).
> 
>> 2) There is currently no back-end support for a limit of any dollar
>> amount.
> 
> We knew this. Plan at the time being:
> 
> - Adding a limit function in the backend is a priority
> - Until we make an official announcement, we expect pledge numbers to be
> low, so we should have plenty of time before we're getting enough money
> to actually do a crowdmatch event.
> - If for some reason we get to the point of doing a crowdmatch event
> before the limit is implemented, we will enforce the limit manually
> (just check to make sure nobody's being charged over $5.
> 

I have a changed view on the limits and it's reflected in the simplified
video script actually.

I think a per-project limit isn't a fundamental problem or a
misunderstanding we need to worry about.

I see the limit plan like this:

A. express that we *have* a budget limit and set it at $5 in the backend
as a starting point

B. make the limit adjustable system-wide (not an alpha requirement, but
if someone decides to do this before the rest of alpha is complete, it's
welcome enough)

C. Long-term plan (in light of real-world alpha experience, and fine to
express publicly as a long-term consideration): offer budget-categories
that users can each define. Let users name a category and put any
selected projects in it. This is comparable to folders/directories such
as how a service like AuctionSniper lets users group a bunch of eBay
items into a folder where you stop once you've won a set number. Because
it's user-adjustable, they could make per-project budgets or choose to
budget separate amounts for music, art, software, etc. as fits their
priorities.

The key point is that there's nothing wrong with C. So, for now we are
FINE with just saying "there's a budget limit" and if someone says "oh,
I can set a budget for each project?" the answer is "for now, it's just
system-wide, but we hope to offer separate budgets like that
eventually". (People could set up multiple accounts to get a similar
effect anyway, but that would mean extra charge accounts, more charges
and fees, and all the hassle of maintaining multiple accounts).

In short: I've DROPPED my big worry about making sure people don't
imagine per-project budgeting.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Trouble Getting Setup

[Aaron Wolf]

On 07/28/2017 03:09 PM, Steven Leiva wrote:
> Hi Folks, 
> 
> I am trying to learn Haskell and looking for a community where I can
> “learn by doing” so to speak. I would love to get involved with the
> snowdrift project as it seems like a great fit for that goal.
> 

Welcome! I agree, we certainly aim to fit that. We want to make sure we
live up to that ideal, and we can certainly use the *doing* from
interested volunteers.

> Anyway, besides a quick introduction, I’m writing because I am having a
> bit of trouble building the snowdrift project. 
> 
> I am following the instructions in the BUILD.md file
> (https://git.snowdrift.coop/sd/snowdrift/blob/master/BUILD.md), and I
> made sure to have *git*, *postgres*, and *stack* installed (ran the
> which command on all of them to make sure they were in my PATH env). 
> 
> Once I cloned the repo and ran *make* in the root directory, I ran into
> an issue with HsOPENSSL (https://paste.ubuntu.com/25193259/). I didn’t
> inline this because we al know how unwieldy error messages can be.
> 
> I tried following the directions of *brew install openssl*, but when I
> did so I got this message: *openssl 1.0.2l is already installed*
> *
> *
> The logs of the error can be found here
> (https://paste.ubuntu.com/25193345/), but they contain the same
> information as the previous URL.
> 
> Thanks for any help folks!
> 
> - Steven
> 
> P.S. I’m running macOS Sierra 10.12.6
> 
> 

Yeah, the "brew" instruction clued me in earlier to the MacOS bit.

I suspect this is a MacOS-specific bug in that building is working for
me on an Ubuntu-based system. Maybe other Mac users on this list can
reproduce the error?

Given that this seems possibly related to version issues, I would wonde
if updating your OS to High Sierra would fix this… if you want to do
that anyway, maybe it's worth trying. If you have some reason to
hesitate on that update, then I don't want to push you to it just to
test this issue.

Anyone who has further thoughts or insights, please weigh in… I hope we
can get this fixed and move on to discussing actual Haskell hacking!

Best,
Aaron



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Port Snowdrift tests from HSpec to Tasty

[Aaron Wolf]

On 07/08/2017 01:41 AM, fr33domlo...@riseup.net wrote:
> From: fr33domlover 
> 
> ---
>  website/Snowdrift.cabal   | 12 +++-
>  website/test/AlertsSpec.hs|  6 +++---
>  website/test/AuthSiteSpec.hs  |  8 
>  website/test/DiscourseSpec.hs | 35 ---
>  website/test/HandlerSpec.hs   |  6 +++---
>  website/test/SampleSpec.hs|  6 +++---
>  website/test/Spec.hs  |  1 -
>  website/test/StripeMock.hs|  2 +-
>  website/test/Tasty.hs |  1 +
>  website/test/TestImport.hs|  4 ++--
>  10 files changed, 40 insertions(+), 41 deletions(-)
>  delete mode 100644 website/test/Spec.hs
>  create mode 100644 website/test/Tasty.hs
> 
> diff --git a/website/Snowdrift.cabal b/website/Snowdrift.cabal
> index 1f1ffc5..c7be912 100644
> --- a/website/Snowdrift.cabal
> +++ b/website/Snowdrift.cabal
> @@ -152,7 +152,7 @@ executable Snowdrift
>  -- test-suite test {{{1
>  test-suite test
>  type:   exitcode-stdio-1.0
> -main-is:Spec.hs
> +main-is:Tasty.hs
>  hs-source-dirs: test
>  ghc-options:-Wall
>  
> @@ -178,24 +178,26 @@ test-suite test
>  -- build-depends {{{2
>  build-depends:
>  Snowdrift
> --- For htmlHasLink (should move upstream)
> -, HUnit >= 1.3.1.1
>  , base
>  , bytestring
>  , classy-prelude
>  , classy-prelude-yesod
>  , cryptonite
> -, hspec >= 2.0.0
>  , http-types
>  , memory
>  , persistent
>  , persistent-postgresql
>  , postgresql-simple
> -, QuickCheck
>  , quickcheck-text
>  , shakespeare
>  , stripe-core
>  , stripe-haskell
> +, tasty
> +, tasty-discover
> +-- For htmlHasLink (should move upstream)
> +, tasty-hunit
> +, tasty-hspec
> +, tasty-quickcheck
>  , text >= 1.2.2.1
>  , wai-extra
>  , yesod
> diff --git a/website/test/AlertsSpec.hs b/website/test/AlertsSpec.hs
> index 62235e8..cf0d9c5 100644
> --- a/website/test/AlertsSpec.hs
> +++ b/website/test/AlertsSpec.hs
> @@ -1,4 +1,4 @@
> -module AlertsSpec (spec) where
> +module AlertsSpec (spec_alerts) where
>  
>  import TestImport
>  import Alerts
> @@ -20,8 +20,8 @@ alertSite = LiteApp go
>  withAlertSite :: SpecWith (TestApp LiteApp) -> Spec
>  withAlertSite = before $ pure (alertSite, id)
>  
> -spec :: Spec
> -spec = withAlertSite $
> +spec_alerts :: Spec
> +spec_alerts = withAlertSite $
>  it "adds an alert" $ do
>  get getR
>  htmlCount ".alert" 0
> diff --git a/website/test/AuthSiteSpec.hs b/website/test/AuthSiteSpec.hs
> index e962fce..a251a9e 100644
> --- a/website/test/AuthSiteSpec.hs
> +++ b/website/test/AuthSiteSpec.hs
> @@ -4,13 +4,13 @@
>  {-# LANGUAGE ScopedTypeVariables #-}
>  {-# LANGUAGE ViewPatterns #-}
>  {-# OPTIONS_GHC -fno-warn-unused-binds #-}
> -module AuthSiteSpec (spec) where
> +module AuthSiteSpec (spec_authSite) where
>  
>  import TestImport hiding (Handler)
>  import Database.Persist.Sql hiding (get)
>  import Database.Persist.Postgresql (pgConnStr)
>  import Network.Wai.Test (SResponse(..))
> -import Test.HUnit (assertBool)
> +import Test.Tasty.HUnit (assertBool)
>  import Yesod hiding (get)
>  import Yesod.Default.Config2 (ignoreEnv, loadYamlSettings)
>  import qualified Data.Text as T
> @@ -171,8 +171,8 @@ withBob = beforeWith makeBob
>  
>  -- ** The actual tests!
>  
> -spec :: Spec
> -spec = mainSpecs >> authRouteSpec
> +spec_authSite :: Spec
> +spec_authSite = mainSpecs >> authRouteSpec
>  
>  -- | Having this defined separately is clumsy. It should be moved back into
>  -- the right spot. The problem is that it needs a different value of
> diff --git a/website/test/DiscourseSpec.hs b/website/test/DiscourseSpec.hs
> index f00c084..e4cc0b0 100644
> --- a/website/test/DiscourseSpec.hs
> +++ b/website/test/DiscourseSpec.hs
> @@ -13,30 +13,27 @@ import Crypto.MAC.HMAC (HMAC, hmac)
>  import Data.ByteArray (ByteArray, ByteArrayAccess)
>  import Data.ByteArray.Encoding (Base(Base16, Base64URLUnpadded), 
> convertToBase)
>  import Data.Text.Arbitrary ()
> -import Test.Hspec.QuickCheck (prop)
> -import Test.QuickCheck (Arbitrary, arbitrary, choose, oneof, vectorOf, 
> NonEmptyList(..))
> +import Test.Tasty.QuickCheck (Arbitrary, arbitrary, choose, oneof, vectorOf, 
> NonEmptyList(..))
>  
>  import qualified Data.ByteString.Char8 as Char8
>  
>  {-# ANN module ("HLint: ignore Reduce duplication" :: String) #-}
>  
> -spec :: Spec
> -spec = do
> -prop "validateSig" $ \(NonEmpty secret) (NonEmpty payload) -> do
> -let secret' = pack secret
> -payload' = pack payload
> -
> -validateSig (DiscourseSecret secret') payload'
> -(base16 (hmac secret' payload' :: HMAC SHA256))
> -
> -prop "parsePayload" $ \(Nonce nonce) (Url url) -> do
> -let payload = "nonce=" <> nonce <> 

[Snowdrift-dev] temporary cert issue with git.snowdrift.coop

[Aaron Wolf]

Sorry for the hassle everyone (especially at a time when we have some
newcomers). Our old cert just expired and an oversight meant we didn't
get the correct (and still valid) cert to the git.snowdrift.coop
subdomain even though it's live on other subdomains.

The issue will be fixed ASAP!

-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] make-payments prototype

[Aaron Wolf]

On 04/28/2017 03:50 PM, Bryan Richter wrote:
> I pushed a branch 'prototype/make-payments' where I just dumped the
> prototypal utility that processes donation payments. It probably doesn't
> compile, and doesn't have any entries in the .cabal anyway. But I wanted
> to throw it up on the repo so people could at least look at it.
> 
> Barring any other activity, working on that utility is what I plan to
> do next when I have time to work on Snowdrift. Someone is welcome to
> beat me to it.
> 
> One concern I have is figuring out how to minimize spamming Stripe. Can
> we batch payments somehow? Etc.
> 
> Enjoy,
> 
> -B
> 
> 

FWIW, I'd be happy to discuss the issue of how payments get processed in
a bounce-ideas sorta fashion independently of evaluating the code
itself. I mean, just to make sure everyone is on the same page about how
the interaction with Stripe should (or shouldn't) work…




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] HLint update

[Aaron Wolf]

testing now but some option for a settings file so that people can run
hlint on a project but not see a bunch of issues they have to then
ignore: https://github.com/ndmitchell/hlint/issues/223

relevant to snowdrift along with other Haskell projects.

I was going to send this just to Bryan, but I figured it makes more
sense to send to the whole dev list. Would be nice (if this works as I
think it does) to commit an hlint settings file to the snowdrift repo.
Maybe someone can test this?

The point being that running hlint on the snowdrift repo gives certain
errors related to language extensions and template haskell, and this
could suppress those, given the right yaml file settings for hlint…

-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] ghci & Snowdrift.coop

[Aaron Wolf]

On 01/29/2017 10:01 PM, Bryan Richter wrote:
> On Fri, Jan 27, 2017 at 09:15:11PM -0600, Jason Harrer wrote:
>> Hello, all -
>>
>> During my adventures of troubleshooting the discourse-sso branch, I tried
>> to access GHCi using both "./build.sh ghci" and "stack ghci".  Neither of
>> them fully loaded the website as I anticipated, which made my debugging and
>> type investigations much harder.  I ultimately fumbled through it,
>> especially with singpolyma's help (thanks again, btw!), but it flustered me
>> to have the issues.
>>
>> So, I'm trying to look into why we're having issues with it.  It appears
>> that there are cabal settings for run-persist & crowdmatch that are causing
>> these to not compile when utilizing GHCi:
>>
> 
> 
> 
> I kind of gave up on using ghci with Snowdrift. The combination of stack, 
> Yesod,
> and ghci just caused all sorts of trouble.
> 
> For instance, a lot of the "warnings" that ghci prints at the beginning are
> nonsense.
> 
> If it helps at all, the crowdmatch utility is fairly independent from the
> website. It just uses the same database.
> 
> 
> 
> ___
> Dev mailing list
> Dev@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/dev
> 

Bryan, can you please just update documentation (BUILD.md and
CONTRIBUTING.md among maybe other spots) to state something about the
status of ghci, even if it's not permanently going to stay in current
status?



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] Discourse SSO support

[Aaron Wolf]

On 12/05/2016 11:34 AM, Bryan Richter wrote:
> Thanks for this. I think the best way to make use of this is to package
> up the logic specific to handling SSO requests in an independent
> library, so we can use it later.
> 
> That's not about you, or about this code. :) It's just that I am going
> to push back hard on having SSO be the second major feature we add to
> our website (or the third, or even the tenth).
> 
> We'll see where that discussion goes.
> 

I *strongly* like the idea of packaging SSO between Yesod app and
Discourse as an independent library we just use because that's in
general a great way to deal with generalized stuff like that.

But I want SSO implemented ASAP, immediately if possible. The
cleanliness and ease of managing everything about our use of Discourse
going forward and the site itself will be really nice if we start
Discourse with SSO from the get-go. I don't want all sorts of awkward
challenges in transition later after we have bunches of disconnected
users on each system and then try to push SSO then.

> On Mon, Dec 05, 2016 at 04:13:42AM +0200, fr33domlover wrote:
>> From: fr33domlover 
>>
>> ---
>>  website/Snowdrift.cabal  |  7 
>>  website/config/routes|  2 ++
>>  website/config/settings.yml  |  4 +++
>>  website/src/Application.hs   |  1 +
>>  website/src/Discourse.hs | 73 
>> 
>>  website/src/Handler/Discourse.hs | 55 ++
>>  website/src/Settings.hs  |  4 +++
>>  7 files changed, 146 insertions(+)
>>  create mode 100644 website/src/Discourse.hs
>>  create mode 100644 website/src/Handler/Discourse.hs
>>
>> diff --git a/website/Snowdrift.cabal b/website/Snowdrift.cabal
>> index 9c1664c..b5cfaa5 100644
>> --- a/website/Snowdrift.cabal
>> +++ b/website/Snowdrift.cabal
>> @@ -40,6 +40,7 @@ library
>>  Avatar
>>  Application
>>  Css
>> +Discourse
>>  Email
>>  Foundation
>>  Import
>> @@ -49,6 +50,7 @@ library
>>  Settings.StaticFiles
>>  Handler
>>  Handler.Dashboard
>> +Handler.Discourse
>>  Handler.PaymentInfo
>>  Handler.Pledge
>>  Handler.Project
>> @@ -74,6 +76,7 @@ library
>>  , bytestring >= 0.9 && < 0.11
>>  , classy-prelude >= 0.10.2
>>  , classy-prelude-yesod   >= 0.10.2
>> +, cryptonite
>>  , data-default
>>  , errors
>>  , esqueleto
>> @@ -82,8 +85,10 @@ library
>>  , formattable
>>  , hjsmin >= 0.1
>>  , http-client
>> +, http-types
>>  , lens
>>  , libravatar
>> +, memory
>>  , mime-mail
>>  , monad-logger   >= 0.3 && < 0.4
>>  , nonce
>> @@ -99,6 +104,7 @@ library
>>  , text   >= 0.11&& < 2.0
>>  , time
>>  , titlecase
>> +, transformers
>>  , unordered-containers
>>  , wai
>>  , wai-extra  >= 3.0 && < 3.1
>> @@ -122,6 +128,7 @@ library
>>  RecordWildCards
>>  ScopedTypeVariables
>>  TemplateHaskell
>> +TupleSections
>>  TypeFamilies
>>  ViewPatterns
>>  
>> diff --git a/website/config/routes b/website/config/routes
>> index 9e4e079..30fdef8 100644
>> --- a/website/config/routes
>> +++ b/website/config/routes
>> @@ -26,6 +26,8 @@
>>  /p/snowdrift SnowdriftProjectR GET
>>  /pledge/snowdrift PledgeSnowdriftR POST DELETE
>>  
>> +/discourse/sso DiscourseR GET
>> +
>>  -- ## Backward compatibility routes
>>  
>>  -- Prevents breakage of external links to the old wiki. See
>> diff --git a/website/config/settings.yml b/website/config/settings.yml
>> index 3c30c0f..e4e30bb 100644
>> --- a/website/config/settings.yml
>> +++ b/website/config/settings.yml
>> @@ -44,3 +44,7 @@ send-email: "_env:SD_EMAILS:false"
>>  # chreekat for assistance.
>>  stripe-secret-key: "_env:STRIPE_SECRET_KEY:"
>>  stripe-publishable-key: "_env:STRIPE_PUBLISHABLE_KEY:"
>> +
>> +# Discourse SSO
>> +discourse-url: "https://discourse.snowdrift.coop;
>> +discourse-sso-secret: ""
>> diff --git a/website/src/Application.hs b/website/src/Application.hs
>> index 8ccd6b2..761d3f8 100644
>> --- a/website/src/Application.hs
>> +++ b/website/src/Application.hs
>> @@ -35,6 +35,7 @@ import qualified Yesod.GitRev as G
>>  
>>  import Handler
>>  import Handler.Dashboard
>> +import Handler.Discourse
>>  import Handler.PaymentInfo
>>  import Handler.Pledge
>>  import Handler.Project
>> diff --git a/website/src/Discourse.hs b/website/src/Discourse.hs
>> new file mode 100644
>> index 000..cca0bb1
>> --- /dev/null
>> +++ b/website/src/Discourse.hs
>> @@ -0,0 +1,73 @@
>> +module Discourse where
>> +
>> +import Prelude
>> +
>> +import Crypto.Hash.Algorithms (SHA256)
>> +import Crypto.MAC.HMAC
>> +import Data.ByteArray.Encoding
>> 

Re: [Snowdrift-dev] [PATCH] Discourse SSO support

[Aaron Wolf]

On 12/05/2016 11:34 AM, Bryan Richter wrote:
> Thanks for this. I think the best way to make use of this is to package
> up the logic specific to handling SSO requests in an independent
> library, so we can use it later.
> 
> That's not about you, or about this code. :) It's just that I am going
> to push back hard on having SSO be the second major feature we add to
> our website (or the third, or even the tenth).
> 
> We'll see where that discussion goes.
> 

I *strongly* like the idea of packaging SSO between Yesod app and
Discourse as an independent library we just use because that's in
general a great way to deal with generalized stuff like that.

But I want SSO implemented ASAP, immediately if possible. The
cleanliness and ease of managing everything about our use of Discourse
going forward and the site itself will be really nice if we start
Discourse with SSO from the get-go. I don't want all sorts of awkward
challenges in transition later after we have bunches of disconnected
users on each system and then try to push SSO then.

> On Mon, Dec 05, 2016 at 04:13:42AM +0200, fr33domlover wrote:
>> From: fr33domlover 
>>
>> ---
>>  website/Snowdrift.cabal  |  7 
>>  website/config/routes|  2 ++
>>  website/config/settings.yml  |  4 +++
>>  website/src/Application.hs   |  1 +
>>  website/src/Discourse.hs | 73 
>> 
>>  website/src/Handler/Discourse.hs | 55 ++
>>  website/src/Settings.hs  |  4 +++
>>  7 files changed, 146 insertions(+)
>>  create mode 100644 website/src/Discourse.hs
>>  create mode 100644 website/src/Handler/Discourse.hs
>>
>> diff --git a/website/Snowdrift.cabal b/website/Snowdrift.cabal
>> index 9c1664c..b5cfaa5 100644
>> --- a/website/Snowdrift.cabal
>> +++ b/website/Snowdrift.cabal
>> @@ -40,6 +40,7 @@ library
>>  Avatar
>>  Application
>>  Css
>> +Discourse
>>  Email
>>  Foundation
>>  Import
>> @@ -49,6 +50,7 @@ library
>>  Settings.StaticFiles
>>  Handler
>>  Handler.Dashboard
>> +Handler.Discourse
>>  Handler.PaymentInfo
>>  Handler.Pledge
>>  Handler.Project
>> @@ -74,6 +76,7 @@ library
>>  , bytestring >= 0.9 && < 0.11
>>  , classy-prelude >= 0.10.2
>>  , classy-prelude-yesod   >= 0.10.2
>> +, cryptonite
>>  , data-default
>>  , errors
>>  , esqueleto
>> @@ -82,8 +85,10 @@ library
>>  , formattable
>>  , hjsmin >= 0.1
>>  , http-client
>> +, http-types
>>  , lens
>>  , libravatar
>> +, memory
>>  , mime-mail
>>  , monad-logger   >= 0.3 && < 0.4
>>  , nonce
>> @@ -99,6 +104,7 @@ library
>>  , text   >= 0.11&& < 2.0
>>  , time
>>  , titlecase
>> +, transformers
>>  , unordered-containers
>>  , wai
>>  , wai-extra  >= 3.0 && < 3.1
>> @@ -122,6 +128,7 @@ library
>>  RecordWildCards
>>  ScopedTypeVariables
>>  TemplateHaskell
>> +TupleSections
>>  TypeFamilies
>>  ViewPatterns
>>  
>> diff --git a/website/config/routes b/website/config/routes
>> index 9e4e079..30fdef8 100644
>> --- a/website/config/routes
>> +++ b/website/config/routes
>> @@ -26,6 +26,8 @@
>>  /p/snowdrift SnowdriftProjectR GET
>>  /pledge/snowdrift PledgeSnowdriftR POST DELETE
>>  
>> +/discourse/sso DiscourseR GET
>> +
>>  -- ## Backward compatibility routes
>>  
>>  -- Prevents breakage of external links to the old wiki. See
>> diff --git a/website/config/settings.yml b/website/config/settings.yml
>> index 3c30c0f..e4e30bb 100644
>> --- a/website/config/settings.yml
>> +++ b/website/config/settings.yml
>> @@ -44,3 +44,7 @@ send-email: "_env:SD_EMAILS:false"
>>  # chreekat for assistance.
>>  stripe-secret-key: "_env:STRIPE_SECRET_KEY:"
>>  stripe-publishable-key: "_env:STRIPE_PUBLISHABLE_KEY:"
>> +
>> +# Discourse SSO
>> +discourse-url: "https://discourse.snowdrift.coop;
>> +discourse-sso-secret: ""
>> diff --git a/website/src/Application.hs b/website/src/Application.hs
>> index 8ccd6b2..761d3f8 100644
>> --- a/website/src/Application.hs
>> +++ b/website/src/Application.hs
>> @@ -35,6 +35,7 @@ import qualified Yesod.GitRev as G
>>  
>>  import Handler
>>  import Handler.Dashboard
>> +import Handler.Discourse
>>  import Handler.PaymentInfo
>>  import Handler.Pledge
>>  import Handler.Project
>> diff --git a/website/src/Discourse.hs b/website/src/Discourse.hs
>> new file mode 100644
>> index 000..cca0bb1
>> --- /dev/null
>> +++ b/website/src/Discourse.hs
>> @@ -0,0 +1,73 @@
>> +module Discourse where
>> +
>> +import Prelude
>> +
>> +import Crypto.Hash.Algorithms (SHA256)
>> +import Crypto.MAC.HMAC
>> +import Data.ByteArray.Encoding
>> 

Re: [Snowdrift-dev] code feedback please!

[Aaron Wolf]

On 10/27/2016 06:55 PM, Bryan Richter wrote:
> Hi everyone,
> 
> The crowdmatch mechanism code is still a work in progress, and I want
> to talk about what I've done so far to get some feedback. This email
> has become rather long! Feel free to skim it to find parts that sound
> interesting. This was written for my benefit as much as yours, and in
> the hope that I get some feedback. Anything at all, like "Well hurry up
> and do it already", is very welcome.
> 
> It is also written for posterity and for your amusement. :)
> 
> The new code is on a branch called split-mechanism. A giant comparison
> can be viewed, but it's longer than this email(!)[1] and I'm going to
> call out specific items instead. This will be a technical discussion,
> but not too nutty. I will talk about how I structured the crowdmatch
> mechanism code, how I've designed it to be used, how I've designed it
> to be testable, and how some quirks popped up during my headlong crash
> through coding it. Please reply with feedback ABOUT ANY PART OF THIS! :D
> 
> ### Table of Contents:
> 
> 1.   A separate module for the crowdmatch mechanism
> 2.   API for the library
> 2.a.   Client code requirements
> 2.b.   Usage example
> 2.c.   Exported actions
> 3.   Database management
> 3.a.   Migrations
> 3.b.   The test database
> 3.c.   run-persist library
> 4.   Implementation to allow property testing
> 5.   Implementation to allow more-than-one Stripe
> 6.   Difference between MechAction and StripeI
> 7.   What's left to do
> 
> Appendix A: Questions
> 
> ### 1. A separate module for the crowdmatch mechanism
> 
> Although there is only one foreseeable client to this code, namely the
> Snowdrift website, I went ahead and structured it as a standalone
> library. It is in a directory called 'crowdmatch'. I did this so it can
> be tested independently. It will be a lot more stable than the website
> eventually, too, which is a good decider for whether something should
> be independent or not.
> 
> ### 2. API for the library
> 
> The crowdmatch library puts certain constraints on client code because
> it requires a database. Then, it does what any API does: provides
> actions and data types.
> 
> ### 2.a. Client code requirements
> 
> A client of this library must be using Postgres via Persistent.
> The only way to be agnostic about databases would be to completely
> reimplement a database. That's nuts. The library will just use Postgres,
> and thus requires client code to use it as well.
> 
> The library also needs to do IO to talk to Stripe. Rather than rely
> on monad transformers or mtl-style classes to manage these different
> layers, I use plain old functions. Each API method needs to be passed
> a handler for running database actions. Will this be a pain in the
> ass? Probably not. It's also the easiest style to change FROM, should
> that become necessary.
> 
> The library maintains its own notion of what a "Patron" is. To
> interface with the website, I created ToMechPatron and FromMechPatron
> type classes. These are easy to define for the User type. Thus, it's
> easy to create a relationship between "website Users" and "crowdmatch
> Patrons".
> 
> ### 2.b. Usage example
> 
> Here's a usage example that covers these parts so far.
> 
> Given:
> 
> fetchPatron
> :: (ToMechPatron usr, MonadIO io, MonadIO env)
> => SqlRunner io env
> -> usr
> -> env Patron
> 
> You can run:
> 
> someHandler = do
> Entity uid user <- requireAuth
> patron <- Crowdmatch.fetchPatron runDB uid
> ...
> 
> See how 'runDB' is passed in as the database runner.
> 
> ### 2.c. Exported actions
> 
> There are about ten operations that will be exported, as well as a
> handful of data types. I am starting with fetching, storing, and
> deleting two items: payment-method tokens and pledges. The payment
> tokens are what Stripe gives us in lieu of credit card info. Pledges are
> what you think they are: the record of a donor pledged to a project.
> 
> Next in the API are two super important methods (prototyped but not
> implemented yet): 'runCrowdmatch' and 'processPayments'.
> 
> The first looks at all pledged patrons and calculates an outstanding
> donation balance. After a crowdmatch event, each pledged patron will
> then "owe" a certain amount to the project. That all happens in the
> database in a single transaction.
> 
> Later, at our leisure, we can run 'processPayments'. That method
> inspects outstanding balances and sends payment commands via
> Stripe. This is where fee limits take effect.
> 
> The website won't trigger the crowdmatch event or payment processing.
> Instead I'll have two simple utilities that do that stuff. I'll just
> run them manually at first.
> 
> This section was longer than I intended, but that's probably good.
> It's one of the more important. Feedback on the API is highly welcome.
> 
> API to date:
> 

[Snowdrift-dev] build error something with Shake

[Aaron Wolf]

I can't run Snowdrift, I get:

# stack (for .stack-work)
Snowdrift-0.1.4: unregistering (dependencies changed)
Error when running Shake build system:
* test
* .stack-work
Build system error - expected a file, got a directory:
  Directory:  .stack-work
Probably due to calling 'need' on a directory. Shake only permits 'need'
on files.


-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] What are the folders to purge to fix or prevent build issues?

[Aaron Wolf]

On 05/04/2016 04:41 AM, Victor/tuxayo wrote:
> Hi,
> 
> My computer crashed during the build of the project and I would like to
> clean the potential mess left.
> 
> I remember at least two folders that I needed to purge during past build
> issues:
> - $PROJECT_ROOT/.stack-work
> - ~/.stack
> 
> Are there any other folders to remove to come back to a *full* clean
> state? (Also useful after few months of new dependency versions/heavy
> refactor to save disk space)
> 
> And what is the priority in purging those folders when having a build
> issue? For example:
> - `.stack-work` first and if there are still issues `~/.stack`
> - always purge both at the same time
> 
> 
> 
> Cheers,
> 

There are no other directories to purge unless you already ran the site
and have database stuff to deal with. To clean out database stuff, it's
better to use the sdb.hs tool rather than manually clean things though.

although it shouldn't cause any troubles if you stopped in the middle of
a build or anything. Purging shouldn't be needed…

$PROJECT_ROOT/.stack-work should always be purged first when purging

~/.stack should never need purging per se, but for cleanliness or to be
just certain, it can be purged, but it should be purged along with or
after the purge of $PROJECT_ROOT/.stack-work

That's it really




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] PSA: Latest version of stack breaks sdb

[Aaron Wolf]

On 03/27/2016 08:23 PM, Peter Harpending wrote:
> Hey, everyone,
> 
> The latest version of stack breaks sdb, so don't update stack until
>  is fixed.
> 
> Peter Harpending
> 
> 

Note to all: Peter is the reckless sort of person who keeps his system
running the latest git version of Stack. The actual latest *release* is
still 1.0.4 not the pre-release 1.0.5 that Peter is running. So this is
probably a non-issue for everyone and our instructions do not tell
people to run pre-release versions. Of course, Peter running pre-release
helps catch bugs before releases, but, to Peter: keep in mind that most
people are not doing that and we will continue to recommend that people
stick to the official stable release.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] snowdrift workshop

[Aaron Wolf]

On 03/10/2016 03:44 PM, Răzvan Panda wrote:
> Hi
> 
> I've been busy lately studying other technologies so I temporarly
> abandoned study of Haskell, that's why I have not been on IRC.
> For this month's Haskell Dublin meetup I am thinking it would be a good
> idea to do a snowdrift workshop, basically working on different tickets
> for it. Any opinions/suggestions on this? I will have to create the
> meetup event soon and provide links relevant to the project. Meetup will
> probably be betwen 28 and 31 this month. I'm hoping people will get
> involved in the project before the meetup as we will only have 2-3 hours
> at disposition to work on stuff.
> 
> Cheers

Nice to hear from you. I'm posting this reply to the dev list, you
should consider at least temporarily re-joining that if you aren't still
subscribed.

The news (among lots of it) for us is that we're paring back to focus on
core MVP stuff to try to really launch. We do have improved docs and
build stuff, although still won't build on Windows.

There's definitely tickets worth doing, although we're pushing off the
wiki and discussion/ticketing to be outside of the MVP core focus. We're
also moving to different approaches to project management.

It would be nice to identify the most appropriate things for people to
hack on, so maybe other folks can weigh in on how we should do this best.

Cheers,
Aaron



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Aaron Wolf]

On 03/07/2016 09:10 PM, Bryan Richter wrote:
> On Tue, Mar 08, 2016 at 04:39:11AM +0200, fr33domlover wrote:
>> On Mon, 7 Mar 2016 16:39:11 -0800
>> Bryan Richter  wrote:
>>
>>> Can I pass the tasks on to someone else who can take the time to
>>> figure out the best way to use OpenProject?
>>
>> Personally I'm not exactly excited about taking that role, unless OP
>> can be used conveniently from the terminal / text-based web browser
>> / email client, but regardless - do we have a documented workflow
>> for using it? Maybe you can push tasks to some TODO file / etherpad
>> / email. So far I like the use of the dev ML and IRC for that: You
>> mention a task, a dev picks it up and sends a patch or MR.
> 
> I like the idea of the ML too, though only for pushing notifications
> and discussing tasks. It's not gonna cut it for tracking them. Design,
> development, *and* users need to be able to track tasks.
> 
> Sadly, I just checked, and OpenProject flatly does not work without
> Javascript. That is unfortunate. I still suspect OpenProject will
> become THE tool for tracking tasks.
> 
>> The same applies to me and any other volunteer here: When someone
>> has some idea / proposal / problem / suggestion, where do they put
>> it? OP or mailing list or Snowdrift wiki?
> 
> Everyone is always welcome to send suggestions to the mailing list,
> and somebody will take care of triaging it. In the shortest of terms,
> that could even just mean I add it to my large list of tasks.
> 
> Eventually, everything will end up in OpenProject, however.
> 
> The "Snowdrift wiki" is one of the things being removed, by the way.
> 

All this needs to keep in mind that our absolute focus is on getting a
working MVP situation and getting the core thing finally launched.
Decisions made now have ramifications for longer term, but we're not
deciding one way or the other about the particular tools and issues in
the long-term. The point is to have a core working MVP.

Once we're on track to have an MVP, how we handle wiki and discussion
things and whatever else isn't set in stone. What matters right now is
that we use something workable to manage our immediate needs to get MVP.

I still want to see us use Gitit2 for a wiki connected to the eventually
launched system. I'm just accepting that the wiki we have on the site
right now is not going to stay as is and *cannot* be a distraction in
the building of the MVP. Once we have a working dev MVP thing, how we
*launch* it in relation to maintaining the content of the wiki and other
stuff is something to not get distracted with discussing today.

-Aaron




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Aaron Wolf]

On 03/07/2016 04:39 PM, Bryan Richter wrote:
> On Mon, Mar 07, 2016 at 02:39:07PM -0800, Aaron Wolf wrote:
>> In this case, I'm fine with moving forward but only if it's otherwise
>> clean progress.
> 
> Ok, if design is fine with it (which was expected) we come to a bigger
> problem.
> 
> Right now I'm working to strip out unnecessary features and prototype
> code. So far, that has resulted in 9,000 lines of code removed.
> 
> 9,000.
> 
> Yes, that is more than what's left. It's also as many as a good-sized
> novel.
> 
> https://github.com/snowdriftcoop/snowdrift/compare/master...chreekat:reboot?expand=1
> 
> IMO this project is dead and we don't know it yet. We HAVE to continue
> stripping out unusable code in order to resuscitate it.
> 
> Doing so, of course, massively conflicts with the changes you (fr33)
> are making; changes that are hard to make precisely because there's so
> much dead weight. This causes me — and presumably you — some tension.
> 
>> I definitely want to see *all* the stuff connected to work packages in
>> OP when it's not just minor typo fixes etc. And to that end, I hope the
>> dev team will already work to add stuff to OP and add more concrete
>> tasks to the existing user stories to make the already entered items
>> complete.
> 
> I still can't make heads or tails of OpenProject. I don't think I can
> take on the project manager role of managing that tool. And it
> *should* be managed, by some one person or another. I guess that's
> a different topic.
> 
> To be more *on* topic, the act of stripping out dead code is creating
> some new tasks. I definitely want to share them and all that.
> OpenProject is the tool to do it with. Can I pass the tasks on to
> someone else who can take the time to figure out the best way to use
> OpenProject?
> 
> (Apologies for cross posting to discuss@, but there's some larger
> topics here and I want to include more people.)
> 
> 

It seems to me that declaring a "freeze" on things makes sense while
making it clear that people can still do isolated valuable things like
figuring out what some CSS should be or discussing what some
architecture needs to look like.

I think resuscitating the code is as broadly simple as learning from all
the experience and work so far, but starting with a core MVP thing with
maximum segregation of parts, clear names for terms, clear tests… i.e.
what you're doing now.

All the design of tools and content and interest and everything else
provides valuable data from which to draw on going forward. The fact
that we already have working notifications being sent by email doesn't
mean we have to stick to the existing code, but it does mean we have
some code to draw on as we rewrite the core MVP. etc. I think when we
have a core clean MVP, it will be easy to say "oh, we need X, can we
just pull that in or adapt it easily enough from the original version?"
and the answers will vary from case to case.

Anyway, we absolutely need some leadership on Open Project. I hope we
can find people to step up and take that lead.





signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] [PATCH] User nicknames as public user IDs: Change UserR route

[Aaron Wolf]

In this case, I'm fine with moving forward but only if it's otherwise
clean progress.

I definitely want to see *all* the stuff connected to work packages in
OP when it's not just minor typo fixes etc. And to that end, I hope the
dev team will already work to add stuff to OP and add more concrete
tasks to the existing user stories to make the already entered items
complete.

I like the direction fr33domlover is going here anyway.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] a public way to potentially indicate and organize work to do on each page…

[Aaron Wolf]

We have alert boxes we're putting on pages to indicate the need to write
a page or update it after moving over…

Would it make any sense to add specific bullet points within those
alerts regarding page-specific work to do? Then it presents the plans as
clearly as possible, and each person could remove the item when they do
the work.

That wouldn't be appropriate for super easy things as it makes more
sense to just do them, and complex things and anything that covers
multiple pages won't work, but I was thinking about the idea of how to
mark page-specific TODO's and maybe putting them straight onto the page
in an alert box publicly is the best approach…

Thoughts?

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Splitting things up: status

[Aaron Wolf]

On 11/05/2015 12:08 PM, Bryan Richter wrote:
> Hello Discuss mailing list,
> 

This is still the Dev list. Apologies, but I originally titled the list
"Discussion about…" for lists that were not the main discuss list, which
means it could be that way in your address book.


> I'm moving this over from the Dev mailing list. The question is, how
> do I proceed with visibly broken changes to the mechanism? (I'll
> include the relevant discussion below, but will incorporate it into
> this top-level post.)
> 
> I was initially going to pose this as a question, but now I'm just
> going to Let It Be Known: I'm going ahead with visibly-breaking
> changes.
> 
> I actually agree with Aaron that breaking things at least *shows
> progress*. It is totally possible to break the mechanism's visible
> aspects without breaking other parts of the site, like tickets or
> discussions or the wiki. Plus, the mechanism is already broken, and
> that fact is already made visible to a greater or lesser extent.
> 
> The only reservation I have is, how long will it stay broken?
> I guess I'm the one to answer that question, but unfortunately I don't
> know right now.
> 
> Let me fill you in on what's happening. I have been working to
> separate the mechanism logic into its own, self-contained code unit
> ("module"). Doing so broke a couple things, which will be fixed later.
> First, though, I'm going to separate out other modules:
> 
> - the wiki
> - notifications
> - discussions
> - tickets
> - others?
> 
> That means I won't be fixing the mechanism right away, and in fact, I
> couldn't do so anyway. The other components need to be separated out
> first.
> 
> The alternative to breaking things would be to keep this new code on a
> separate branch, but that creates a lot of trouble. Work done in
> parallel is harder to synchronize. Things stagnate. Velocity wanes.
> 
> This is just going to be a rocky time right now, but the payoff will
> be huge!
> 
> On Wed, Nov 04, 2015 at 09:19:57PM -0500, Stephen Michel wrote:
>>
>>
>> On November 4, 2015 9:14:12 PM EST, Aaron Wolf
>> <aa...@snowdrift.coop> wrote:
>>>
>>>
>>> On 11/04/2015 04:56 PM, Bryan Richter wrote:
>>>>
>>>> This is more a question for the discuss@ list, I guess, but what
>>>> do you think? Should I go ahead and "break" the website? The only
>>>> loss will be UI/UX bugs related to the mechanism, and the
>>>> cessation of payouts.
>>>>
>>>
>>> Exciting to hear about the progress. I think it's *much* more
>>> important that the site show changes, breakage, new things, etc.
>>> than that it be stable. Here's what we *need* stable on the site:
>>> access to the wiki pages, editing, commenting, ticket searching and
>>> sorting, discussion, the establishment process…
>>>
>>> The fact that the mechanism is broken means it isn't giving people
>>> a great impression anyway. I am *strongly* in favor of (actually
>>> *want* to see) the updates get to master sooner rather than later,
>>> but only as long as no link just fails, no page is truly broken
>>> broken… i.e. show a "broken for now, update in progress [DATE]"
>>> message which will give people the sense that things are happening!
>>> So we want to be sure every FIXME issue is presented on the
>>> front-end, and then we should merge and deploy even…
>>
>> Agreed in some ways.
>>
>> I when it comes to bugs, I VERY MUCH prefer the visible variety.
>>
>> That said, as a beta tester (or person who is interested in being
>> involved but not in the thick of it), it's frustrating if much time
>> passes without change, and can lead to a lack of engagement and
>> people walking away. 
>>
>> Overall I'm leaning towards the 'break it now' option, but I want to
>> make sure that before you break things, there's a plan in motion to
>> fix them. 
>>
>>
>> ___
>> Dev mailing list
>> Dev@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/dev

-- 
Aaron Wolf
co-founder, Snowdrift.coop
music teacher, wolftune.com

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] snowdrift-ci status update

[Aaron Wolf]

 
 * Is it okay to put the full build log in a comment?  If not, I'd
   suggest to cut the first 80% when the build is successful.  What do
   you think?  Would you like to cut it always?
 
 Like Aaron said, I think providing a link is best.
 

To clarify, I didn't say link, although link to a pastebin would be
fine. I said attach a file because GitLab comments can have attached
files…

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] FunBot updates

[Aaron Wolf]

On 08/17/2015 02:05 AM, fr33domlover wrote:
 Hello,
 
 I've been working on FunBot, the IRC bot running in #snowdrift under
 the nick 'fpbot', a lot lately. I went over the IRC bot related tickets
 in snowdrift's ticket page and decided I'd summarize a bit of the new
 things the bot can do, in case it helps anyone.
 
 While there's no persistent state yet (and a lot of features are
 waiting for that), useful things that work are:
 
 (1) Announcing git commits and merge request events
 (2) Announcing news feed items (experimental)
 (3) Receiving events from custom clients via HTTP/JSON (experimental)
 
 News regarding these features:
 
 - I temporarily disabled MR update event announcements because GitLab
   is very verbose. While this is being debugged, there's a log of all
   MR events at http://bot.rel4tion.org/log
 - RSS/Atom feeds are a new feature being tested, last time I tried it
   didn't work with Snowdrift's project newsfeed but made a lot of mess
   with Wikipedia's change feed - so still not stable
 - Now that the bot can receive events both by pushing them into a
   'Chan' and by sending them as JSON over HTTP, perhaps Snowdrift can
   use an instance of it to integrate an IRC bot into the server,
   announcing money related events and so on. I know you already have
   Snowbot and Snowcaster and at least 1 bot Peter has been working on,
   so this is just a random suggestion.
 - There was an issue in which when pushing many commits, all get
   announced instantly and it fills the channel with spam. Also, all
   repo branches' commits were announced. I fixed these, still needs
   testing though: 1) Branches to announce/block can now be set in bot
   config per-repo; 2) There is an option to shorter big pushes in a
   friendly way, you'll see this in action in #snowdrift eventually
 
 --fr33domlover


Following up on this: we're happy to potentially host that bot / replace
snowbot, etc. — I'm not sure how active Peter is with his bot, maybe not
at all.

Could you look into pulling in the code from snowbot into fpbot perhaps?
Then we could just deprecate snowbot potentially. Right now, I think all
snowbot does is provide optional missed messages log to known folks, and
there's a never-deployed function for telling absent people something
when they show up again…

Feel free to redo / close / comment on specific items on snowbot's
discussion page etc.

Thanks for all your work!

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Bake on Gitlab

[Aaron Wolf]

On 08/10/2015 04:38 PM, Bryan Richter wrote:
 On Mon, Aug 10, 2015 at 11:29:36AM +0300, Nikita Karetnikov wrote:
 FYI, I renamed the project to snowdrift-ci because I'm no longer
 planning to use Bake:

 https://github.com/ndmitchell/bake/issues/15#issuecomment-129343416
 
 I have a lot of concerns about this. I am concerned about starting yet
 another in-house project that solves problems that have existing
 solutions. (FLO solutions, even.) I also haven't seen any concrete
 reasons why Bake can't be used.
 
 Over all of this, though, I am concerned that we are spreading
 ourselves way too thin. Github + Travis does exactly... *exactly*...
 what we need. Can we please make one tiny concession to our present
 reality and switch to using it?
 
 Will anyone on this list be forced to stop contributing if we make
 Github our primary source location?
 
 

As long as we *accept* code from other sources, nobody will be
disenfranchised by our emphasis on GitHub, but as long as we don't
*require* GitHub, I'm confused about how it would work. If we can have a
process that is realistic for doing Travis CI stuff on GitHub even when
code comes in from git.gnu.io, then why can't we just do that anyway
while continuing to emphasize git.gnu.io? For that matter, did we ever
actually consider GitLab CI?

I also don't understand what's going on with Bake, nor do I personally
yet fully appreciate the need to prioritize CI, but I don't have
experience to judge.

FWIW, GitLab.com itself is preferable to GitHub for various reasons (no
proprietary JS!), so if hosting *there* was required for using GitLab
CI, it would be an option to consider *if* GitLab CI would be a real answer.

I also don't understand why CI is so complex. From Nikita's wording, it
sounds like he actually thinks it'd be pretty easy to just get it
working his way… but I also am super wary about overly-optimistic
attempts to take on everything and end up with way more hassle than
anticipated…

I do *not* fundamentally oppose focusing on GitHub and Travis, it just
seems crazy that it would be the only reasonable solution. Personally,
I'd be okay with just pushing forward without CI, but again, I don't
understand what we're missing.

Overall, it's quite frustrating to keep running into these walls that
aren't the core focus, but I do think at the *least* its valuable to at
least *see* what the possibilities are for doing things ideally before
we give up, but maybe we've done that at this point… not sure…

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Dev] Community engagement with Snowdrift.coop, mailing lists, forums…

[Aaron Wolf]

.

All the best,
Aaron

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] [PATCH] Add libravatar support

[Aaron Wolf]

On 08/02/2015 04:39 PM, fr33domlover wrote:
 I tried making a fork in git.gnu.io but got 404s, so I sent the patch here.
 

Hmm, I hope you'll try that again or figure out the error. If it really
can't work right, we need to talk to mattl and figure out the bug.

 
 On 2015-08-02
 fr33domlo...@riseup.net wrote:
 
 From: fr33domlover fr33domlo...@rel4tion.org

 Until now, if there is no avatar URL, no other source is used to display an
 avatar. With this commit, if there is no avatar URL but the user does have a
 verified email address, the email address is passed through libravatar to get
 an avatar URL from it.

 Things to consider modifying:

 - Fallback URL (currently none is specified)
 - Size (currently it's the default, 80)
 - HTTPS (currently an HTTP URL is generated)
 ---
  Snowdrift.cabal   |  1 +
  View/User.hs  | 11 +++
  stack.yaml|  2 ++
  templates/user.hamlet |  2 +-
  4 files changed, 15 insertions(+), 1 deletion(-)

 diff --git a/Snowdrift.cabal b/Snowdrift.cabal
 index 8e3c553..d610cd6 100644
 --- a/Snowdrift.cabal
 +++ b/Snowdrift.cabal
 @@ -200,6 +200,7 @@ library
   , http-types
   -- Oh yeah!
   , lens
 + , libravatar
   , lifted-base
   , mime-mail
   , monad-logger
 diff --git a/View/User.hs b/View/User.hs
 index 7fbbc24..51ec69a 100644
 --- a/View/User.hs
 +++ b/View/User.hs
 @@ -26,6 +26,8 @@ import   Widgets.ProjectPledges
  import qualified Data.Map   as M
  import qualified Data.Set   as S
  import   Data.String(fromString)
 +import qualified Data.Text  as T
 +import   Network.Libravatar (avatarUrl)
  
  createUserForm :: Maybe Text - Form (Text, Text, Maybe Text, Maybe Text,
 Maybe Text, Maybe Text) createUserForm ident extra = do
 @@ -142,6 +144,15 @@ renderUser mviewer_id user_id user projects_and_roles =
 do then Just $ handlerToWidget (generateFormPost establishUserForm)
  else return Nothing
  
 +let libravatar email = avatarUrl (Left email) False Nothing Nothing
 +avatarFinal - liftIO $
 +case (userAvatar user, userEmail user, userEmail_verified user) of
 +(Just url, _, _)- return $ Just url
 +(Nothing, Just email, True) - do
 +murl - libravatar $ T.unpack email
 +return $ murl = return . fromString
 +_   - return Nothing
 +
  $(widgetFile user)
  
  setPasswordForm :: Form SetPassword
 diff --git a/stack.yaml b/stack.yaml
 index c8d430f..045b906 100644
 --- a/stack.yaml
 +++ b/stack.yaml
 @@ -5,8 +5,10 @@ packages:
  - '.'
  extra-deps:
  # Absent from LTS 2.13
 +- dns-2.0.0
  - mime-0.4.0.2
  - github-0.13.2
 +- libravatar-0.1.0.1
  - titlecase-0.1.0.1
  - yesod-markdown-0.9.4
  # Transitive dep of github
 diff --git a/templates/user.hamlet b/templates/user.hamlet
 index cfe91e6..1b56936 100644
 --- a/templates/user.hamlet
 +++ b/templates/user.hamlet
 @@ -21,7 +21,7 @@ $if Just user_id == mviewer_id
  h1
#{userDisplayName user_entity}
  div .row
 -  $maybe avatar - userAvatar user
 +  $maybe avatar - avatarFinal
  div .col-sm-5
figure
  img .headshot src=#{avatar}
 
 
 
 ---
 fr33domlover http://www.rel4tion.org/people/fr33domlover
 GPG key ID:  63E5E57D (size: 4096)
 GPG key fingerprint: 6FEE C222 7323 EF85 A49D  5487 5252 C5C8 63E5 E57D
 ___
 Dev mailing list
 Dev@lists.snowdrift.coop
 https://lists.snowdrift.coop/mailman/listinfo/dev
 

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] Concerns regarding the mechanism

[Aaron Wolf]

On 07/31/2015 03:17 PM, Bryan Richter wrote:
 On Thu, Jul 30, 2015 at 05:18:00PM +0300, Nikita Karetnikov wrote:
 I have to admit the current mechanism implementation makes me uneasy.
 Everything is mutable and some functions, like underfundedPatrons, do
 too much, making it hard to test and even follow.
 
 Incidentally, where's what I would like underfundedPatrons to look
 like:
 
 select * from (
 select pl.user
 , balance - (outlay.tot - (funded_shares * share_value)) as avail
 , pr.id as project
 , pr.share_value

This isn't certain to be back-end accurate terms: I don't object
strongly, but share_value still seems opaque. It isn't a value that is
ever specified by itself, it just is a variable that is a synonym of (
num-active-patrons * min-pledge-level ), right? I think I'm okay with
keeping it if it isn't confusing anyone else, but we need the definition
to be really easy to find at least…

 , pl.funded_shares
 , ac.id account
 from pledge pl
 join user u on pl.user = u.id
 join account ac on ac.id = u.account
 join project pr on pl.project = pr.id
 join (
 select u.id as user, sum(funded_shares * share_value) as tot
 from pledge pl
 join project pr on pl.project = pr.id
 join user u on pl.user = u.id
 join account ac on u.account = ac.id
 group by u.id
 ) outlay on outlay.user = u.id
 ) as q
 where avail  share_value * funded_shares
 order by q.user
 
 This is a pure function of the underlying tables (except perhaps for
 the use of share_value, which is strictly speaking non-normalized and
 thus spooky). It could be easily tested in isolation. The subquery q
 could be turned into a database view and thus encapsulated.
 
 The problem is I don't know how to interface this query with the
 Haskell code, yet. I would very much like to. Thanks to years of
 experience, I can write queries like this in a matter of minutes, but
 it still takes me hours to hammer them into the persistent/esqueleto
 mold.
 
 I also want compile time guarantees (types). There's a un(i)typed
 multiplication in there between funded_shares and share_value that
 should be a compile-time error. The sum itself is another potential
 type error, since in general it could return null (Nothing) — although
 I think it never will in this case. I should also be able to ensure
 that every use of this query expects the correct result types.
 
 So... any thoughts? For now I think I'll just crash through some more
 persistent and esqueleto to end up with the equivalent data. If anyone
 wants to look into this, though, I'm pretty sure you'd get good
 support from upstream.
 
 -*-*-*- holy crap -*-*-*-
 
 This is what I want:
 
 https://github.com/tomjaguarpaw/haskell-opaleye
 
 Using Opaleye would probably require some deep restructuring of the
 Snowdrift Model code, so I'll hold off for now. I do hope we can move
 towards using it, though.
 
 

Not qualified to really weigh in, but Opaleye sounds great on the
surface. Seems reasonable to me to keep it in mind and start using it /
replacing things with it if it's better. As long as we keep all the
Haskell functional / typed goodness, I'm all for whatever is smoothest.


 
 ___
 Dev mailing list
 Dev@lists.snowdrift.coop
 https://lists.snowdrift.coop/mailman/listinfo/dev
 

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] GitLab CI

[Aaron Wolf]

On 07/10/2015 08:11 AM, Bryan Richter wrote:
 On Thu, Jul 09, 2015 at 10:40:39PM -0700, Aaron Wolf wrote:
 So, we've been chatting about Continuous Integration… I didn't know
 before about this: https://about.gitlab.com/gitlab-ci/ — fully FLO CI
 designed for GitLab… is there a chance we could use that?
 
 The free version seems to only work for projects on gitlab.com. I can
 sign in, but since I have no projects on gitlab.com I can't do
 anything.
 
 This is analagous to having free* Travis CI on Github, which is also no
 use to us.
 
 Travis! -- needs Github
 Gitlab CI! -- needs Gitlab
 
 You see the pattern.
 
 *IF* the person running git.gnu.io set up a local instance of Gitlab
 CI, we could use that. Or they could set up any other CI system. Or we
 could set one up ourselves.
 
 If we're going to set up one ourselves, it makes sense to use bake,
 contributing any necessary features back to the project as they arise.
 I say that with no greater rationale than it is also written in
 Haskell. Really, if *anyone* makes *any* CI available to our project,
 that would be rad.
 
 The hard requirements are:
 
 1. Is triggered by HTTP POST requests.
 2. For merge requests, it checks out master, merges the request
 branch, runs tests, and reports results.
 3. It logs each attempt somewhere accessible.
 
 Ideally, the reporting would be *right in the merge request*, as it is
 with Travis on Github. It's actually possible this could be done
 without modifying Gitlab, if the CI system could write comments on the
 MR's discussion.
 
 * Only free as in beer, of course: Testing your open source project
   is 1% free. Seriously. Always.
 
Ok, I'm fine with whatever, we could ask Matt Lee about GitLab CI, but I
know he's busy. GitLab CI is FLO though, so we could potentially use it
without Gitlab.com — but if Bake works, then great…




-- 
Aaron Wolf
co-founder, Snowdrift.coop
music teacher, wolftune.com

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] vim foldmarkers in Snowdrift.cabal

[Aaron Wolf]

Well, I was okay with seeing the thing in the file and with the folding,
but not with the fact that your additions cause `stack build` to fail!!
(per volunteer who just now tried to build…)

Unable to parse cabal file: [...]: FromString unexpected '{' (Just 28)

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev