Re: [Kicad-developers] Proposed roadmap changes

[Andrey Kuznetsov]

Are there plans to add Constraint Manager to KiCad?

In Allegro, CM allows Design Engineers to specify physical, electrical and
spacing rules for classes, groups and nets, so that the PCB Layout Engineer
will be constrained by these definitions when working on the layout. It's
an explicit engineering note that forces the layout designer to obey these
rules rather than by word of mouth or email for the layout engineer to
follow.

On Thu, Mar 8, 2018 at 10:49 AM, jp charras  wrote:

> Le 08/03/2018 à 19:02, Ouabache Designworks a écrit :
> >
> >
> > On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans > wrote:
> >
> > Netlist export is a key feature of every schematic editor. So is
> multi-sheet support. These
> > aren't random extra features, they are a normal part of any modern
> schematic editor.
> >
> >
> >
> > Yes they are necessary features. My argument is that they have little to
> do with the core mission of
> > putting graphical objects on the screen and probably would not share
> much code with
> > the rest of the program. If you add this into the main program then it
> only makes it bigger and more
> > complex. I alway go  for the simpler and cleaner approach.  Calling the
> netlister is more
> > of a design management task than a schematic editor one so it should go
> into the Design Manager program.
> >
> > John Eaton
>
> "they have little to do with the core mission..."
> This is false.
> A internal netlister is mandatory in a schematic design tool at least
> because it is the key for ERC
> and net highlight.
> An especially for net highlight, it must be *very* fast.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Proposed roadmap changes

[jp charras]

Le 08/03/2018 à 19:02, Ouabache Designworks a écrit :
> 
> 
> On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans  > wrote:
> 
> Netlist export is a key feature of every schematic editor. So is 
> multi-sheet support. These
> aren't random extra features, they are a normal part of any modern 
> schematic editor. 
> 
> 
> 
> Yes they are necessary features. My argument is that they have little to do 
> with the core mission of
> putting graphical objects on the screen and probably would not share much 
> code with
> the rest of the program. If you add this into the main program then it only 
> makes it bigger and more
> complex. I alway go  for the simpler and cleaner approach.  Calling the 
> netlister is more
> of a design management task than a schematic editor one so it should go into 
> the Design Manager program.
> 
> John Eaton

"they have little to do with the core mission..."
This is false.
A internal netlister is mandatory in a schematic design tool at least because 
it is the key for ERC
and net highlight.
An especially for net highlight, it must be *very* fast.

-- 
Jean-Pierre CHARRAS

___
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] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans  wrote:

> Netlist export is a key feature of every schematic editor. So is
> multi-sheet support. These aren't random extra features, they are a normal
> part of any modern schematic editor.
>
>

Yes they are necessary features. My argument is that they have little to do
with the core mission of putting graphical objects on the screen and
probably would not share much code with
the rest of the program. If you add this into the main program then it only
makes it bigger and more complex. I alway go  for the simpler and cleaner
approach.  Calling the netlister is more
of a design management task than a schematic editor one so it should go
into the Design Manager program.

John Eaton
___
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] Proposed roadmap changes

[Tomasz Wlostowski]

On 08/03/18 18:45, Ouabache Designworks wrote:
> 
> 
> On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski
> > wrote:
> 
> 
> Please, give me a single argument what benefits Kicad would get by
> having a netlist generator as a separate program. I also asked you for
> an example of a successful graphical editing application following 'the
> unix way', but so far you've not answered my question. Does this mean
> that there isn't any?
> 
> Tom
> 
> 
> 
> EEschema is a schematic editor. You give it a schematic file, it edits
> that file and you save it. Nice simple tool.
> 
> Now you  want to tack on netlist exporting. Thats fine as long as the
> entire design is in one file but what do you do when you have a
> multisheet design?  Now you need a top sheet that contains the file
> names for all the other sheets. You have to parse out all those names,
> read those files into memory, interconnect them with the existing
> connections before writing out the netlist.  All this has nothing to do
> with editing schematics and should not be included in EEschema.

I don't see any problem with the way it's done today with multiple
sheets. The netlister starts with the root sheet and loads sub-sheets
when necessary. Making a netlist is so essential for PCB design that in
most modern packages (Kicad V5 included) it's not even visible to the user.

Imagine an audio workstation program requiring an external command line
tool just to mix down all the tracks and produce and MP3 file. Find me a
musician who would like to use it :)

> 
> 
> 
> To answer your question: I am not aware of any popular graphics editors
> that do strictly follow the unix way.

Me neither. The unix way was defined in early '70s, so it works well for
things that were invented in '70s: shell interpreters or compilers (not
all of them). If it worked well for graphical software, we would have
tons of proprietary applications following the unix principles with
crowds of happy users.


Tom

___
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] Proposed roadmap changes

[Jon Evans]

Netlist export is a key feature of every schematic editor. So is
multi-sheet support. These aren't random extra features, they are a normal
part of any modern schematic editor.

On Thu, Mar 8, 2018, 12:45 Ouabache Designworks  wrote:

>
>
> On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>>
>> Please, give me a single argument what benefits Kicad would get by
>> having a netlist generator as a separate program. I also asked you for
>> an example of a successful graphical editing application following 'the
>> unix way', but so far you've not answered my question. Does this mean
>> that there isn't any?
>>
>> Tom
>>
>>
>>
> EEschema is a schematic editor. You give it a schematic file, it edits
> that file and you save it. Nice simple tool.
>
> Now you  want to tack on netlist exporting. Thats fine as long as the
> entire design is in one file but what do you do when you have a multisheet
> design?  Now you need a top sheet that contains the file names for all the
> other sheets. You have to parse out all those names,
> read those files into memory, interconnect them with the existing
> connections before writing out the netlist.  All this has nothing to do
> with editing schematics and should not be included in EEschema.
>
>
>
> To answer your question: I am not aware of any popular graphics editors
> that do strictly follow the unix way.
>
>
> John Eaton
>
>
>
___
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] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski  wrote:

>
> Please, give me a single argument what benefits Kicad would get by
> having a netlist generator as a separate program. I also asked you for
> an example of a successful graphical editing application following 'the
> unix way', but so far you've not answered my question. Does this mean
> that there isn't any?
>
> Tom
>
>
>
EEschema is a schematic editor. You give it a schematic file, it edits that
file and you save it. Nice simple tool.

Now you  want to tack on netlist exporting. Thats fine as long as the
entire design is in one file but what do you do when you have a multisheet
design?  Now you need a top sheet that contains the file names for all the
other sheets. You have to parse out all those names,
read those files into memory, interconnect them with the existing
connections before writing out the netlist.  All this has nothing to do
with editing schematics and should not be included in EEschema.



To answer your question: I am not aware of any popular graphics editors
that do strictly follow the unix way.


John Eaton
___
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] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 8:26 AM, Andy Peters  wrote:

>
> > On Mar 7, 2018, at 9:22 PM, Ouabache Designworks 
> wrote:
> >
> >
> > If you are doing a PCB with a FPGA on it then you really want that FPGA
> designer to be using kicad to design their padring. Kicad could fill this
> niche and it would make your job a lot easier.
>
> If only it was that simple. FPGA (and to some extent, microcontroller) pin
> swapping during layout is a holy grail. The problem is that it’s not as
> simple as it seems. The layout person cannot arbitrarily assign pinouts
> without understanding the specific chip I/O architecture and rules and also
> understanding the FPGA design. Our layout guy is literally on the other
> side of a low wall from me, and I hear his cursing about pin selection all
> the time!
>
>
Andy,

