kicad-developers team mailing list archive

[Vesa Solonen <vsolonen@...>]

Bumping made some bounce...

On Fri, 26 Feb 2010, phinitnan_c wrote:

> Dear all librarians,
> After reading this thread, I think we need a brainstorm. This is what i can summarize:
> 1. A central place to collect our work.
> 2. A new mailing list.
> 3. A convenient way to review each other's libraries.
>
> Here is my opinion:
> 1. We can use launchpad as a central repository. Everyone can have his/her branch to collect their
> work. When all work is ready, we can collect them and set as the main trunk.
>
> 2. We can also use launchpad as a new mailing list for new library development. Moving to launchpad
> has been talking for quite a while. I dont see any reason why shouldn't we move. Am i missing
> something?

Do you feel like managing the launchpad repository for external commits 
from those who don't have an account on launchpad or don't want to 
register?

For the mailing list I think kicad-devel will also do as traffic is very 
bursty and there is still some capacity left. Naturally other developers 
will have something to say regarding volume and relevance, but if we honor 
the thread topics, there should be no problems. I'm all in for a larger 
move, but I think we are still too small a community to need any more 
splitting.

> 3. Manveru suggested we can use wiki to collect image of drawings. This seems to be good at start.
> But when the number of drawing get larger, it can be problematic. What i suggest is, according to
> (1), a librarian can checkout any branch (any librarian's work) from launchpad and review it
> locally using library editor (instead of viewing captured images). Reviewer can go to the
> librarian's branch and make any comment/suggestion.

If there is a possibility to run some code on the server, it would make 
sense to render the library or parts to svg/png on demand. If I recall 
correctly Dick is at least thinking some web interface to footprint 
management, so that infrastructure may be used for symbols and component 
libraries also.

> Note: If we can have a conclusion whether the library's directory looks like(if we need a new
> structure), we can merge all work to the main trunk instantly. what benefit we can have is that
> only single main branch where all old/new approved librarians can 'checkout' and edit what they
> like.

The complex part is that are we satisfied with the current library system 
as a whole or does it benefit from a larger rework. And how is that 
possible rework implemented and by who? IMHO the pin and gate swap with 
clever pin naming and numbering back and forth in the workflow is a very 
valuable addition. If implemented this will probably make deep hierarchial 
library stucture somewhat useless and unneeded. Only special function IC's 
will need the library hierarchy, but clever search will make this 
redundant as well.

-Vesa