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
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
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
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,
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
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:
>
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
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
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
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
> >
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
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
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
13 matches
Mail list logo
