kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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)



Questions:

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?


Thanks,

Dick



> 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.