All of these are good points and they fall into what I call "Engineering
notes". A schematic alone is not enough information to layout a PCB. The
design engineer must also include a long list of engineering requirements
that must be meet in order for the board to actually
work. Most of these involve Signal Integrity ,EMI,ESD,Power and timing.

Kicad need to develop a language so that the design engineer can enter
these notes in a machine readable format that is passed to the Layout
programs DRC tests.



An obvious house rule is one we have at the day job: before a PCB is
> released, the FPGA tools are run on the design to ensure that you don’t get
> timing screw-ups and you don’t have illegal pin locations. The problem, of
> course, is that you need to have enough of the FPGA design done before you
> can do that, and there’s always someone with a schedule demanding that the
> board be sent out for fab before you’ve even started simulating your design.
>
>
This is opposite of the problem that we have with ASICs. The ASIC usually
leads the board development by at least one year so you might have to
design the padring before the board design team has even been staffed. This
is why you want your IC designers to be
able to do a partial design with only the major chips to find obvious
problems.

You could create a fpga design with no logic but the correct I/O pads that
toggled at the correct rates. That would let you test out your board before
the real design was ready and could even do your JTAG board testing.

John Eaton
___
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] Proposed roadmap changes

[Tomasz Wlostowski]

On 08/03/18 03:21, Ouabache Designworks wrote:
> 
> What happens if you edit a schematic, export the netlist and are
> interrupted before you can save the schematic? 

I guess in this case a crash happens sometime after the netlist export
if the user can't save the schematic anymore... Which is bad whether
it's done unix-style or not.

In Kicad, the ultimate netlist is stored in the schematic. The net
indices in PCB are derived from the schematic. Netlist is just an
intermediate file, or in the newer Kicad versions, a variable in the memory.

Please, give me a single argument what benefits Kicad would get by
having a netlist generator as a separate program. I also asked you for
an example of a successful graphical editing application following 'the
unix way', but so far you've not answered my question. Does this mean
that there isn't any?

Tom



___
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] Proposed roadmap changes

[Andy Peters]

On Mar 8, 2018, at 9:21 AM, Ouabache Designworks  wrote:
> 
> Why don't we run PCB layout on the schematic file and let it call the 
> netlister program every time it runs. This is a simpler process flow with 
> fewer cases where you make the user jump through hoops to get something done.

This makes a ton of sense. When working on a layout, it must match the 
schematic. 

(In the past, we had a rule. When a layout is complete, generate a new netlist 
from the schematic and import it into the layout. If layout reports no changes 
are necessary, the two are in sync and all is well.)

The netlist is just ephemeral, anyway; once it is imported into the layout it’s 
no longer necessary. The netlist is a vestige of the days when PCB CAD packages 
were a collection of disparate programs.

But … 

This action should be one way, that is, changes in the schematic should not 
force an automatic update of the layout. Consider: you made some updates to the 
schematic, and you’d like your colleagues to review it before you commit to it. 
They look at it, make suggestions, which might include not making the changes. 
If the layout automagically updated from your unreviewed changes, then you’d 
have to undo those changes in the layout.

This means that when you open the layout, it can notice that the schematic has 
changed and ask the user if it should be updated to sync with those changes. 
Because the answer might well be no, I am not ready to do that yet. Maybe you 
just want to look at the layout as it is, for whatever reason.

-a
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 7, 2018, at 9:22 PM, Ouabache Designworks  wrote:
> 
> 
> If you are doing a PCB with a FPGA on it then you really want that FPGA 
> designer to be using kicad to design their padring. Kicad could fill this 
> niche and it would make your job a lot easier.

If only it was that simple. FPGA (and to some extent, microcontroller) pin 
swapping during layout is a holy grail. The problem is that it’s not as simple 
as it seems. The layout person cannot arbitrarily assign pinouts without 
understanding the specific chip I/O architecture and rules and also 
understanding the FPGA design. Our layout guy is literally on the other side of 
a low wall from me, and I hear his cursing about pin selection all the time!

Some examples of why this is not so straightforward.

a) The obvious one is clock inputs. They have to be on specific pins if one 
wants the best routing from the pin to the internal clock buffer, and if one 
wants to take advantage of advanced clocking features (DLLs, PLLs, input 
delays).

b) FPGAs have rules about differential pairs. Pins on specific banks are 
differential inputs or outputs only, pins on other banks can be both. Some have 
internal termination on certain pairs, others don’t. Bank I/O voltage is 
important, so you can’t move the pair to another bank with a different supply.

c) Mind the bank supplies for your signals. You can’t put a 3.3 V signal on a 
2.5 V bank. The schematic and layout tools don’t have a “net type” attribute 
that says, “This is an LVCMOS33 signal” which would bark at you if you tried to 
connect it to a pin that had an LVCMOS25 type attribute. It would be great if 
such a feature existed. 

d) Regional clock inputs require that all of the things that might use that 
clock be constrained to be in the clock region — and the region and the I/O 
bank don’t necessarily map to each other. And the layout person might not 
realize that a pin even needs to be in a specific region. And how would he know 
that a specific pin is in the right region?

e) Lattice MachXO2 (to use a recent example) has limitations on the total 
output current for pins on a bank. It’s not straightforward. The good news is 
that their fitter tool complains if the bank is overloaded. The less good news 
is that there’s no obvious way to communicate that information to the layout. 
Schematic and layout don’t know about pin loading, for example. While pin 
loading could be (and in some high-end schematic tools, is) part of the DRC, 
this particular Lattice constraint would need to have some code that does the 
test.

f) Specialist features such as gigabit serializers and deserializers, memory 
interfaces, and the like, simply cannot be swapped.

An obvious house rule is one we have at the day job: before a PCB is released, 
the FPGA tools are run on the design to ensure that you don’t get timing 
screw-ups and you don’t have illegal pin locations. The problem, of course, is 
that you need to have enough of the FPGA design done before you can do that, 
and there’s always someone with a schedule demanding that the board be sent out 
for fab before you’ve even started simulating your design.

So if we’re talking pie-in-the-sky wish-list: Kicad should have a plug-in that 
can read and parse FPGA constraint files and “know” the FPGA symbol pin names 
and attributes. And after the swapping, which will automatically update the 
schematic, and which has ERC of some sort enforced, Kicad will update the 
constraint file with the new pin assignments.

-a
___
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] Proposed roadmap changes

[Ouabache Designworks]

On Wed, Mar 7, 2018 at 11:59 PM, Russell Oliver 
wrote:

> From what I am reading John your call for acting on the files on disk
> instead of memory is a call for a clear demarcation of actions that need to
> be irrevocable and require the project data to be consistent.
>
> In my opinion this doesn't necessarily require separate programs, just
> consistent checks on the current state of the project and its data. A check
> and dialog box to force the user to save the all schematic sheets before
> exporting the netlist might be sufficient.
>
> Likewise saving the pcb after changing say a selected footprint or
> changing the reference or value of a component, would force a back
> annotation of the schematic which would also be saved. A change would not
> be allowed to persist without it being consistently applied across the
> project.
>
>
>
>
True, You can simply check for unsaved changes and refuse to export the
netlist until after the user saves the schematic. But what do you do if
they save the schematic but do not export the netlist? Pcb layout will see
that the netlist file is older than the
schematic and this means it might be out of date. Do you refuse to do the
layout until the user goes back and corrects it? Do you run a netlist
program and fix it without telling the user? You give the user the option
to export a netlist or not but if they don't
then you won't let them continue until they do. No wonder people hate
computers.



