kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Yes, that's what I was intending

On Fri, Jun 26, 2020 at 10:21 AM Wayne Stambaugh <stambaughw@xxxxxxxxx> 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 <stambaughw@xxxxxxxxx> 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
> >>>> <eeli.kaikkonen@xxxxxxxxx <mailto:eeli.kaikkonen@xxxxxxxxx>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>     On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard <oe.nick@xxxxxxxxx
> >>>>     <mailto:oe.nick@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
> >>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >>>>     Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>     More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp