Re: [Kicad-developers] Stable 5 branch status

[Wayne Stambaugh]

This is fine but we still have some work to do before we branch and tag
rc1.  I think we might (fingers crossed) be able to pull that off by
FOSDEM but it will be close.  I still have to get my presentation done
for FOSDEM.

On 01/07/2018 04:37 PM, Nick Østergaard wrote:
> I am just talking about tagging, not doing any realease announcement.
> Getting an early tag will make it easer for packagers to prepare.
> 
> 2018-01-07 22:17 GMT+01:00 Wayne Stambaugh  >:
> 
> Nick,
> 
> I think you possibly misunderstood me or perhaps I didn't explain it
> very well.  I would have liked to have the stable 5 release ready for
> FOSDEM but realistically I would be happy if we were ready to create the
> v5 branch and tag rc1 by FOSDEM.  That's a far more realistic goal.  I
> don't want to rush v5 out.  I still need to fix a few things with the
> remapping and the new symbol library editor has a least one crash bug
> that needs to be fixed before I would be comfortable with branching v5.
> I just don't see any possibility of getting v5 released by FOSDEM even
> if I didn't sleep until then. :)  I want to give everyone at least a
> month to get the libraries, docs, translations, and packages ready from
> the time the source tree is tagged as stable.  If we got the stable 5
> release out by the end of March, I would be pretty happy.
> 
> Cheers,
> 
> Wayne
> 
> On 01/07/2018 04:06 PM, Nick Østergaard wrote:
> > Hello all,
> >
> > I will attempt to summarize the status as I see it.
> >
> > Lots of fixes have been comming in over the last few weeks. But if we
> > are to keep up with Wayne's goal of having a v5 release for FOSDEM, I
> > think we tag 5.0.0-rc1 soon. There is no reason we can still fix stuff
> > untill we make the final 5.0.0 release, and create the 5.0 branch from
> > there. Then we can unfreeze the feature freeze on master, and git
> > describe matster will be relative to this point. I have attached an
> > example and caricature of the previous kicad branching and how I see
> > expect the future too look like.
> >
> > We shall accept that it will probably only be a release candidate for
> > FOSDEM, but that would be great too!
> >
> > If there are some things that simply need to be in 5.0.0 -- I think we
> > need a shoutout now. Looking at
> > https://launchpad.net/kicad/+milestone/5.0.0-rc1
> 
> >  > there are only two
> > outstanding bugs.
> >
> > The library team seem to be ready to tag also,
> > https://github.com/KiCad/kicad-symbols/issues/133
> 
> >  >
> >
> > I guess the doc will not have much time to get much love before the
> > release. But this is mostly about new features not being
> documented and
> > probably some cleanup and modernization. I guess we are more likely to
> > get some feedback on the docs after the first v5 release.
> >
> > The translations will need a bit of touchup on some languages, the
> ones
> > almost done but needs a bit is en, ru, de, and es. These can probably
> > reach 100% before v5 if we are lucky. This sort of requires we have a
> > kicad tag to update against. I think some of those languages also keep
> > unused strings, so even if it is not at 100% it might be complete.
> But I
> > am not sure about this.
> >
> > Regards
> > Nick Østergaard
> >
> >
> >
> > 2018-01-02 21:07 GMT+01:00 Wayne Stambaugh  
> > >>:
> >
> >     I plan on adding the remapping feature to the Eeschema
> documentation
> >     before the stable 5 release.  Hopefully I can find the time to
> knock it
> >     out it the next week or two to give our translators plenty of
> time.
> >
> >     On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> >     > Of course. My confusion mostly surrounds how it interacts
> with rescue
> >     > and when it does and does not decide to write things to disk
> (see
> >     José's
> >     > point about it clobbering its own backups).
> >     >
> >     > In any case, I don't need you to explain it to me. You and I
> >     aren't the
> >     > only KiCad users, and if people who've been using KiCad for
> years and
> >     > have actual dev experience (specifically myself and José
> here) can't
> >     > figure it out, scads of users are going to have the same
> problem. It
> >     > needs to be mad

Re: [Kicad-developers] Stable 5 branch status

[Nick Østergaard]

I am just talking about tagging, not doing any realease announcement.
Getting an early tag will make it easer for packagers to prepare.

2018-01-07 22:17 GMT+01:00 Wayne Stambaugh :

> Nick,
>
> I think you possibly misunderstood me or perhaps I didn't explain it
> very well.  I would have liked to have the stable 5 release ready for
> FOSDEM but realistically I would be happy if we were ready to create the
> v5 branch and tag rc1 by FOSDEM.  That's a far more realistic goal.  I
> don't want to rush v5 out.  I still need to fix a few things with the
> remapping and the new symbol library editor has a least one crash bug
> that needs to be fixed before I would be comfortable with branching v5.
> I just don't see any possibility of getting v5 released by FOSDEM even
> if I didn't sleep until then. :)  I want to give everyone at least a
> month to get the libraries, docs, translations, and packages ready from
> the time the source tree is tagged as stable.  If we got the stable 5
> release out by the end of March, I would be pretty happy.
>
> Cheers,
>
> Wayne
>
> On 01/07/2018 04:06 PM, Nick Østergaard wrote:
> > Hello all,
> >
> > I will attempt to summarize the status as I see it.
> >
> > Lots of fixes have been comming in over the last few weeks. But if we
> > are to keep up with Wayne's goal of having a v5 release for FOSDEM, I
> > think we tag 5.0.0-rc1 soon. There is no reason we can still fix stuff
> > untill we make the final 5.0.0 release, and create the 5.0 branch from
> > there. Then we can unfreeze the feature freeze on master, and git
> > describe matster will be relative to this point. I have attached an
> > example and caricature of the previous kicad branching and how I see
> > expect the future too look like.
> >
> > We shall accept that it will probably only be a release candidate for
> > FOSDEM, but that would be great too!
> >
> > If there are some things that simply need to be in 5.0.0 -- I think we
> > need a shoutout now. Looking at
> > https://launchpad.net/kicad/+milestone/5.0.0-rc1
> >  there are only two
> > outstanding bugs.
> >
> > The library team seem to be ready to tag also,
> > https://github.com/KiCad/kicad-symbols/issues/133
> > 
> >
> > I guess the doc will not have much time to get much love before the
> > release. But this is mostly about new features not being documented and
> > probably some cleanup and modernization. I guess we are more likely to
> > get some feedback on the docs after the first v5 release.
> >
> > The translations will need a bit of touchup on some languages, the ones
> > almost done but needs a bit is en, ru, de, and es. These can probably
> > reach 100% before v5 if we are lucky. This sort of requires we have a
> > kicad tag to update against. I think some of those languages also keep
> > unused strings, so even if it is not at 100% it might be complete. But I
> > am not sure about this.
> >
> > Regards
> > Nick Østergaard
> >
> >
> >
> > 2018-01-02 21:07 GMT+01:00 Wayne Stambaugh  > >:
> >
> > I plan on adding the remapping feature to the Eeschema documentation
> > before the stable 5 release.  Hopefully I can find the time to knock
> it
> > out it the next week or two to give our translators plenty of time.
> >
> > On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> > > Of course. My confusion mostly surrounds how it interacts with
> rescue
> > > and when it does and does not decide to write things to disk (see
> > José's
> > > point about it clobbering its own backups).
> > >
> > > In any case, I don't need you to explain it to me. You and I
> > aren't the
> > > only KiCad users, and if people who've been using KiCad for years
> and
> > > have actual dev experience (specifically myself and José here)
> can't
> > > figure it out, scads of users are going to have the same problem.
> It
> > > needs to be made clearer, not explained on the mailing list.
> > >
> > > On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> > >> Let's start at the beginning.  Are you clear on why symbols need
> > to be
> > >> remapped?
> > >>
> > >> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> > >>> Honestly, with this symbol library stuff it's been hard for me
> > to figure
> > >>> out what's a bug and what's a confusing design decision. Bug
> > reports for
> > >>> the latter are rather frowned upon so I've been refraining from
> > filing
> > >>> many bugs.
> > >>>
> > >>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
> >  I just tested this repo and it failed to remap every symbol so
> > either
> >  something has been broken or this project is a corner case that
> I
> >  haven't stumbled across yet.  I will keep informed of my
> > progress.  In
> >  the futur

Re: [Kicad-developers] Stable 5 branch status

[Nick Østergaard]

Hello all,

I will attempt to summarize the status as I see it.

Lots of fixes have been comming in over the last few weeks. But if we are
to keep up with Wayne's goal of having a v5 release for FOSDEM, I think we
tag 5.0.0-rc1 soon. There is no reason we can still fix stuff untill we
make the final 5.0.0 release, and create the 5.0 branch from there. Then we
can unfreeze the feature freeze on master, and git describe matster will be
relative to this point. I have attached an example and caricature of the
previous kicad branching and how I see expect the future too look like.

We shall accept that it will probably only be a release candidate for
FOSDEM, but that would be great too!

If there are some things that simply need to be in 5.0.0 -- I think we need
a shoutout now. Looking at https://launchpad.net/kicad/+milestone/5.0.0-rc1
there are only two outstanding bugs.

The library team seem to be ready to tag also,
https://github.com/KiCad/kicad-symbols/issues/133

I guess the doc will not have much time to get much love before the
release. But this is mostly about new features not being documented and
probably some cleanup and modernization. I guess we are more likely to get
some feedback on the docs after the first v5 release.

The translations will need a bit of touchup on some languages, the ones
almost done but needs a bit is en, ru, de, and es. These can probably reach
100% before v5 if we are lucky. This sort of requires we have a kicad tag
to update against. I think some of those languages also keep unused
strings, so even if it is not at 100% it might be complete. But I am not
sure about this.

Regards
Nick Østergaard



2018-01-02 21:07 GMT+01:00 Wayne Stambaugh :

