[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Anarchdb-devel] Re: database layout questions?

From: Karl George Schaefer
Subject: Re: [Anarchdb-devel] Re: database layout questions?
Date: Mon, 13 Mar 2006 17:43:44 -0500

Removed extraneous text for this reply (for clarity). There is some good development talk in the previous messages, though.

Most of us are coming to the code for the first time and will need to
become accustomed to it.  We also want to hit a release date of less
than a week after NoR.  We want to keep our users happy and still meet
the needs of the new set.

I was not aware of the goal of one week between NoR release and new ardb
release otherwise i fully agree with you. We shoud make our users happy,
then make ourselves happy with the codebase
Well, no one's actually place a date on us. But, we've all sort of nodded that we need to have the new version out quickly afterwards. In the past, that was about a week after, so we should try to keep up the pace.

After we hack together the first release, we should have ~9 months until
the next set, so that should give us some time to work out a development

if i have to put a plan here i would do this in several steps:
* include NoR in anarchdb codebase
* i would then put a maintenance release that close all know issues
and the new ones produced from NoR release. This would allow us all to
accustom to the codebase and enhance our team work. By the same time
we will set up a developpemnt plan.
* last step: codebase refactoring.
I consider refactoring a great way for a developer to learn about his code base. I would push it higher on the spectrum, simply because it gives the newer developers a greater sense of code ownership and a deeper understanding of how the code actually works. We have very few known issues and it might be best to wrap them into refactoring. Also, as I've looked at all of the known issues, some will be difficult to reproduce. We need to get a Mac developer to check out some of them. If we can't replicate the problem, we'll need to wait until it's reported again in a better fashion.

Here are some ideas that I have about a development plan:
1.  Create scripts and readmes that will allow the building of ardb to be
easier on Windows platforms.  This is mostly completed (I'm guessing) for
linux.  Ease of building will allow less strong developers to aid the
project more easily.

Agree, the app is deadly missing developpers docs. we should consider
including doxygen to our building env to generate doc.
Never used it. But, my chief language is Java, so sure whatever everyone's comfortable with. Do you have a link to information about how to use Doxygen?

2.  A UI group focused on good UI design that encompasses a heuristic
methodology about user interaction will give ARDB a higher level of
polish. This group doesn't need a lot of programmers.  This group needs
to have people that can sketch new UI designs and determine where the UI
currently fails the user.  There currently isn't a lot here that we need
to concern ourselves with, the tool is pretty straight forward.  The
inventory section will need some work and will probably be the focus of
most of these efforts.

Agree. The best way should be to do it user-driven
But, we should endeavor to give the users a good product to begin with. I have a list of UI heuristics that I use when developing an application. I'll post them later.

also want to look into ways the code can be self-expanding (handling new
disciplines and clans without adding lines to the code).

We need database
designers here that can plan a reproducible work-flow that transforms the
WW files into our needs.

agree, we should also take care of fran├žois deck morphing issues.
What's this?

On the code side, we need to update to the latest
libraries, tighten up the code (it may be tight already, I haven't really
delved into it too deeply),

Yes, i did notice that the codebase does not include any automatic
unit tests. That is something i'm willing to promote.
Sure.  I used to do QA work and hated it.  So, if you're willing...

5.  Request for features from users.

There are probably other focus areas and perhaps 2 and 3 should be
swapped in order (and most of 4's tasks will be short and can be folded
in during downtime on other parts).  Anyone else have any ideas about

We really need to worry about this stuff *after* we get an ARDB that will
handle NoR.  Is everyone agreed on that?

I do agree. We won't do much before releasing NoR in anarchDB.

None the less i think we need to evaluate our task force to see what
is acheavable in short and long terms
So, we have a lot of developers here.  Who can do what?  Who has time?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]