Re: [Snowdrift-dev] Weekly dev status, 2017-09-11

[Stephen Michel]

On Mon, Sep 11, 2017 at 10:50 AM, Bryan Richter <br...@snowdrift.coop> 
wrote:

On 09/11/2017 03:16 PM, Stephen Michel wrote:



 On September 11, 2017 5:19:29 AM EDT, Bryan Richter 
<br...@snowdrift.coop> wrote:

 == Last week.

 Code changes: some updates and fixes to the snowdrift project page,
 thanks to Iko.

 == This month.

 My goal for this month is to finish the website and crowdmatch
 mechanism for Alpha. Maybe a bit optimistic. :) But we seem close.
 The mechanism is functional; it just needs testing. The website is
 functional; it just needs testing. What is mainly missing is a 
little
 bit of practice: practice restoring backups, practice analyzing 
logs,

 practice deploying breaking changes -- that sort of thing.

 There's a lot more we *could* do, but there always will be.

 == This week.

 - Start practicing and figuring out where things are the most 
broken

  or flimsy.

 - Do some system administration work. Hard drives are filling up, 
and

  not much is documented.

 - Coordinate with other components of the project. Make sure we 
have

  the bones of a post-Alpha plan.

 - Encourage people to prod the website and report UI problems.

 == "What can I do?"

 - Write tests! Or ask me how. It needs documenting, anyway.

 - Get the haskell-stripe packages back into Stackage.
  https://github.com/dmjio/stripe/issues/76

 - Ask questions about open issues.
  https://git.snowdrift.coop/sd/snowdrift/issues

 Thanks!


 When we reach alpha, maybe it's time to run our first crowdmatch?
 It'll be below our normal minimum, thus we'll be paying much more in
 stripe fees than we'd like, but the point would be to find pain
 points in the process, not recieve significant sums of money.


My answer to your question is both "yes" and "no". Yes we should do
the first crowdmatch before October 1. But we won't charge any fees.

Recall that there are two processes: crowdmatching and payment
processing. A crowdmatch transaction updates the amount that a
patron "owes" to a project. Separately, we use Stripe to settle up
between patrons and projects. This is just another way of saying that
donations roll over to the next month if the amount owed isn't enough
to minimize fees.

This raises an important point: the significance of these numbers 
needs

to be made clear on the website: current pledge value, current amount
"owed", and total amount paid to the project to date.

Now, should we do special-case payment processing that ignores our
promise about maximum fees? I definitely think not. :) Right now we'd
be talking about a 30 cent charge on a 6 cent donation. Bleh


Ah, let me update my verbiage: I meant to propose that we run a 
crowdmatch for all months that people have been pledging with real 
credit card numbers, then run a payout on that total. So it'd be more 
like a 35 cent charge on a 45 cent donation (for me anyway, newly 
pledged patrons will be closer to what you said).


With 67 patrons that's just under $25 in fees. So, let's not do that, 
but maybe let's trigger a payout for just a handful of accounts (those 
of team members), to verify that it will work in The Real World (tm), 
rather than running into issues later that might affect people with 
less stake in the project. :)
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Taiga backups

[Stephen Michel]

On Sat, Aug 19, 2017 at 7:38 PM, Aaron Wolf  
wrote:

On 02/06/2017 10:45 AM, Bryan Richter wrote:
 Now that there are a multiplicity of Taiga projects, automating the 
Taiga
 backups has become high severity. I don't have the time to click 
through all the

 projects and have all the dumps emailed to me. :)

 The best long-term solution is to use the Taiga API to streamline 
the process. I

 think there used to be an issue about that, but I can't find it.

 A good short-to-long term solution is to put somebody else in 
charge of Taiga

 backups.

 I'm still backing up the website database (though I've missed a few 
weeks). That

 should also be automated...




Any status update on this? If nothing else, let's make sure there 
*is* a

ticket somewhere.


I think it is no longer important to back up Taiga. The most recent 
work (ie, that which has not been backed up) relates to Alpha and has 
already been acted on. The rest of what's on Taiga is a dump of "stuff 
not to forget about", will probably migrate to gitlab eventually, and 
is already saved in the older backups.


--
I try to write short, functional emails. http://smichel.me/email

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

