kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

It looks like this is a sensitive topic, and I now understand the
packagers feel pressure and that they aren't appreciated enough. That
wasn't my intention and I didn't want to hint or imply anything
negative towards anyone. On the contrary, I know packaging isn't easy
(I have looked at the packaging systems and given up) and appreciate
the work.

There seems to be more than one subjects going on, packaging is only
one. The more fundamental is the need or lack of need for offline
documentation, and if there is need, how is that solved. This also
seems to be a sensitive topic. Personally I don't see why
documentation should be packaged at all for distros if it can be
downloaded anyway.

I mentioned PCM, not because I would think it would be the best
solution, but just for brainstorming (however, this topic seems to be
too sensitive for brainstorming). It would just be a natural way to
download KiCad documentation because other content is downloaded with
it, too, and it would be readily available to the end users. An extra
benefit would be that it would automatically go to a location known to
KiCad, so if KiCad tries to find local documentation, it would be in
the right place.

Eeli Kaikkonen

On Thu, Jan 20, 2022 at 5:59 PM Carsten Schoenert
<c.schoenert@xxxxxxxxxxx> wrote:
>
> Hi,
>
> Am 19.01.22 um 23:18 schrieb Eeli Kaikkonen:
>
> > I don't understand why this discussion is so difficult to understand.
>
> sorry but I don't understand what problem you are trying to solve!
> There is no problem within the Linux world and their distros to provide
> packaged documentation, there is no need to develop another new way for
> distributing documentation.
>
> > I agree with Jon and don't see any problem for distros. As far as I
> > can see the point is that the documentation package version shouldn't
> > be logically dependent on the KiCad packages or vice versa. You can
> > have package kicad-v6.0-documentation version, say, 20222001 [date],
> > can't you? You don't have to give it the version number 6.0.x. If a
> > git tag is needed for technical reasons, let's have automatic tagging
> > which adds a tag each day.
>
> To use the words from Marco...
>
> "Are you serious?"
>
> I'm getting a bit disappointed because I become the feeling that you are
> somehow ignorant about the arguments of at least two main packagers of
> KiCad within Linux. And I really think that you want to solve problems
> on the wrong corner.
>
> THE MAIN PROBLEM ARE THE OUTDATED DOCUMENTS!
> NOT THE WAY THEY ARE DISTRIBUTED.
>
> So it's better to think about how the documentation can be updated and
> how a ongoing process can be introduced to make contributions easier
> with a low barrier for one time contributors.
>
> And as Marco did explain, we need to fix the tools if there is something
> missed at the end. Be friendly to the distributions, please do not try
> to ignore them. They are part of the FOSS ecosystem KiCad is depending on.
> Do not try to "solve" things were distributions already have a process
> for and established rules for that.
>
> I stop now reading any new post on this topic.
>
> --
> 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