[darcs-devel] Contributors: Getting Started?

David Roundy droundy at abridgegame.org
Sat Oct 9 04:15:50 PDT 2004


On Fri, Oct 08, 2004 at 04:19:49PM -0400, Ryan Lowe wrote:
> I've been following the darcs mailing list for a little while and 
> noticed you might need some help with bugfixes.  I've never programmed 
> in Haskell, but I'm relatively strong in other languages, especially 
> Java, and I have a Software Engineering university degree (not that it 
> matters much in the FLOSS community). :)

Well, new darcs developers are most definitely welcome.  A nice starting
feature that would be welcome while you get up to speed on the code and on
haskell would be adding new tests.  That just requires shell scripting, but
also involves understanding how the various darcs commands work, which
should be helpful when actually making modifications.

One excellent way to help with bugfixes would be to write a "failing"
contribution to the test suite for bug reports.  It's great when users give
me a nice series of shell commands to trigger a bug, but it'd be even
better to have a new test in the test suite.  It'd both make it easier for
me to debug, and reduce the chance of new related bugs being introduced in
the future.

> While considering whether or not to start contributing to this project 
> I was looking around for some development information, but couldn't 
> find any on the web site, wiki or mailing list.  Maybe you can answer 
> these questions for me, or just point to a rundown of the general 
> procedures...
>
> 1. Is everything coordinated on the mailing lists?

Yes.

> 2. If not, is there a bug database somewhere?

No.  There's some thought (and work) on putting an experimental bug
database into the darcs repository, but there aren't any bugs that have
been reported using "darcs reportbug" so it hasn't gone anywhere.

> 3. Is there developer documentation?

Not really.  There's a bit of documentation some places in the code itself
(which is literate), but there hasn't really been an attempt to put it
together in a sane way.

> 4. Is there a release schedule or roadmap?

Not really.  I've got some idea in my head where darcs needs to go, and
since I've talked about such things a bit on the mailing list, some people
may have a decent idea what I'm thinking (but it's hard to know).  There is
a TODO list, which sometimes is relevant.

>    How do enhancements and fixes get prioritized? How do you ensure two
>    people don't work on the same bugfix?

Well, mostly I do the bugfixing, except for bugs in darcs.cgi (which Will,
who wrote it, works on), and bugs that people introduced themselves.

Since I do most of the bugfixing myself, prioritization is mostly done in
my head.  Right now I'm trying to avoid doing any
potentially-bug-introducing changes, which makes life a bit boring.
Contributors usually ask on the list if they have an idea for an
enhancement or new feature.  Some older contributors just code up with an
idea and send it in, which is fine with me, although in theory it could
lead to duplication.

> 5. Is there a procedure or preconditions (ie. unit testing) for 
> submitting patches?

Well, darcs has a test suite that you really ought to run before sending a
patch.  But if you don't, I'll run it anyways (it's automatically run when
I send patches to the central repository), so the worst that happens is I
unpull your patch and you feel embarrassed.

The procedure is just a darcs send.  It'll go to the darcs-devel list, and
I'll either apply it or reply to it or both.  If you have a potentially
dangerous feature, you probably should be working on the darcs-unstable
branch where I'm putting such features.

> It may be that all of these things are just informal and learned as a 
> new developer comes online, and I'm nearly expecting that for a project 
> of this size.  I can handle that no problem, but I was just wondering 
> if there was anything to read beforehand (I've gone through the manual, 
> but besides the source code) to save some time so I don't have to waste 
> your time asking too many noob questions. :)

At this stage, any questions (on list) are welcome! When there are too many
frequently asked questions, I'll just have to write a FAQ.

> Particularly, I'd be interested in reading a general SCM document on 
> branching to get me up to speed in that area.  I have the general idea 
> of it, but when the branching discussion took place on the user list I 
> found my eyes glazing over with all of the moving of patches between 
> branches and all of the different types of branches (trunk/HEAD, 
> release, dev, etc) and how to organize/manage them, along with 
> versioning.  It might be useful to be on the same page.  I guess this 
> is something that people just pick up over the years and after a while 
> becomes common knowledge.  I'm not at that point yet.  :)

Alas, there's not much that I can point you to on the subject.  There are
so many different ways to deal with branches. Definitely the (empty)
best_practices.tex would be helpful here if it were filled in...
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-devel mailing list