Re: [Kicad-developers] WYSISYG pad editor

[Jeff Young]

Hi Roberto,

I confess I haven’t looked at the padstack document yet.

The prototype WYSIWYG shape editor is currently only in the Footprint Editor, 
although I’ve made most of the code agnostic between that and the board editor. 
 

I did look at doing it in the Pad Properties dialog, but that got nixed on 
account of many custom-shaped pads being related to each other (and therefore 
easier to edit en masse), and on that being the hardest place to integrate our 
tool framework (although I got far enough down that path that it’s now somewhat 
easier).

The trouble with the single-pad mode is that there’s a *lot* of editing code 
you do want to make available (copy/paste, duplicate, flip, rotate, move 
exactly, creating new shapes, deleting some existing shapes, etc.), and a *lot* 
that you want to exclude (pasting other shapes, pasting into other layers, 
switching layers, etc.).  That’s going to equate to a lot of code that has to 
be maintained.

Doing all pads at once gets around this, but it does indeed have the “might 
connect two pads” issue.  (Then again, it will only do that if their 
copper/mask/whatever is touching, so is that really an issue in practice?  Hmm… 
if someone is using a polygon to do a neck-down to a pad, and we allow 
recombine to run in Pcbnew, then we’re going to suck that polygon into the pad 
definition.  Maybe we do need to keep it Footprint Editor only.)

Cheers,
Jeff.

> On 26 Jun 2020, at 17:05, Roberto Fernández Bautista 
>  wrote:
> 
> Hi Jeff,
> 
> Did you have a chance to look at the draft document I sent on padstacks a few 
> days ago? I briefly explain how Altium and Cadstar handle pads and vias in 
> that document - hopefully it is helpful?
> 
> I'd like to point out that custom pad shapes are not actually well supported 
> in most other commercial EDAs, so what you are doing at KiCad is definitely 
> above and beyond! Great stuff!
> 
> The prototype shape editor that you are talking about: is this in pcbnew or 
> in the footprint editor? I suppose it would be valid to use this both for 
> editing vias in the PCB as well as pads in a footprint, in the library.  
> Maybe this could be done in the properties window of the pad/via where you 
> could have a basic drawing canvas to draw the shape of the pad/via (maybe in 
> the future you could even import a DXF or other similar format to define the 
> pad shape). Each shape could maybe be saved into a library that can be 
> re-used/selected.
> 
> I'd suggest that regardless of it being a "high contrast mode" or a 
> "properties" window: if you are creating custom shapes for a pad, you should 
> only be doing that: i.e. you are entering "pad editing mode" - you don't want 
> to be accidentally moving other things around while you are doing that and 
> certain certain things should be restricted while in this "mode" - e.g. 
> if you "paste other stuff", you should look at what is being pasted and if it 
> is a valid shape object, you could accept it, otherwise just don't do 
> anything; 
> you should not allow to "delete the pad anchor" - only to move it
> new objects on different layers - isn't the idea of this to be a padstack 
> editor? If so, then assign those shapes to the specific layer.
> I'm not sure I understand your second approach of exploding pads into shapes? 
> Seems to me like you might end up with a lot of random shapes that don't get 
> recombined if you forget to run the "recombine" command? Also I can see that 
> you'd end up joining up several pads together accidentally... I'd suggest the 
> "editing" mode should restrict editing to a single pad
> 
> Roberto (Qbort)
> 
> On Thu, 25 Jun 2020 at 21:53, Jeff Young  > wrote:
> I implemented a prototype of a WYSIWYG custom-pad shape editor.
> 
> You can ctrl-E on a pad and it explodes it and puts you into high-contrast 
> mode with the shapes.  After editing the shapes a second ctrl-E re-combines 
> everything and exits high-contrast mode.
> 
> While it’s pretty neat if you do exactly that, it turns out to have a 
> bazillion corner cases.  (What happens if you paste other stuff in; what 
> happens if you delete the pad anchor; what happens if you create new objects 
> on different layers; etc.)
> 
> So I was considering a different idea which would be more “regular” (from an 
> implementation perspective).
> 
> Basically it would be a command to explode *all* pads in the current 
> footprint, and a command to recombine everything.  The recombine would expand 
> outwards from each pad to consume touching copper shapes.  (It might still 
> need a few edge cases for net-ties.)
> 
> Thoughts?
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 

