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 <[email protected]> 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 <[email protected]> > wrote: > >> okay, thanks for the info, Sergey. >> >> Don't find any explicit rule on how to select reviewers on the how to >> contribute <http://kicad-pcb.org/contribute/developers/> 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 <[email protected]> >> 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" <[email protected] <mailto: >>>> [email protected]>> wrote: >>>> >>>> >>>> >>>> On 29 May 2017 at 09:40, Sergey A. Borshch < >>>> [email protected] >>>> <mailto:[email protected]>> 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 < >>>> [email protected] >>>> <mailto:[email protected]> <mailto: >>>> [email protected] >>>> >>>> <mailto:[email protected]>>> 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: [email protected] >>>> <mailto:[email protected]> >>>> SB ELDI ltd. Riga, Latvia >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> <https://launchpad.net/~kicad-developers> >>>> Post to : [email protected] >>>> <mailto:[email protected]> >>>> 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: [email protected] >>> SB ELDI ltd. Riga, Latvia >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