Why don't we run PCB layout on the schematic file and let it call the
netlister program every time it runs. This is a simpler process flow with
fewer cases where you make the user jump through hoops to get something
done.

John Eaton
___
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] Proposed roadmap changes

[Chris Gammell]

>
> Are these users professional users who are using KiCad at there day job
> and is there any way to confirm this?
>

It's self reporting, but their email domains, LinkedIn profiles and product
listings seem to bear it out


> I am currently surveying that group and will be returning with some
> > recommendations. I'm also asking if they would be interested in telling
> > their stories to the development team when asked as part of the survey.
>
> Thank you for gathering this information rather than having 40 users
> bombarding the developers mailing list.  I appreciate the effort in
> putting this information together.  I'm willing to listen to user
> experience once v5 is out.  I am swamped at the moment and I don't want
> users feel that they don't have my full attention.
>

No problem! I used to do product management and I recall the competing
interests of what individual voices want vs what is good for the project vs
what needs to be fixed in the immediate future from an infrastructure
perspective. I'm super excited about v5 (and beyond) and I'm happy to help
coordinate community efforts however I can.

If there are other groups we should target on a community feedback level
(hobbyist, academic, enterprise) and people would be interested in heading
up those kinds of groups, I'd be happy to coordinate, either through email
lists or the user forum.

~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] Proposed roadmap changes

[Russell Oliver]

>From what I am reading John your call for acting on the files on disk
instead of memory is a call for a clear demarcation of actions that need to
be irrevocable and require the project data to be consistent.

In my opinion this doesn't necessarily require separate programs, just
consistent checks on the current state of the project and its data. A check
and dialog box to force the user to save the all schematic sheets before
exporting the netlist might be sufficient.

Likewise saving the pcb after changing say a selected footprint or changing
the reference or value of a component, would force a back annotation of the
schematic which would also be saved. A change would not be allowed to
persist without it being consistently applied across the project.






On Thu, 8 Mar 2018 15:22 Ouabache Designworks,  wrote:

>
>
> On Wed, Mar 7, 2018 at 8:01 PM, José Ignacio 
> wrote:
>
>> The separate program issue is just an implementation detail. The main
>> thing that Kicad is headed for is the refactoring slated for the 6.0 dev
>> cycle. The cleaner data structure foundation and subsequent decoupling of
>> the logic from the UI classes will allow all sorts of automation that are
>> currently very hard or impossible. The vision that was set since over 5
>> years ago was for Kicad to present a library-like interface to the outside
>> world. It kind of does now on PCBnew only, but things are slowly improving
>> as things get refactored and legacy code gets phased out.
>>
>> I honestly think the last thing Kicad needs right now is a chance of
>> direction, I speak as a user that has been using Kicad professionally for
>> just over 2 years now, working on dozens of PCB projects over that time.
>> The developments in the past few years have been nothing but awesome for a
>> project with Kicad's resources. We just need to be patient, or try to help
>> out in a constructive manner.
>>
>> Over the past couple years I have been using the dev version in
>> production to take advantage of the new features (dealing with
>> versions/instability was a small price to pay for me), I also helped a
>> little bit (as time allowed) with the occasional patch or grumpy bug
>> report. I'd like to thank everyone that has worked on the project so far;
>> It basically has made it possible for me to make a living doing what I
>> enjoy, and I really hope the project can retain the momentum it has built
>> up in the past few months, it just keeps getting better!
>>
>> Thanks,
>> Jose
>>
>>
>>
>
> Nothing that I am asking for is a change of direction. Instead of calling
> a function that operates on data in memory you call a program that operates
> on the same data in the file system.
> You see the same menu pick either way. This will fit in with the
> refactoring.
>
> If you are doing a PCB with a FPGA on it then you really want that FPGA
> designer to be using kicad to design their padring. Kicad could fill this
> niche and it would make your job a lot
> easier.
>
> John Eaton
>
>
> ___
> 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
>
___
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] Proposed roadmap changes

[Ouabache Designworks]

On Wed, Mar 7, 2018 at 8:01 PM, José Ignacio  wrote:

> The separate program issue is just an implementation detail. The main
> thing that Kicad is headed for is the refactoring slated for the 6.0 dev
> cycle. The cleaner data structure foundation and subsequent decoupling of
> the logic from the UI classes will allow all sorts of automation that are
> currently very hard or impossible. The vision that was set since over 5
> years ago was for Kicad to present a library-like interface to the outside
> world. It kind of does now on PCBnew only, but things are slowly improving
> as things get refactored and legacy code gets phased out.
>
> I honestly think the last thing Kicad needs right now is a chance of
> direction, I speak as a user that has been using Kicad professionally for
> just over 2 years now, working on dozens of PCB projects over that time.
> The developments in the past few years have been nothing but awesome for a
> project with Kicad's resources. We just need to be patient, or try to help
> out in a constructive manner.
>
> Over the past couple years I have been using the dev version in production
> to take advantage of the new features (dealing with versions/instability
> was a small price to pay for me), I also helped a little bit (as time
> allowed) with the occasional patch or grumpy bug report. I'd like to thank
> everyone that has worked on the project so far; It basically has made it
> possible for me to make a living doing what I enjoy, and I really hope the
> project can retain the momentum it has built up in the past few months, it
> just keeps getting better!
>
> Thanks,
> Jose
>
>
>

Nothing that I am asking for is a change of direction. Instead of calling
a function that operates on data in memory you call a program that operates
on the same data in the file system.
You see the same menu pick either way. This will fit in with the
refactoring.

If you are doing a PCB with a FPGA on it then you really want that FPGA
designer to be using kicad to design their padring. Kicad could fill this
niche and it would make your job a lot
easier.

John Eaton
___
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] Proposed roadmap changes

[José Ignacio]

The separate program issue is just an implementation detail. The main thing
that Kicad is headed for is the refactoring slated for the 6.0 dev cycle.
The cleaner data structure foundation and subsequent decoupling of the
logic from the UI classes will allow all sorts of automation that are
currently very hard or impossible. The vision that was set since over 5
years ago was for Kicad to present a library-like interface to the outside
world. It kind of does now on PCBnew only, but things are slowly improving
as things get refactored and legacy code gets phased out.

I honestly think the last thing Kicad needs right now is a chance of
direction, I speak as a user that has been using Kicad professionally for
just over 2 years now, working on dozens of PCB projects over that time.
The developments in the past few years have been nothing but awesome for a
project with Kicad's resources. We just need to be patient, or try to help
out in a constructive manner.

Over the past couple years I have been using the dev version in production
to take advantage of the new features (dealing with versions/instability
was a small price to pay for me), I also helped a little bit (as time
allowed) with the occasional patch or grumpy bug report. I'd like to thank
everyone that has worked on the project so far; It basically has made it
possible for me to make a living doing what I enjoy, and I really hope the
project can retain the momentum it has built up in the past few months, it
just keeps getting better!

Thanks,
Jose

On Wed, Mar 7, 2018 at 8:21 PM, Ouabache Designworks 
wrote:

