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

Re: [Kicad-developers] GitLab milestone cleanup

[Nick Østergaard]

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


fre. 26. jun. 2020 00.49 skrev Jon Evans :

> Hi all,
>
> I wanted to make it more clear what the remaining work is for 6.0, so
> I created a new "6.0 Feature Freeze" milestone separate from the
> 6.0.0-rc1 milestone that already existed:
>
> Those with permissions to assign milestones on GitLab: please assign
> wishlist/feature-request items to the Feature Freeze milestone (if
> they will be worked on for 6.0) and bug reports to the 6.0.0-rc1
> milestone.  That way, we can keep track of the remaining work needed
> before feature freeze can happen separate from issues that could get
> fixed after feature freeze.
>
> Also, if anyone is planning on working on something for 6.0 and is not
> currently assigned to it in GitLab, please assign yourself the issue
> (and create the issue for it if it's not there yet!)
>
> Thanks,
> Jon
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] GitLab milestone cleanup

[Jon Evans]

Hi all,

I wanted to make it more clear what the remaining work is for 6.0, so
I created a new "6.0 Feature Freeze" milestone separate from the
6.0.0-rc1 milestone that already existed:

Those with permissions to assign milestones on GitLab: please assign
wishlist/feature-request items to the Feature Freeze milestone (if
they will be worked on for 6.0) and bug reports to the 6.0.0-rc1
milestone.  That way, we can keep track of the remaining work needed
before feature freeze can happen separate from issues that could get
fixed after feature freeze.

Also, if anyone is planning on working on something for 6.0 and is not
currently assigned to it in GitLab, please assign yourself the issue
(and create the issue for it if it's not there yet!)

Thanks,
Jon

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp