Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On Fri, Jan 3, 2014 at 12:01 AM, Ouabache Designworks z3qmt...@gmail.com wrote: My experience has been that any code worth writing will long outlive whatever rcs system that you are using. Expect to have to do this on a regular basis John Eaton On Thu, Jan 2, 2014 at 4:08 AM, Kaspar Emanuel kaspar.eman...@gmail.com wrote: This discussion springing up on emacs-devel is likely relevant: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html On 2 December 2013 04:51, Povilas Kanapickas povi...@radix.lt wrote: Just for the record, git has submodules feature, which allows to store external dependencies in-tree and easily manage local patches to them. Regards, Povilas I've mentioned this on another thread but I'd like to re-iterate that I've tried to contribute to kicad but found bzr workflows to be very difficult to wrap my head around. I'm very familiar with cvs/svn/git though so I'd welcome a switch to git. Because git is so widely used now it may also make it easier for others to contribute. Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On Fri, Jan 3, 2014 at 9:02 AM, Brian Sidebotham brian.sidebot...@gmail.com wrote: Sorry, I've been off-list for a while whilst building my house over Christmas. bzr works fine and is what Launchpad hosted projects work with most easily. I don't see anyone wanting to change, especially as there's no real reason to change; Besides, bzr usage is included in the build system now too, so the commitment to bzr from KiCad appears clear. Tim/Chris, it's best to tell us what you're struggling with. All you have to actually do to contribute is: bzr branch lp:kicad *make changes* bzr diff new_feature.patch and email the patch to the developers list for review. Make sure you read the coding policies too. There's not much to bzr workflow, it's very typical distributed workflow. Best Regards, Brian. I'm not actively making changes but in case it helps someone else, here is what was confusing me. This is something I do a few times a day with git in order to keep history clean and integrate patch review feedback. How to get upstream changes while making local changes (or if I had a few local commits)? The other thing I couldn't figure out was how to modify local changes, and how to modify changes that were one or more changes behind my latest change. So if I wanted to build up a patch series how do I clean that up based on feedback or things I've learned along the way? ... - commit X (upstream HEAD) - commit 1 (local change) - commit 2 (local change / local HEAD) How to modify commit 1? It might help to document how to map these operations from git to bzr on the kicad page to help get people familiar with git up-to-speed. Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On 3 January 2014 14:09, Chris Morgan chmor...@gmail.com wrote: I'm not actively making changes but in case it helps someone else, here is what was confusing me. This is something I do a few times a day with git in order to keep history clean and integrate patch review feedback. How to get upstream changes while making local changes (or if I had a few local commits)? Just merge the current tip: bzr merge lp:kicad The other thing I couldn't figure out was how to modify local changes, and how to modify changes that were one or more changes behind my latest change. So if I wanted to build up a patch series how do I clean that up based on feedback or things I've learned along the way? ... - commit X (upstream HEAD) - commit 1 (local change) - commit 2 (local change / local HEAD) How to modify commit 1? Changing your workflow here will probably help if you want to work on different features at the same time, rather than trying to shoehorn that into one feature per commit, which I guess is what you're trying to achieve. Just branch locally as it's cheap: bzr branch ./kicad ./kicad-newfeature-1 bzr branch ./kicad ./kicad-newfeature-2 etc. Then commit locally as many times as you like in each feature. If you're doing parallel development and need both changes simultaneously, you could branch again and merge both features in, etc. Don't use bzr like git or svn or rcs or anything else, it's bzr and git's git! They do not have direct translation to one another. It might help to document how to map these operations from git to bzr on the kicad page to help get people familiar with git up-to-speed. Contributing to KiCad is extremely easy given you only have to branch, make changes and then create a patch and email it to the list. Please feel free to use this easy method to contribute your first changes. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] various patches
On 2 January 2014 03:27, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: Hi folks, I have put two sets of patches onto github for anyone to review or apply. The (bzr) patches: export_idf3.patch : Adds basic IDF3 export (board and cutouts / holes only) export_vrml.patch : Improved VRML export; includes more realistic coloring scheme, zone fills, improved eye candy. This patch is better than the patch I previously posted here; this patch fixes a number of bugs, eliminates a redundant class, and provides features such as the zone fills and silver pads. Hi Cirilo, Thanks for this work, the IDF export may well be something I could use. So thanks for contributing! :D Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Kipy, Klonor
Dear All As an happy Kicad user I had to draw the PCB of a product called V6 overdrive that saturates guitare sound on a string by string basis. As you may imagine there are 6 identicall ways and some common functions. Each way features 70 components. The ways share components two by two (way 0 and 1, 2 and 3, 4 and 5) My approach was to draw a hierarchichal schematic with Kicad. This feature is already stable. Then I faced the problem of doing a modular routing. I used kipy/klonor as a basis. I modified it to track the instances of the components is the kicad schematic and offset the components using the first two ways as a template. It does not run for tracks, but it is easy to copy and paste it. Now I would like to release it, in order to share it for both usage and development. What do you think is the best for that? Is there a room in kicad for such python script? Or anywhere else on the internet? SY Lionel SAINTE CLUQUE adresse: 1, rue Paul de KOCK 92500 Rueil Malmaison Téléphone +33 (0)6 18 04 20 75 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] various patches
- Original Message - From: Brian Sidebotham brian.sidebot...@gmail.com To: Cirilo Bernardo cirilo_berna...@yahoo.com Cc: Ki Cad Developers kicad-developers@lists.launchpad.net Sent: Saturday, January 4, 2014 1:41 AM Subject: Re: [Kicad-developers] various patches On 2 January 2014 03:27, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: Hi folks, I have put two sets of patches onto github for anyone to review or apply. The (bzr) patches: export_idf3.patch : Adds basic IDF3 export (board and cutouts / holes only) export_vrml.patch : Improved VRML export; includes more realistic coloring scheme, zone fills, improved eye candy. This patch is better than the patch I previously posted here; this patch fixes a number of bugs, eliminates a redundant class, and provides features such as the zone fills and silver pads. Hi Cirilo, Thanks for this work, the IDF export may well be something I could use. So thanks for contributing! :D Best Regards, Brian. No problem, I was in desperate need of IDF export for my own work (at least the board with cutouts and thru-holes). Let me know if you need other features implemented and I'll make sure I set some time aside for it. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] TODO: remove this whole if test on or after 14-Jan-2014 and remove the system/*.s sources if no one complains by then.
Dick, I’ve to support multiple processors,I’ve just ended to spit blood implementing it in boost for PPC32 an PPC64 in asm to add support in boost::context. ( https://svn.boost.org/trac/boost/ticket/8266 ). Now i’m building all for three platforms, then i’ll try to do a more extensive testing of kicad applications. I’ll try to test and change your code if needed, but which is the problem with using directly boost::context ? — Marco___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