>
>
> On Wed, Mar 7, 2018 at 3:08 PM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>>
>> Which features you think should go to separate programs?
>>
>
> Export netlist for one. It is a simple addition as long as your design
> fits completely
> on the sheet that you are editing but what happens if you have a
> multisheet design?
> Now you have to locate and read  all those other sheets from files.  What
> used to
> be a graphics editor now has to deal with a lot of other problems that
> have nothing
> to do with placing and displaying graphics.
>
> What happens if you edit a schematic, export the netlist and are
> interrupted before
> you can save the schematic?  That might only happen one time out of a
> thousand
> but you now have a corrupt database where the schematic file doesn't match
> the
> netlist. Kicad is getting enough users to make that a real problem. We
> need to
> go through and prevent that from every occurring in the first place. You
> can
> do that by placing the netlister in a separate program that only operates
> on
> the outputed files.
>
> DRC has the same problem in that it depends on data that has to be located
> and
> read in from other files.
>
>
>>
>> Bear in mind that most PCB designers don't like the 'unix-style'
>> workflow, if by that you mean writing makefiles, shell scripts or other
>> programming just to stitch different 'independent programs that do their
>> particular jobs well' together.
>
>
> The user doesn't do the stitching. The tool smith does. EEschema will call
> a
> netlist or DRC program to operate on the schematic files rather than on the
> design image in memory.
>
>
> >
>> > Create a Pad Mux tool that lets you codesign the IC package and pinout
>> > as part of the IC design team. That is the ultimate in pin swapping
>> > capability.
>> >
>> Kicad is a PCB design tool. We don't aim to become an IC design tool.
>>
>> Tom
>>
>
> I used to be a PCB design engineer until I switched over to design IC's.
> My tools
> did not change, all I did was change libraries. It was great. My
> deliverable to the
> board designer was the symbol that they used for my chip. It was easy to
> work
> together have them try out different pinouts before we had to release.
>
> That was back in the 90's. 10 years later our tools had diverged enough
> that on my
> latest chips the tool that we used to collaborate between the IC and PCB
> teams was
> a spreadsheet. The system architects that used to use schematic capture to
> create
> their block diagrams had switched over to using microsoft visio. We can do
> a lot  better.
>
> EEschema would make a great engineering tool for a lot of engineers if it
> only had two
> additional features. The first is true hierarchy and the second is
> heterogeneous buses.
> I understand that Jon Evans has the bussing working and we could deal with
> the hierarchy
> by writing out the data and processing it in separate programs.
>
>
> John Eaton
>
>
>
>
>
>
>
>
>
> ___
> 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
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Proposed roadmap changes

[Ouabache Designworks]

On Wed, Mar 7, 2018 at 3:08 PM, Tomasz Wlostowski  wrote:

>
> Which features you think should go to separate programs?
>

Export netlist for one. It is a simple addition as long as your design fits
completely
on the sheet that you are editing but what happens if you have a multisheet
design?
Now you have to locate and read  all those other sheets from files.  What
used to
be a graphics editor now has to deal with a lot of other problems that have
nothing
to do with placing and displaying graphics.

What happens if you edit a schematic, export the netlist and are
interrupted before
you can save the schematic?  That might only happen one time out of a
thousand
but you now have a corrupt database where the schematic file doesn't match
the
netlist. Kicad is getting enough users to make that a real problem. We need
to
go through and prevent that from every occurring in the first place. You can
do that by placing the netlister in a separate program that only operates
on
the outputed files.

DRC has the same problem in that it depends on data that has to be located
and
read in from other files.


>
> Bear in mind that most PCB designers don't like the 'unix-style'
> workflow, if by that you mean writing makefiles, shell scripts or other
> programming just to stitch different 'independent programs that do their
> particular jobs well' together.


The user doesn't do the stitching. The tool smith does. EEschema will call a
netlist or DRC program to operate on the schematic files rather than on the
design image in memory.


>
> > Create a Pad Mux tool that lets you codesign the IC package and pinout
> > as part of the IC design team. That is the ultimate in pin swapping
> > capability.
> >
> Kicad is a PCB design tool. We don't aim to become an IC design tool.
>
> Tom
>

I used to be a PCB design engineer until I switched over to design IC's. My
tools
did not change, all I did was change libraries. It was great. My
deliverable to the
board designer was the symbol that they used for my chip. It was easy to
work
together have them try out different pinouts before we had to release.

That was back in the 90's. 10 years later our tools had diverged enough
that on my
latest chips the tool that we used to collaborate between the IC and PCB
teams was
a spreadsheet. The system architects that used to use schematic capture to
create
their block diagrams had switched over to using microsoft visio. We can do
a lot  better.

EEschema would make a great engineering tool for a lot of engineers if it
only had two
additional features. The first is true hierarchy and the second is
heterogeneous buses.
I understand that Jon Evans has the bussing working and we could deal with
the hierarchy
by writing out the data and processing it in separate programs.


John Eaton
___
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] Proposed roadmap changes

[Wayne Stambaugh]

Chris,

I saw your previous message, I've just been busy getting v5 stuff ready.

On 3/7/2018 4:23 PM, Chris Gammell wrote:
> Hi Everyone,
> 
> /(tried sending this once but saw on the archive that it didn't go through)/
> 
> I'm pretty quiet on this list since I have zero ability to talk about
> the actual development. The future roadmap stuff seems relevant though.
> After chatting with the team at FOSDEM and Javier mentioning the idea of
> targeting KiCad towards small and medium businesses, I've been gathering
> up a group of people who are regularly using KiCad to design and
> manufacture boards (currently 40+ on the list)

Are these users professional users who are using KiCad at there day job
and is there any way to confirm this?

> 
> I am currently surveying that group and will be returning with some
> recommendations. I'm also asking if they would be interested in telling
> their stories to the development team when asked as part of the survey.

Thank you for gathering this information rather than having 40 users
bombarding the developers mailing list.  I appreciate the effort in
putting this information together.  I'm willing to listen to user
experience once v5 is out.  I am swamped at the moment and I don't want
users feel that they don't have my full attention.

Cheers,

Wayne

> 
> If there are others on the list that are doing manufacturing, please
> feel free to join here: http://kicad.info/manufacturing/ (it should
> prompt you with the survey upon joining the list)
> 
> ~Chris Gammell
> 
> (I run the KiCad.info forum , which you're
> also invited to join if you're not already on there! Devs get special
> badges! :-D)
> 
> 
> On Wed, Mar 7, 2018 at 12:49 PM Andy Peters  > wrote:
> 
> 
> On Mar 7, 2018, at 11:46 AM, Seth Hillbrand
> > wrote:
> >
> > You should take a look at Mitja Nemec's action plugin here:
> https://github.com/MitjaNemec/Kicad_action_plugins
> >
> > I think the replicate layout covers a lot of the functionality you
> are looking for.
> 
> Wow, yeah, I will try that!
> 
> > -S
> >
> > 2018-03-07 10:25 GMT-08:00 Andrey Kuznetsov  >:
> > Not sure how you would turn this into an effortless feature, but a
> few months ago I’ve designed just that, replicated channels using
> the same subsheet, on layout I did it once, then copy pasted and
> manually renamed each component based on each channel number component.
> >
> > On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  > wrote:
> >
> > > On Mar 5, 2018, at 10:57 AM, Jon Evans  > wrote:
> > >
> > > Hi all,
> > >
> > > Since my day job involves a lot of engineering
> planning/timelines/etc, I've had this rolling around in my head...
> > > I started brainstorming some proposed changes to the roadmaps.
> > >
> > > I am using Google drive because that's what is easiest for me to
> play with; I'm happy to send patches against the official roadmaps
> if get some buy-in for this.
> > >
> > > Feel free to comment (either directly on the doc or by email)
> with thoughts on this.
> > >
> > >
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> > >
> > > Basically what I am proposing is to put most of the energy into
> Eeschema for 6.0, with changes to other parts of the software
> basically being "whatever people have time left over for". 
> Everything else has been bumped to 7.0
> >
> > I’ll add one more to the list, clearly it’s a v7 wish … layout
> “rooms,” like the Altium feature. Consider a multi-channel design
> where you have to replicate a layout several times. It would be nice
> to define the channel in, say, a hierarchical subsheet, and the
> layout knows that it should replicate the work you do for one
> channel across the others.
> >
> > I realize that this is a completely non-trivial thing to
> implement, and further I recall some discussion about this but
> nobody had any real good ideas about how to do it.
> >
> > -a
> >
> 
> 
> ___
> 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
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : 