Re: [Snowdrift-dev] Anyone knowledgeable on spam filtering?

[Stephen Michel]

Okay, seems non-pressing then, so I'm not going to worry about it for the 
moment. If it becomes important/pressing later we can re-evaluate.
-- 
I try to write short, functional emails. http://smichel.me/email

On September 3, 2017 4:51:58 AM EDT, Bryan Richter <br...@snowdrift.coop> wrote:
>On 09/02/2017 02:58 AM, Stephen Michel wrote:
>> I do my hosting through hcoop.net. They commit the same folly we do
>> (running our own mail server), but at least have SpamAssassin set up.
>> Maybe we could send our email through them? If we're interested in
>that,
>> I could be the liaison and handle email configuration.
>
>The problem has gone way down recently. I did set up postgrey, which
>seemed to help a lot.
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] Anyone knowledgeable on spam filtering?

[Stephen Michel]

*realizing I wasn't explicit* -> ie, instead of running our own mail 
server.


Not suggesting we do our hosting through them, as it's a slightly more 
complex environment than a VPS and we don't need to add more complexity 
to deploys right now.


--
I try to write short, functional emails. http://smichel.me/email

On Fri, Sep 1, 2017 at 7:58 PM, Stephen Michel 
<stephen.mic...@tufts.edu> wrote:

I do my hosting through hcoop.net. They commit the same folly we do
(running our own mail server), but at least have SpamAssassin set up.
Maybe we could send our email through them? If we're interested in
that, I could be the liaison and handle email configuration.

--
I try to write short, functional emails. http://smichel.me/email

On Mon, Apr 24, 2017 at 2:26 PM, Bryan Richter <br...@snowdrift.coop>
wrote:
> We will need to set up spam filtering. I have never done that. Does
> anyone know the state of the art?
>
> In particular, ad...@snowdrift.coop is now getting a half-dozen spam
> messages a day, which we can all assume will only get worse. admin@
> is a
> special address; we need it public and unmoderated. Thus, we need to
> set
> up spam filtering, or find someone who will do it for us.
>
> Thanks for any pointers!
> ___
> Dev mailing list
> Dev@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/dev

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


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

Re: [Snowdrift-dev] Anyone knowledgeable on spam filtering?

[Stephen Michel]

I do my hosting through hcoop.net. They commit the same folly we do 
(running our own mail server), but at least have SpamAssassin set up. 
Maybe we could send our email through them? If we're interested in 
that, I could be the liaison and handle email configuration.


--
I try to write short, functional emails. http://smichel.me/email

On Mon, Apr 24, 2017 at 2:26 PM, Bryan Richter  
wrote:

We will need to set up spam filtering. I have never done that. Does
anyone know the state of the art?

In particular, ad...@snowdrift.coop is now getting a half-dozen spam
messages a day, which we can all assume will only get worse. admin@ 
is a
special address; we need it public and unmoderated. Thus, we need to 
set

up spam filtering, or find someone who will do it for us.

Thanks for any pointers!
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev


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

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

[Stephen Michel]

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.


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

Re: [Snowdrift-dev] code feedback please!

[Stephen Michel]

On November 3, 2016 7:38:24 PM EDT, Aaron Wolf  wrote:
>On 10/27/2016 06:55 PM, Bryan Richter wrote:
>> 
>> -snip-
>
>I hope others will weigh in.

I'm planning on weighing in but I'm in the middle of a big crunch so it won't 
be until at least next Friday.
-- 
Sent from my phone; please excuse my brevity.
Email policy: http://smichel.me/email
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] taiga: can't edit or comment my own issue

[Stephen Michel]

On Tue, May 3, 2016 at 9:25 AM, Victor Grousset/tuxayo 
<vic...@tuxayo.net> wrote:

On 02/05/2016 20:16, Bryan Richter wrote:
 On Sun, May 01, 2016 at 12:05:16PM +0200, Victor Grousset/tuxayo 
wrote:

 For command line email readers or are there others reasons?


 It's usually a lot more usable in a lot more contexts. For instance,
 your message was completely eaten on the archives:

 https://lists.snowdrift.coop/pipermail/dev/2016-April/000319.html


