kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Rene,

Am 02.05.2018 um 14:57 schrieb Rene Pöschl:
> Most of our contributors have no previous experience with git. So we 
> really can not expect them to understand anything beyond the github 
> workflow. (They are experts in electronics. Not IT) I also don't believe 
> we should burden the contributors with too much with this.

that's unfortunately true for most of contributors or contributions no
matter what kind of software or project and that's a social challenge we
all need to deal with.

> This is even true for the maintainers. They are selected because they 
> understand how to make good symbols and footprints. (Understanding of 
> industry standards, limitations of manufacturing processes and the 
> limitations of kicad)

Reading this thread and following from time to time some library issue
on GitHub (only by reading) I see this point in another light. It's up
to the maintainers to get fulfilled the requirements of the project if
he is accepting a pull request.

I see long lists of pull request on GitHub for the libraries which, and
this list seems even to increase more over the last months which is a
good sign I think, which waiting a review from one of the people which
are allowed to do merge requests. OTOH I see also commit messages as
Reece has pointed out. So for me it looks like there are two problems
which interacting together.

1. The maintainers (you mean above I assume), which are needed to make
QS on new or modified parts based on the library standards, are also
"only" volunteering by there free time and this brings long waiting
queues even for simply contributions. This shows a lack of available
human resources with a deep understanding what the given standards are
mean on technical work.

2. There are also some library maintaining people needed which know how
to do the technical git work right. And this means mostly you sometimes
have to leave the world of platforms like GitHub, GitLab etc if needed.
If you know what a git merge really is and how a GitHub PR is
technically working under the hood you are able to solve quickly
contributions which otherwise need to wait until someone with a better
technical understanding will provide something useful in the issue
tracker on GitHub. Over the time this can become a serious problem for a
project as people can get quickly frustrated and wont contributing in
future times.

> For a lot of our casual contributors the current way of contributing is 
> already too complex. I have seen a lot of them simply give up as soon as 
> git did something they did not expect. This is especially common on the 
> symbol lib side as it is likely that the contributor needs to do a 
> manual merge because somebody else touched the same lib.

Also this problem isn't new and is related to git can't handle big
rather complex text files well if two persons have changed such a file.
git was developed for source code not for handling large text based
files. In the end you will come to the conclusion that git isn't the
best tool here but it's also the best we have.
For me than the workflow heavily based direct on plain git isn't the
correct one.

Thinking in long term where more KiCad users will hopefully come the
current model of library modifications will not work well enough and
better forms of possibilities for contributions need to prepared. The
GitHub platform is only one part to get all things together.

> These casual contributions can in most cases be summarized as a single 
> "added symbol for component x" message. The enduser might not be 
> concerned on the detailed mistakes made by the contributor. (And if they 
> are, the pull request is always linked to the contribution anyways.)
> As we don't want users to hide their history from us maintainers (we 
> want to see what they changed after feedback from us) we really do not 
> want them to squash their commits (by using amend).

This information is quite useless in the end and confusing due blowing
of commits and meta information by this. You need this information only
to decide if further changes are needed before merging or committing.
For me later all these changes are pointless. So please no merge commits
in pull requests and no further modification commits.

For classical pull requests on mailing list this information is handled
in the patch itself as this text block which will not result in the
final git history. Looks like this

> --
> Changes
> v1 -> v2
>  - With drop of patch to remove cflags use of relro flags, needed
>    to rework variable assignments for use of spec files (Matt W.)
> ---

http://patchwork.ozlabs.org/patch/907093/

On GitHub you have tracked such information already within the issue
itself. And if you add a "Closes: #1234" into your commit message the
WebUI on GitHub will point you to the associated issue.

So no, this is all not needed and only time consuming on both sides.

> So the best solution might be to use the github squash merge feature 
> instead of a normal merge and require the maintainer to write a good 
> message about what changed. (Of course only if the contributor did not 
> already make good commit messages.)
Yes, at least the maintainers need to do more like this or locally on
their machine before doing ping pong with pull or merge request. Don't
get me wrong, it's awesome what the libraries have been evolved over the
last year. It's just a never ending task as you will find always new
advantages to get things improved.

-- 
Regards
Carsten Schoenert