Re: [Kicad-developers] WYSISYG pad editor

[Roberto Fernández Bautista]

Hi Jeff,

Did you have a chance to look at the draft document I sent on padstacks a
few days ago? I briefly explain how Altium and Cadstar handle pads and vias
in that document - hopefully it is helpful?

I'd like to point out that custom pad shapes are not actually well
supported in most other commercial EDAs, so what you are doing at KiCad is
definitely above and beyond! Great stuff!

The prototype shape editor that you are talking about: is this in pcbnew or
in the footprint editor? I suppose it would be valid to use this both for
editing vias in the PCB as well as pads in a footprint, in the library.
Maybe this could be done in the properties window of the pad/via where you
could have a basic drawing canvas to draw the shape of the pad/via (maybe
in the future you could even import a DXF or other similar format to define
the pad shape). Each shape could maybe be saved into a library that can be
re-used/selected.

I'd suggest that regardless of it being a "high contrast mode" or a
"properties" window: if you are creating custom shapes for a pad, you
should *only *be doing that: i.e. you are entering "pad editing mode" - you
don't want to be accidentally moving other things around while you are
doing that and certain certain things should be restricted while in this
"mode" - e.g.

   - if you "paste other stuff", you should look at what is being pasted
   and if it is a valid shape object, you could accept it, otherwise just
   don't do anything;
   - you should not allow to "delete the pad anchor" - only to move it
   - new objects on different layers - isn't the idea of this to be a
   padstack editor? If so, then assign those shapes to the specific layer.

I'm not sure I understand your second approach of exploding pads into
shapes? Seems to me like you might end up with a lot of random shapes that
don't get recombined if you forget to run the "recombine" command? Also I
can see that you'd end up joining up several pads together accidentally...
I'd suggest the "editing" mode should restrict editing to a single pad

Roberto (Qbort)

On Thu, 25 Jun 2020 at 21:53, Jeff Young  wrote:

> I implemented a prototype of a WYSIWYG custom-pad shape editor.
>
> You can ctrl-E on a pad and it explodes it and puts you into high-contrast
> mode with the shapes.  After editing the shapes a second ctrl-E re-combines
> everything and exits high-contrast mode.
>
> While it’s pretty neat if you do exactly that, it turns out to have a
> bazillion corner cases.  (What happens if you paste other stuff in; what
> happens if you delete the pad anchor; what happens if you create new
> objects on different layers; etc.)
>
> So I was considering a different idea which would be more “regular” (from
> an implementation perspective).
>
> Basically it would be a command to explode *all* pads in the current
> footprint, and a command to recombine everything.  The recombine would
> expand outwards from each pad to consume touching copper shapes.  (It might
> still need a few edge cases for net-ties.)
>
> Thoughts?
> ___
> 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] GitLab milestone cleanup

[Wayne Stambaugh]

Done.  Thanks Jon.

