On 17/05/2020 11:24, Carsten Schoenert wrote:
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
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
On Sun, 17 May 2020 at 11:24, Carsten Schoenert 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
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.
On 14/05/2020 18:43, Wayne Stambaugh wrote:
Rene,
I wonder if we should implement a library commit message policy similar
to the one we use for the source repo[1] and tailor the changelog tags
for how library commits (or any other kicad repo) are made? It's pretty
painless from a committers
Carsten,
What information do you need from KiCad. Does Debian (or any other
disto) have recommendations for upstream projects to help packagers?
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.
Rene,
I wonder if we should
The kicad library team does not have the resources to properly handle
even our main tasks (see the number of open pull requests awaiting
review, hint it is >300 with >600 open over all) let alone handling
additional docu. Plus we are not working with sourcecode. The skills of
the librarieans
Hello Evan,
thanks for taking some time and writing up some sentences and opinions.
I don't wanted to blame anybody by my email, I just wanted to raise some
concerns I did have.
KiCad is not the only upstream project I package for Debian. From about
5 years experience of Debian packaging I can
Carsten,
It was was my PR that was merged (
https://github.com/KiCad/kicad-footprints/pull/1586) which removed these
footprints. In the initial PR comment I noted removing the Multicomp
footprints and it was also discussed in later comments. Those footprints
were deleted with commit
Hello Rene,
Am 12.05.20 um 22:58 schrieb Rene Pöschl:
> What is broken here? The old library folder is still there to ensure
> users do not get an error message. Footprints are embedded in the design
> files so no negative impact on old designs. The new footprints are
> vastly superior to the
10 matches
Mail list logo
