kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 12/11/19 11:17 AM, Jonatan Liljedahl wrote:
> Ok, good to hear!
> 
> How about moving the new symbol inheritance stuff into such a feature
> branch until it's working? (See
> https://gitlab.com/kicad/code/kicad/issues/3658) I understand it would
> mean less testing, but in its current state it's impossible to test or
> work on anything else since kicad keeps crashing.

It was.  I pushed the branch to my personal development repo and made an
announcement on the dev mailing list several weeks ago.  AFAIK, only JP
did any testing and replied with a bug fix that he found.  During that
time I had a least 3 merge conflicts with the master branch which I had
to fix.  Given the effort to fix merge conflicts and the fact that no
one seem to have time to test it, I merged into master to actually get
some testing done.  I fixed the first crash bug report within 36 hours.
 I will most likely get the next crash report fixed with 24 hours.  It's
not as though you are having to wait days or weeks for bug fixes.  You
are doing a wonderful job of validating my argument.  If the issue is
keeping you from getting work done, please use a build before the
introduction of the new symbol inheritance code or better yet, keep a
copy of the stable version installed on your machine.  That's what other
user seem to do without too many issues.

> 
> On Wed, Dec 11, 2019 at 4:26 PM Jon Evans <jon@xxxxxxxxxxxxx> wrote:
>>
>> We already have used temporary branches for major features in the past. I'm sure we'll continue to do this (through gitlab merge requests) where it makes sense - it's a lot of work to keep a feature branch in mergeable state.
>>
>> -Jon
>>
>> On Wed, Dec 11, 2019, 10:16 Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
>>>
>>> Good points. However, I still think it might make sense to have at
>>> least one more level of granularity, and use temporary branches for
>>> major changes etc. so that they can be tested before being merged into
>>> master. Simply, to make a merge request for big changes even if done
>>> by one of the core developers. Going back to the 5.1 branch just to
>>> have a non-crashing version of kicad is quite a leap.
>>>
>>> On Wed, Dec 11, 2019 at 3:41 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>
>>>> We have discussed this before and given that very few users would ever
>>>> test the development branch(es), I'm not going to change our branching
>>>> policy.  I don't think it's unfair to ask users who are aware that the
>>>> master branch (which is the KiCad development branch) is always in a
>>>> state of flux to deal with a bit of temporary instability in exchange
>>>> for some comprehensive testing of new features.  Most users seem willing
>>>> to help with the testing in spite of some minor and sometimes some not
>>>> so minor inconveniences.  I think have development branches would just
>>>> slow down how quickly new feature bugs would get fixed.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 12/11/19 9:21 AM, Jonatan Liljedahl wrote:
>>>>> Hi,
>>>>>
>>>>> Perhaps it would make sense to adopt something like this?
>>>>> https://nvie.com/posts/a-successful-git-branching-model/#the-main-branches
>>>>>
>>>>> In short, all development happens on 'develop' branch and only when
>>>>> this is stable it's merged back to 'master'. One doesn't have to
>>>>> follow the above model strictly, for example a merge into master
>>>>> doesn't need to mean "new version to be released".
>>>>>
>>>>> Another nice thing is that stuff that are work in progress and not yet
>>>>> stable can live in a feature branch until it's stable enough to merge
>>>>> into 'develop'. (For example the new symbol inheritance stuff, which
>>>>> currently makes the master branch a bit unusable)
>>>>>
>>>>> Maybe some of this makes sense, and some not? Just some thoughts while
>>>>> trying to find a point in the master branch history that doesn't crash
>>>>> all the time :)
>>>>>
>>>>> Cheers
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>> --
>>> /Jonatan
>>> http://kymatica.com
>>>
>>> _______________________________________________
>>> 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
> 
> 
>