On 6/26/20 10:21 AM, Jon Evans wrote:
> Yes, that's what I was intending
> 
> On Fri, Jun 26, 2020 at 10:21 AM Wayne Stambaugh  wrote:
>>
>> I should replace the entire "Milestone" section with the text you
>> provided correct?
>>
>> On 6/26/20 10:13 AM, Jon Evans wrote:
>>> I tried to change the Milestones section to the below text, but
>>> GitLab's website is currently only half-working for me:
>>>
>>> # Milestone
>>>
>>> Attaching a milestone to an issue is intended to associate the fix for
>>> the issue with a target release. If an issue is present in two
>>> branches, target it to the milestone for the older release (e.g. if an
>>> issue is present in both 5.1 and 6.0, use the 5.1 milestone). The
>>> exception to this is if the fix for the issue will be too invasive to
>>> the code or has a high risk of introducing new bugs. In this case it
>>> should be targeted at the currently active development branch. When in
>>> doubt, target the issue to the older release and revisit the milestone
>>> when the fix is committed.
>>>
>>> The milestone field should only be set for wishlist and low-priority
>>> bugs by the developer who plans to work on that issue.  In other
>>> words, issues without a developer assigned should generally not have a
>>> milestone unless they are medium priority or higher.
>>>
>>> For major releases, we may have two milestones open at once:  A
>>> feature freeze milestone and one for the actual release (typically the
>>> first release candidate, like `6.0.0-rc1`).  Feature requests,
>>> wishlist items, and tasks should be targeted to the feature freeze
>>> milestone, which should have a due date before the release candidate.
>>> Bug reports should be targeted to the release candidate.  This way,
>>> the feature freeze milestone shows the remaining work until feature
>>> freeze, and the release candidate milestone shows the rest of the work
>>> that can be done before or after feature freeze.
>>>
>>> On Fri, Jun 26, 2020 at 10:03 AM Wayne Stambaugh  
>>> wrote:

 We should probably update our issue tracker policy wiki page[1] on
 GitLab to be aligned with these changes.

 [1]:
 https://gitlab.com/kicad/code/kicad/-/wikis/Developers/Guidelines/Issue-Tracker


 On 6/26/20 9:25 AM, Wayne Stambaugh wrote:
> I concur.  It's the purview of the development team to determine when
> manpower will be available to implement a wish list issue.  We should
> remove the milestone from wish list issues unless someone is planning on
> working on them for V6.
>
> Cheers,
>
> Wayne
>
> On 6/26/20 6:11 AM, Ian McInerney wrote:
>> In general, wishlist items should only be given a milestone if they are
>> either:
>> 1) Actively being worked on by a developer
>> 2) Currently on the plan for the release they are milestoned against
>> (this one doesn't need a developer assigned/working on them yet)
>>
>> Other wishlist items don't get a milestone attached to them. I don't
>> think there is a need to have a "future" milestone though, since the
>> GitLab interface makes it easy to look through issues with no milestone
>> and the wishlist label (it is far easier than Launchpad was).
>>
>> -Ian
>>
>> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
>> mailto:eeli.kaikko...@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard > > wrote:
>>
>> What about feature requests / wishes from users that are very
>> unlikely to realise quickly? Should they still be assigned the
>> new milestone?
>>
>> I just worry they may clutter the overview too much, but I guess
>> when we will see how it goes. :) My concern may not be a real
>> problem afterall.
>>
>> Nick
>>
>>
>> Could there be a milestone "Future" for features which are wanted
>> but not planned for the next release? For example, some things were
>> in the v6 roadmap but were moved to the future roadmap, and even
>> more can(?) be moved later. It would be better to have them in
>> Future milestone than keep them in v6 milestone or remove the
>> milestone completely.
>>
>> Eeli Kaikkonen
>> ___
>> 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 : 

Re: [Kicad-developers] GitLab milestone cleanup

[Jon Evans]

Yes, that's what I was intending

On Fri, Jun 26, 2020 at 10:21 AM Wayne Stambaugh  wrote:
>
> I should replace the entire "Milestone" section with the text you
> provided correct?
>
> On 6/26/20 10:13 AM, Jon Evans wrote:
> > I tried to change the Milestones section to the below text, but
> > GitLab's website is currently only half-working for me:
> >
> > # Milestone
> >
> > Attaching a milestone to an issue is intended to associate the fix for
> > the issue with a target release. If an issue is present in two
> > branches, target it to the milestone for the older release (e.g. if an
> > issue is present in both 5.1 and 6.0, use the 5.1 milestone). The
> > exception to this is if the fix for the issue will be too invasive to
> > the code or has a high risk of introducing new bugs. In this case it
> > should be targeted at the currently active development branch. When in
> > doubt, target the issue to the older release and revisit the milestone
> > when the fix is committed.
> >
> > The milestone field should only be set for wishlist and low-priority
> > bugs by the developer who plans to work on that issue.  In other
> > words, issues without a developer assigned should generally not have a
> > milestone unless they are medium priority or higher.
> >
> > For major releases, we may have two milestones open at once:  A
> > feature freeze milestone and one for the actual release (typically the
> > first release candidate, like `6.0.0-rc1`).  Feature requests,
> > wishlist items, and tasks should be targeted to the feature freeze
> > milestone, which should have a due date before the release candidate.
> > Bug reports should be targeted to the release candidate.  This way,
> > the feature freeze milestone shows the remaining work until feature
> > freeze, and the release candidate milestone shows the rest of the work
> > that can be done before or after feature freeze.
> >
> > On Fri, Jun 26, 2020 at 10:03 AM Wayne Stambaugh  
> > wrote:
> >>
> >> We should probably update our issue tracker policy wiki page[1] on
> >> GitLab to be aligned with these changes.
> >>
> >> [1]:
> >> https://gitlab.com/kicad/code/kicad/-/wikis/Developers/Guidelines/Issue-Tracker
> >>
> >>
> >> On 6/26/20 9:25 AM, Wayne Stambaugh wrote:
> >>> I concur.  It's the purview of the development team to determine when
> >>> manpower will be available to implement a wish list issue.  We should
> >>> remove the milestone from wish list issues unless someone is planning on
> >>> working on them for V6.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> On 6/26/20 6:11 AM, Ian McInerney wrote:
>  In general, wishlist items should only be given a milestone if they are
>  either:
>  1) Actively being worked on by a developer
>  2) Currently on the plan for the release they are milestoned against
>  (this one doesn't need a developer assigned/working on them yet)
> 
>  Other wishlist items don't get a milestone attached to them. I don't
>  think there is a need to have a "future" milestone though, since the
>  GitLab interface makes it easy to look through issues with no milestone
>  and the wishlist label (it is far easier than Launchpad was).
> 
>  -Ian
> 
>  On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
>  mailto:eeli.kaikko...@gmail.com>> wrote:
> 
> 
> 
>  On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard   > wrote:
> 
>  What about feature requests / wishes from users that are very
>  unlikely to realise quickly? Should they still be assigned the
>  new milestone?
> 
>  I just worry they may clutter the overview too much, but I guess
>  when we will see how it goes. :) My concern may not be a real
>  problem afterall.
> 
>  Nick
> 
> 
>  Could there be a milestone "Future" for features which are wanted
>  but not planned for the next release? For example, some things were
>  in the v6 roadmap but were moved to the future roadmap, and even
>  more can(?) be moved later. It would be better to have them in
>  Future milestone than keep them in v6 milestone or remove the
>  milestone completely.
> 
>  Eeli Kaikkonen
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers
>  Post to : kicad-developers@lists.launchpad.net
>  
>  Unsubscribe : https://launchpad.net/~kicad-developers
>  More help   : https://help.launchpad.net/ListHelp
> 
> 
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers
>  Post to : kicad-developers@lists.launchpad.net
>  Unsubscribe : https://launchpad.net/~kicad-developers
>  More help   : 

Re: [Kicad-developers] GitLab milestone cleanup

[Wayne Stambaugh]

I should replace the entire "Milestone" section with the text you
provided correct?

On 6/26/20 10:13 AM, Jon Evans wrote:
> I tried to change the Milestones section to the below text, but
> GitLab's website is currently only half-working for me:
> 
> # Milestone
> 
> Attaching a milestone to an issue is intended to associate the fix for
> the issue with a target release. If an issue is present in two
> branches, target it to the milestone for the older release (e.g. if an
> issue is present in both 5.1 and 6.0, use the 5.1 milestone). The
> exception to this is if the fix for the issue will be too invasive to
> the code or has a high risk of introducing new bugs. In this case it
> should be targeted at the currently active development branch. When in
> doubt, target the issue to the older release and revisit the milestone
> when the fix is committed.
> 
> The milestone field should only be set for wishlist and low-priority
> bugs by the developer who plans to work on that issue.  In other
> words, issues without a developer assigned should generally not have a
> milestone unless they are medium priority or higher.
> 
> For major releases, we may have two milestones open at once:  A
> feature freeze milestone and one for the actual release (typically the
> first release candidate, like `6.0.0-rc1`).  Feature requests,
> wishlist items, and tasks should be targeted to the feature freeze
> milestone, which should have a due date before the release candidate.
> Bug reports should be targeted to the release candidate.  This way,
> the feature freeze milestone shows the remaining work until feature
> freeze, and the release candidate milestone shows the rest of the work
> that can be done before or after feature freeze.
> 
> On Fri, Jun 26, 2020 at 10:03 AM Wayne Stambaugh  wrote:
>>
>> We should probably update our issue tracker policy wiki page[1] on
>> GitLab to be aligned with these changes.
>>
>> [1]:
>> https://gitlab.com/kicad/code/kicad/-/wikis/Developers/Guidelines/Issue-Tracker
>>
>>
>> On 6/26/20 9:25 AM, Wayne Stambaugh wrote:
>>> I concur.  It's the purview of the development team to determine when
>>> manpower will be available to implement a wish list issue.  We should
>>> remove the milestone from wish list issues unless someone is planning on
>>> working on them for V6.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 6/26/20 6:11 AM, Ian McInerney wrote:
 In general, wishlist items should only be given a milestone if they are
 either:
 1) Actively being worked on by a developer
 2) Currently on the plan for the release they are milestoned against
 (this one doesn't need a developer assigned/working on them yet)

 Other wishlist items don't get a milestone attached to them. I don't
 think there is a need to have a "future" milestone though, since the
 GitLab interface makes it easy to look through issues with no milestone
 and the wishlist label (it is far easier than Launchpad was).

 -Ian

 On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
 mailto:eeli.kaikko...@gmail.com>> wrote:



 On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard >>> > wrote:

 What about feature requests / wishes from users that are very
 unlikely to realise quickly? Should they still be assigned the
 new milestone?

 I just worry they may clutter the overview too much, but I guess
 when we will see how it goes. :) My concern may not be a real
 problem afterall.

 Nick


 Could there be a milestone "Future" for features which are wanted
 but not planned for the next release? For example, some things were
 in the v6 roadmap but were moved to the future roadmap, and even
 more can(?) be moved later. It would be better to have them in
 Future milestone than keep them in v6 milestone or remove the
 milestone completely.

 Eeli Kaikkonen
 ___
 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] GitLab milestone cleanup

[Jon Evans]

I tried to change the Milestones section to the below text, but
GitLab's website is currently only half-working for me:

# Milestone

Attaching a milestone to an issue is intended to associate the fix for
the issue with a target release. If an issue is present in two
branches, target it to the milestone for the older release (e.g. if an
issue is present in both 5.1 and 6.0, use the 5.1 milestone). The
exception to this is if the fix for the issue will be too invasive to
the code or has a high risk of introducing new bugs. In this case it
should be targeted at the currently active development branch. When in
doubt, target the issue to the older release and revisit the milestone
when the fix is committed.

The milestone field should only be set for wishlist and low-priority
bugs by the developer who plans to work on that issue.  In other
words, issues without a developer assigned should generally not have a
milestone unless they are medium priority or higher.

For major releases, we may have two milestones open at once:  A
feature freeze milestone and one for the actual release (typically the
first release candidate, like `6.0.0-rc1`).  Feature requests,
wishlist items, and tasks should be targeted to the feature freeze
milestone, which should have a due date before the release candidate.
Bug reports should be targeted to the release candidate.  This way,
the feature freeze milestone shows the remaining work until feature
freeze, and the release candidate milestone shows the rest of the work
that can be done before or after feature freeze.

