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 t
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
> > GitL
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 is
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 mile
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 det
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
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 plannin
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 nee
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,
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 mileston
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 goe
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.
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 Featu
13 matches
Mail list logo