> I plan on adding the remapping feature to the Eeschema documentation
> before the stable 5 release.  Hopefully I can find the time to knock it
> out it the next week or two to give our translators plenty of time.
>
> On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> > Of course. My confusion mostly surrounds how it interacts with rescue
> > and when it does and does not decide to write things to disk (see José's
> > point about it clobbering its own backups).
> >
> > In any case, I don't need you to explain it to me. You and I aren't the
> > only KiCad users, and if people who've been using KiCad for years and
> > have actual dev experience (specifically myself and José here) can't
> > figure it out, scads of users are going to have the same problem. It
> > needs to be made clearer, not explained on the mailing list.
> >
> > On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> >> Let's start at the beginning.  Are you clear on why symbols need to be
> >> remapped?
> >>
> >> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> >>> Honestly, with this symbol library stuff it's been hard for me to
> figure
> >>> out what's a bug and what's a confusing design decision. Bug reports
> for
> >>> the latter are rather frowned upon so I've been refraining from filing
> >>> many bugs.
> >>>
> >>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
>  I just tested this repo and it failed to remap every symbol so either
>  something has been broken or this project is a corner case that I
>  haven't stumbled across yet.  I will keep informed of my progress.  In
>  the future, please file bug report when you see something like this.
> If
>  you just discuss it on irc, I have no way of knowing this is an issue
>  unless I manage to free up some time (unlikely any time soon) to spend
>  on irc.
> 
>  On 1/2/2018 2:42 PM, José Ignacio wrote:
> > This sequence of actions is what puts the project on a stuffed up
> state:
> >
> > * Open schematic and be greeted with some symbols that need rescue,
> > rescue a couple symbols
> > * Be greeted by the remap dialog (1)
> > * Regret remapping and quit without save
> > * Open schematic again
> > * Be greeted by the rescue dialog, with ALL symbols, refuse
> > * Remap dialog fails to find anything, click through (2)
> >
> > Schematic looks fine, but the remap and rescue dialogs will show up
> > every time even though there is a valid sym-lib-table.
> >
> > (1) At this point the pro file is overwritten, deleting all project
> > library entries
> > (2) At this point the pro file is overwritten again!, clobbering the
> > backup (SOL)
> >
> > If you accept the second rescue you will have to map everything
> > manually. The remapper should really take the existing sym-lib-table
> or
> > just not clobber the pro file until the schematic is saved.
> >
> > The close without save step should be perfectly valid if you're just
> > peeking at an old project and (possibly much later) you want to go
> > modify it you're greeted with that bad surprise.
> >
> >
> > On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina <
> pavlina.ch...@gmail.com
> > 

Re: [Kicad-developers] Stable 5 branch status

[Wayne Stambaugh]

Nick,

I think you possibly misunderstood me or perhaps I didn't explain it
very well.  I would have liked to have the stable 5 release ready for
FOSDEM but realistically I would be happy if we were ready to create the
v5 branch and tag rc1 by FOSDEM.  That's a far more realistic goal.  I
don't want to rush v5 out.  I still need to fix a few things with the
remapping and the new symbol library editor has a least one crash bug
that needs to be fixed before I would be comfortable with branching v5.
I just don't see any possibility of getting v5 released by FOSDEM even
if I didn't sleep until then. :)  I want to give everyone at least a
month to get the libraries, docs, translations, and packages ready from
the time the source tree is tagged as stable.  If we got the stable 5
release out by the end of March, I would be pretty happy.

Cheers,

Wayne

On 01/07/2018 04:06 PM, Nick Østergaard wrote:
> Hello all,
> 
> I will attempt to summarize the status as I see it.
> 
> Lots of fixes have been comming in over the last few weeks. But if we
> are to keep up with Wayne's goal of having a v5 release for FOSDEM, I
> think we tag 5.0.0-rc1 soon. There is no reason we can still fix stuff
> untill we make the final 5.0.0 release, and create the 5.0 branch from
> there. Then we can unfreeze the feature freeze on master, and git
> describe matster will be relative to this point. I have attached an
> example and caricature of the previous kicad branching and how I see
> expect the future too look like.
> 
> We shall accept that it will probably only be a release candidate for
> FOSDEM, but that would be great too!
> 
> If there are some things that simply need to be in 5.0.0 -- I think we
> need a shoutout now. Looking at
> https://launchpad.net/kicad/+milestone/5.0.0-rc1
>  there are only two
> outstanding bugs.
> 
> The library team seem to be ready to tag also,
> https://github.com/KiCad/kicad-symbols/issues/133
> 
> 
> I guess the doc will not have much time to get much love before the
> release. But this is mostly about new features not being documented and
> probably some cleanup and modernization. I guess we are more likely to
> get some feedback on the docs after the first v5 release.
> 
> The translations will need a bit of touchup on some languages, the ones
> almost done but needs a bit is en, ru, de, and es. These can probably
> reach 100% before v5 if we are lucky. This sort of requires we have a
> kicad tag to update against. I think some of those languages also keep
> unused strings, so even if it is not at 100% it might be complete. But I
> am not sure about this.
> 
> Regards
> Nick Østergaard
> 
> 
> 
> 2018-01-02 21:07 GMT+01:00 Wayne Stambaugh  >:
> 
> I plan on adding the remapping feature to the Eeschema documentation
> before the stable 5 release.  Hopefully I can find the time to knock it
> out it the next week or two to give our translators plenty of time.
> 
> On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> > Of course. My confusion mostly surrounds how it interacts with rescue
> > and when it does and does not decide to write things to disk (see
> José's
> > point about it clobbering its own backups).
> >
> > In any case, I don't need you to explain it to me. You and I
> aren't the
> > only KiCad users, and if people who've been using KiCad for years and
> > have actual dev experience (specifically myself and José here) can't
> > figure it out, scads of users are going to have the same problem. It
> > needs to be made clearer, not explained on the mailing list.
> >
> > On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> >> Let's start at the beginning.  Are you clear on why symbols need
> to be
> >> remapped?
> >>
> >> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> >>> Honestly, with this symbol library stuff it's been hard for me
> to figure
> >>> out what's a bug and what's a confusing design decision. Bug
> reports for
> >>> the latter are rather frowned upon so I've been refraining from
> filing
> >>> many bugs.
> >>>
> >>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
>  I just tested this repo and it failed to remap every symbol so
> either
>  something has been broken or this project is a corner case that I
>  haven't stumbled across yet.  I will keep informed of my
> progress.  In
>  the future, please file bug report when you see something like
> this.  If
>  you just discuss it on irc, I have no way of knowing this is an
> issue
>  unless I manage to free up some time (unlikely any time soon)
> to spend
>  on irc.
> 
>  On 1/2/2018 2:42 PM, José Ignacio wrote:
> > This sequence of actions is what puts the proje

Re: [Kicad-developers] Stable 5 branch status

[Michael McCormack]

As an end user who has projects from well over 10 years ago and who has
lurked on the development mailing list since the diode pin numbering (yes,
opening old projects still get messages diode pin numbering) I want to
thank you for ensuring there is a way to back out of remapping.  I am not
infrequently opening an old schematic on a new system, getting messages
about library issues with very poor suggestions about how to fix them,
exiting Kicad and then editing schematics or project files with text
editors to get the proper symbols loaded.  If the project or schematic
changed just by trying to see what needed fixing that would be end for me.

Thanks for taking the feedback and altering course.

Mike

FYI - joined a new outfit and cancelled a migration from Kicad to Altium
when even the Altium sales people could not articulate what we would gain.
When you look at the stuff like the FreeCad plugins to help with 3D and the
numerous BOM options (and source code you can customize) to help with
product management its hard to beat the Kicad extended ecosystem.

On Thu, Jan 4, 2018 at 10:55 AM, Wayne Stambaugh 
wrote:

> Yes, now it doesn't change anything until you click the remap button.
> If you close without remapping, no changes will be make to any project
> files.  If you do this, do not add new symbols to the schematic and save
> or you will be responsible for remapping the entire schematic by hand.
>
> I am going implement a dry run feature as well so you can see what will
> be changed before actually remapping your schematic.  Given that I am
> currently snowed in, I may actually have time to get it done over the
> weekend.
>
> On 01/04/2018 10:46 AM, Nick Østergaard wrote:
> > Hasn't this been fixed already?
> >
> > 2018-01-04 15:37 GMT+01:00 Jörg Hermann  > >:
> >
> > > scared me the most was a comment about the project being written
> to the disk on opening, so you can't close/kill kicad and keep your project
> untouched.
> >
> > 1000++
> >
> > IMHO Kicad breaks the Principle Of Least Surprise (aka POLA,
> > ...Astonishment) in a big way here.
> >
> > Also a user that reads the dev list.
> >
> > Jörg Hermann
> >
> >
> > ___
> > 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] Stable 5 branch status

[Wayne Stambaugh]

Yes, now it doesn't change anything until you click the remap button.
If you close without remapping, no changes will be make to any project
files.  If you do this, do not add new symbols to the schematic and save
or you will be responsible for remapping the entire schematic by hand.

I am going implement a dry run feature as well so you can see what will
be changed before actually remapping your schematic.  Given that I am
currently snowed in, I may actually have time to get it done over the
weekend.

On 01/04/2018 10:46 AM, Nick Østergaard wrote:
> Hasn't this been fixed already?
> 
> 2018-01-04 15:37 GMT+01:00 Jörg Hermann  >:
> 
> > scared me the most was a comment about the project being written to the 
> disk on opening, so you can't close/kill kicad and keep your project 
> untouched.
> 
> 1000++
> 
> IMHO Kicad breaks the Principle Of Least Surprise (aka POLA,
> ...Astonishment) in a big way here.
> 
> Also a user that reads the dev list.
> 
> Jörg Hermann
> 
> 
> ___
> 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] Stable 5 branch status

[Nick Østergaard]

Hasn't this been fixed already?

2018-01-04 15:37 GMT+01:00 Jörg Hermann :

> > scared me the most was a comment about the project being written to the
> disk on opening, so you can't close/kill kicad and keep your project
> untouched.
>
> 1000++
>
> IMHO Kicad breaks the Principle Of Least Surprise (aka POLA,
> ...Astonishment) in a big way here.
>
> Also a user that reads the dev list.
>
> Jörg Hermann
>
>
> ___
> 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] Stable 5 branch status

[Jörg Hermann]

> scared me the most was a comment about the project being written to the disk 
> on opening, so you can't close/kill kicad and keep your project untouched.

1000++

IMHO Kicad breaks the Principle Of Least Surprise (aka POLA, ...Astonishment) 
in a big way here.

Also a user that reads the dev list.

Jörg Hermann


___
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] Stable 5 branch status

[Marcos Chaparro]

As a power user that likes to be standing on the bleeding edge of kicad, I
find this last library stuff terrifying, even before Chris' comments, and I
will keep standing on the nighties before this library merge because I'm
clueless about how and even why it works. ( And I've read the blog post
about this).

Maybe some documentation with drawings instead a lot of text would help us
understand better. The thing that scared me the most was a comment about
the project being written to the disk on opening, so you can't close/kill
kicad and keep your project untouched.

Just my feedback as a user that reads the dev list.

Cheers


Marcos

On Tue, Jan 2, 2018 at 5:13 PM, Chris Pavlina 
wrote:

> That's good, I just worry that if people need to read the manual for
> something as mundane as importing old projects, it might not be ready
> for release yet. I don't mean to whine at you over this, I understand
> that this is a complicated thing to get right and there are a lot of
> corner cases and weird projects to deal with --- I just really don't
> think it's ready. I understand the pressure to get a release out but I
> don't think we should be making one until the rough edges here are
> smoothed.
>
> Beware of the pitfall of thinking something makes sense to everyone
> because it made sense when you designed it. I find myself falling for
> that one a lot too --- things are always more obvious to their
> designers. The footprint preview is causing people trouble too so I'm
> removing it (well, soft-removing it, as an option). I really didn't want
> to admit it was causing people trouble either :P
>
> On Tue, Jan 02, 2018 at 03:07:44PM -0500, Wayne Stambaugh wrote:
> > I plan on adding the remapping feature to the Eeschema documentation
> > before the stable 5 release.  Hopefully I can find the time to knock it
> > out it the next week or two to give our translators plenty of time.
> >
> > On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> > > Of course. My confusion mostly surrounds how it interacts with rescue
> > > and when it does and does not decide to write things to disk (see
> José's
> > > point about it clobbering its own backups).
> > >
> > > In any case, I don't need you to explain it to me. You and I aren't the
> > > only KiCad users, and if people who've been using KiCad for years and
> > > have actual dev experience (specifically myself and José here) can't
> > > figure it out, scads of users are going to have the same problem. It
> > > needs to be made clearer, not explained on the mailing list.
> > >
> > > On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> > >> Let's start at the beginning.  Are you clear on why symbols need to be
> > >> remapped?
> > >>
> > >> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> > >>> Honestly, with this symbol library stuff it's been hard for me to
> figure
> > >>> out what's a bug and what's a confusing design decision. Bug reports
> for
> > >>> the latter are rather frowned upon so I've been refraining from
> filing
> > >>> many bugs.
> > >>>
> > >>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
> >  I just tested this repo and it failed to remap every symbol so
> either
> >  something has been broken or this project is a corner case that I
> >  haven't stumbled across yet.  I will keep informed of my progress.
> In
> >  the future, please file bug report when you see something like
> this.  If
> >  you just discuss it on irc, I have no way of knowing this is an
> issue
> >  unless I manage to free up some time (unlikely any time soon) to
> spend
> >  on irc.
> > 
> >  On 1/2/2018 2:42 PM, José Ignacio wrote:
> > > This sequence of actions is what puts the project on a stuffed up
> state:
> > >
> > > * Open schematic and be greeted with some symbols that need rescue,
> > > rescue a couple symbols
> > > * Be greeted by the remap dialog (1)
> > > * Regret remapping and quit without save
> > > * Open schematic again
> > > * Be greeted by the rescue dialog, with ALL symbols, refuse
> > > * Remap dialog fails to find anything, click through (2)
> > >
> > > Schematic looks fine, but the remap and rescue dialogs will show up
> > > every time even though there is a valid sym-lib-table.
> > >
> > > (1) At this point the pro file is overwritten, deleting all project
> > > library entries
> > > (2) At this point the pro file is overwritten again!, clobbering
> the
> > > backup (SOL)
> > >
> > > If you accept the second rescue you will have to map everything
> > > manually. The remapper should really take the existing
> sym-lib-table or
> > > just not clobber the pro file until the schematic is saved.
> > >
> > > The close without save step should be perfectly valid if you're
> just
> > > peeking at an old project and (possibly much later) you want to go
> > > modify it you're greeted with that bad surprise.
> > >
> > 

Re: [Kicad-developers] Stable 5 branch status

[Chris Pavlina]

That's good, I just worry that if people need to read the manual for
something as mundane as importing old projects, it might not be ready
for release yet. I don't mean to whine at you over this, I understand
that this is a complicated thing to get right and there are a lot of
corner cases and weird projects to deal with --- I just really don't
think it's ready. I understand the pressure to get a release out but I
don't think we should be making one until the rough edges here are
smoothed.

Beware of the pitfall of thinking something makes sense to everyone
because it made sense when you designed it. I find myself falling for
that one a lot too --- things are always more obvious to their
designers. The footprint preview is causing people trouble too so I'm
removing it (well, soft-removing it, as an option). I really didn't want
to admit it was causing people trouble either :P

On Tue, Jan 02, 2018 at 03:07:44PM -0500, Wayne Stambaugh wrote:
> I plan on adding the remapping feature to the Eeschema documentation
> before the stable 5 release.  Hopefully I can find the time to knock it
> out it the next week or two to give our translators plenty of time.
> 
> On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> > Of course. My confusion mostly surrounds how it interacts with rescue
> > and when it does and does not decide to write things to disk (see José's
> > point about it clobbering its own backups).
> > 
> > In any case, I don't need you to explain it to me. You and I aren't the
> > only KiCad users, and if people who've been using KiCad for years and
> > have actual dev experience (specifically myself and José here) can't
> > figure it out, scads of users are going to have the same problem. It
> > needs to be made clearer, not explained on the mailing list.
> > 
> > On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> >> Let's start at the beginning.  Are you clear on why symbols need to be
> >> remapped?
> >>
> >> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> >>> Honestly, with this symbol library stuff it's been hard for me to figure
> >>> out what's a bug and what's a confusing design decision. Bug reports for
> >>> the latter are rather frowned upon so I've been refraining from filing
> >>> many bugs.
> >>>
> >>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
>  I just tested this repo and it failed to remap every symbol so either
>  something has been broken or this project is a corner case that I
>  haven't stumbled across yet.  I will keep informed of my progress.  In
>  the future, please file bug report when you see something like this.  If
>  you just discuss it on irc, I have no way of knowing this is an issue
>  unless I manage to free up some time (unlikely any time soon) to spend
>  on irc.
> 
>  On 1/2/2018 2:42 PM, José Ignacio wrote:
> > This sequence of actions is what puts the project on a stuffed up state:
> >
> > * Open schematic and be greeted with some symbols that need rescue,
> > rescue a couple symbols
> > * Be greeted by the remap dialog (1)
> > * Regret remapping and quit without save
> > * Open schematic again
> > * Be greeted by the rescue dialog, with ALL symbols, refuse
> > * Remap dialog fails to find anything, click through (2)
> >
> > Schematic looks fine, but the remap and rescue dialogs will show up
> > every time even though there is a valid sym-lib-table.
> >
> > (1) At this point the pro file is overwritten, deleting all project
> > library entries
> > (2) At this point the pro file is overwritten again!, clobbering the
> > backup (SOL)
> >
> > If you accept the second rescue you will have to map everything
> > manually. The remapper should really take the existing sym-lib-table or
> > just not clobber the pro file until the schematic is saved.
> >
> > The close without save step should be perfectly valid if you're just
> > peeking at an old project and (possibly much later) you want to go
> > modify it you're greeted with that bad surprise.
> >
> >
> > On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina  > > wrote:
> >
> > On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > > It's exactly as insane as the cache has always been.
> >
> > I respectfully disagree. As I recall from many years of using KiCad
> > before this, nothing about the cache has ever spontaneously deleted 
> > all
> > libraries without warning. That's a whole new level of insanity that
> > deserves its own "what not to do" section in a UX book somewhere. 
> > (And
> > before you think this is all just "this UX guide sez" vague 
> > complaining,
> > don't forget that I and many others still have _no idea wtf we're 
> > doing_
> > trying to drive this thing.)
> >
> > > The only w

Re: [Kicad-developers] Stable 5 branch status

[Wayne Stambaugh]

I plan on adding the remapping feature to the Eeschema documentation
before the stable 5 release.  Hopefully I can find the time to knock it
out it the next week or two to give our translators plenty of time.

On 1/2/2018 2:59 PM, Chris Pavlina wrote:
> Of course. My confusion mostly surrounds how it interacts with rescue
> and when it does and does not decide to write things to disk (see José's
> point about it clobbering its own backups).
> 
> In any case, I don't need you to explain it to me. You and I aren't the
> only KiCad users, and if people who've been using KiCad for years and
> have actual dev experience (specifically myself and José here) can't
> figure it out, scads of users are going to have the same problem. It
> needs to be made clearer, not explained on the mailing list.
> 
> On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
>> Let's start at the beginning.  Are you clear on why symbols need to be
>> remapped?
>>
>> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
>>> Honestly, with this symbol library stuff it's been hard for me to figure
>>> out what's a bug and what's a confusing design decision. Bug reports for
>>> the latter are rather frowned upon so I've been refraining from filing
>>> many bugs.
>>>
>>> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
 I just tested this repo and it failed to remap every symbol so either
 something has been broken or this project is a corner case that I
 haven't stumbled across yet.  I will keep informed of my progress.  In
 the future, please file bug report when you see something like this.  If
 you just discuss it on irc, I have no way of knowing this is an issue
 unless I manage to free up some time (unlikely any time soon) to spend
 on irc.

 On 1/2/2018 2:42 PM, José Ignacio wrote:
> This sequence of actions is what puts the project on a stuffed up state:
>
> * Open schematic and be greeted with some symbols that need rescue,
> rescue a couple symbols
> * Be greeted by the remap dialog (1)
> * Regret remapping and quit without save
> * Open schematic again
> * Be greeted by the rescue dialog, with ALL symbols, refuse
> * Remap dialog fails to find anything, click through (2)
>
> Schematic looks fine, but the remap and rescue dialogs will show up
> every time even though there is a valid sym-lib-table.
>
> (1) At this point the pro file is overwritten, deleting all project
> library entries
> (2) At this point the pro file is overwritten again!, clobbering the
> backup (SOL)
>
> If you accept the second rescue you will have to map everything
> manually. The remapper should really take the existing sym-lib-table or
> just not clobber the pro file until the schematic is saved.
>
> The close without save step should be perfectly valid if you're just
> peeking at an old project and (possibly much later) you want to go
> modify it you're greeted with that bad surprise.
>
>
> On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina  > wrote:
>
> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > It's exactly as insane as the cache has always been.
>
> I respectfully disagree. As I recall from many years of using KiCad
> before this, nothing about the cache has ever spontaneously deleted 
> all
> libraries without warning. That's a whole new level of insanity that
> deserves its own "what not to do" section in a UX book somewhere. (And
> before you think this is all just "this UX guide sez" vague 
> complaining,
> don't forget that I and many others still have _no idea wtf we're 
> doing_
> trying to drive this thing.)
>
> > The only way I can
> > think of this happening is that the schematic was not saved after 
> the
> > remapping and once all of the libraries are removed from the project
> > file but cache should still be valid if no save was performed.  Let 
> me
> > try remapping this project and I will get back to you.
> >
> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > > Ah, that explains my question mark case. That's insane.
> > >
> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > >> One big problem is that even if everything fails, the project
> will show up
> > >> fine with all symbols, but they wont have the remap done. at
> the same time
> > >> the remapper deletes all library entries from the project file,
> which
> > >> causes it to open with question marks only if you reopen it
> again after
> > >> saving. It should show the question marks before then or make
> better use of
> > >> the cache.
> > >>
> > >> On Tue, Jan 2