On Fri, Jun 26, 2020 at 10:03 AM Wayne Stambaugh  wrote:
>
> We should probably update our issue tracker policy wiki page[1] on
> GitLab to be aligned with these changes.
>
> [1]:
> https://gitlab.com/kicad/code/kicad/-/wikis/Developers/Guidelines/Issue-Tracker
>
>
> On 6/26/20 9:25 AM, Wayne Stambaugh wrote:
> > I concur.  It's the purview of the development team to determine when
> > manpower will be available to implement a wish list issue.  We should
> > remove the milestone from wish list issues unless someone is planning on
> > working on them for V6.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 6/26/20 6:11 AM, Ian McInerney wrote:
> >> In general, wishlist items should only be given a milestone if they are
> >> either:
> >> 1) Actively being worked on by a developer
> >> 2) Currently on the plan for the release they are milestoned against
> >> (this one doesn't need a developer assigned/working on them yet)
> >>
> >> Other wishlist items don't get a milestone attached to them. I don't
> >> think there is a need to have a "future" milestone though, since the
> >> GitLab interface makes it easy to look through issues with no milestone
> >> and the wishlist label (it is far easier than Launchpad was).
> >>
> >> -Ian
> >>
> >> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
> >> mailto:eeli.kaikko...@gmail.com>> wrote:
> >>
> >>
> >>
> >> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  >> > wrote:
> >>
> >> What about feature requests / wishes from users that are very
> >> unlikely to realise quickly? Should they still be assigned the
> >> new milestone?
> >>
> >> I just worry they may clutter the overview too much, but I guess
> >> when we will see how it goes. :) My concern may not be a real
> >> problem afterall.
> >>
> >> Nick
> >>
> >>
> >> Could there be a milestone "Future" for features which are wanted
> >> but not planned for the next release? For example, some things were
> >> in the v6 roadmap but were moved to the future roadmap, and even
> >> more can(?) be moved later. It would be better to have them in
> >> Future milestone than keep them in v6 milestone or remove the
> >> milestone completely.
> >>
> >> Eeli Kaikkonen
> >> ___
> >> 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   

Re: [Kicad-developers] GitLab milestone cleanup

[Wayne Stambaugh]

We should probably update our issue tracker policy wiki page[1] on
GitLab to be aligned with these changes.

[1]:
https://gitlab.com/kicad/code/kicad/-/wikis/Developers/Guidelines/Issue-Tracker


On 6/26/20 9:25 AM, Wayne Stambaugh wrote:
> I concur.  It's the purview of the development team to determine when
> manpower will be available to implement a wish list issue.  We should
> remove the milestone from wish list issues unless someone is planning on
> working on them for V6.
> 
> Cheers,
> 
> Wayne
> 
> On 6/26/20 6:11 AM, Ian McInerney wrote:
>> In general, wishlist items should only be given a milestone if they are
>> either:
>> 1) Actively being worked on by a developer
>> 2) Currently on the plan for the release they are milestoned against
>> (this one doesn't need a developer assigned/working on them yet)
>>
>> Other wishlist items don't get a milestone attached to them. I don't
>> think there is a need to have a "future" milestone though, since the
>> GitLab interface makes it easy to look through issues with no milestone
>> and the wishlist label (it is far easier than Launchpad was).
>>
>> -Ian
>>
>> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
>> mailto:eeli.kaikko...@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard > > wrote:
>>
>> What about feature requests / wishes from users that are very
>> unlikely to realise quickly? Should they still be assigned the
>> new milestone?
>>
>> I just worry they may clutter the overview too much, but I guess
>> when we will see how it goes. :) My concern may not be a real
>> problem afterall.
>>
>> Nick
>>
>>
>> Could there be a milestone "Future" for features which are wanted
>> but not planned for the next release? For example, some things were
>> in the v6 roadmap but were moved to the future roadmap, and even
>> more can(?) be moved later. It would be better to have them in
>> Future milestone than keep them in v6 milestone or remove the
>> milestone completely.
>>
>> Eeli Kaikkonen
>> ___
>> 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] GitLab milestone cleanup

[Wayne Stambaugh]

