kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

FWIW, there are a few software packages out there that can help with git and are free to use with open source projects, such as, Gitkraken and Smartgit.

I am not affiliated with any of them, but I have used them both. They are pretty much similar for the most common use cases and both provide a (hopefully) clearer view into the tree

/Martijn
P.S. This is not to start a flamewar. I apologise for the noise to the git-masters around.

> On 3 May 2018, at 07:31, Carsten Schoenert <c.schoenert@xxxxxxxxxxx> wrote:
> 
> 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
> 
> _______________________________________________
> 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