kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Does it not work by using the KIPRJMOD as is?

2017-05-31 15:17 GMT+02:00 Cheng Sheng <jeru.sheng@xxxxxxxxx>:
> Thanks, Fabrizio. It's good to know such info that is not mentioned in the
> doc. I'm indeed quite new to contributing code here.
>
> Regards,
> Cheng
>
> On 31 May 2017 at 13:06, Fabrizio Tappero <fabrizio.tappero@xxxxxxxxx>
> wrote:
>>
>> Hi Cheng,
>>
>> Don't worry you are doing just fine.
>>
>> Whenever somebody submits a patch, he does exactly what you did. Normally
>> it takes some days for the patch to get submitted because in these days
>> several people express opinions and feedback, as in your case.
>>
>> If nobody is against it and if the patch is useful for KiCad, the patch is
>> applied to the main repo in few days. A gentle reminder is a good way to
>> communicate with people with kicad repo writing rights.
>>
>> I hope you will submit more stuff. Contributing can be quite a rewarding
>> experience, I think. Just remember that the dev. community decides what goes
>> in and what stays out. And normally common good is paramount.
>>
>> cheers
>> Fabrizio
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 31, 2017 at 11:49 AM, Cheng Sheng <jeru.sheng@xxxxxxxxx>
>> wrote:
>>>
>>> okay, thanks for the info, Sergey.
>>>
>>> Don't find any explicit rule on how to select reviewers on the how to
>>> contribute page. So cc Jean-Pierre because you did a lot of commits
>>> recently. Let me know or reassign if there's some duty partitioning. Thanks.
>>>
>>> Regards,
>>> Cheng
>>>
>>> On 31 May 2017 at 11:01, Sergey A. Borshch <sb-sf@xxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>>
>>>> On 31.05.2017 10:57, Cheng Sheng wrote:
>>>>>
>>>>> So is there any conclusion on this patch like it will be accepted or
>>>>> rejected or needs some improvement?
>>>>>
>>>>> Sergey, are you a patch reviewer who can commit to the repo, or I need
>>>>> to add someone explicitly? Thanks.
>>>>
>>>> No, I'm just a user who wanted to share it's point of view.
>>>>
>>>>> Regards,
>>>>> Cheng
>>>>>
>>>>> On May 29, 2017 12:33 PM, "Cheng Sheng" <jeru.sheng@xxxxxxxxx
>>>>> <mailto:jeru.sheng@xxxxxxxxx>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>     On 29 May 2017 at 09:40, Sergey A. Borshch
>>>>> <sb-sf@xxxxxxxxxxxxxxxxxxxxx
>>>>>     <mailto:sb-sf@xxxxxxxxxxxxxxxxxxxxx>> wrote:
>>>>>
>>>>>         On 28.05.2017 23:49, Cheng Sheng wrote:
>>>>>
>>>>>             I myself prefer storing all files specific to the project
>>>>> within the
>>>>>             project directory, including datasheets, components,
>>>>> adjusted
>>>>>             footprints and scripts. This way makes things easier when I
>>>>> copy the
>>>>>             project around. After all, I don't mind disk space waste on
>>>>> a few
>>>>>             duplicated datasheets; they don't take much space.
>>>>>
>>>>>         Ok, what is your workflow? You choose component, pick it from
>>>>> library
>>>>>         into schematics and then manually copy it's datasheet (from
>>>>> where?) into
>>>>>         the project folder to make it available from schematics?
>>>>>
>>>>>     I'm not a professional on electronics so I don't (want/bother to)
>>>>> maintain a
>>>>>     centralized collection of datasheets. Instead, when I select
>>>>> components, I
>>>>>     do parametric search on digikey/mouser/whatever, then check
>>>>> datasheets on
>>>>>     the website, download to project dir if chosen.
>>>>>
>>>>>
>>>>>         I have my library and my project both under version control
>>>>> system, so I
>>>>>         use latest, exactly the same (with all latest error fixes)
>>>>> library and
>>>>>         latest, most actual datasheets in every project. But I always
>>>>> can easily
>>>>>         revert library repository to state it was when project was
>>>>> finished.
>>>>>
>>>>>     I admire your patience and professionalism. I see your spirit to
>>>>> reuse as
>>>>>     many things as possible. Shared library has its reuse benefit. Of
>>>>> course,
>>>>>     also has its downsides. Eg., I don't necessarily remember how the
>>>>> shared
>>>>>     libraries are setup one year after I finish a project or after I
>>>>> move to a
>>>>>     new machine. So I prefer each project to be as self-containing as
>>>>> possible.
>>>>>
>>>>>     Of course, putting everything inside the project also has its
>>>>> downsides,
>>>>>     maybe even more than your proposed shared library approach. But I
>>>>> suppose
>>>>>     this is just personal preferences. Unless there's a strong reason
>>>>> why my
>>>>>     personal preference is terrible (that it is worse than a "standard
>>>>> approach"
>>>>>     in ALL aspects) or by following this preference my patch makes the
>>>>> software
>>>>>     terrible, it shouldn't be forbidden, right?
>>>>>
>>>>>
>>>>>         There is "Archive library" option in eeschema File menu, which
>>>>> extract
>>>>>         from library all components used in project. It can be extended
>>>>> to
>>>>>         extract datasheets as well if it doesn't do it right now.
>>>>>
>>>>>     hm... Am I missing some compile options? I don't see such an option
>>>>> in
>>>>>     eevschema. Instead, only an "Archive Current Project" item in the
>>>>> project
>>>>>     window.
>>>>>
>>>>>     Anyway, even if datasheet extraction is added to "Archive library",
>>>>> you'll
>>>>>     still need a way to open a relative datasheet unless the archiving
>>>>> leaves an
>>>>>     absolute path (which seems unlikely the case, by guessing).
>>>>>
>>>>>
>>>>>
>>>>>             If the direction of move by the patch makes some other
>>>>> workflow
>>>>>             styles harder to optimize in the future, please let me
>>>>> know. I don't
>>>>>             mind alternative proposals that can fulfill more workflow
>>>>> types.
>>>>>             What I wrote is just a "shortest-path" I can see based on
>>>>> my own
>>>>>             workflow.
>>>>>
>>>>>             Regards,
>>>>>             Cheng
>>>>>
>>>>>             On 28 May 2017 at 20:53, Ingo Kletti
>>>>> <ikletti@xxxxxxxxxxxxxxxx
>>>>>             <mailto:ikletti@xxxxxxxxxxxxxxxx>
>>>>> <mailto:ikletti@xxxxxxxxxxxxxxxx
>>>>>
>>>>>             <mailto:ikletti@xxxxxxxxxxxxxxxx>>> wrote:
>>>>>
>>>>>                  Am 28.05.2017 um 18:47 schrieb Sergey A. Borshch:
>>>>>
>>>>>                      On 28.05.2017 14:35, Cheng Sheng wrote:
>>>>>
>>>>>                          So I made a patch to resolve the path before
>>>>> it is
>>>>>             passed to
>>>>>                          "wxLaunchDefaultBrowser()". If it looks like a
>>>>> URL or
>>>>>             is an absolute
>>>>>                          path, doesn't do anything; but if it is a
>>>>> relative
>>>>>             path, append
>>>>>                          "${KIPRJMOD}" to it.
>>>>>
>>>>>                      Are you storing all datasheets in every project? I
>>>>> think
>>>>>             it's better to
>>>>>                      keep one copy per library, so path must be
>>>>> relative to
>>>>>             library location.
>>>>>
>>>>>
>>>>>                  Don't know about the OP, but from past experience it
>>>>> is wise to
>>>>>             store the
>>>>>                  datasheet for the different components tpgether with
>>>>> the
>>>>>             project files. That
>>>>>                  way you always have the specs available that your
>>>>> design is
>>>>>             based on.
>>>>>
>>>>>                  So a relative path makes sense depending on the use
>>>>> case and
>>>>>             workflow.
>>>>>
>>>>>                  Regards,
>>>>>
>>>>>                  Ingo
>>>>>
>>>>>             --
>>>>>         Regards,
>>>>>            Sergey A. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxx
>>>>>         <mailto:sb-sf@xxxxxxxxxxxxxxx>
>>>>>              SB ELDI ltd. Riga, Latvia
>>>>>
>>>>>         _______________________________________________
>>>>>         Mailing list: https://launchpad.net/~kicad-developers
>>>>>         <https://launchpad.net/~kicad-developers>
>>>>>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>         Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>         <https://launchpad.net/~kicad-developers>
>>>>>         More help   : https://help.launchpad.net/ListHelp
>>>>>         <https://help.launchpad.net/ListHelp>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>   Sergey A. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxx
>>>>     SB ELDI ltd. Riga, Latvia
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>
>
> _______________________________________________
> 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
>