I concur.  It's the purview of the development team to determine when
manpower will be available to implement a wish list issue.  We should
remove the milestone from wish list issues unless someone is planning on
working on them for V6.

Cheers,

Wayne

On 6/26/20 6:11 AM, Ian McInerney wrote:
> In general, wishlist items should only be given a milestone if they are
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against
> (this one doesn't need a developer assigned/working on them yet)
> 
> Other wishlist items don't get a milestone attached to them. I don't
> think there is a need to have a "future" milestone though, since the
> GitLab interface makes it easy to look through issues with no milestone
> and the wishlist label (it is far easier than Launchpad was).
> 
> -Ian
> 
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen
> mailto:eeli.kaikko...@gmail.com>> wrote:
> 
> 
> 
> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  > wrote:
> 
> What about feature requests / wishes from users that are very
> unlikely to realise quickly? Should they still be assigned the
> new milestone?
> 
> I just worry they may clutter the overview too much, but I guess
> when we will see how it goes. :) My concern may not be a real
> problem afterall.
> 
> Nick
> 
> 
> Could there be a milestone "Future" for features which are wanted
> but not planned for the next release? For example, some things were
> in the v6 roadmap but were moved to the future roadmap, and even
> more can(?) be moved later. It would be better to have them in
> Future milestone than keep them in v6 milestone or remove the
> milestone completely.
> 
> Eeli Kaikkonen
> ___
> 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] GitLab milestone cleanup

[Jon Evans]

Hi Jeff,

Yes, I think anything you are playing with or working on should / can have
the milestone, even if it's not required for 6.0.

We mostly thought it would be good to remove the milestone from things that
are not assigned to anyone in GitLab and that nobody is currently working
on or planning to work on for 6.0

-Jon

On Fri, Jun 26, 2020, 06:59 Jeff Young  wrote:

> Hi Jon, *et al*,
>
> So I’m still playing with WYSIWYG pad editing, but there’s no requirement
> for it in 6.0.  If I find something that works well then I’ll merge it, but
> otherwise it will probably get pushed to the back-burner (ie: 7.0 &
> padstacks).
>
> So should it be in the milestone or not?
>
> Cheers,
> Jeff.
>
> On 26 Jun 2020, at 11:11, Ian McInerney  wrote:
>
> In general, wishlist items should only be given a milestone if they are
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against (this
> one doesn't need a developer assigned/working on them yet)
>
> Other wishlist items don't get a milestone attached to them. I don't think
> there is a need to have a "future" milestone though, since the GitLab
> interface makes it easy to look through issues with no milestone and the
> wishlist label (it is far easier than Launchpad was).
>
> -Ian
>
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen 
> wrote:
>
>>
>>
>> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard 
>> wrote:
>>
>>> What about feature requests / wishes from users that are very unlikely
>>> to realise quickly? Should they still be assigned the new milestone?
>>>
>>> I just worry they may clutter the overview too much, but I guess when we
>>> will see how it goes. :) My concern may not be a real problem afterall.
>>>
>>> Nick
>>>
>>>
>> Could there be a milestone "Future" for features which are wanted but not
>> planned for the next release? For example, some things were in the v6
>> roadmap but were moved to the future roadmap, and even more can(?) be moved
>> later. It would be better to have them in Future milestone than keep them
>> in v6 milestone or remove the milestone completely.
>>
>> Eeli Kaikkonen
>> ___
>> 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] GitLab milestone cleanup

[Nick Østergaard]

Ok, that sonds good to me.

fre. 26. jun. 2020 12.11 skrev Ian McInerney :

