kicad-developers team mailing list archive
Mailing list archive
Re: Devel list at SF
Dick Hollenbeck <dick@...>
Mon, 15 Dec 2008 08:40:10 -0600
Thunderbird 220.127.116.11 (X11/20081125)
Your contributions to the "Identify Needs" step are quite helpful and
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.
* 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
1B* Patch management: accepted, rejected, pending
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.