Indeed, that pretty bad :-(


On 02/05/2016 23:07, Stephen Michel wrote:
 I have already submitted a feature request for issue creators to be 
able
 to comment on and edit their own issues. However, more people 
doesn't

 hurt!


I can't find your feature request among the issues at
https://tree.taiga.io/project/taiga/issues


The taiga project doesn't allow external users to create issues, so you 
send them feedback and they create issues themselves. Here's one for 
the feature we're talking about: 
https://tree.taiga.io/project/taiga/issue/2132


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

Re: [Snowdrift-dev] taiga: can't edit or comment my own issue

[Stephen Michel]

On April 30, 2016 8:24:07 AM EDT, Victor Grousset/tuxayo  
wrote:
>Hi,
>
>I just opened
>https://tree.taiga.io/project/snowdrift/issue/304
>
>However I wanted to updated the title and improve the formatting of the
>content but I can't.
>Nor comment to add more details and discuss the issue.
>
>Is this to be expected?

Unfortunately, Taiga does not have a separate permission for editing your own 
posts or commenting on posts -- they are both under the 'edit' permission. So 
in order for me to allow you to comment and edit by default, I'd have to allow 
the public to edit any issue. I can add you to the project so you can 
comment/edit.

>Should I have used Taiga in the first place to ask about updating the
>links in the repository?

I'll have some documentation out about how we use our tools soon, but the short 
answer is that Taiga issues is a good place for everything (except governance 
issues of the snowdrift.coop team, and those are the kind of thing where if 
you're unsure whether they're relevant to you, they are probably irrelevant).

-- 
Email Policy: http://stephenmichel.me/email
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Snowdrift-dev] New Dev - Some help

[Stephen Michel]

On Tue, Apr 12, 2016 at 11:32 AM, Bryan Richter  
wrote:
On Tue, Apr 12, 2016 at 09:41:44AM +0200, Barbara Martina Rodeker 
wrote:

 Hi guys,

 I 've started yesterday to download the project and now I'm in 
the step

 of running the tests.
 I followed the instructions in:
 https://git.gnu.io/snowdrift/snowdrift/blob/master/BUILD.md

 Could somebody point me to some clue why tests are failing?


Hi! Welcome.

The tests are failing right now because I'm in the middle of
reorganizing the code. It might be hard to find good things to work on
right now because of that. I'll send updates to this list as things
progress.

In the meanwhile, you may want to sign up for this list (your message
was moderated because you are not a member). :)

You can also look around our Taiga instance, although the content
there is *also* still in a lot of flux, since we started using it
about two weeks ago.

List signup: https://lists.snowdrift.coop/mailman/listinfo/dev
Taiga instance: https://tree.taiga.io/project/snowdrift/kanban

Thanks!


There's also usually a fair number of people hanging out in irc, 
#snowdrift on freenode, who're happy to chat and answer questions or 
point you to people who know the answers
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

[Snowdrift-dev] PSA: I assume you're also on the snowdrift discuss mailing list

[Stephen Michel]

Attached is a little diagram of how I think of the mailing list 
membership.


I don't believe there's anything official about how they're set up, but 
you'll still possibly miss info if you're not on a higher-level mailing 
list. I'd also *like* to make that view of the mailing lists official, 
in the future.


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

Re: [Snowdrift-dev] Code reboot going into master

[Stephen Michel]

On March 21, 2016 8:52:47 PM EDT, Bryan Richter  wrote:
>On Sat, Mar 19, 2016 at 06:12:39PM +0200, fr33domlover wrote:
>>
>> 4. What about the `/u/username` thing? Do we want it for the reboot,
>> should it be taken into account in any way?
>
>I think this is a separate question; one that I do not know the answer
>to. Waiting on product requirements.

This is a thing that needs to be decided. I want to talk to mray, msiep about 
it. 

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

Re: [Snowdrift-dev] snowdrift workshop

[Stephen Michel]

On Thu, Mar 10, 2016 at 8:57 PM, Aaron Wolf  
wrote:

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


Probably the best way to do this is through our project management 
tool. Once it is set up, it should be pretty clear what our priorities 
are.


Unless I hear a convincing argument in favor of OpenProject in the next 
~12 hours, I will begin to set up Taiga for this purpose tomorrow. I'll 
make sure to keep you and the ML updated.
___
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