> In general, wishlist items should only be given a milestone if they are
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against (this
> one doesn't need a developer assigned/working on them yet)
>
> Other wishlist items don't get a milestone attached to them. I don't think
> there is a need to have a "future" milestone though, since the GitLab
> interface makes it easy to look through issues with no milestone and the
> wishlist label (it is far easier than Launchpad was).
>
> -Ian
>
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen 
> wrote:
>
>>
>>
>> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard 
>> wrote:
>>
>>> What about feature requests / wishes from users that are very unlikely
>>> to realise quickly? Should they still be assigned the new milestone?
>>>
>>> I just worry they may clutter the overview too much, but I guess when we
>>> will see how it goes. :) My concern may not be a real problem afterall.
>>>
>>> Nick
>>>
>>>
>> Could there be a milestone "Future" for features which are wanted but not
>> planned for the next release? For example, some things were in the v6
>> roadmap but were moved to the future roadmap, and even more can(?) be moved
>> later. It would be better to have them in Future milestone than keep them
>> in v6 milestone or remove the milestone completely.
>>
>> Eeli Kaikkonen
>> ___
>> 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] GitLab milestone cleanup

[Jeff Young]

Hi Jon, et al,

So I’m still playing with WYSIWYG pad editing, but there’s no requirement for 
it in 6.0.  If I find something that works well then I’ll merge it, but 
otherwise it will probably get pushed to the back-burner (ie: 7.0 & padstacks).

So should it be in the milestone or not?

Cheers,
Jeff.

> On 26 Jun 2020, at 11:11, Ian McInerney  wrote:
> 
> In general, wishlist items should only be given a milestone if they are 
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against (this 
> one doesn't need a developer assigned/working on them yet)
> 
> Other wishlist items don't get a milestone attached to them. I don't think 
> there is a need to have a "future" milestone though, since the GitLab 
> interface makes it easy to look through issues with no milestone and the 
> wishlist label (it is far easier than Launchpad was).
> 
> -Ian
> 
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen  > wrote:
> 
> 
> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  > wrote:
> What about feature requests / wishes from users that are very unlikely to 
> realise quickly? Should they still be assigned the new milestone?
> 
> I just worry they may clutter the overview too much, but I guess when we will 
> see how it goes. :) My concern may not be a real problem afterall.
> 
> Nick
> 
> 
> Could there be a milestone "Future" for features which are wanted but not 
> planned for the next release? For example, some things were in the v6 roadmap 
> but were moved to the future roadmap, and even more can(?) be moved later. It 
> would be better to have them in Future milestone than keep them in v6 
> milestone or remove the milestone completely.
> 
> Eeli Kaikkonen
> ___
> 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] GitLab milestone cleanup

[Ian McInerney]

In general, wishlist items should only be given a milestone if they are
either:
1) Actively being worked on by a developer
2) Currently on the plan for the release they are milestoned against (this
one doesn't need a developer assigned/working on them yet)

Other wishlist items don't get a milestone attached to them. I don't think
there is a need to have a "future" milestone though, since the GitLab
interface makes it easy to look through issues with no milestone and the
wishlist label (it is far easier than Launchpad was).

-Ian

On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen 
wrote:

>
>
> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  wrote:
>
>> What about feature requests / wishes from users that are very unlikely to
>> realise quickly? Should they still be assigned the new milestone?
>>
>> I just worry they may clutter the overview too much, but I guess when we
>> will see how it goes. :) My concern may not be a real problem afterall.
>>
>> Nick
>>
>>
> Could there be a milestone "Future" for features which are wanted but not
> planned for the next release? For example, some things were in the v6
> roadmap but were moved to the future roadmap, and even more can(?) be moved
> later. It would be better to have them in Future milestone than keep them
> in v6 milestone or remove the milestone completely.
>
> Eeli Kaikkonen
> ___
> 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] GitLab milestone cleanup

[Eeli Kaikkonen]

On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  wrote:

> What about feature requests / wishes from users that are very unlikely to
> realise quickly? Should they still be assigned the new milestone?
>
> I just worry they may clutter the overview too much, but I guess when we
> will see how it goes. :) My concern may not be a real problem afterall.
>
> Nick
>
>
Could there be a milestone "Future" for features which are wanted but not
planned for the next release? For example, some things were in the v6
roadmap but were moved to the future roadmap, and even more can(?) be moved
later. It would be better to have them in Future milestone than keep them
in v6 milestone or remove the milestone completely.

Eeli Kaikkonen
___
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