search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
700 stars 747 forks source link

5.1.0-rc1 is near, anything still open that we need to finish before that? #1470

Closed poeschlr closed 5 years ago

poeschlr commented 5 years ago

https://lists.launchpad.net/kicad-developers/msg39175.html

I would really like this to be merged till we need to tag:

myfreescalewebpage commented 5 years ago

Just looked at the milestone https://github.com/KiCad/kicad-symbols/milestone/4, maybe https://github.com/KiCad/kicad-symbols/pull/1243 (or to be scheduled for 6.0.0) ?

myfreescalewebpage commented 5 years ago

Footprint https://github.com/KiCad/kicad-footprints/milestone/2 has a single PR opened, can be postponed to next release

Package 3D https://github.com/KiCad/kicad-packages3D/milestone/1 100% completed.

evanshultz commented 5 years ago

I'd like to get the symbol fixed. Pinged the PR submitter. If we don't hear back in a couple days I can take it over since I'd rather not have another KiCad release with a known bug in the libraries.

Personally, I'd like to get https://github.com/KiCad/kicad-footprints/pull/981 done since I'm not sure what is holding it up now. Agreed that the other footprint PR isn't going to be ready and can wait.

myfreescalewebpage commented 5 years ago

Agree with @evanshultz, milestones updated.

https://github.com/KiCad/kicad-symbols/milestone/4 https://github.com/KiCad/kicad-footprints/milestone/2 https://github.com/KiCad/kicad-packages3D/milestone/1

poeschlr commented 5 years ago

@evanshultz regarding your pull request: Well it has 55 very complex manually created footprints that need to be reviewed. (A taunting task) I would at least like to overlay the new and old footprints and check how much they differ. (And check the ones closer that differ when looked at by eye.)

For the future please split up such large changes such that one can review the whole thing in one sitting. (I would suggest at least 5 pull requests instead of one in that case.)

myfreescalewebpage commented 5 years ago

@poeschlr maybe you have a target date for the next release ?

evanshultz commented 5 years ago

The devs will decide. You can see the public message of the mailing list in the first post here which gives Wayne's current projection.

myfreescalewebpage commented 5 years ago

Yes no date but soon, was hoping we could have something more detailed.

poeschlr commented 5 years ago

The original plan was to have the final v5.1 release ready for fosdem (2nd and 3rd of february -> this weekend.). After it got clear that this can not be achieved it was decided to at least try to get a release candidate ready till then. It looks increasingly like this might also not be achievable. (At most they can get the tag ready till then. My reasoning is that i doubt there will be any chance that the packaging guys can get packages ready in such a short time even if the source, libraries and docu would be tagged right now.)

evanshultz commented 5 years ago

We should perhaps include https://github.com/KiCad/kicad-footprints/pull/1351 for 5.1.

stambaughw commented 5 years ago

We are agonizingly close to 5.1.0-rc1. There are two high/critical bugs1 outstanding against the development branch and a few more lower priority bugs some of which may get pushed to v6. Once this bug list goes to zero, I will tag rc1 and give the library, doc, and translation devs 3-4 weeks to get ready for the 5.1.0 release.

Cheers,

Wayne

On 1/30/2019 3:20 PM, Rene Pöschl wrote:

The original plan was to have the final v5.1 release ready for fosdem (2nd and 3rd of february -> this weekend.). After it got clear that this can not be achieved it was decided to at least try to get a release candidate ready till then. It looks increasingly like this might also not be achievable. (At most they can get the tag ready till then. My reasoning is that i doubt there will be any chance that the packaging guys can get packages ready in such a short time even if the source, libraries and docu would be tagged right now.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KiCad/kicad-symbols/issues/1470#issuecomment-459094018, or mute the thread https://github.com/notifications/unsubscribe-auth/AFnmplFtoemaJuqRbX_6yJF8ZDwE4jjfks5vIf6WgaJpZM4aYakX.

evanshultz commented 5 years ago

I submitted https://github.com/KiCad/kicad-symbols/pull/1472 which can replace https://github.com/KiCad/kicad-symbols/pull/1243.

evanshultz commented 5 years ago

I'd also like to see https://github.com/KiCad/kicad-symbols/pull/1395 get into 5.1 (final, not necessarily rc1) since it adds back symbols that were previously in the library and removes one duplicate symbol.

myfreescalewebpage commented 5 years ago

@poeschlr just added this https://github.com/KiCad/kicad-footprints/pull/1370 in 5.1.0 Milestone, that's a fix for a bug in a footprint.

poeschlr commented 5 years ago

I ran the check for design breaking changes. It through up the following changes since 5.0.2:

Removed

Pins have been moved, renumbered or removed in symbol:

Normal pins ok but NC pins have been moved, renumbered or removed in symbol

evanshultz commented 5 years ago

Can somebody get to https://github.com/KiCad/kicad-symbols/pull/1472? That is a bug that should be fixed.

I would also personally like to see https://github.com/KiCad/kicad-symbols/pull/1395 get in, if not RC1 then 5.1 final, because it contains symbols that were in the lib earlier and have gotten lost.

aewallin commented 5 years ago

If, as suggested in #605, there will be a new RF_Filter library then I can move some recent symbols there before the 5.1 release. (filters to be moved would be at least #1373 #1223 #1219 #1218 #1212 ). These have potentially many aliases, if someone can find time&energy to make a list of all the aliases..

EDIT: PR that moves filters is now #1525

evanshultz commented 5 years ago

As I noted in the PR, if symbols have been added since 5.0.2 they can be moved. If, however, the symbols existed with the 5.0.0 release we should err on the side of not breaking working schematics and leave them alone for now. Moving existing symbols can be done for 6.0.0 when we will accept more disruption in the libraries.

evanshultz commented 5 years ago

Oh. Sorry. I was looking at the PR open date no the merge date. As these symbols were all merged after 5.0.2 was released on 9 Dec, so it should be fine to move them all to the new RF_Filter library.

heitorPB commented 5 years ago

There's an ongoing discussion in the forum here about a Geiger-Muller symbol that I started a few days ago. I made a symbol and it was merged #1502 last week. But 9V1MI found a specification about the symbol and there will be 2 more symbols arriving soon here. I just don't know how to name the alternative versions. Any help would be very appreciated! Should I open an issue to track it?

evanshultz commented 5 years ago

@aewallin I merged #605 so if you want to put any other symbols added since 5.0.2's release into that new lib please create a PR soon; the 5.1 RC1 window should be closing soon. Thanks!

evanshultz commented 5 years ago

@heitorPB Yes, please move this into an issue. Adding these new symbols may not interact with 5.1 RC1, though I understand wanting to resolve it quickly to get things done nicely for the forthcoming KiCad release.

After reading the forum post, here is what I'd like for you to put in the new issue:

  1. All the symbols (note which are existing and which are proposed) and the difference(s) between them. Please try to capture all info in the issue instead of referring to the forum as Rene has mentioned.
  2. Use of the umlaut. We have used "ue" instead of "u" which is proper and understood for users of the languages which contain umlauts. So... all of them should have been "Mueller" instead of "Muller".
  3. Other outstanding questions. You mentioned the symbol names above; anything else?
evanshultz commented 5 years ago

I'll assume we can continue this discussion for 5.1 RC2 and the final release of 5.1...

I intend to merge https://github.com/KiCad/kicad-symbols/pull/1550 soon.

I would like to see https://github.com/KiCad/kicad-symbols/pull/1060 get merged as it's a true bug. If the OP doesn't do it I'll submit a PR.

https://github.com/KiCad/kicad-symbols/issues/1547 isn't too hard to resolve. Anybody object to me doing this? And since it could certainly cause merge conflicts is someone willing to merge quickly?

https://github.com/KiCad/kicad-symbols/issues/1523 is easy enough to change, and a clear violation of KLC, but would break schematics. Is having on-grid pins worth doing now or after 5.1's library is tagged for these few symbols which may not get used too often?

https://github.com/KiCad/kicad-symbols/issues/1377 spawned https://github.com/KiCad/kicad-symbols/pull/1386, which added a totally non-homogenous logic gate to the lib. While we have discussed in the past about hidden power pins and do not like them at all, I'm uncomfortable with shattering the library like this. I would prefer conformance over scattered symbols merged one-by-one. Should this stay? Be reverted? It uses a specific TI suffix so this is a symbol that would likely be removed in the future when the logic libs are updated since I assume we want to be more generic.

And lastly, while noting this is a footprint thing, we have a bug documented at https://github.com/KiCad/kicad-footprints/issues/1320 which would be good to include.

evanshultz commented 5 years ago

I wanted to make this a separate post.

https://github.com/KiCad/kicad-symbols/pull/1059 changed the thickness of the polylines in the logic libs from -1000. Also see https://lists.launchpad.net/kicad-developers/msg38049.html.

I wanted to take a look at the current state of things, using the modern canvas, now that we're close to 5.1 Maybe too late, but let's just see what we've got. In yesterday's build I tried the following line thicknesses for all arcs currently -1000mil: -1000 (current) -1 0 1 10

Only 10mil looks a bit different in LibEdit because of the polylines on the left side not being perfectly on top of each other and causing a bit of "spreading".

In Eeschema, I zoomed in an out to various levels to capture a few different points: image image image image

To me, when zoomed more out the 0mil thickness looks best. When zooming in more, -1mil and -1000mil look equivalent and better.

Note that I believe this is all without the latest code to add a bit of visual polish, which is driving 5.1 RC2. I haven't seen that it is merged yet so I hope I'm not wrong..

Does anybody object to leaving things as they are for 5.1?

evanshultz commented 5 years ago

5.1 RC2 should be tagged soon. See https://lists.launchpad.net/kicad-developers/msg39560.html. Then 5.1 this weekend, if all goes well, with a target date to get everything ready and announce 5.1 a week after that.

So... what more do we need to do? Ideally, the libraries would be wrapped up and ready to tag for 5.1 in a week as well.

Lots of progress today!

After merging https://github.com/KiCad/kicad-footprints/pull/1437 I looked at the jumpers and we have some jumper pads with solid zone connections and others without. Do we want all jumper pads to have solid zone connections? @poeschlr ? I'm happy to take care of it if you do.

I submitted https://github.com/KiCad/kicad-footprints/pull/1439 and https://github.com/KiCad/kicad-symbols/pull/1579 to address the MeanWell IRM issues. Only the first one is critical and addressing an error in our library.

That only leaves the grounded crystal symbols and the 74LVC1GU04 symbol, which are mentioned above.

Anything else?

antoniovazquezblanco commented 5 years ago

KiCad 5.1.0-rc2 has been tagged

https://launchpad.net/kicad/+announcement/15216

poeschlr commented 5 years ago

@evanshultz only footpirnts with complex pads need the pad connection set as solid. Normal pads should keep it as "from footprint" and the footprint as "from zone" (I do not remember the exact names used in the kicad dialogs. But i would guess you can figure it out from my response.)

I am aware that the source has been tagged. We have a few days to tag the libs but i will still try to tag today or maybe tomorrow.

We then will have a bit of time till v5.1 will be tagged. (Not sure how much is still to be done for that. I doubt rc2 was planned to ever exist but some critical bugs seem to have forced the development team to release another pre release for further testing before releasing 5.1.)

evanshultz commented 5 years ago

That's what I thought. Then https://github.com/KiCad/kicad-footprints/pull/1440, which I just submitted, should be included in 5.1 so that non-custom pads on jumper footprints have the default zone connection type ("From Parent Footprint").

Also, I submitted https://github.com/KiCad/kicad-symbols/pull/1580 which fixes the jumper symbols so the bridged ones and the ones in Device.lib show jumper footprints in CvPcb.

myfreescalewebpage commented 5 years ago

@evanshultz @poeschlr I have a pending footprint+symbol that can be easily integrated, just want to know if travis error at https://github.com/KiCad/kicad-footprints/pull/1081 are normal for this device or not ? If you have time to address it it's really nice :)

poeschlr commented 5 years ago

Final analysis of what changed on the symbol side between 5.0.2 and 5.1.0-rc2

It looks a lot more now than a few weeks ago because this time i enabled checking of aliases.

Removed:

Pins have been moved, renumbered or removed in symbol:

Normal pins ok but NC pins have been moved, renumbered or removed in symbol:

Full log files (.log with color requires a text editor that supports it, .txt is the no color version should work anywhere. The colored version is intended for dark backgrounds.)

5.0.2vs5.1.0-rc2.log 5.0.2vs5.1.0-rc2.txt

evanshultz commented 5 years ago

Thanks Rene!

A couple of notes on the items above:

Things still left that I've posted about above:

  1. Crystal symbols at https://github.com/KiCad/kicad-symbols/issues/1470#issuecomment-466458734.
  2. 74LVC1GU04 symbol at https://github.com/KiCad/kicad-symbols/issues/1470#issuecomment-466458734.
  3. Logic symbol line widths at https://github.com/KiCad/kicad-symbols/issues/1470#issuecomment-466464548.
  4. MeanWell IRM-03 footprint at https://github.com/KiCad/kicad-symbols/issues/1470#issuecomment-467234992.

Is anybody able to help wrap up any or all of the items above?

evanshultz commented 5 years ago

https://lists.launchpad.net/kicad-developers/msg39596.html Wayne would like to tag everything (including the libs) on Friday.

There are 4 items above that I would like to decide to fix or delay for 5.1. Any feedback?

I also pinged the following PRs late last week that included the word "fix" in the title:

  1. https://github.com/KiCad/kicad-symbols/pull/1592 (merged already; thanks!)
  2. https://github.com/KiCad/kicad-symbols/pull/1460
  3. https://github.com/KiCad/kicad-footprints/pull/1347
  4. https://github.com/KiCad/kicad-symbols/pull/1445 (I propose to wait until after 5.1)
  5. https://github.com/KiCad/kicad-symbols/pull/1458 (I propose to wait until after 5.1)

And there is also https://github.com/KiCad/kicad-symbols/pull/1571.

myfreescalewebpage commented 5 years ago

@evanshultz I have finally fixed https://github.com/KiCad/kicad-symbols/pull/1571 I think, let me known

poeschlr commented 5 years ago

I will tag on friday. No matter which of these are still open to be honest. My reasoning is simple: The lib has way too many problems that we kind of know about and many more that we do not really know yet so it really does not make any sense that we should be the reason for any delay for releasing version 5.1

evanshultz commented 5 years ago

My intent was to surface known issues so they can be resolved, if possible.

antoniovazquezblanco commented 5 years ago

Tag day!

I just simply wanted to thank you people for your work and help. You guys have almost closed 400 issues and PRs only in the sym repo between the latest release and this one.

Certainly KiCad is much better thanks to every one of you!

myfreescalewebpage commented 5 years ago

Thanks @antoniovazquezblanco ! For me it was a pleasure to enter in the team during this release, hope the job done is satisfying, but still so many details to learn ! Thanks for the help from all other librarians, @antoniovazquezblanco @evanshultz @poeschlr particularly !

poeschlr commented 5 years ago

5.1 is tagged on the source code side:

poeschlr commented 5 years ago

I am tempted to reuse the rc2 tags for the final v5.1 release. (Because there has been only a week.) Has anything important been merged since then?

evanshultz commented 5 years ago

There have been a few things merged in the last couple days, including some bugs fixed. Nothing major, but still improvements. Why not tag the latest?

poeschlr commented 5 years ago

Notable changes on the symbol side since rc2:

Pins have been moved, renumbered or removed in symbol:

Removed 'Amplifier_Operational.lib:LT6233' was an alias of LM2904 (bugfix: typo in alias name)

Full logs: 5.1.0_vs_5.0.0.log 5.1.0_vs_5.0.0.txt 5.1.0_vs_5.0.2.log 5.1.0_vs_5.0.2.txt 5.1.0_vs_5.1.0-rc2.log 5.1.0_vs_5.1.0-rc2.txt

poeschlr commented 5 years ago

@evanshultz it took me 2 hours or so to generate all the changelog reports and check that everything is ok in general. I hope this explains why i have been tempted to reuse the rc2 tag.

antoniovazquezblanco commented 5 years ago

Closing as libraries have been tagged.

Thank you to everyone again!