kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 2/1/2018 7:48 AM, Jeff Young wrote:
> One other question: what about large but simple changes?
> 
> For instance, I’m currently working on getting rid of the g_UserUnits global.  It’s going to be several thousand lines of changes, but each one is pretty brain-dead.

In this case, a patch will do.  The only bad thing about a big patch
like this is that it only takes one commit by someone else to make a
patch fail to apply cleanly so you may want to coordinate with other
developers to avoid unnecessary rebasing.

> 
> This one already has a bug report, so that’s not an issue.  But would you rather have a patch or a pull-request?

Can you hold off on this until after the stable release just in case
there are some unexpected side effects?  I know the risk is low but I
*really* want to focus on getting the stable release out.  Trust me when
I tell you that global variables are one of my pet peeves but fixing
them doesn't really help the user which is what we need to focus on for
the stable release.  I'm hoping to put together a list of bugs within
the next 24 hours that I would like fixed before the stable 5 release
happens.

> 
> Cheers,
> Jeff.
> 
> Opps, one more:
> 
> Can a public repo have an upstream chain of:
>    personal-public >> personal-local >> kicad
> or does it have to be:
>    personal-local >> personal-public >> kicad

I have my main personal repo which pretty much tracks the head of the
development repo.  I use separate branches for feature development and
push them to my public repo for other developers to review and test.  I
keep my feature branches rebased against the head of the development
branch so they merge cleanly.

> 
>> On 30 Jan 2018, at 23:34, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> This is dependent on the size of the change.  If it's small change,
>> patches are fine.  If it's a very large change, then I prefer that you
>> create a public repo on launchpad so I can clone it locally to review
>> and test it.  You have to use your best judgment on this.
>>
>> It's important to get input from the developer list before you spend too
>> much time coding to avoid wasting time.
>>
>> I am considering using launchpad blueprints for new feature development.
>> Unfortunately I haven't figured out a way to restrict changes to the
>> blueprints so it a bit of a mess right now.  One nice thing with
>> blueprints is that we can collaborate on determining the feature design
>> without using email.  We can also link the blueprint to a development
>> series.  Until I figure out how to limit access to the blueprint
>> database I am a bit hesitant to go this route.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 01/30/2018 04:23 PM, Jeff Young wrote:
>>> If we implement a feature or an improvement to a feature, does it need an issue, or do we just send patches to the dev-list?
>>>
>>> (Obviously this is for 6.0, so I’m just trying to understand the process.)
>>>
>>> Thanks,
>>> Jeff.
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>