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 <b...@chreekat.net> 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