Re: [Kicad-developers] Proposed roadmap changes

[Tomasz Wlostowski]

On 07/03/18 23:04, Ouabache Designworks wrote:
> 
> 
> On Mon, Mar 5, 2018 at 9:57 AM, Jon Evans  > wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering
> planning/timelines/etc, I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to
> play with; I'm happy to send patches against the official roadmaps
> if get some buy-in for this.
> 
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> 
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> 
> 
> 
> Basically what I am proposing is to put most of the energy into
> Eeschema for 6.0, with changes to other parts of the software
> basically being "whatever people have time left over for". 
> Everything else has been bumped to 7.0
> 
> -Jon
> 
> 
> 
> 
> 
> My wishlist:
> 
> Follow the unix philosophy. All programs must do one thing and do it
> well. You solve complex problems by chaining simple tools together. If
> you don't then your tool becomes bloated and hard to use and maintain.
> EEschema is heading down this path and we need to strip it down to
> EEschema Lite and put the ancillary features in their own programs.
> 
> 
Dear John,

Which features you think should go to separate programs?

Bear in mind that most PCB designers don't like the 'unix-style'
workflow, if by that you mean writing makefiles, shell scripts or other
programming just to stitch different 'independent programs that do their
particular jobs well' together. Furthermore, it doesn't only apply to
PCB or schematics design, but to any graphical application. Show me one
example of a truly successful graphical editing program (be that CAD,
bitmap editor or a vector graphics editor) that is not 'bloated' or
conforms fully to the 'unix philosophy'. By successful I mean used by a
major number of professionals.


> Design for BIG data. The rules don't change for big data but they are
> more rigorously enforced. PCB's are usually small enough that you can
> ignore the rules and still succeed but you will never be able to handle
> to large workloads that IC and system designers handle on a daily basis.
> Why should you  care? Because you receive deliverables from both of
> those groups and if you could offer them a decent open source schematic
> editor then they will make their deliverables in kicad formated files.
> 
> Your libraries are getting into the realm of big data. Most of the
> complaints about libraries on the forum stem from trying to solve big
> data problems with small data solutions. Ask yourselves if this would
> work for the Library of Congress and if it won't then don't try it.
> 
This is worth considering. Thanks.
> 
> Create a Pad Mux tool that lets you codesign the IC package and pinout
> as part of the IC design team. That is the ultimate in pin swapping
> capability.
> 
Kicad is a PCB design tool. We don't aim to become an IC design tool.

Tom

___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 7, 2018, at 3:04 PM, Ouabache Designworks  wrote:
> 
> 
> 
> On Mon, Mar 5, 2018 at 9:57 AM, Jon Evans  > wrote:
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>  
> 
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0
> 
> -Jon
> 
> 
> 
> 
> My wishlist:
> 
> Follow the unix philosophy. All programs must do one thing and do it well. 
> You solve complex problems by chaining simple tools together. If you don't 
> then your tool becomes bloated and hard to use and maintain. EEschema is 
> heading down this path and we need to strip it down to EEschema Lite and put 
> the ancillary features in their own programs.

What features of EESchema are “core” and what are “ancillary?”

-a___
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] Proposed roadmap changes

[Ouabache Designworks]

On Mon, Mar 5, 2018 at 9:57 AM, Jon Evans  wrote:

> Hi all,
>
> Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
>
> I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
>
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
>
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
>
> Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been bumped
> to 7.0
>
> -Jon
>




My wishlist:

Follow the unix philosophy. All programs must do one thing and do it well.
You solve complex problems by chaining simple tools together. If you don't
then your tool becomes bloated and hard to use and maintain. EEschema is
heading down this path and we need to strip it down to EEschema Lite and
put the ancillary features in their own programs.


Design for BIG data. The rules don't change for big data but they are more
rigorously enforced. PCB's are usually small enough that you can ignore the
rules and still succeed but you will never be able to handle to large
workloads that IC and system designers handle on a daily basis. Why should
you  care? Because you receive deliverables from both of those groups and
if you could offer them a decent open source schematic editor then they
will make their deliverables in kicad formated files.

Your libraries are getting into the realm of big data. Most of the
complaints about libraries on the forum stem from trying to solve big data
problems with small data solutions. Ask yourselves if this would work for
the Library of Congress and if it won't then don't try it.


Create a Pad Mux tool that lets you codesign the IC package and pinout as
part of the IC design team. That is the ultimate in pin swapping capability.




John Eaton
___
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] Proposed roadmap changes

[Chris Gammell]

Hi Everyone,

*(tried sending this once but saw on the archive that it didn't go through)*

I'm pretty quiet on this list since I have zero ability to talk about the
actual development. The future roadmap stuff seems relevant though. After
chatting with the team at FOSDEM and Javier mentioning the idea of
targeting KiCad towards small and medium businesses, I've been gathering up
a group of people who are regularly using KiCad to design and manufacture
boards (currently 40+ on the list)

I am currently surveying that group and will be returning with some
recommendations. I'm also asking if they would be interested in telling
their stories to the development team when asked as part of the survey.

If there are others on the list that are doing manufacturing, please feel
free to join here: http://kicad.info/manufacturing/ (it should prompt you
with the survey upon joining the list)

~Chris Gammell

(I run the KiCad.info forum , which you're also
invited to join if you're not already on there! Devs get special badges!
:-D)


On Wed, Mar 7, 2018 at 12:49 PM Andy Peters  wrote:

>
> On Mar 7, 2018, at 11:46 AM, Seth Hillbrand 
> wrote:
> >
> > You should take a look at Mitja Nemec's action plugin here:
> https://github.com/MitjaNemec/Kicad_action_plugins
> >
> > I think the replicate layout covers a lot of the functionality you are
> looking for.
>
> Wow, yeah, I will try that!
>
> > -S
> >
> > 2018-03-07 10:25 GMT-08:00 Andrey Kuznetsov :
> > Not sure how you would turn this into an effortless feature, but a few
> months ago I’ve designed just that, replicated channels using the same
> subsheet, on layout I did it once, then copy pasted and manually renamed
> each component based on each channel number component.
> >
> > On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  wrote:
> >
> > > On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> > >
> > > Hi all,
> > >
> > > Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> > > I started brainstorming some proposed changes to the roadmaps.
> > >
> > > I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
> > >
> > > Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> > >
> > >
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> > >
> > > Basically what I am proposing is to put most of the energy into
> Eeschema for 6.0, with changes to other parts of the software basically
> being "whatever people have time left over for".  Everything else has been
> bumped to 7.0
> >
> > I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,”
> like the Altium feature. Consider a multi-channel design where you have to
> replicate a layout several times. It would be nice to define the channel
> in, say, a hierarchical subsheet, and the layout knows that it should
> replicate the work you do for one channel across the others.
> >
> > I realize that this is a completely non-trivial thing to implement, and
> further I recall some discussion about this but nobody had any real good
> ideas about how to do it.
> >
> > -a
> >
>
>
> ___
> 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
>
___
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] Proposed roadmap changes

