Re: [Kicad-developers] Launchpad bug tracker guidelines
Hey Nick, This was on my list but if you want to take it on, I'm fine with that. I agree that it should be a separate developer document in markdown format. I also recommend that we link this document on the bug squad page[1]. There needs to be section on when and how set the various bug settings. There is currently too much variation in how we handle bug reports. Cheers, Wayne [1]: https://launchpad.net/~kicad-bug-squad On 5/21/2019 5:27 PM, Nick Østergaard wrote: > Dear Developers, > > and other people actively using the launchpad bug tracker for KiCad. > > I have had the intention to write a guideline on how to help triage > bugs. Mostly categorizing the priority, target milestone and tags. I > have never reached this and we are now far into the year of 2019... > > I think we should add notes in the kicad dev docs (some md file in the > doxygen docs) along the lines of: > > > # Tags > Use tags if it makes sense, a bug does not _need_ to have tags, but it > is often useful to add eeschema or pcbnew if it only applies to > specifics in that sub-application. > > There is a moderated set of "official tags", these are tags that will > appear as a suggestion when entering tags. We want simple tags. Some > tags are multi word, like 3d-viewer, but otherwise we should try to > avoid this, don't use underscores. Just use words that can be used as > separate tags. This is for example used for bugs relating to some > import for export of a file, for example export of step models, they > are tagged as "export step", preferably pcbnew is added here as well > as this is clearly not relating to anything other than pcbnew. Or it > could be "pcbnew import svg" if it is about the secret SVG importer, > or "pcbnew pns" if it is purely related with the router tool in > pcbnew. > > be good here> > > We should avoid using too many other tags that are not "official > tags". They are not forbidden, but probably not needed. If we have a > billion tags, then they are of no use. There is no need spending > cycles to be creative with adding as may tags as you can think of in > thirty seconds. > > # Status > This should be more or less self explanatory. Worth mentioning is that > Fix Committed is used when it is merged on master or a feature branch. > An exception to this could be if it is specifically a bug made against > a developers preview branch. > > Fix Released is used when bugs are in Fix Committed state around > tagging a release of KiCad. This may also be used if it is an issue > not directly related to KiCad source code, like packaging or > peripheral KiCad project. > > Triaged: This one is subjective. I don't really think this is very > useful. Many bugs have this status while I don't really think it is > clear what the next steps for the bug is, or what the intention with > the bug is. IMHO this should only be used for bugs where a good > description of an issue or feature is present, and there is some very > concrete work that can be done. > > # Importance > The meaning of the importance used in the KiCad project: > > Not decided yet. | This is OK for many bugs. > Critical | Exclusively for things like build errors and crash bug > High | Reserved for bugs that cause loss of or corrupt data. > Medium | Fix when convenient, or schedule to fix later. > Low | Fix when convenient. > Wishlist | Not a bug. It's an enhancement/new feature. > > Low bugs could be bugs tagged with starter as well, it may be easy > bugs, or it may be hard work for a simple task! > > Please do not escalate any bug that does not meet the appropriate > criterias on High and Critical. > > # Milestone > Use of this field is intended to put the bug on a milestone to be able > to get a quick and good feeling of how far we are from tagging a > milestone. > > > > This email is not intended to be a discussion, just a +1 thing if you > like it and feedback on where we should document this. This specific > part is intended for developers and the bug squad as a guideline, not > a guideline for newbies reporting bugs, but similar information could > be used as part of the content of > http://kicad-pcb.org/help/report-a-bug/. For that page we should > probably also give some very quick guide to provide backtraces, or is > this not needed with the new stuff from Tom? > > So please indicate on the way forward. Should we add it to the dev > docs or the website? > > Regards > Nick Østergaard > > ___ > 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
[Kicad-developers] Launchpad bug tracker guidelines
Dear Developers, and other people actively using the launchpad bug tracker for KiCad. I have had the intention to write a guideline on how to help triage bugs. Mostly categorizing the priority, target milestone and tags. I have never reached this and we are now far into the year of 2019... I think we should add notes in the kicad dev docs (some md file in the doxygen docs) along the lines of: # Tags Use tags if it makes sense, a bug does not _need_ to have tags, but it is often useful to add eeschema or pcbnew if it only applies to specifics in that sub-application. There is a moderated set of "official tags", these are tags that will appear as a suggestion when entering tags. We want simple tags. Some tags are multi word, like 3d-viewer, but otherwise we should try to avoid this, don't use underscores. Just use words that can be used as separate tags. This is for example used for bugs relating to some import for export of a file, for example export of step models, they are tagged as "export step", preferably pcbnew is added here as well as this is clearly not relating to anything other than pcbnew. Or it could be "pcbnew import svg" if it is about the secret SVG importer, or "pcbnew pns" if it is purely related with the router tool in pcbnew. We should avoid using too many other tags that are not "official tags". They are not forbidden, but probably not needed. If we have a billion tags, then they are of no use. There is no need spending cycles to be creative with adding as may tags as you can think of in thirty seconds. # Status This should be more or less self explanatory. Worth mentioning is that Fix Committed is used when it is merged on master or a feature branch. An exception to this could be if it is specifically a bug made against a developers preview branch. Fix Released is used when bugs are in Fix Committed state around tagging a release of KiCad. This may also be used if it is an issue not directly related to KiCad source code, like packaging or peripheral KiCad project. Triaged: This one is subjective. I don't really think this is very useful. Many bugs have this status while I don't really think it is clear what the next steps for the bug is, or what the intention with the bug is. IMHO this should only be used for bugs where a good description of an issue or feature is present, and there is some very concrete work that can be done. # Importance The meaning of the importance used in the KiCad project: Not decided yet. | This is OK for many bugs. Critical | Exclusively for things like build errors and crash bug High | Reserved for bugs that cause loss of or corrupt data. Medium | Fix when convenient, or schedule to fix later. Low | Fix when convenient. Wishlist | Not a bug. It's an enhancement/new feature. Low bugs could be bugs tagged with starter as well, it may be easy bugs, or it may be hard work for a simple task! Please do not escalate any bug that does not meet the appropriate criterias on High and Critical. # Milestone Use of this field is intended to put the bug on a milestone to be able to get a quick and good feeling of how far we are from tagging a milestone. This email is not intended to be a discussion, just a +1 thing if you like it and feedback on where we should document this. This specific part is intended for developers and the bug squad as a guideline, not a guideline for newbies reporting bugs, but similar information could be used as part of the content of http://kicad-pcb.org/help/report-a-bug/. For that page we should probably also give some very quick guide to provide backtraces, or is this not needed with the new stuff from Tom? So please indicate on the way forward. Should we add it to the dev docs or the website? Regards Nick Østergaard ___ 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] PATCH: exact match of component with sub-units in schematic did not show
John, If this is not acceptable, would an option that allows the user to turn this feature on or off be an acceptable solution. In some use cases, I can see the value of the this patch. Henner, If John, is OK with a user option, would you be OK with making this behavior user configurable? Cheers, Wayne On 5/2/19 1:24 PM, John Beard wrote: > I had a quick look at this. I'm not sure expanding all search hits to > show sub units is the best fix here. It means for the 7400 series that > you can fit only 3 or 4 search hits in the dialog at default size. > > I think it would be reasonable to expand only as far as the LIBID nodes. > > Cheers, > > John > > On 2 May 2019 17:22:12 BST, Wayne Stambaugh wrote: > > Hey Henner, > > On 5/2/19 12:18 PM, Henner Zeller wrote: > > On Tue, 30 Apr 2019 at 20:24, Henner Zeller > wrote: > > > Hi, > so here one digit patch. > > Problem Symptom: in the schematic symbol chooser, if you > search for an > exact match of a component with multiple units, it is not > selected. > For instance, search for > > 74LS00 > > The scored element is in the tree, but you need to manually > unfold it > (see before.png image). This usually works otherwise (I > suspect it has > to do with the fact that there are sub-units). > > The attached change will reliably select the first unit of that > particular symbol and fix the problem (after.png image). > > Now it might be up for debate if the search should actually > unfold to > the first unit or if the tree unfolding should stop at the > 74LS00 part > - I guess if the latter is wished, something dependent on > tree-children needs to be introduced. I leave that up to you. > > Attached: patch (against 5.1 branch), > > > It also applies cleanly against current head, which has the same > problem. > > > I'm on it. I'm digging through my backlog of patch reviews. I should > get to it today or tomorrow. > > 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] Patch set: Display Origin Transforms
Am 2019-05-21 10:21, schrieb Wayne Stambaugh: 4. I did not touch the Bezier coordinates because it appears this is not fully implemented in Pcbnew and I couldn't figure out how I would test such changes. I thought we did go live with this recently so Bezier coordinates will need to be supported unless this was only in the footprint editor. Beziers were activated with the new graphics import routines. You can import a bezier from a dxf. I'm working on a transformations patch between lines/arcs/beziers that will expose this to more easier user access. Until then, let me know if you'd like a .kicad_pcb file with beziers that you can move around to test things. -Seth ___ 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] Patch set: Display Origin Transforms
Hey Reece, I tested your patch set and everything seems to work as advertised. I have a few minor comments: The ORIGIN_TRANSFORMS references should be passed as const in all places where they are used internally by another object that doesn't modify them. It's not necessary to add '1' to the header compile guards. AFAIK, none of the other header files do this. I'm fine if these fixes are implemented in a separate patch. I'm fine with merging this patch set as long as there are no objections. I answered some of your questions in-line below. On 5/19/19 10:13 PM, Reece R. Pollack wrote: > I've attached a Zip file containing 11 patches. These implement the > Origin Transforms feature I've been talking about since KiCon. They > should apply cleanly to the master branch at this commit (currently HEAD): > > 9d56102 Prevent unannotated components from driving connectivity > > In summary, this adds Pcbnew user preferences that allow the user to > select the origin from which absolute coordinates are displayed and > entered. The supported origins are the Page Origin, the Auxiliary > Origin, and the Grid Origin. If the user preference has not been set the > default is Page Origin, which looks just like what we have now. > > Additionally, two other Pcbnew user preferences are added to allow the > user to select which way the X and Y axes increase: Left or Right for > the X axis, and Up or Down for the Y axis. If the user preference has > not been set the default is X Right and Y Down, which again looks just > like what we have now. > > I added a new panel to the Pcbnew "Preferences" dialog called "Origins & > Axes" to allow the user to change these options. I did not add any > toolbar icons as I expect these will be "set and forget" options for > most users. > > These patches do not alter the content of the board file, nor do they > change the internal representation of coordinates. The user can change > preferences without causing revision-managed data churn. The only affect > is how the user sees and enters coordinate values. > > My intent has been to implement these transforms only in Pcbnew, but the > changes to common data structures necessarily affect all KiCad > applications. Thus support for display origin and axis shifts is latent > in the Footprint Editor, GerbView, Eeschema, and the Symbol Editor, and > can be implemented with minimal effort. However, at this point there > should be no user-visible changes in any of these applications. > > Some notes: > > 1. The new file "origin_transform.cpp" is currently in common/widgets/ > because that's where unit_binder.cpp was located. It might ought to > be in common/ instead. Should be in common. It's not really a widget object. > 2. I believe I've addressed all user-visible Pcbnew displays and dialog > boxes other than the Move Exactly dialog. If I missed something > else, let me know. > 3. I haven't decided how the "Move Exactly" dialog should work yet; I > think it needs axis orientation support but not origin translation. > I'd be happy to get feedback before I code a patch for this. It probably should be implemented in the move exactly dialog for absolution positions. > 4. I did not touch the Bezier coordinates because it appears this is > not fully implemented in Pcbnew and I couldn't figure out how I > would test such changes. I thought we did go live with this recently so Bezier coordinates will need to be supported unless this was only in the footprint editor. > 5. I'm willing to make a pass through the code to unify the name of the > Auxiliary Origin once there is a consensus on what to call it. By auxiliary origin, I'm assuming you mean the place and drill origin in pcbnew. If so, the latter is more descriptive. Auxiliary origin is not very descriptive. > 6. Patching the file containing the list of developers to add my name > felt kinda presumptuous. I'd be happy if these patches constitutes > cause to do so. I will do that once your patches are merged. > 7. Would someone send Jeff Young on holiday for a week or two? I'm > getting burned out just trying to keep these patches rebased on his > changes. :-) Jeff, you want to field this question? > > > -Reece > > > > ___ > 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