Re: [Kicad-developers] Stable 5 branch status

[Chris Pavlina]

Of course. My confusion mostly surrounds how it interacts with rescue
and when it does and does not decide to write things to disk (see José's
point about it clobbering its own backups).

In any case, I don't need you to explain it to me. You and I aren't the
only KiCad users, and if people who've been using KiCad for years and
have actual dev experience (specifically myself and José here) can't
figure it out, scads of users are going to have the same problem. It
needs to be made clearer, not explained on the mailing list.

On Tue, Jan 02, 2018 at 02:55:31PM -0500, Wayne Stambaugh wrote:
> Let's start at the beginning.  Are you clear on why symbols need to be
> remapped?
> 
> On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> > Honestly, with this symbol library stuff it's been hard for me to figure
> > out what's a bug and what's a confusing design decision. Bug reports for
> > the latter are rather frowned upon so I've been refraining from filing
> > many bugs.
> > 
> > On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
> >> I just tested this repo and it failed to remap every symbol so either
> >> something has been broken or this project is a corner case that I
> >> haven't stumbled across yet.  I will keep informed of my progress.  In
> >> the future, please file bug report when you see something like this.  If
> >> you just discuss it on irc, I have no way of knowing this is an issue
> >> unless I manage to free up some time (unlikely any time soon) to spend
> >> on irc.
> >>
> >> On 1/2/2018 2:42 PM, José Ignacio wrote:
> >>> This sequence of actions is what puts the project on a stuffed up state:
> >>>
> >>> * Open schematic and be greeted with some symbols that need rescue,
> >>> rescue a couple symbols
> >>> * Be greeted by the remap dialog (1)
> >>> * Regret remapping and quit without save
> >>> * Open schematic again
> >>> * Be greeted by the rescue dialog, with ALL symbols, refuse
> >>> * Remap dialog fails to find anything, click through (2)
> >>>
> >>> Schematic looks fine, but the remap and rescue dialogs will show up
> >>> every time even though there is a valid sym-lib-table.
> >>>
> >>> (1) At this point the pro file is overwritten, deleting all project
> >>> library entries
> >>> (2) At this point the pro file is overwritten again!, clobbering the
> >>> backup (SOL)
> >>>
> >>> If you accept the second rescue you will have to map everything
> >>> manually. The remapper should really take the existing sym-lib-table or
> >>> just not clobber the pro file until the schematic is saved.
> >>>
> >>> The close without save step should be perfectly valid if you're just
> >>> peeking at an old project and (possibly much later) you want to go
> >>> modify it you're greeted with that bad surprise.
> >>>
> >>>
> >>> On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina  >>> > wrote:
> >>>
> >>> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> >>> > It's exactly as insane as the cache has always been.
> >>>
> >>> I respectfully disagree. As I recall from many years of using KiCad
> >>> before this, nothing about the cache has ever spontaneously deleted 
> >>> all
> >>> libraries without warning. That's a whole new level of insanity that
> >>> deserves its own "what not to do" section in a UX book somewhere. (And
> >>> before you think this is all just "this UX guide sez" vague 
> >>> complaining,
> >>> don't forget that I and many others still have _no idea wtf we're 
> >>> doing_
> >>> trying to drive this thing.)
> >>>
> >>> > The only way I can
> >>> > think of this happening is that the schematic was not saved after 
> >>> the
> >>> > remapping and once all of the libraries are removed from the project
> >>> > file but cache should still be valid if no save was performed.  Let 
> >>> me
> >>> > try remapping this project and I will get back to you.
> >>> >
> >>> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> >>> > > Ah, that explains my question mark case. That's insane.
> >>> > >
> >>> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> >>> > >> One big problem is that even if everything fails, the project
> >>> will show up
> >>> > >> fine with all symbols, but they wont have the remap done. at
> >>> the same time
> >>> > >> the remapper deletes all library entries from the project file,
> >>> which
> >>> > >> causes it to open with question marks only if you reopen it
> >>> again after
> >>> > >> saving. It should show the question marks before then or make
> >>> better use of
> >>> > >> the cache.
> >>> > >>
> >>> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina
> >>> mailto:pavlina.ch...@gmail.com>>
> >>> > >> wrote:
> >>> > >>
> >>> > >>> Keep in mind my problem is not necessarily that things are
> >>> _broken_ but
> >>> > >>> perhaps that they are so opaque that they only m

Re: [Kicad-developers] Stable 5 branch status

[Wayne Stambaugh]

Let's start at the beginning.  Are you clear on why symbols need to be
remapped?

On 1/2/2018 2:52 PM, Chris Pavlina wrote:
> Honestly, with this symbol library stuff it's been hard for me to figure
> out what's a bug and what's a confusing design decision. Bug reports for
> the latter are rather frowned upon so I've been refraining from filing
> many bugs.
> 
> On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
>> I just tested this repo and it failed to remap every symbol so either
>> something has been broken or this project is a corner case that I
>> haven't stumbled across yet.  I will keep informed of my progress.  In
>> the future, please file bug report when you see something like this.  If
>> you just discuss it on irc, I have no way of knowing this is an issue
>> unless I manage to free up some time (unlikely any time soon) to spend
>> on irc.
>>
>> On 1/2/2018 2:42 PM, José Ignacio wrote:
>>> This sequence of actions is what puts the project on a stuffed up state:
>>>
>>> * Open schematic and be greeted with some symbols that need rescue,
>>> rescue a couple symbols
>>> * Be greeted by the remap dialog (1)
>>> * Regret remapping and quit without save
>>> * Open schematic again
>>> * Be greeted by the rescue dialog, with ALL symbols, refuse
>>> * Remap dialog fails to find anything, click through (2)
>>>
>>> Schematic looks fine, but the remap and rescue dialogs will show up
>>> every time even though there is a valid sym-lib-table.
>>>
>>> (1) At this point the pro file is overwritten, deleting all project
>>> library entries
>>> (2) At this point the pro file is overwritten again!, clobbering the
>>> backup (SOL)
>>>
>>> If you accept the second rescue you will have to map everything
>>> manually. The remapper should really take the existing sym-lib-table or
>>> just not clobber the pro file until the schematic is saved.
>>>
>>> The close without save step should be perfectly valid if you're just
>>> peeking at an old project and (possibly much later) you want to go
>>> modify it you're greeted with that bad surprise.
>>>
>>>
>>> On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina >> > wrote:
>>>
>>> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
>>> > It's exactly as insane as the cache has always been.
>>>
>>> I respectfully disagree. As I recall from many years of using KiCad
>>> before this, nothing about the cache has ever spontaneously deleted all
>>> libraries without warning. That's a whole new level of insanity that
>>> deserves its own "what not to do" section in a UX book somewhere. (And
>>> before you think this is all just "this UX guide sez" vague complaining,
>>> don't forget that I and many others still have _no idea wtf we're doing_
>>> trying to drive this thing.)
>>>
>>> > The only way I can
>>> > think of this happening is that the schematic was not saved after the
>>> > remapping and once all of the libraries are removed from the project
>>> > file but cache should still be valid if no save was performed.  Let me
>>> > try remapping this project and I will get back to you.
>>> >
>>> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
>>> > > Ah, that explains my question mark case. That's insane.
>>> > >
>>> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
>>> > >> One big problem is that even if everything fails, the project
>>> will show up
>>> > >> fine with all symbols, but they wont have the remap done. at
>>> the same time
>>> > >> the remapper deletes all library entries from the project file,
>>> which
>>> > >> causes it to open with question marks only if you reopen it
>>> again after
>>> > >> saving. It should show the question marks before then or make
>>> better use of
>>> > >> the cache.
>>> > >>
>>> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina
>>> mailto:pavlina.ch...@gmail.com>>
>>> > >> wrote:
>>> > >>
>>> > >>> Keep in mind my problem is not necessarily that things are
>>> _broken_ but
>>> > >>> perhaps that they are so opaque that they only make sense in
>>> the mind of
>>> > >>> the designer. As I said in the previous message, we've been
>>> getting TONS
>>> > >>> of people on IRC who can't figure out how the hell to drive
>>> this thing,
>>> > >>> and I count myself among them. Still takes me like three tries
>>> to load
>>> > >>> an old project without it stuffing everything up.
>>> > >>>
>>> > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
>>> >  Please send me a sample project if possible.  I have tested
>>> this every
>>> >  which way I can think of and it works fine for everything I
>>> throw at it.
>>> >   The only time things fall apart are when the cache is
>>> corrupted or
>>> >  missing and/or rescues have be ignored. 

Re: [Kicad-developers] Stable 5 branch status

[Chris Pavlina]

Honestly, with this symbol library stuff it's been hard for me to figure
out what's a bug and what's a confusing design decision. Bug reports for
the latter are rather frowned upon so I've been refraining from filing
many bugs.

