kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

This is a good point, Eeli.

Lead devs, what do you think about adding a bright-colored label "needs
cherry pick" that can be removed when the commits are picked to the
required branch? That way, we can run searches for this label and inspect
issues that have it (even if the issue is closed)

I guess we could also try to make a script to detect possible mistakes: if
an issue is closed and has a 5.x milestone, there should be a commit on the
latest 5.x branch that contains a reference to that issue number. If we
manually ran this check from time to time, we could catch issues before a
release.

-Jon


On Tue, Dec 31, 2019, 07:14 Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx> wrote:

> There are some problems with bug reports which affect both the stable
> branch and the development branch (ATM 5.1.x and 5.99).
>
> It's not possible to see from the main list of bugs if both versions are
> affected. Milestone is only for one.
>
> It's not possible to handle versions for bug fixes. It's either closed or
> opened but if the bug affects both versions, IMO it should remain open
> until both have received the fix. And as far as I can see it's not possible
> to see which version was fixed. It can be seen only by going to a commit
> which fixed it.
>
> I don't know if it's even theoretically possible to handle versioning for
> bugs in gitlab, but it should at least possible to use tags which would
> make the states visible. Would that be a good idea?
>
> (One specific issue is https://gitlab.com/kicad/code/kicad/issues/3711,
> see the discussion in
> https://forum.kicad.info/t/5-1-5-another-annoying-pcbnew-bug/20407/13 .)
>
> Eeli Kaikkonen
> _______________________________________________
> 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
>