kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

I think the question is, do the other repos actually need to do "release
candidates." We switched to the release candidate paradigm for the main
code repo because for the initial releases in the 5.1 series it seemed like
as soon as a new version was released a critical regression was found that
resulted in crashes for users, so a new release was spun very quickly. The
release candidate is a time when the commits to the 5.1 branch are limited
in scope to critical fixes only, and we call it a rc to get more user
feedback.

This also provides a good time for the translators to update parts, since
there shouldn't be any changes to the strings (so it essentially becomes a
string freeze as well). Is there really a benefit for doing a release
candidate for the docs and translations? I don't think there is, but if
people do want it then we need to introduce a new milestone in the main
code repo for doing a string freeze before we do a release candidate so
that the translations have time to catch up before the release candidate.

-Ian

On Sun, May 17, 2020 at 5:45 PM Nick Østergaard <oe.nick@xxxxxxxxx> wrote:

> On Sun, 17 May 2020 at 11:24, Carsten Schoenert <c.schoenert@xxxxxxxxxxx>
> wrote:
> >
> > Hello Wayne,
> >
> > Am 14.05.20 um 18:43 schrieb Wayne Stambaugh:
> > > Carsten,
> > >
> > > What information do you need from KiCad.  Does Debian (or any other
> > > disto) have recommendations for upstream projects to help packagers?
> >
> > Debian has some dedicated information for upstream projects and coders
> > of course.
> >
> > https://wiki.debian.org/UpstreamGuide
> >
> > But these are all plain technically points written down. You will not
> > find any issues for the main KiCad application based on the list from
> > the Debian wiki and that's good.
> >
> > > Packaging is import to the project so if we can package devs lives a
> bit
> > > easier, I'm willing to consider ways to do so.
> >
> > We are going in loops so I currently don't want to put more energy into
> > a for me pointless discussion. And it's also disappointing and not
> > encouraging if people saying they haven't read my complete message(s) ...
> >
> > The main point is that projects simply should provide as much
> > information and communication as possible about the new versions they
> > provide. Distributions need always to think about how intrusive
> > modifications are, that's mainly a simple risk analysis.
> >
> > What do you think if a contributor is providing a 1000 line patch for
> > KiCad and you have no further information than that pure diff?
> > That's mainly the situation for me regarding to symbols and footprints.
> >
> > The release of a new KiCad version can be improved in my eyes by doing a
> > better job of release managing. For example some parts do create release
> > candidates some don't. Makes it difficult for me to do packaging
> > preparations as the final version of the kicad package says then nothing
> > about the real combined l10n and documentation parts as I need to pick
> > up some random versions. Also not helpful if users bring up issues as
> > you need to figure out against what commits these are for real.
> >
>
> There were probably no -rc tag for i18n and the doc, but I didn't see
> you pointing it out in time either.
>
> > --
> > Regards
> > Carsten
> >
> > _______________________________________________
> > 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
>