← Back to team overview

kicad-developers team mailing list archive

Re: Devel list at SF


Thanks Philip,

Your contributions to the "Identify Needs" step are quite helpful and clarifying.

If we were to prioritize the items, (in case we could not have everything) then I would say the patch manager is most important to me. Maybe we can have everything, but without excellent patch management, I would be disappointed.

While we are still planning, some other questions arise. Let me set the stage for my questions.

I see these categories of *developer's* software support services:

* Developer's Mailing List (Maillist)

* Source Code Repository (Repo)

* Tracker (Patches, enhancement requests, bugs)

* Wiki (arguably could be partioned from *user's* support services)


1) Can some of these reside on one machine and IP address, and others on another, and still make the "Tracker" happy, i.e. tie it all together?

2) Of the four listed, aren't we already OK with Repo and Wiki?

3) I appreciate your offer to host some or all of this. (How) does your system get backed up?



Dick Hollenbeck wrote:

Dick Hollenbeck escreveu:

1. Identify needs.

I am listening, and what I hear so far about "Identify Needs":

1A* Mail list to accept attachments

* Mailing list should not append a massive signature to every single message
* Mailing list should not convert messages to HTML just to tag on a tacky advertisement. If the message was sent text-only, it should STAY text-only. * Mailing list must archive attachments. No use having the message and an "attachment stripped because it was too big" error.

1B* Patch management: accepted, rejected, pending

* Patches: Submit -- 1 or more patch files per ticket, and a message to explain what it is. Should track who is assigned to handle the patch (who submitted it, who is working on integrating it into the codebase) People must be able to post reply messages to the patch 'thread'. Use something like Markdown for text formatting (similar to Wiki markup).

1C* Tracking issue changes need to be echoed into a mailing list

IIRC Trac can do that.

1D* stability of site (if it is measurable)

Less than two minutes downtime in the past six months and that was for a kernel upgrade :)

I did not get a warm feeling about Trac's abiltity to handle 1B.

I can't say I'm fond of Trac's patch handling either...

I should probably mention I'm a PHP/HTML/SQL developer by trade; if we really need a custom patch/ticket tracker then I could probably write one, but it would be on the proviso that I could release it as open-source for all to use.