kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Wed, Nov 13, 2013 at 1:56 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> I hope you had our <kicad_src>/rules file in your
>
>   ~/.bazaar/
>
> directory.
>
> Otherwise we have a rather large mess on our hands.
>
> I don't know that an uncommit works against a push.
>
> We will ask that somebody with a pristine library repo not update for a moment until we
> can confirm.
>
>
> I don't give a shit about wrl files, I just want the fp-lib-table editor to look nice, and
> that means shorter stuff.
>
>
> Dick
>
>
>
>
> On 11/13/2013 11:51 AM, Carl Poirier wrote:
>> Coming from Mercurial, I prefer "branch, commit, push" rather than "checkout, commit". :P
>>
>> So I pushed one first set of changes. I renamed approximately 25 library files, and for
>> only a few of them, I renamed their 3d view files and more. Please let me know if it looks
>> alright. I'll then go on with the remaining.
>>
>> Attached is the corresponding fp-lib-table.
>>
>> Carl
>>
>>
>> On Tue, Nov 12, 2013 at 8:43 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>> <mailto:dick@xxxxxxxxxxx>> wrote:
>>
>>     bzr push
>>
>>     is almost always a mistake.
>>
>>      bzr commit
>>
>>     is appropriate, but requires that your branch is a "checkout".  People who talk about
>>     pushing with bzr are often confused, more often than not.
>>
>>     BTW the COW talk should have been put into a separate posting.  It has no bearing on
>>     what you are doing.
>>
>>
>>
>>     Sent from my Galaxy S®III
>>
>>
>>
>>     -------- Original message --------
>>     From: Carl Poirier <carl.poirier.2@xxxxxxxxx <mailto:carl.poirier.2@xxxxxxxxx>>
>>     Date: 11/12/2013 6:11 PM (GMT-06:00)
>>     To: Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>>     Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>     Subject: Re: [Kicad-developers] footprint library help needed
>>
>>
>>     There's lots of information for me to digest in there. I'll be looking at it more in
>>     details tomorrow, after I push a first batch of changes to the libraries.
>>
>>     Carl
>>
>>
>>     On Tue, Nov 12, 2013 at 4:36 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>>     <mailto:dick@xxxxxxxxxxx>> wrote:
>>
>>         Thanks Carl.
>>
>>         I have finished my work on the fp-lib-table dialog editor today.  Carl, your work will
>>         help make the wxGrid look sensible, and other than a long winded, too wide, circus.
>>
>>         I also finished its child options editor.  Options are separately supportable for each
>>         kind of PLUGIN.  Each PLUGIN tells the options editor which options it supports, along
>>         with "Internationalized HTML Help Text".
>>
>>         I have a number of phoney options compiled in for now, which will show up in the
>>         options
>>         editor but not be supported in any plugin.  These are designed to ask questions
>>         and spur
>>         ideas.  I plan on coding up actual support for *none* of these options myself, but you
>>         will see the kind of concepts that it allows.
>>
>>         In the /new eeschema library design I had the notion of a LIB_SOURCE and a
>>         LIB_SINK.  That
>>         let you read from one place and save to another.
>>
>>         Borrowing from that concept, it would be only a couple of hours to extend
>>         GITHUB_PLUGIN
>>         from KICAD_PLUGIN, (maybe making stuff protected rather than private), and being
>>         able to
>>         FootprintSave() in the GITHUB_PLUGIN locally.  Those saved footprints would be in
>>         their
>>         own *.pretty dir, and would conceptually be combined with what is in the GITHUB
>>         repo.  It
>>         would also represent your notion footprints that you would like to modify on the
>>         github
>>         repo, and could be emailed to the library maintainer for his git push-ing.
>>
>>         This is Copy On Write (COW).  The lib_path for the base class KICAD_PLUGIN would
>>         come from
>>         an option passed to the derived class, and it really is less than about 40 to 50
>>         lines of
>>         code, at most.  A volunteer is welcome to make this modification, I will not be.
>>
>>         But even without GITHUB_PLUGIN's COW, I think the project is best served by
>>         putting *all*
>>         the libraries on github and dump the launchpad copies.  If the footprint subset of
>>         thos
>>         libraries are saved in a way suitable for the github plugin, then a person would
>>         not need
>>         to install them, and would always have up to date footprints.
>>
>>         Carl, I appreciate your help.  On this topic I feel like I am talking to in a
>>         nearly empty
>>         cave, and you are the lone voice in the cave.
>>
>>
>>         Regards,
>>
>>         Dick
>>
>>
>>
>>
>>
>>
>>         > Yes, by the end of the week I'll push part of the whole refactoring, with a,b,
>>         and c done.
>>         > I've been caught up by some exams last week, but it should be better now.
>>         >
>>         > Carl
>>         >
>>         >
>>         > On Mon, Nov 11, 2013 at 4:30 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>>         <mailto:dick@xxxxxxxxxxx>
>>         > <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>>         >
>>         >     On 10/30/2013 10:31 AM, Dick Hollenbeck wrote:
>>         >     >
>>         >     > With the advent of the fp_lib_table support, we encounter some ill effects
>>         of long
>>         >     > footprint library names.  Please see row 61 in attached *.png file.
>>         >     >
>>         >     > What I suggest be done:
>>         >     >
>>         >     > a) *Nicknames*: revise the template/fp-lib-table file wrt nicknames:
>>         >     >   i) no longer than 25 characters
>>         >     >   ii) adopt a consistent choice of capitalization
>>         >     >
>>         >     >
>>         >     > b) shorten the name of *Library Path* entries, this means renaming most
>>         footprint
>>         >     > libraries in the bzr repo to remove any reference to date or revision and
>>         to remove any
>>         >     > inclusion of part names.
>>         >     >
>>         >     >
>>         >     > c) add the previously existing references to part names which were in the
>>         library names,
>>         >     > into the "Description" column of the fp-lib-table if the author so desires.
>>         >
>>         >     c) was modified to "Description" field should include about 50- 80 characters of
>>         >     descriptive text, not necessarily originating from the filename.
>>         >
>>         >
>>         >
>>         >     Carl,
>>         >
>>         >     Any progress on a), b) or c)?
>>         >
>>         >
>>         >     Will you be able to provide a new <kicad_src>/_global fp-lib-table soon,
>>         with updated
>>         >     Descriptions field?
>>         >
>>         >     If not please say approximately when.
>>         >
>>         >
>>         >     Thanks very much,
>>         >
>>         >     Dick
>>         >
>>         >
>>         >     _______________________________________________
>>         >     Mailing list: https://launchpad.net/~kicad-developers
>>         >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>         >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>         >     Unsubscribe : https://launchpad.net/~kicad-developers
>>         >     More help   : https://help.launchpad.net/ListHelp
>>         >
>>         >
>>
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


It might be a bit off-topic but this looks like a place where github
and pull requests would be helpful to make it easy to review and merge
work by the integrator and let the committer do the work to ensure
things are in the right format for pulling.

Chris