On Tue, Jan 02, 2018 at 02:51:14PM -0500, Wayne Stambaugh wrote:
> I just tested this repo and it failed to remap every symbol so either
> something has been broken or this project is a corner case that I
> haven't stumbled across yet.  I will keep informed of my progress.  In
> the future, please file bug report when you see something like this.  If
> you just discuss it on irc, I have no way of knowing this is an issue
> unless I manage to free up some time (unlikely any time soon) to spend
> on irc.
> 
> On 1/2/2018 2:42 PM, José Ignacio wrote:
> > This sequence of actions is what puts the project on a stuffed up state:
> > 
> > * Open schematic and be greeted with some symbols that need rescue,
> > rescue a couple symbols
> > * Be greeted by the remap dialog (1)
> > * Regret remapping and quit without save
> > * Open schematic again
> > * Be greeted by the rescue dialog, with ALL symbols, refuse
> > * Remap dialog fails to find anything, click through (2)
> > 
> > Schematic looks fine, but the remap and rescue dialogs will show up
> > every time even though there is a valid sym-lib-table.
> > 
> > (1) At this point the pro file is overwritten, deleting all project
> > library entries
> > (2) At this point the pro file is overwritten again!, clobbering the
> > backup (SOL)
> > 
> > If you accept the second rescue you will have to map everything
> > manually. The remapper should really take the existing sym-lib-table or
> > just not clobber the pro file until the schematic is saved.
> > 
> > The close without save step should be perfectly valid if you're just
> > peeking at an old project and (possibly much later) you want to go
> > modify it you're greeted with that bad surprise.
> > 
> > 
> > On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina  > > wrote:
> > 
> > On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > > It's exactly as insane as the cache has always been.
> > 
> > I respectfully disagree. As I recall from many years of using KiCad
> > before this, nothing about the cache has ever spontaneously deleted all
> > libraries without warning. That's a whole new level of insanity that
> > deserves its own "what not to do" section in a UX book somewhere. (And
> > before you think this is all just "this UX guide sez" vague complaining,
> > don't forget that I and many others still have _no idea wtf we're doing_
> > trying to drive this thing.)
> > 
> > > The only way I can
> > > think of this happening is that the schematic was not saved after the
> > > remapping and once all of the libraries are removed from the project
> > > file but cache should still be valid if no save was performed.  Let me
> > > try remapping this project and I will get back to you.
> > >
> > > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > > > Ah, that explains my question mark case. That's insane.
> > > >
> > > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > > >> One big problem is that even if everything fails, the project
> > will show up
> > > >> fine with all symbols, but they wont have the remap done. at
> > the same time
> > > >> the remapper deletes all library entries from the project file,
> > which
> > > >> causes it to open with question marks only if you reopen it
> > again after
> > > >> saving. It should show the question marks before then or make
> > better use of
> > > >> the cache.
> > > >>
> > > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina
> > mailto:pavlina.ch...@gmail.com>>
> > > >> wrote:
> > > >>
> > > >>> Keep in mind my problem is not necessarily that things are
> > _broken_ but
> > > >>> perhaps that they are so opaque that they only make sense in
> > the mind of
> > > >>> the designer. As I said in the previous message, we've been
> > getting TONS
> > > >>> of people on IRC who can't figure out how the hell to drive
> > this thing,
> > > >>> and I count myself among them. Still takes me like three tries
> > to load
> > > >>> an old project without it stuffing everything up.
> > > >>>
> > > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > >  Please send me a sample project if possible.  I have tested
> > this every
> > >  which way I can think of and it works fine for everything I
> > throw at it.
> > >   The only time things fall apart are when the cache is
> > corrupted or
> > >  missing and/or rescues have be ignored.  In those cases there
> > is nothing
> > >  I can do because the proper symbols do not exist anywhere so
> > remapping

Re: [Kicad-developers] Stable 5 branch status

[Wayne Stambaugh]

I just tested this repo and it failed to remap every symbol so either
something has been broken or this project is a corner case that I
haven't stumbled across yet.  I will keep informed of my progress.  In
the future, please file bug report when you see something like this.  If
you just discuss it on irc, I have no way of knowing this is an issue
unless I manage to free up some time (unlikely any time soon) to spend
on irc.

On 1/2/2018 2:42 PM, José Ignacio wrote:
> This sequence of actions is what puts the project on a stuffed up state:
> 
> * Open schematic and be greeted with some symbols that need rescue,
> rescue a couple symbols
> * Be greeted by the remap dialog (1)
> * Regret remapping and quit without save
> * Open schematic again
> * Be greeted by the rescue dialog, with ALL symbols, refuse
> * Remap dialog fails to find anything, click through (2)
> 
> Schematic looks fine, but the remap and rescue dialogs will show up
> every time even though there is a valid sym-lib-table.
> 
> (1) At this point the pro file is overwritten, deleting all project
> library entries
> (2) At this point the pro file is overwritten again!, clobbering the
> backup (SOL)
> 
> If you accept the second rescue you will have to map everything
> manually. The remapper should really take the existing sym-lib-table or
> just not clobber the pro file until the schematic is saved.
> 
> The close without save step should be perfectly valid if you're just
> peeking at an old project and (possibly much later) you want to go
> modify it you're greeted with that bad surprise.
> 
> 
> On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina  > wrote:
> 
> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > It's exactly as insane as the cache has always been.
> 
> I respectfully disagree. As I recall from many years of using KiCad
> before this, nothing about the cache has ever spontaneously deleted all
> libraries without warning. That's a whole new level of insanity that
> deserves its own "what not to do" section in a UX book somewhere. (And
> before you think this is all just "this UX guide sez" vague complaining,
> don't forget that I and many others still have _no idea wtf we're doing_
> trying to drive this thing.)
> 
> > The only way I can
> > think of this happening is that the schematic was not saved after the
> > remapping and once all of the libraries are removed from the project
> > file but cache should still be valid if no save was performed.  Let me
> > try remapping this project and I will get back to you.
> >
> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > > Ah, that explains my question mark case. That's insane.
> > >
> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > >> One big problem is that even if everything fails, the project
> will show up
> > >> fine with all symbols, but they wont have the remap done. at
> the same time
> > >> the remapper deletes all library entries from the project file,
> which
> > >> causes it to open with question marks only if you reopen it
> again after
> > >> saving. It should show the question marks before then or make
> better use of
> > >> the cache.
> > >>
> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina
> mailto:pavlina.ch...@gmail.com>>
> > >> wrote:
> > >>
> > >>> Keep in mind my problem is not necessarily that things are
> _broken_ but
> > >>> perhaps that they are so opaque that they only make sense in
> the mind of
> > >>> the designer. As I said in the previous message, we've been
> getting TONS
> > >>> of people on IRC who can't figure out how the hell to drive
> this thing,
> > >>> and I count myself among them. Still takes me like three tries
> to load
> > >>> an old project without it stuffing everything up.
> > >>>
> > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> >  Please send me a sample project if possible.  I have tested
> this every
> >  which way I can think of and it works fine for everything I
> throw at it.
> >   The only time things fall apart are when the cache is
> corrupted or
> >  missing and/or rescues have be ignored.  In those cases there
> is nothing
> >  I can do because the proper symbols do not exist anywhere so
> remapping
> >  is not possible.
> > 
> >  On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > Are we really going to do an RC now without any more work to
> the remap
> > > stuff? I just had it ruin another project last night. It
> behaves very
> > > poorly when things also have to be rescued or libraries are
> missing, it
> > > seems.
> > >
> > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> 

Re: [Kicad-developers] Stable 5 branch status

[Jon Evans]

Maybe one quick and helpful change would be to make
DIALOG_SYMBOL_REMAP::backupProject() add a timestamp or other unique ID to
the backup file name, so it won't clobber old backups if run multiple times
due to "non-standard" workflows?

On Tue, Jan 2, 2018 at 2:42 PM, José Ignacio  wrote:

> This sequence of actions is what puts the project on a stuffed up state:
>
> * Open schematic and be greeted with some symbols that need rescue, rescue
> a couple symbols
> * Be greeted by the remap dialog (1)
> * Regret remapping and quit without save
> * Open schematic again
> * Be greeted by the rescue dialog, with ALL symbols, refuse
> * Remap dialog fails to find anything, click through (2)
>
> Schematic looks fine, but the remap and rescue dialogs will show up every
> time even though there is a valid sym-lib-table.
>
> (1) At this point the pro file is overwritten, deleting all project
> library entries
> (2) At this point the pro file is overwritten again!, clobbering the
> backup (SOL)
>
> If you accept the second rescue you will have to map everything manually.
> The remapper should really take the existing sym-lib-table or just not
> clobber the pro file until the schematic is saved.
>
> The close without save step should be perfectly valid if you're just
> peeking at an old project and (possibly much later) you want to go modify
> it you're greeted with that bad surprise.
>
>
> On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina 
> wrote:
>
>> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
>> > It's exactly as insane as the cache has always been.
>>
>> I respectfully disagree. As I recall from many years of using KiCad
>> before this, nothing about the cache has ever spontaneously deleted all
>> libraries without warning. That's a whole new level of insanity that
>> deserves its own "what not to do" section in a UX book somewhere. (And
>> before you think this is all just "this UX guide sez" vague complaining,
>> don't forget that I and many others still have _no idea wtf we're doing_
>> trying to drive this thing.)
>>
>> > The only way I can
>> > think of this happening is that the schematic was not saved after the
>> > remapping and once all of the libraries are removed from the project
>> > file but cache should still be valid if no save was performed.  Let me
>> > try remapping this project and I will get back to you.
>> >
>> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
>> > > Ah, that explains my question mark case. That's insane.
>> > >
>> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
>> > >> One big problem is that even if everything fails, the project will
>> show up
>> > >> fine with all symbols, but they wont have the remap done. at the
>> same time
>> > >> the remapper deletes all library entries from the project file, which
>> > >> causes it to open with question marks only if you reopen it again
>> after
>> > >> saving. It should show the question marks before then or make better
>> use of
>> > >> the cache.
>> > >>
>> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina <
>> pavlina.ch...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> Keep in mind my problem is not necessarily that things are _broken_
>> but
>> > >>> perhaps that they are so opaque that they only make sense in the
>> mind of
>> > >>> the designer. As I said in the previous message, we've been getting
>> TONS
>> > >>> of people on IRC who can't figure out how the hell to drive this
>> thing,
>> > >>> and I count myself among them. Still takes me like three tries to
>> load
>> > >>> an old project without it stuffing everything up.
>> > >>>
>> > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
>> >  Please send me a sample project if possible.  I have tested this
>> every
>> >  which way I can think of and it works fine for everything I throw
>> at it.
>> >   The only time things fall apart are when the cache is corrupted or
>> >  missing and/or rescues have be ignored.  In those cases there is
>> nothing
>> >  I can do because the proper symbols do not exist anywhere so
>> remapping
>> >  is not possible.
>> > 
>> >  On 1/2/2018 1:33 PM, Chris Pavlina wrote:
>> > > Are we really going to do an RC now without any more work to the
>> remap
>> > > stuff? I just had it ruin another project last night. It behaves
>> very
>> > > poorly when things also have to be rescued or libraries are
>> missing, it
>> > > seems.
>> > >
>> > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
>> > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
>> > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
>> >  There are a few outstanding crash bugs that need to be fixed
>> before
>> > >>> we
>> >  can consider branching the stable 5 release.  Here is the list
>> of
>> >  unresolved crash bugs that effect the development branch:
>> > 
>> >  https://bugs.launchpad.net/kicad/+bug/1562788
>> > 

Re: [Kicad-developers] Stable 5 branch status

[José Ignacio]

This sequence of actions is what puts the project on a stuffed up state:

* Open schematic and be greeted with some symbols that need rescue, rescue
a couple symbols
* Be greeted by the remap dialog (1)
* Regret remapping and quit without save
* Open schematic again
* Be greeted by the rescue dialog, with ALL symbols, refuse
* Remap dialog fails to find anything, click through (2)

Schematic looks fine, but the remap and rescue dialogs will show up every
time even though there is a valid sym-lib-table.

(1) At this point the pro file is overwritten, deleting all project library
entries
(2) At this point the pro file is overwritten again!, clobbering the backup
(SOL)

If you accept the second rescue you will have to map everything manually.
The remapper should really take the existing sym-lib-table or just not
clobber the pro file until the schematic is saved.

The close without save step should be perfectly valid if you're just
peeking at an old project and (possibly much later) you want to go modify
it you're greeted with that bad surprise.