[Andy Peters]

On Mar 7, 2018, at 11:46 AM, Seth Hillbrand  wrote:
> 
> You should take a look at Mitja Nemec's action plugin here: 
> https://github.com/MitjaNemec/Kicad_action_plugins
> 
> I think the replicate layout covers a lot of the functionality you are 
> looking for.

Wow, yeah, I will try that! 

> -S
> 
> 2018-03-07 10:25 GMT-08:00 Andrey Kuznetsov :
> Not sure how you would turn this into an effortless feature, but a few months 
> ago I’ve designed just that, replicated channels using the same subsheet, on 
> layout I did it once, then copy pasted and manually renamed each component 
> based on each channel number component.
> 
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  wrote:
> 
> > On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc, I've 
> > had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play with; 
> > I'm happy to send patches against the official roadmaps if get some buy-in 
> > for this.
> >
> > Feel free to comment (either directly on the doc or by email) with thoughts 
> > on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema 
> > for 6.0, with changes to other parts of the software basically being 
> > "whatever people have time left over for".  Everything else has been bumped 
> > to 7.0
> 
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
> the Altium feature. Consider a multi-channel design where you have to 
> replicate a layout several times. It would be nice to define the channel in, 
> say, a hierarchical subsheet, and the layout knows that it should replicate 
> the work you do for one channel across the others.
> 
> I realize that this is a completely non-trivial thing to implement, and 
> further I recall some discussion about this but nobody had any real good 
> ideas about how to do it.
> 
> -a
> 


___
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] Proposed roadmap changes

[Seth Hillbrand]

You should take a look at Mitja Nemec's action plugin here:
https://github.com/MitjaNemec/Kicad_action_plugins

I think the replicate layout covers a lot of the functionality you are
looking for.

-S

2018-03-07 10:25 GMT-08:00 Andrey Kuznetsov :

> Not sure how you would turn this into an effortless feature, but a few
> months ago I’ve designed just that, replicated channels using the same
> subsheet, on layout I did it once, then copy pasted and manually renamed
> each component based on each channel number component.
>
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  wrote:
>
>>
>> > On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
>> >
>> > Hi all,
>> >
>> > Since my day job involves a lot of engineering planning/timelines/etc,
>> I've had this rolling around in my head...
>> > I started brainstorming some proposed changes to the roadmaps.
>> >
>> > I am using Google drive because that's what is easiest for me to play
>> with; I'm happy to send patches against the official roadmaps if get some
>> buy-in for this.
>> >
>> > Feel free to comment (either directly on the doc or by email) with
>> thoughts on this.
>> >
>> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
>> 7ooTtcT_HU86kw/edit#
>> >
>> > Basically what I am proposing is to put most of the energy into
>> Eeschema for 6.0, with changes to other parts of the software basically
>> being "whatever people have time left over for".  Everything else has been
>> bumped to 7.0
>>
>> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,”
>> like the Altium feature. Consider a multi-channel design where you have to
>> replicate a layout several times. It would be nice to define the channel
>> in, say, a hierarchical subsheet, and the layout knows that it should
>> replicate the work you do for one channel across the others.
>>
>> I realize that this is a completely non-trivial thing to implement, and
>> further I recall some discussion about this but nobody had any real good
>> ideas about how to do it.
>>
>> -a
>>
>>
>>
>> ___
>> 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
>>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> ___
> 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
>
>
___
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] Proposed roadmap changes

[Wayne Stambaugh]

There has already been discussion on this some time ago.  I would not us
the Altium room moniker.  The last time we discussed this, the term
"group" was used so that you can associate items in the schematic with
items on the board by a group name rather than limit this two individual
sheets.

On 3/7/2018 1:25 PM, Andrey Kuznetsov wrote:
> Not sure how you would turn this into an effortless feature, but a few
> months ago I’ve designed just that, replicated channels using the same
> subsheet, on layout I did it once, then copy pasted and manually renamed
> each component based on each channel number component.
> 
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  > wrote:
> 
> 
> > On Mar 5, 2018, at 10:57 AM, Jon Evans  > wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering
> planning/timelines/etc, I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to
> play with; I'm happy to send patches against the official roadmaps
> if get some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> >
> >
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into
> Eeschema for 6.0, with changes to other parts of the software
> basically being "whatever people have time left over for". 
> Everything else has been bumped to 7.0
> 
> I’ll add one more to the list, clearly it’s a v7 wish … layout
> “rooms,” like the Altium feature. Consider a multi-channel design
> where you have to replicate a layout several times. It would be nice
> to define the channel in, say, a hierarchical subsheet, and the
> layout knows that it should replicate the work you do for one
> channel across the others.
> 
> I realize that this is a completely non-trivial thing to implement,
> and further I recall some discussion about this but nobody had any
> real good ideas about how to do it.
> 
> -a
> 
> 
> 
> ___
> 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
> 
> -- 
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
> 
> kandre...@gmail.com 
> Live Long and Prosper,
> Andrey
> 
> 
> ___
> 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
> 

___
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] Proposed roadmap changes

[Andy Peters]

On Mar 7, 2018, at 11:25 AM, Andrey Kuznetsov  wrote:
> 
> Not sure how you would turn this into an effortless feature, but a few months 
> ago I’ve designed just that, replicated channels using the same subsheet, on 
> layout I did it once, then copy pasted and manually renamed each component 
> based on each channel number component.

I will argue against manual intervention and manual renaming of anything. The 
possibility of error goes _way_ up. Who wants to rename all of the parts on 16 
channels of analog preamp/ADC driver/ADC? 

-a



> 
> On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  > wrote:
> 
> > On Mar 5, 2018, at 10:57 AM, Jon Evans  > > wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc, I've 
> > had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play with; 
> > I'm happy to send patches against the official roadmaps if get some buy-in 
> > for this.
> >
> > Feel free to comment (either directly on the doc or by email) with thoughts 
> > on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >  
> > 
> >
> > Basically what I am proposing is to put most of the energy into Eeschema 
> > for 6.0, with changes to other parts of the software basically being 
> > "whatever people have time left over for".  Everything else has been bumped 
> > to 7.0
> 
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
> the Altium feature. Consider a multi-channel design where you have to 
> replicate a layout several times. It would be nice to define the channel in, 
> say, a hierarchical subsheet, and the layout knows that it should replicate 
> the work you do for one channel across the others.
> 
> I realize that this is a completely non-trivial thing to implement, and 
> further I recall some discussion about this but nobody had any real good 
> ideas about how to do it.
> 
> -a
___
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] Proposed roadmap changes

[Andrey Kuznetsov]

Not sure how you would turn this into an effortless feature, but a few
months ago I’ve designed just that, replicated channels using the same
subsheet, on layout I did it once, then copy pasted and manually renamed
each component based on each channel number component.