[Stephen Michel]

I think this is the kind of thing that it's important for you 
(chreekat) to get input on, but is ultimately your decision. It's also 
the kind of thing I'm having trouble working through on my own.


Originally I had more to this email but then decided it's a separate 
topic and deserves its own email. Sending it shortly.


On Mon, Mar 7, 2016 at 3:00 PM, Bryan Richter  
wrote:

Before I comment on this patch, I think we should make sure that
Snowdrift.coop at large is ok with this change, and that that "ok" is
made real by adding the feature to OpenProject.

I want to get in the habit of doing feature-work that is in
OpenProject, and only that is in OpenProject. From the designer/owner
side, that ensures they get a chance to approve and prioritize work,
and from the developer side, it means we have a clear understanding of
new development we're responsible for. I think both aspects are
equally important.

Still, this is probably a good thing, so I've pushed this commit to a
new branch to ease collaboration.

https://git.gnu.io/snowdrift/snowdrift/tree/user-nicknames

On Mon, Mar 07, 2016 at 02:13:07PM +0200, fr33domlover wrote:

 From: fr33domlover 

 Making UserR take a Text that refers to a whole new User field is a 
big
 change. Many handlers and templates need to be updated. Therefore 
please
 read below carefully to understand my plan and what exactly this 
commit

 does.

 The GOAL is to move all UserId-based routes to use UserHandle 
instead,
 which is Text. That "handle" references a new 'userNick` field in 
the
 User table. But since this is a huge change, this commit does a 
smaller
 change. The rest will come in the next patches. What this commit 
does

 is:

 1. Update the UserR route and add a deprecated UserByIdR route
 2. Add the 'userNick' field to account creation and account update 
forms

 3. Require a pattern for the 'userNick' field to avoid all-digit
nicknames and other potential issues
 4. Fix all handlers and templates to pass the 'userNick' to 'UserR'
instead of the 'userId'. That includes inserting 'get404' calls 
in

several places just to get the User value, and other helpers that
will be removed later. They are used just so that the code 
builds and

works after applying this patch.

 The next patch(es) will update all the other handlers and probably
 change some of the helper functions to work with the new 'userNick'
 field.

 Before this gets committed, some input/review from dev and desig 
teams
 will be great. But don't be pedantic, as the next commits will 
change

 many things and will remove some of the ugly parts used here
 temporarily.

 I suggest we make this change in 2 steps because it's so big:

 1. Change the routes and UI as needed, and do whatever is needed to 
make the

code build again
 2. When done, refactor and add helpers and put all the chaos back 
to order

 ---
  config/models|   7 +
  config/routes|   3 +-
  src/Foundation.hs|  24 +++-
  src/Handler/NewDesign.hs |  19 ++-
  src/Handler/Project.hs   |  20 +--
  src/Handler/User/Comment.hs  |   1 +
  src/Handler/User/Delete.hs   |   3 +-
  src/Handler/User/Edit.hs |   7 +-
  src/Handler/User/NewDiscussion.hs|   1 +
  src/Handler/User/Notifications.hs|   3 +-
  src/Handler/User/ProjectNotifications.hs |   3 +-
  src/Handler/User/SelectProject.hs|   3 +-
  src/Handler/User/User.hs |   3 +-
  src/Handler/User/Utils.hs|   2 +-
  src/Handler/Who.hs   |  10 +-
  src/Model/Transaction.hs |   2 +-
  src/Model/User.hs|   7 +-
  src/Model/User/Internal.hs   |  18 +--
  src/View/SnowdriftEvent.hs   |  22 +--
  src/View/User.hs |  37 -
  templates/application.hamlet |   2 +-
  templates/auth/create-user-form.hamlet   |  12 +-
  templates/comment.hamlet |   7 +-
  templates/default/navbar.hamlet  |  35 ++---
  templates/invite.hamlet  |   8 +-
  templates/navbar.hamlet  |   8 +-
  templates/project_patrons.hamlet |   2 +-
  templates/project_transactions.hamlet|   2 +-
  templates/sponsors.hamlet| 226 