On Tue, Jan 2, 2018 at 1:28 PM, Chris Pavlina 
wrote:

> On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> > It's exactly as insane as the cache has always been.
>
> I respectfully disagree. As I recall from many years of using KiCad
> before this, nothing about the cache has ever spontaneously deleted all
> libraries without warning. That's a whole new level of insanity that
> deserves its own "what not to do" section in a UX book somewhere. (And
> before you think this is all just "this UX guide sez" vague complaining,
> don't forget that I and many others still have _no idea wtf we're doing_
> trying to drive this thing.)
>
> > The only way I can
> > think of this happening is that the schematic was not saved after the
> > remapping and once all of the libraries are removed from the project
> > file but cache should still be valid if no save was performed.  Let me
> > try remapping this project and I will get back to you.
> >
> > On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > > Ah, that explains my question mark case. That's insane.
> > >
> > > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > >> One big problem is that even if everything fails, the project will
> show up
> > >> fine with all symbols, but they wont have the remap done. at the same
> time
> > >> the remapper deletes all library entries from the project file, which
> > >> causes it to open with question marks only if you reopen it again
> after
> > >> saving. It should show the question marks before then or make better
> use of
> > >> the cache.
> > >>
> > >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina <
> pavlina.ch...@gmail.com>
> > >> wrote:
> > >>
> > >>> Keep in mind my problem is not necessarily that things are _broken_
> but
> > >>> perhaps that they are so opaque that they only make sense in the
> mind of
> > >>> the designer. As I said in the previous message, we've been getting
> TONS
> > >>> of people on IRC who can't figure out how the hell to drive this
> thing,
> > >>> and I count myself among them. Still takes me like three tries to
> load
> > >>> an old project without it stuffing everything up.
> > >>>
> > >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> >  Please send me a sample project if possible.  I have tested this
> every
> >  which way I can think of and it works fine for everything I throw
> at it.
> >   The only time things fall apart are when the cache is corrupted or
> >  missing and/or rescues have be ignored.  In those cases there is
> nothing
> >  I can do because the proper symbols do not exist anywhere so
> remapping
> >  is not possible.
> > 
> >  On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > Are we really going to do an RC now without any more work to the
> remap
> > > stuff? I just had it ruin another project last night. It behaves
> very
> > > poorly when things also have to be rescued or libraries are
> missing, it
> > > seems.
> > >
> > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> >  There are a few outstanding crash bugs that need to be fixed
> before
> > >>> we
> >  can consider branching the stable 5 release.  Here is the list
> of
> >  unresolved crash bugs that effect the development branch:
> > 
> >  https://bugs.launchpad.net/kicad/+bug/1562788
> >  https://bugs.launchpad.net/kicad/+bug/1732274
> >  https://bugs.launchpad.net/kicad/+bug/1738872
> >  https://bugs.launchpad.net/kicad/+bug/1738999
> >  https://bugs.launchpad.net/kicad/+bug/1739614
> >  https://bugs.launchpad.net/kicad/+bug/1740253
> > >>>
> > >>> Hey Wayne,
> > >>>
> > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a
> bug
> > >>>

Re: [Kicad-developers] Stable 5 branch status

[Chris Pavlina]

On Tue, Jan 02, 2018 at 02:20:10PM -0500, Wayne Stambaugh wrote:
> It's exactly as insane as the cache has always been.

I respectfully disagree. As I recall from many years of using KiCad
before this, nothing about the cache has ever spontaneously deleted all
libraries without warning. That's a whole new level of insanity that
deserves its own "what not to do" section in a UX book somewhere. (And
before you think this is all just "this UX guide sez" vague complaining,
don't forget that I and many others still have _no idea wtf we're doing_
trying to drive this thing.)

> The only way I can
> think of this happening is that the schematic was not saved after the
> remapping and once all of the libraries are removed from the project
> file but cache should still be valid if no save was performed.  Let me
> try remapping this project and I will get back to you.
> 
> On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> > Ah, that explains my question mark case. That's insane.
> > 
> > On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> >> One big problem is that even if everything fails, the project will show up
> >> fine with all symbols, but they wont have the remap done. at the same time
> >> the remapper deletes all library entries from the project file, which
> >> causes it to open with question marks only if you reopen it again after
> >> saving. It should show the question marks before then or make better use of
> >> the cache.
> >>
> >> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
> >> wrote:
> >>
> >>> Keep in mind my problem is not necessarily that things are _broken_ but
> >>> perhaps that they are so opaque that they only make sense in the mind of
> >>> the designer. As I said in the previous message, we've been getting TONS
> >>> of people on IRC who can't figure out how the hell to drive this thing,
> >>> and I count myself among them. Still takes me like three tries to load
> >>> an old project without it stuffing everything up.
> >>>
> >>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
>  Please send me a sample project if possible.  I have tested this every
>  which way I can think of and it works fine for everything I throw at it.
>   The only time things fall apart are when the cache is corrupted or
>  missing and/or rescues have be ignored.  In those cases there is nothing
>  I can do because the proper symbols do not exist anywhere so remapping
>  is not possible.
> 
>  On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > Are we really going to do an RC now without any more work to the remap
> > stuff? I just had it ruin another project last night. It behaves very
> > poorly when things also have to be rescued or libraries are missing, it
> > seems.
> >
> > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
>  There are a few outstanding crash bugs that need to be fixed before
> >>> we
>  can consider branching the stable 5 release.  Here is the list of
>  unresolved crash bugs that effect the development branch:
> 
>  https://bugs.launchpad.net/kicad/+bug/1562788
>  https://bugs.launchpad.net/kicad/+bug/1732274
>  https://bugs.launchpad.net/kicad/+bug/1738872
>  https://bugs.launchpad.net/kicad/+bug/1738999
>  https://bugs.launchpad.net/kicad/+bug/1739614
>  https://bugs.launchpad.net/kicad/+bug/1740253
> >>>
> >>> Hey Wayne,
> >>>
> >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug
> >>> in
> >>> OCE). Please proceed with the 5.0-rc.
> >>>
> >>> Tom
> >>>
> >>
> >> Hi Tom,
> >>
> >> Thanks!.  I wont have time to get to this until the weekend.  If there
> >> are no additional critical severity bug reports by then, I will create
> >> the version 5 branch.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> ___
> >> 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] Stable 5 branch status

[Wayne Stambaugh]

It's exactly as insane as the cache has always been.  The only way I can
think of this happening is that the schematic was not saved after the
remapping and once all of the libraries are removed from the project
file but cache should still be valid if no save was performed.  Let me
try remapping this project and I will get back to you.

On 1/2/2018 2:08 PM, Chris Pavlina wrote:
> Ah, that explains my question mark case. That's insane.
> 
> On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
>> One big problem is that even if everything fails, the project will show up
>> fine with all symbols, but they wont have the remap done. at the same time
>> the remapper deletes all library entries from the project file, which
>> causes it to open with question marks only if you reopen it again after
>> saving. It should show the question marks before then or make better use of
>> the cache.
>>
>> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
>> wrote:
>>
>>> Keep in mind my problem is not necessarily that things are _broken_ but
>>> perhaps that they are so opaque that they only make sense in the mind of
>>> the designer. As I said in the previous message, we've been getting TONS
>>> of people on IRC who can't figure out how the hell to drive this thing,
>>> and I count myself among them. Still takes me like three tries to load
>>> an old project without it stuffing everything up.
>>>
>>> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
 Please send me a sample project if possible.  I have tested this every
 which way I can think of and it works fine for everything I throw at it.
  The only time things fall apart are when the cache is corrupted or
 missing and/or rescues have be ignored.  In those cases there is nothing
 I can do because the proper symbols do not exist anywhere so remapping
 is not possible.

 On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> Are we really going to do an RC now without any more work to the remap
> stuff? I just had it ruin another project last night. It behaves very
> poorly when things also have to be rescued or libraries are missing, it
> seems.
>
> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
>> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
>>> On 28/12/17 20:24, Wayne Stambaugh wrote:
 There are a few outstanding crash bugs that need to be fixed before
>>> we
 can consider branching the stable 5 release.  Here is the list of
 unresolved crash bugs that effect the development branch:

 https://bugs.launchpad.net/kicad/+bug/1562788
 https://bugs.launchpad.net/kicad/+bug/1732274
 https://bugs.launchpad.net/kicad/+bug/1738872
 https://bugs.launchpad.net/kicad/+bug/1738999
 https://bugs.launchpad.net/kicad/+bug/1739614
 https://bugs.launchpad.net/kicad/+bug/1740253
>>>
>>> Hey Wayne,
>>>
>>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug
>>> in
>>> OCE). Please proceed with the 5.0-rc.
>>>
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> Thanks!.  I wont have time to get to this until the weekend.  If there
>> are no additional critical severity bug reports by then, I will create
>> the version 5 branch.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> 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] Stable 5 branch status

[José Ignacio]

This is doubly compounded if the project has symbols with (newly) illegal
names. The cache gets symbols with the original names but the code cant
find them anymore, even though the remapper can find it in the library with
the slashes, so you have to manually edit the library before opening, or
operate on a copy. It's been pretty painful to convert my old projects when
I've had to uprev them. Add rescue to the mix and things get even more
confusing.

On Tue, Jan 2, 2018 at 1:08 PM, Chris Pavlina 
wrote:

> Ah, that explains my question mark case. That's insane.
>
> On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> > One big problem is that even if everything fails, the project will show
> up
> > fine with all symbols, but they wont have the remap done. at the same
> time
> > the remapper deletes all library entries from the project file, which
> > causes it to open with question marks only if you reopen it again after
> > saving. It should show the question marks before then or make better use
> of
> > the cache.
> >
> > On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
> > wrote:
> >
> > > Keep in mind my problem is not necessarily that things are _broken_ but
> > > perhaps that they are so opaque that they only make sense in the mind
> of
> > > the designer. As I said in the previous message, we've been getting
> TONS
> > > of people on IRC who can't figure out how the hell to drive this thing,
> > > and I count myself among them. Still takes me like three tries to load
> > > an old project without it stuffing everything up.
> > >
> > > On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > > > Please send me a sample project if possible.  I have tested this
> every
> > > > which way I can think of and it works fine for everything I throw at
> it.
> > > >  The only time things fall apart are when the cache is corrupted or
> > > > missing and/or rescues have be ignored.  In those cases there is
> nothing
> > > > I can do because the proper symbols do not exist anywhere so
> remapping
> > > > is not possible.
> > > >
> > > > On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > > > Are we really going to do an RC now without any more work to the
> remap
> > > > > stuff? I just had it ruin another project last night. It behaves
> very
> > > > > poorly when things also have to be rescued or libraries are
> missing, it
> > > > > seems.
> > > > >
> > > > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > > > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > > > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> > > >  There are a few outstanding crash bugs that need to be fixed
> before
> > > we
> > > >  can consider branching the stable 5 release.  Here is the list
> of
> > > >  unresolved crash bugs that effect the development branch:
> > > > 
> > > >  https://bugs.launchpad.net/kicad/+bug/1562788
> > > >  https://bugs.launchpad.net/kicad/+bug/1732274
> > > >  https://bugs.launchpad.net/kicad/+bug/1738872
> > > >  https://bugs.launchpad.net/kicad/+bug/1738999
> > > >  https://bugs.launchpad.net/kicad/+bug/1739614
> > > >  https://bugs.launchpad.net/kicad/+bug/1740253
> > > > >>>
> > > > >>> Hey Wayne,
> > > > >>>
> > > > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a
> bug
> > > in
> > > > >>> OCE). Please proceed with the 5.0-rc.
> > > > >>>
> > > > >>> Tom
> > > > >>>
> > > > >>
> > > > >> Hi Tom,
> > > > >>
> > > > >> Thanks!.  I wont have time to get to this until the weekend.  If
> there
> > > > >> are no additional critical severity bug reports by then, I will
> create
> > > > >> the version 5 branch.
> > > > >>
> > > > >> Cheers,
> > > > >>
> > > > >> Wayne
> > > > >>
> > > > >> ___
> > > > >> 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] Stable 5 branch status

[Chris Pavlina]

I have a slight feeling it should be doing the remap _before_ rescue
instead of after, but I'm at work now so I can't really poke around at
it.

It's stuffing everything up in multiple ways, depending on exactly what
I tell it to do and I'm still not sure what I'm doing wrong. In one
case, it rescues symbols that don't need it, presumably due to trying to
rescue _before_ remapping; I have to go through the schematic and
reassign symbols to the actual library symbol rather than the rescued
one. In the other case, it gives a project that looks like it works, but
clearly some state is messed up because when I save and reopen, it fails
to find the symbols and everything is a question mark.

I'd give you more than that but _I don't understand what it's doing_.
It's really, really opaque.

On Tue, Jan 02, 2018 at 02:05:05PM -0500, Wayne Stambaugh wrote:
> You're going to have to give me a bit more than "stuffing everything
> up".  Are the symbols being incorrectly remapped?  Even if the symbol
> library table is empty, the recovery should still be correct as long as
> the cache library is valid.  If as you suggest it's so opaque that users
> cannot understand what is happening (which I find hard to believe given
> that it reports every action required to remap a schematic), I don't
> know how to fix that other than silently remap the schematic and only
> show the dialog when something goes wrong.  I'll take a look at this
> project as soon as I get a chance.
> 
> On 1/2/2018 1:44 PM, Chris Pavlina wrote:
> > Keep in mind my problem is not necessarily that things are _broken_ but
> > perhaps that they are so opaque that they only make sense in the mind of
> > the designer. As I said in the previous message, we've been getting TONS
> > of people on IRC who can't figure out how the hell to drive this thing,
> > and I count myself among them. Still takes me like three tries to load
> > an old project without it stuffing everything up.
> > 
> > On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> >> Please send me a sample project if possible.  I have tested this every
> >> which way I can think of and it works fine for everything I throw at it.
> >>  The only time things fall apart are when the cache is corrupted or
> >> missing and/or rescues have be ignored.  In those cases there is nothing
> >> I can do because the proper symbols do not exist anywhere so remapping
> >> is not possible.
> >>
> >> On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> >>> Are we really going to do an RC now without any more work to the remap
> >>> stuff? I just had it ruin another project last night. It behaves very
> >>> poorly when things also have to be rescued or libraries are missing, it
> >>> seems.
> >>>
> >>> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
>  On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > On 28/12/17 20:24, Wayne Stambaugh wrote:
> >> There are a few outstanding crash bugs that need to be fixed before we
> >> can consider branching the stable 5 release.  Here is the list of
> >> unresolved crash bugs that effect the development branch:
> >>
> >> https://bugs.launchpad.net/kicad/+bug/1562788
> >> https://bugs.launchpad.net/kicad/+bug/1732274
> >> https://bugs.launchpad.net/kicad/+bug/1738872
> >> https://bugs.launchpad.net/kicad/+bug/1738999
> >> https://bugs.launchpad.net/kicad/+bug/1739614
> >> https://bugs.launchpad.net/kicad/+bug/1740253
> >
> > Hey Wayne,
> >
> > I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> > OCE). Please proceed with the 5.0-rc.
> >
> > Tom
> >
> 
>  Hi Tom,
> 
>  Thanks!.  I wont have time to get to this until the weekend.  If there
>  are no additional critical severity bug reports by then, I will create
>  the version 5 branch.
> 
>  Cheers,
> 
>  Wayne
> 
>  ___
>  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] Stable 5 branch status

[Chris Pavlina]

Ah, that explains my question mark case. That's insane.

On Tue, Jan 02, 2018 at 01:08:11PM -0600, José Ignacio wrote:
> One big problem is that even if everything fails, the project will show up
> fine with all symbols, but they wont have the remap done. at the same time
> the remapper deletes all library entries from the project file, which
> causes it to open with question marks only if you reopen it again after
> saving. It should show the question marks before then or make better use of
> the cache.
> 
> On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
> wrote:
> 
> > Keep in mind my problem is not necessarily that things are _broken_ but
> > perhaps that they are so opaque that they only make sense in the mind of
> > the designer. As I said in the previous message, we've been getting TONS
> > of people on IRC who can't figure out how the hell to drive this thing,
> > and I count myself among them. Still takes me like three tries to load
> > an old project without it stuffing everything up.
> >
> > On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > > Please send me a sample project if possible.  I have tested this every
> > > which way I can think of and it works fine for everything I throw at it.
> > >  The only time things fall apart are when the cache is corrupted or
> > > missing and/or rescues have be ignored.  In those cases there is nothing
> > > I can do because the proper symbols do not exist anywhere so remapping
> > > is not possible.
> > >
> > > On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > > Are we really going to do an RC now without any more work to the remap
> > > > stuff? I just had it ruin another project last night. It behaves very
> > > > poorly when things also have to be rescued or libraries are missing, it
> > > > seems.
> > > >
> > > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> > >  There are a few outstanding crash bugs that need to be fixed before
> > we
> > >  can consider branching the stable 5 release.  Here is the list of
> > >  unresolved crash bugs that effect the development branch:
> > > 
> > >  https://bugs.launchpad.net/kicad/+bug/1562788
> > >  https://bugs.launchpad.net/kicad/+bug/1732274
> > >  https://bugs.launchpad.net/kicad/+bug/1738872
> > >  https://bugs.launchpad.net/kicad/+bug/1738999
> > >  https://bugs.launchpad.net/kicad/+bug/1739614
> > >  https://bugs.launchpad.net/kicad/+bug/1740253
> > > >>>
> > > >>> Hey Wayne,
> > > >>>
> > > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug
> > in
> > > >>> OCE). Please proceed with the 5.0-rc.
> > > >>>
> > > >>> Tom
> > > >>>
> > > >>
> > > >> Hi Tom,
> > > >>
> > > >> Thanks!.  I wont have time to get to this until the weekend.  If there
> > > >> are no additional critical severity bug reports by then, I will create
> > > >> the version 5 branch.
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Wayne
> > > >>
> > > >> ___
> > > >> 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] Stable 5 branch status

[José Ignacio]

One big problem is that even if everything fails, the project will show up
fine with all symbols, but they wont have the remap done. at the same time
the remapper deletes all library entries from the project file, which
causes it to open with question marks only if you reopen it again after
saving. It should show the question marks before then or make better use of
the cache.

On Tue, Jan 2, 2018 at 12:44 PM, Chris Pavlina 
wrote:

> Keep in mind my problem is not necessarily that things are _broken_ but
> perhaps that they are so opaque that they only make sense in the mind of
> the designer. As I said in the previous message, we've been getting TONS
> of people on IRC who can't figure out how the hell to drive this thing,
> and I count myself among them. Still takes me like three tries to load
> an old project without it stuffing everything up.
>
> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> > Please send me a sample project if possible.  I have tested this every
> > which way I can think of and it works fine for everything I throw at it.
> >  The only time things fall apart are when the cache is corrupted or
> > missing and/or rescues have be ignored.  In those cases there is nothing
> > I can do because the proper symbols do not exist anywhere so remapping
> > is not possible.
> >
> > On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > > Are we really going to do an RC now without any more work to the remap
> > > stuff? I just had it ruin another project last night. It behaves very
> > > poorly when things also have to be rescued or libraries are missing, it
> > > seems.
> > >
> > > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
> >  There are a few outstanding crash bugs that need to be fixed before
> we
> >  can consider branching the stable 5 release.  Here is the list of
> >  unresolved crash bugs that effect the development branch:
> > 
> >  https://bugs.launchpad.net/kicad/+bug/1562788
> >  https://bugs.launchpad.net/kicad/+bug/1732274
> >  https://bugs.launchpad.net/kicad/+bug/1738872
> >  https://bugs.launchpad.net/kicad/+bug/1738999
> >  https://bugs.launchpad.net/kicad/+bug/1739614
> >  https://bugs.launchpad.net/kicad/+bug/1740253
> > >>>
> > >>> Hey Wayne,
> > >>>
> > >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug
> in
> > >>> OCE). Please proceed with the 5.0-rc.
> > >>>
> > >>> Tom
> > >>>
> > >>
> > >> Hi Tom,
> > >>
> > >> Thanks!.  I wont have time to get to this until the weekend.  If there
> > >> are no additional critical severity bug reports by then, I will create
> > >> the version 5 branch.
> > >>
> > >> Cheers,
> > >>
> > >> Wayne
> > >>
> > >> ___
> > >> 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] Stable 5 branch status

[Wayne Stambaugh]

You're going to have to give me a bit more than "stuffing everything
up".  Are the symbols being incorrectly remapped?  Even if the symbol
library table is empty, the recovery should still be correct as long as
the cache library is valid.  If as you suggest it's so opaque that users
cannot understand what is happening (which I find hard to believe given
that it reports every action required to remap a schematic), I don't
know how to fix that other than silently remap the schematic and only
show the dialog when something goes wrong.  I'll take a look at this
project as soon as I get a chance.