On Wed, Mar 7, 2018 at 8:42 AM Andy Peters  wrote:

>
> > On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> >
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> >
> >
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been bumped
> to 7.0
>
> I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,”
> like the Altium feature. Consider a multi-channel design where you have to
> replicate a layout several times. It would be nice to define the channel
> in, say, a hierarchical subsheet, and the layout knows that it should
> replicate the work you do for one channel across the others.
>
> I realize that this is a completely non-trivial thing to implement, and
> further I recall some discussion about this but nobody had any real good
> ideas about how to do it.
>
> -a
>
>
>
> ___
> 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
>
-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0

I’ll add one more to the list, clearly it’s a v7 wish … layout “rooms,” like 
the Altium feature. Consider a multi-channel design where you have to replicate 
a layout several times. It would be nice to define the channel in, say, a 
hierarchical subsheet, and the layout knows that it should replicate the work 
you do for one channel across the others.

I realize that this is a completely non-trivial thing to implement, and further 
I recall some discussion about this but nobody had any real good ideas about 
how to do it.

-a



___
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] Proposed roadmap changes

[Jon Evans]

I think copy/paste is a good feature to have, it's not just you!

Re. roadmap, I have now gone through my document and assigned priorities
based on my guess, and owners (i.e. primary developers) also based on my
guess.
Developers who are going to work on things for V6, please comment or email
me letting me know if you were already planning to take point on some of
these roadmap items, and/or if you'd be willing to help with others.

The priority system I'm using (open to modification):

P0 - Must Ship:  These features define what 6.0 is at a minimum
P1 - Important: We should really aim to get these features into 6.0 (i.e.
maybe delay the release to get them in, on a case-by-case basis), but it
wouldn't be a disaster to ship 6.0 without them
P2 - Nice to Have: These can go into 6.0 if they are done in time, but they
shouldn't delay 6.0 release

Feel free to chime in if you think I've misjudged the priority of anything.
Keep in mind, my point is not to keep anyone from working on anything by
saying it's a lower priority, but rather to try to clarify what the
"minimum" set of things we should have for 6.0 is, so that we can focus
attention on them.

-Jon

On Wed, Mar 7, 2018 at 3:39 AM, Fabrizio Tappero  wrote:

> Hello,
> as Andy mentioned, I consider quite important to have schematic components
> embedded into schematic file. This will allow people to share small
> schematic sheets and schematic snippets without painful  lib cache file. In
> Eagle and in Altium the "make library from schematic" capability is/was a
> great feature.
>
> In my opinion, the limitation of not being able to copy and paste
> schematic portions (outside a kicad project) is a big limitation for
> anybody who makes/reuse/share a lot of schematics.
>
> Am I the only one suffering from the inability to reuse schematics?
>
> my 2c
> Fabrizio
>
>
> On Tue, Mar 6, 2018 at 9:03 PM, Jon Evans  wrote:
>
>> I will be sure to send a proposed update to the official doc after there
>> is no more churn on my scratch pad doc.
>> I am not allowing anyone to edit, only I can edit (anyone can comment,
>> and I have been incorporating changes based on people's comments)
>>
>> I think the next pass (now that it has been a day with no one making any
>> more comments on my doc) is to think about who is going to do what to make
>> sure the manpower thing makes sense.
>>
>> -Jon
>>
>> On Tue, Mar 6, 2018 at 2:33 PM, Wayne Stambaugh 
>> wrote:
>>
>>> I'm fine with using this for bike shedding as long as the results get
>>> updated in the actual road map and this is not the official road map.
>>> One caveat, by allowing anyone to edit this file, you may loose control
>>> of it's content.  That's one of the things I don't like about launchpads
>>> blueprints.  I also don't want this to turn into a popularity contest.
>>> We have to make sensible decisions based upon project requirements and
>>> manpower limitations so all final decisions are made by the lead
>>> development team.
>>>
>>> On 3/5/2018 12:57 PM, Jon Evans wrote:
>>> > Hi all,
>>> >
>>> > Since my day job involves a lot of engineering planning/timelines/etc,
>>> > I've had this rolling around in my head...
>>> > I started brainstorming some proposed changes to the roadmaps.
>>> >
>>> > I am using Google drive because that's what is easiest for me to play
>>> > with; I'm happy to send patches against the official roadmaps if get
>>> > some buy-in for this.
>>> >
>>> > Feel free to comment (either directly on the doc or by email) with
>>> > thoughts on this.
>>> >
>>> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhyS
>>> SpFxF7ooTtcT_HU86kw/edit#
>>> >
>>> > Basically what I am proposing is to put most of the energy into
>>> Eeschema
>>> > for 6.0, with changes to other parts of the software basically being
>>> > "whatever people have time left over for".  Everything else has been
>>> > bumped to 7.0
>>> >
>>> > -Jon
>>> >
>>> >
>>> > ___
>>> > 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
>>> >
>>>
>>> ___
>>> 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
>>>
>>
>>
>> ___
>> 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
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Proposed roadmap changes

[Fabrizio Tappero]

Hello,
as Andy mentioned, I consider quite important to have schematic components
embedded into schematic file. This will allow people to share small
schematic sheets and schematic snippets without painful  lib cache file. In
Eagle and in Altium the "make library from schematic" capability is/was a
great feature.

In my opinion, the limitation of not being able to copy and paste schematic
portions (outside a kicad project) is a big limitation for anybody who
makes/reuse/share a lot of schematics.

Am I the only one suffering from the inability to reuse schematics?

my 2c
Fabrizio


On Tue, Mar 6, 2018 at 9:03 PM, Jon Evans  wrote:

> I will be sure to send a proposed update to the official doc after there
> is no more churn on my scratch pad doc.
> I am not allowing anyone to edit, only I can edit (anyone can comment, and
> I have been incorporating changes based on people's comments)
>
> I think the next pass (now that it has been a day with no one making any
> more comments on my doc) is to think about who is going to do what to make
> sure the manpower thing makes sense.
>
> -Jon
>
> On Tue, Mar 6, 2018 at 2:33 PM, Wayne Stambaugh 
> wrote:
>
>> I'm fine with using this for bike shedding as long as the results get
>> updated in the actual road map and this is not the official road map.
>> One caveat, by allowing anyone to edit this file, you may loose control
>> of it's content.  That's one of the things I don't like about launchpads
>> blueprints.  I also don't want this to turn into a popularity contest.
>> We have to make sensible decisions based upon project requirements and
>> manpower limitations so all final decisions are made by the lead
>> development team.
>>
>> On 3/5/2018 12:57 PM, Jon Evans wrote:
>> > Hi all,
>> >
>> > Since my day job involves a lot of engineering planning/timelines/etc,
>> > I've had this rolling around in my head...
>> > I started brainstorming some proposed changes to the roadmaps.
>> >
>> > I am using Google drive because that's what is easiest for me to play
>> > with; I'm happy to send patches against the official roadmaps if get
>> > some buy-in for this.
>> >
>> > Feel free to comment (either directly on the doc or by email) with
>> > thoughts on this.
>> >
>> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhyS
>> SpFxF7ooTtcT_HU86kw/edit#
>> >
>> > Basically what I am proposing is to put most of the energy into Eeschema
>> > for 6.0, with changes to other parts of the software basically being
>> > "whatever people have time left over for".  Everything else has been
>> > bumped to 7.0
>> >
>> > -Jon
>> >
>> >
>> > ___
>> > 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
>> >
>>
>> ___
>> 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
>>
>
>
> ___
> 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
>
>
___
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] Proposed roadmap changes

[Jon Evans]

I will be sure to send a proposed update to the official doc after there is
no more churn on my scratch pad doc.
I am not allowing anyone to edit, only I can edit (anyone can comment, and
I have been incorporating changes based on people's comments)

I think the next pass (now that it has been a day with no one making any
more comments on my doc) is to think about who is going to do what to make
sure the manpower thing makes sense.

-Jon

On Tue, Mar 6, 2018 at 2:33 PM, Wayne Stambaugh 
wrote:

> I'm fine with using this for bike shedding as long as the results get
> updated in the actual road map and this is not the official road map.
> One caveat, by allowing anyone to edit this file, you may loose control
> of it's content.  That's one of the things I don't like about launchpads
> blueprints.  I also don't want this to turn into a popularity contest.
> We have to make sensible decisions based upon project requirements and
> manpower limitations so all final decisions are made by the lead
> development team.
>
> On 3/5/2018 12:57 PM, Jon Evans wrote:
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> > I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> > with; I'm happy to send patches against the official roadmaps if get
> > some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> > thoughts on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> > for 6.0, with changes to other parts of the software basically being
> > "whatever people have time left over for".  Everything else has been
> > bumped to 7.0
> >
> > -Jon
> >
> >
> > ___
> > 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
> >
>
> ___
> 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
>
___
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] Proposed roadmap changes

[José Ignacio]

Only jon can edit, our "edits" are just suggestions, which can be accepted
or rejected.

On Tue, Mar 6, 2018 at 1:33 PM, Wayne Stambaugh 
wrote:

> I'm fine with using this for bike shedding as long as the results get
> updated in the actual road map and this is not the official road map.
> One caveat, by allowing anyone to edit this file, you may loose control
> of it's content.  That's one of the things I don't like about launchpads
> blueprints.  I also don't want this to turn into a popularity contest.
> We have to make sensible decisions based upon project requirements and
> manpower limitations so all final decisions are made by the lead
> development team.
>
> On 3/5/2018 12:57 PM, Jon Evans wrote:
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> > I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> > with; I'm happy to send patches against the official roadmaps if get
> > some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> > thoughts on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> > for 6.0, with changes to other parts of the software basically being
> > "whatever people have time left over for".  Everything else has been
> > bumped to 7.0
> >
> > -Jon
> >
> >
> > ___
> > 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
> >
>
> ___
> 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
>
___
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] Proposed roadmap changes