+++

  templates/tag.hamlet |   2 +-
  templates/user.hamlet|   2 +-
  templates/user_discuss.hamlet|   2 +-
  templates/user_discussion_wrapper.hamlet |   2 +-
  templates/user_tickets.hamlet|   2 +-
  templates/users.hamlet   |   2 +-
  templates/who.hamlet |   4 +-
  templates/wiki_history.hamlet|   2 +-
  tests/TestImport.hs  |   2 +-
  38 files changed, 295 insertions(+), 222 

Re: [Dev] Splitting things up: status

[Stephen Michel]

As someone not particularly familiar with the code base: Since you're 
our lead dev and (at least at some point) will be the person most 
familiar with the code base, I think you need to make the ultimate call 
on this.


My personal feeling is that it seems like refactoring the code, as 
you're doing now, takes the most wholistic knowledge, whereas #1 and #2 
are slightly more localized. It seems like a smaller investment 
required by someone like me to get involved with something more 
localized, so I'd advise that you continue to do the work that has the 
highest burden of knowledge.


As to breaking the site, I'm not sure I fully grasp the pros and cons 
at the moment so I'm going to wait for more discussion before taking a 
side. Just for clarification: we're talking about pushing to master but 
not to live, correct?


On Wed, Nov 4, 2015 at 7:56 PM, Bryan Richter  wrote:

My branch 'strip-mechanism' on my Gitlab repo
(g...@git.gnu.io:chreekat/snowdrift.git) now has all backend-y code
related to the mechanism in one file: original/src/Mechanism.hs.

It's not pretty right now. Everything in there was cut and pasted from
its original location. It lacks a clear and consistent API, and some
of the code is straight-up broken — not to mention it still doesn't
implement the new mechanism properly.

At this point there are a few possible paths to take.

1. Begin cleaning up Mechanism.hs and designing a decent API.

2. Actually implement the mechanism.

3. Split the mechanism into a separate library.

4. Split out other components from the main project, like
Notifications.

I think the best thing for me to do is #4. If I don't, #1 will be
harder and might need to be re-done later.

#1 and #2 will probably be done in parallel. I think a lot of code
will end up getting removed.

#3 doesn't seem especially necessary yet. Plus, doing so would
complicate issues like database access. I'm going to take it off the
plan for now.

IMPORTANT: Because of the nature of this change, merging it into
master would break a lot of website functionality. But the truth is, a
lot of that functionality is broken anyway — just less visibly.

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.
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev
___
Dev mailing list
Dev@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/dev

Re: [Dev] GH-144 and the construction of the test suite

[Stephen Michel]

IMO, 3 is the right thing to do. It may be more work immediately but I 
believe it'll serve us best in the long run, particularly as we'll need 
to do it eventually no matter what.


On Tue, Oct 20, 2015 at 12:25 PM, Peter Harpending 
 wrote:

Hey, y'all!

I am Peter, pharpend in the channel. For a while, I've been spending
some spare time working on GH-144:
. I thought it
was a trivial issue that would take 20 minutes to fix, but it turns 
out

to be symptomatic of a much larger problem.

There are two sides to it:

1. Logged-in users can create a new user in /u/new.
2. Logged-in users can view /auth/login without trouble.

The fix to the first problem was pretty easy: put a clause in
UserCreateR to 400 if the user is already logged in, as seen here:
. See
 for
more details.

The second turned out to be an issue with yesod-auth, which the Yesod
people are now working on:
.

The problem: fixing the first half caused half the tests to fail, 
mostly
because they were structured poorly. Here, there's a seemingly 
innocuous

test that dictates that users should be able to create a new user:


However, that test is incorrect, and by GH-144 should fail. I couldn't
figure out a way to make it pass, so Bryan suggested I remove
it. However, it turns out that other tests depend on that first test
passing. Essentially, further tests log in as the users created during
that test.

This is bad, because each test should be independent: a test passing
should not depend on other tests passing.

So, we need to do one of three things:

1. Ignore GH-144 for the time being.
2. Figure out some hack so that the test in question passes.
3. Rewrite the test suite so that silly things like that don't happen.

I think (3) would be the best option, but it would require a lot of
dedicated effort. I know that rewriting the test suite is a fairly
high-priority item, and probably a necessity before we reach a full
release.

I would like everyone's thoughts on the matter before I go raining on
everyone's parade.

Peter

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