On 1/2/2018 1:44 PM, Chris Pavlina wrote:
> Keep in mind my problem is not necessarily that things are _broken_ but
> perhaps that they are so opaque that they only make sense in the mind of
> the designer. As I said in the previous message, we've been getting TONS
> of people on IRC who can't figure out how the hell to drive this thing,
> and I count myself among them. Still takes me like three tries to load
> an old project without it stuffing everything up.
> 
> On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
>> Please send me a sample project if possible.  I have tested this every
>> which way I can think of and it works fine for everything I throw at it.
>>  The only time things fall apart are when the cache is corrupted or
>> missing and/or rescues have be ignored.  In those cases there is nothing
>> I can do because the proper symbols do not exist anywhere so remapping
>> is not possible.
>>
>> On 1/2/2018 1:33 PM, Chris Pavlina wrote:
>>> Are we really going to do an RC now without any more work to the remap
>>> stuff? I just had it ruin another project last night. It behaves very
>>> poorly when things also have to be rescued or libraries are missing, it
>>> seems.
>>>
>>> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
 On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> On 28/12/17 20:24, Wayne Stambaugh wrote:
>> There are a few outstanding crash bugs that need to be fixed before we
>> can consider branching the stable 5 release.  Here is the list of
>> unresolved crash bugs that effect the development branch:
>>
>> https://bugs.launchpad.net/kicad/+bug/1562788
>> https://bugs.launchpad.net/kicad/+bug/1732274
>> https://bugs.launchpad.net/kicad/+bug/1738872
>> https://bugs.launchpad.net/kicad/+bug/1738999
>> https://bugs.launchpad.net/kicad/+bug/1739614
>> https://bugs.launchpad.net/kicad/+bug/1740253
>
> Hey Wayne,
>
> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> OCE). Please proceed with the 5.0-rc.
>
> Tom
>

 Hi Tom,

 Thanks!.  I wont have time to get to this until the weekend.  If there
 are no additional critical severity bug reports by then, I will create
 the version 5 branch.

 Cheers,

 Wayne

 ___
 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] Stable 5 branch status

[Chris Pavlina]

Are we really going to do an RC now without any more work to the remap
stuff? I just had it ruin another project last night. It behaves very
poorly when things also have to be rescued or libraries are missing, it
seems.

On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > On 28/12/17 20:24, Wayne Stambaugh wrote:
> >> There are a few outstanding crash bugs that need to be fixed before we
> >> can consider branching the stable 5 release.  Here is the list of
> >> unresolved crash bugs that effect the development branch:
> >>
> >> https://bugs.launchpad.net/kicad/+bug/1562788
> >> https://bugs.launchpad.net/kicad/+bug/1732274
> >> https://bugs.launchpad.net/kicad/+bug/1738872
> >> https://bugs.launchpad.net/kicad/+bug/1738999
> >> https://bugs.launchpad.net/kicad/+bug/1739614
> >> https://bugs.launchpad.net/kicad/+bug/1740253
> > 
> > Hey Wayne,
> > 
> > I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> > OCE). Please proceed with the 5.0-rc.
> > 
> > Tom
> > 
> 
> Hi Tom,
> 
> Thanks!.  I wont have time to get to this until the weekend.  If there
> are no additional critical severity bug reports by then, I will create
> the version 5 branch.
> 
> Cheers,
> 
> Wayne
> 
> ___
> 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] Stable 5 branch status

[Wayne Stambaugh]

Please send me a sample project if possible.  I have tested this every
which way I can think of and it works fine for everything I throw at it.
 The only time things fall apart are when the cache is corrupted or
missing and/or rescues have be ignored.  In those cases there is nothing
I can do because the proper symbols do not exist anywhere so remapping
is not possible.

On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> Are we really going to do an RC now without any more work to the remap
> stuff? I just had it ruin another project last night. It behaves very
> poorly when things also have to be rescued or libraries are missing, it
> seems.
> 
> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
>> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
>>> On 28/12/17 20:24, Wayne Stambaugh wrote:
 There are a few outstanding crash bugs that need to be fixed before we
 can consider branching the stable 5 release.  Here is the list of
 unresolved crash bugs that effect the development branch:

 https://bugs.launchpad.net/kicad/+bug/1562788
 https://bugs.launchpad.net/kicad/+bug/1732274
 https://bugs.launchpad.net/kicad/+bug/1738872
 https://bugs.launchpad.net/kicad/+bug/1738999
 https://bugs.launchpad.net/kicad/+bug/1739614
 https://bugs.launchpad.net/kicad/+bug/1740253
>>>
>>> Hey Wayne,
>>>
>>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
>>> OCE). Please proceed with the 5.0-rc.
>>>
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> Thanks!.  I wont have time to get to this until the weekend.  If there
>> are no additional critical severity bug reports by then, I will create
>> the version 5 branch.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> 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] Stable 5 branch status

[Chris Pavlina]

Keep in mind my problem is not necessarily that things are _broken_ but
perhaps that they are so opaque that they only make sense in the mind of
the designer. As I said in the previous message, we've been getting TONS
of people on IRC who can't figure out how the hell to drive this thing,
and I count myself among them. Still takes me like three tries to load
an old project without it stuffing everything up.

On Tue, Jan 02, 2018 at 01:40:40PM -0500, Wayne Stambaugh wrote:
> Please send me a sample project if possible.  I have tested this every
> which way I can think of and it works fine for everything I throw at it.
>  The only time things fall apart are when the cache is corrupted or
> missing and/or rescues have be ignored.  In those cases there is nothing
> I can do because the proper symbols do not exist anywhere so remapping
> is not possible.
> 
> On 1/2/2018 1:33 PM, Chris Pavlina wrote:
> > Are we really going to do an RC now without any more work to the remap
> > stuff? I just had it ruin another project last night. It behaves very
> > poorly when things also have to be rescued or libraries are missing, it
> > seems.
> > 
> > On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> >> On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> >>> On 28/12/17 20:24, Wayne Stambaugh wrote:
>  There are a few outstanding crash bugs that need to be fixed before we
>  can consider branching the stable 5 release.  Here is the list of
>  unresolved crash bugs that effect the development branch:
> 
>  https://bugs.launchpad.net/kicad/+bug/1562788
>  https://bugs.launchpad.net/kicad/+bug/1732274
>  https://bugs.launchpad.net/kicad/+bug/1738872
>  https://bugs.launchpad.net/kicad/+bug/1738999
>  https://bugs.launchpad.net/kicad/+bug/1739614
>  https://bugs.launchpad.net/kicad/+bug/1740253
> >>>
> >>> Hey Wayne,
> >>>
> >>> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> >>> OCE). Please proceed with the 5.0-rc.
> >>>
> >>> Tom
> >>>
> >>
> >> Hi Tom,
> >>
> >> Thanks!.  I wont have time to get to this until the weekend.  If there
> >> are no additional critical severity bug reports by then, I will create
> >> the version 5 branch.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> ___
> >> 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] Stable 5 branch status

[Chris Pavlina]

We're currently close to inundated on IRC with people using nightlies
wondering what to do because their projects don't load properly. If it's
not _broken_ it's definitely so unintuitive that most people seem unable
to figure it out. Myself included, it took me way too long to figure out
how to load [1] in a way that all symbols loaded, all symbols loaded the
_second_ time (for some reason, I got a project that worked once and
then replaced everything with question mark boxes the next time I opened
it), and nothing was unnecessarily rescued that didn't need to be. I
have no idea how to use this thing myself and I actually understand the
libraries...

[1] https://github.com/conorpp/u2f-zero

On Tue, Jan 02, 2018 at 11:33:49AM -0700, Chris Pavlina wrote:
> Are we really going to do an RC now without any more work to the remap
> stuff? I just had it ruin another project last night. It behaves very
> poorly when things also have to be rescued or libraries are missing, it
> seems.
> 
> On Tue, Jan 02, 2018 at 09:10:20AM -0500, Wayne Stambaugh wrote:
> > On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> > > On 28/12/17 20:24, Wayne Stambaugh wrote:
> > >> There are a few outstanding crash bugs that need to be fixed before we
> > >> can consider branching the stable 5 release.  Here is the list of
> > >> unresolved crash bugs that effect the development branch:
> > >>
> > >> https://bugs.launchpad.net/kicad/+bug/1562788
> > >> https://bugs.launchpad.net/kicad/+bug/1732274
> > >> https://bugs.launchpad.net/kicad/+bug/1738872
> > >> https://bugs.launchpad.net/kicad/+bug/1738999
> > >> https://bugs.launchpad.net/kicad/+bug/1739614
> > >> https://bugs.launchpad.net/kicad/+bug/1740253
> > > 
> > > Hey Wayne,
> > > 
> > > I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> > > OCE). Please proceed with the 5.0-rc.
> > > 
> > > Tom
> > > 
> > 
> > Hi Tom,
> > 
> > Thanks!.  I wont have time to get to this until the weekend.  If there
> > are no additional critical severity bug reports by then, I will create
> > the version 5 branch.
> > 
> > Cheers,
> > 
> > Wayne
> > 
> > ___
> > 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] Stable 5 branch status

[Wayne Stambaugh]

On 1/2/2018 8:58 AM, Tomasz Wlostowski wrote:
> On 28/12/17 20:24, Wayne Stambaugh wrote:
>> There are a few outstanding crash bugs that need to be fixed before we
>> can consider branching the stable 5 release.  Here is the list of
>> unresolved crash bugs that effect the development branch:
>>
>> https://bugs.launchpad.net/kicad/+bug/1562788
>> https://bugs.launchpad.net/kicad/+bug/1732274
>> https://bugs.launchpad.net/kicad/+bug/1738872
>> https://bugs.launchpad.net/kicad/+bug/1738999
>> https://bugs.launchpad.net/kicad/+bug/1739614
>> https://bugs.launchpad.net/kicad/+bug/1740253
> 
> Hey Wayne,
> 
> I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
> OCE). Please proceed with the 5.0-rc.
> 
> Tom
> 

Hi Tom,

Thanks!.  I wont have time to get to this until the weekend.  If there
are no additional critical severity bug reports by then, I will create
the version 5 branch.

Cheers,

Wayne

___
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] Stable 5 branch status

[Tomasz Wlostowski]

On 28/12/17 20:24, Wayne Stambaugh wrote:
> There are a few outstanding crash bugs that need to be fixed before we
> can consider branching the stable 5 release.  Here is the list of
> unresolved crash bugs that effect the development branch:
> 
> https://bugs.launchpad.net/kicad/+bug/1562788
> https://bugs.launchpad.net/kicad/+bug/1732274
> https://bugs.launchpad.net/kicad/+bug/1738872
> https://bugs.launchpad.net/kicad/+bug/1738999
> https://bugs.launchpad.net/kicad/+bug/1739614
> https://bugs.launchpad.net/kicad/+bug/1740253

Hey Wayne,

I fixed the remaining 2 bugs yesterday (the STEP import one is a bug in
OCE). Please proceed with the 5.0-rc.

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