[Wayne Stambaugh]

I'm fine with using this for bike shedding as long as the results get
updated in the actual road map and this is not the official road map.
One caveat, by allowing anyone to edit this file, you may loose control
of it's content.  That's one of the things I don't like about launchpads
blueprints.  I also don't want this to turn into a popularity contest.
We have to make sensible decisions based upon project requirements and
manpower limitations so all final decisions are made by the lead
development team.

On 3/5/2018 12:57 PM, Jon Evans wrote:
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get
> some buy-in for this.
> 
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> 
> Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been
> bumped to 7.0
> 
> -Jon
> 
> 
> ___
> 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
> 

___
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] Proposed roadmap changes

[Wayne Stambaugh]

On 3/5/2018 1:15 PM, Jon Evans wrote:
> I believe embedded symbols is part of the file format / library format
> change heading.

It is part of the new schematic file format.

> 
> Back-annotation support in general is under the heading of "Pin and Part
> Swapping" in the roadmap, and it's a good idea to include re-annotating
> components as part of that.

That would be part of the back annotation process.

> 
> On Mon, Mar 5, 2018 at 1:11 PM, Andy Peters  > wrote:
> 
> 
> 
>> On Mar 5, 2018, at 10:57 AM, Jon Evans > > wrote:
>>
>> Hi all,
>>
>> Since my day job involves a lot of engineering
>> planning/timelines/etc, I've had this rolling around in my head...
>> I started brainstorming some proposed changes to the roadmaps.
>>
>> I am using Google drive because that's what is easiest for me to
>> play with; I'm happy to send patches against the official roadmaps
>> if get some buy-in for this.
>>
>> Feel free to comment (either directly on the doc or by email) with
>> thoughts on this.
>>
>> 
>> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>> 
>> 
>>
>> Basically what I am proposing is to put most of the energy into
>> Eeschema for 6.0, with changes to other parts of the software
>> basically being "whatever people have time left over for". 
>> Everything else has been bumped to 7.0
> 
> I’m not sure where it fits into the roadmap, but the main EESchema
> feature I’d like to see implemented is the embedding of schematic
> symbols into the schematic sheet, in the same way that footprints
> are part of the kicad_pcb file.
> 
> Also the whole idea of renumbering the reference designators in a
> layout to be geographical, and then backannotating the designators
> to the schematic. (A guy can dream ..)
> -a
> 
> 
> ___
> 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
> 
> 
> 
> 
> 
> ___
> 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
> 

___
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] Proposed roadmap changes

[Jon Evans]

I believe embedded symbols is part of the file format / library format
change heading.

Back-annotation support in general is under the heading of "Pin and Part
Swapping" in the roadmap, and it's a good idea to include re-annotating
components as part of that.

On Mon, Mar 5, 2018 at 1:11 PM, Andy Peters  wrote:

>
>
> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
>
> Hi all,
>
> Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
>
> I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get some
> buy-in for this.
>
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
>
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
>
> Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been bumped
> to 7.0
>
>
> I’m not sure where it fits into the roadmap, but the main EESchema feature
> I’d like to see implemented is the embedding of schematic symbols into the
> schematic sheet, in the same way that footprints are part of the kicad_pcb
> file.
>
> Also the whole idea of renumbering the reference designators in a layout
> to be geographical, and then backannotating the designators to the
> schematic. (A guy can dream ..)
> -a
>
>
> ___
> 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
>
>
___
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] Proposed roadmap changes

[Andy Peters]

> On Mar 5, 2018, at 10:57 AM, Jon Evans  wrote:
> 
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc, I've 
> had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play with; 
> I'm happy to send patches against the official roadmaps if get some buy-in 
> for this.
> 
> Feel free to comment (either directly on the doc or by email) with thoughts 
> on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
>  
> 
> 
> Basically what I am proposing is to put most of the energy into Eeschema for 
> 6.0, with changes to other parts of the software basically being "whatever 
> people have time left over for".  Everything else has been bumped to 7.0

I’m not sure where it fits into the roadmap, but the main EESchema feature I’d 
like to see implemented is the embedding of schematic symbols into the 
schematic sheet, in the same way that footprints are part of the kicad_pcb file.

Also the whole idea of renumbering the reference designators in a layout to be 
geographical, and then backannotating the designators to the schematic. (A guy 
can dream ..)
-a

___
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] Proposed roadmap changes

[Jon Evans]

Hi all,

Since my day job involves a lot of engineering planning/timelines/etc, I've
had this rolling around in my head...
I started brainstorming some proposed changes to the roadmaps.

I am using Google drive because that's what is easiest for me to play with;
I'm happy to send patches against the official roadmaps if get some buy-in
for this.

Feel free to comment (either directly on the doc or by email) with thoughts
on this.

https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#

Basically what I am proposing is to put most of the energy into Eeschema
for 6.0, with changes to other parts of the software basically being
"whatever people have time left over for".  Everything else has been bumped
to 7.0

-Jon
___
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