Re: [Kicad-developers] Branches

[Simon Richter]

Hi,

On 25.07.2018 18:00, Wayne Stambaugh wrote:

> The 5.1 branch will go away.  I just haven't gotten around to it.

Even better.

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Wayne Stambaugh]

I thought I made it clear what the current branches were for but I will
officially reiterate my previous comments.

The development branch is currently only open for 5.1 development.  This
includes 5.0 bug fixes, Jeff's UI refactoring, and the GTK3 fixes.  No
new features will be allowed until 5.1 is released.  I want to stay
focused on 5.1 to get the gtk3 fix release asap.  My fear is that if I
open the dev branch up to new features, we will get caught up in that
and forget about the gtk3 fix.

The 5.1 branch will go away.  I just haven't gotten around to it.

The only thing left to do is figure out the branch naming issue.
Apparently we cannot come up with a branch naming convention that
doesn't cause everyone to run out of the room with their hair on fire. :)

If anyone asks again what the official policy is, please point them to
this message.

Cheers,

Wayne

On 7/25/2018 8:45 AM, Simon Richter wrote:
> Hi,
> 
> On 24.07.2018 09:01, Maciej Sumiński wrote:
> 
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
> 
> As it should be. Well, ideally commits on 5.1 should be cherry-picked
> from master by the 5.1 release manager.
> 
> Do we have a release manager for 5.1? Or a scope for the release?
> 
> My suggestion:
> 
>  - 5.1: gtk3 (because that is what distros are waiting for)
>  - 5.2: UI updates (after 5.1 because they need user feedback and
> documentation updates)
> 
>Simon



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Simon Richter]

Hi,

On 24.07.2018 09:01, Maciej Sumiński wrote:

> At the moment the master branch contains all commits from 5.1 and a few
> more. It might be the right moment to drop 5.1 branch.

As it should be. Well, ideally commits on 5.1 should be cherry-picked
from master by the 5.1 release manager.

Do we have a release manager for 5.1? Or a scope for the release?

My suggestion:

 - 5.1: gtk3 (because that is what distros are waiting for)
 - 5.2: UI updates (after 5.1 because they need user feedback and
documentation updates)

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Carsten Schoenert]

Am 25.07.18 um 17:40 schrieb Maciej Sumiński:
> Nobody forbids working on new features in separate branches that we will
> start merging once 5.1 is released and 6.0 development cycle starts. I
> have already started a few branches for v6 features, but they need to
> wait now.

That's what I mean, why I need to wait? In recent days this is for me a
mismanagement and such things are mostly not needed. Those are feature
branches made for so people can continue on their work continuously. You
will need to merge the related changes into the other branches.

Remember the link to the website I made, it show this nicely.

https://nvie.com/posts/a-successful-git-branching-model/

> I simply rebase them from time to time, but it is not a big deal so
> far.
This will get annoying and frustrating the more often you need to do
this. It may be not a big deal for you as a core developer because you
know mostly every detail in the source, but for people from outside it's
unneeded load to do such rebasing again and again. I've done this for
thunderbird for about a half year before I was going further. This was
really frustrating.

> I anticipate GTK3 fixes to be ready in 1-2 months from now,
> I am not sure if the delay is significant enough to keep this discussion
> going on.

This is a decision you have to make. For me GTK fixes are a thing you of
course will need to have also in later version so the typical solution
is to merge theses things into the current master branch. No need for
cherry-picking.

> We have already experienced a significant overhead in late v5 cycle due
> to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
> keep working on 5.1 and 6.0 at the same time.

I know such things from other projects, this is real life. Other
projects have people which are responsible for release management.

> I am sure we could right now dump enough code onto the 6.0 branch to
> diverge it from 5.1 so much that porting fixes between them becomes
> non trivial. Keep in mind that there is 5.0 branch that may need to
> share some patches with the remaining branches too. Please notice
> that *every* patch that we applied to 5.1 had to be applied to the
> master branch as well via cherry-picking.
You really wont do cherry-picking! Merging is the right thing here.
KiCad is not the Linux kernel or Gnome, but look how these projects are
working. Both need to take care about older releases too. And many other
projects also.
If you keep up the branches in the core in sync it isn't that difficult
to backport changes.

> What are the benefits of maintaining 3 branches?

Simply that every one can make progress without being slowed down due
some technical reasons? It's all about organization.

In the long run you will need at least two branches like before, so
currently you will need also 5.0 to provide urgent fixes before any
5.1.x release is made. It's not that much more I guess.

But again, it's up to you guys how you will organize your work, all from
me are just suggestions based on experiences I made in the last decade
while contributing to various projects. Let's stop here.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Maciej Sumiński]

On 07/25/2018 11:23 AM, Carsten Schoenert wrote:
> Hello Orson,
> 
> Am 25.07.18 um 15:53 schrieb Maciej Sumiński:
> ...
>> It has been discussed in this thread already, but I will repeat: the
>> main problem now is that we need to apply patches to both master and
>> 5.1.
> 
> thanks for clarifying (probably again).
> The question will come again and again, unless it's written down to a
> road map where it can be referenced to. I haven't found anything related
> to this on the website and I also haven't time to follow any thread in
> deep here on the ml which is more technical, but it's also interesting
> for me as the person who is doing the Debian packaging where the
> developing will move to and what are the plans for which release.
> 
> Why not discuss the goals which are targeted for 5.1.x (now mostly
> already happen) and make this public (as a blog post on the website
> e.g.)? This can be used later while developing to see how far the next
> release is. I think the current development isn't that transparent
> that's for sure not intended.

A blog post sounds like a good idea, I have noticed the current plan is
not very clear for everyone.

>> This is fairly easy now, as there are no new features in the master
>> branch yet, but if we merged all the feature branches then I think we
>> would spend too much time resolving conflicts. There is no point nor
>> manpower to develop two branches in parallel.
> 
> Sorry, I don't get this or I don't understand this really. If you say
> this you will also constrain the development to only work in serial mode
> like happen a decade ago while Subversion was a modern VCS and all needs
> mostly done in just one branch. I don't think this is wanted as this
> would mean you bothersome people who want to work on features for 6.x to
> delay their work. And this is normally the last thing you wanna do.
> That's part of the development projects needs to handle and deal with.
> Git gives the possibility to get this managed, the only thing you need
> to be clear is to know which branch needs to be merged into another.
> And, yes this needs manpower to handle releases, but this needs to be
> done anyway. To say there is no manpower would be a wrong thing to me,
> as this has will have a huge impact just later. As I tried to express in
> one of my previous emails I think it's important KiCad will get a better
> policy for development and also for release planning.
> 
> All above is just my personal view and I don't want to enforce the
> "real" developers to do something exactly in this way. The developers
> are deciding what to do and how, so I don't want to bother any of you.

Nobody forbids working on new features in separate branches that we will
start merging once 5.1 is released and 6.0 development cycle starts. I
have already started a few branches for v6 features, but they need to
wait now. I simply rebase them from time to time, but it is not a big
deal so far. I anticipate GTK3 fixes to be ready in 1-2 months from now,
I am not sure if the delay is significant enough to keep this discussion
going on.

We have already experienced a significant overhead in late v5 cycle due
to porting certain v4 fixes to v5 branch or vice versa. Imagine that we
keep working on 5.1 and 6.0 at the same time. I am sure we could right
now dump enough code onto the 6.0 branch to diverge it from 5.1 so much
that porting fixes between them becomes non trivial. Keep in mind that
there is 5.0 branch that may need to share some patches with the
remaining branches too. Please notice that *every* patch that we applied
to 5.1 had to be applied to the master branch as well via
cherry-picking. What are the benefits of maintaining 3 branches?

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Carsten Schoenert]

Hello Orson,

Am 25.07.18 um 15:53 schrieb Maciej Sumiński:
...
> It has been discussed in this thread already, but I will repeat: the
> main problem now is that we need to apply patches to both master and
> 5.1.

thanks for clarifying (probably again).
The question will come again and again, unless it's written down to a
road map where it can be referenced to. I haven't found anything related
to this on the website and I also haven't time to follow any thread in
deep here on the ml which is more technical, but it's also interesting
for me as the person who is doing the Debian packaging where the
developing will move to and what are the plans for which release.

Why not discuss the goals which are targeted for 5.1.x (now mostly
already happen) and make this public (as a blog post on the website
e.g.)? This can be used later while developing to see how far the next
release is. I think the current development isn't that transparent
that's for sure not intended.

> This is fairly easy now, as there are no new features in the master
> branch yet, but if we merged all the feature branches then I think we
> would spend too much time resolving conflicts. There is no point nor
> manpower to develop two branches in parallel.

Sorry, I don't get this or I don't understand this really. If you say
this you will also constrain the development to only work in serial mode
like happen a decade ago while Subversion was a modern VCS and all needs
mostly done in just one branch. I don't think this is wanted as this
would mean you bothersome people who want to work on features for 6.x to
delay their work. And this is normally the last thing you wanna do.
That's part of the development projects needs to handle and deal with.
Git gives the possibility to get this managed, the only thing you need
to be clear is to know which branch needs to be merged into another.
And, yes this needs manpower to handle releases, but this needs to be
done anyway. To say there is no manpower would be a wrong thing to me,
as this has will have a huge impact just later. As I tried to express in
one of my previous emails I think it's important KiCad will get a better
policy for development and also for release planning.

All above is just my personal view and I don't want to enforce the
"real" developers to do something exactly in this way. The developers
are deciding what to do and how, so I don't want to bother any of you.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Maciej Sumiński]

On 07/25/2018 04:28 AM, Carsten Schoenert wrote:
> Am 24.07.18 um 15:01 schrieb Maciej Sumiński:
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
> 
> This depends on the achievements which are desired or wanted in my eyes.
> 
> The branch 5.1 was created to work on the planned releases 5.1.x, right?
> Dropping this branch would mean all further work would done only in the
> master branch. I'm not sure this is really wanted as it's need to be
> ensured that all releases are backwards compatible to the current 5.0.0
> release without breaking potential work done from people targeted post
> 5.x. KiCad will need some kine of release managing in the near future I
> guess.
> 
> It seem to me that there are at least some potential confusion exists
> about the intention of feature branches, nothing more are the existing
> branches 5.1 and master.
> 
> But as long there is no agreement what should happen to which release it
> will be messy all the time. Is this somewhere documented what will
> happen to 5.1 especially?

There is no document regarding 5.1 goals, as I think it is too brief to
make it formal: wxGTK3 fix is the main goal, minor UI improvements and
bugfixes are acceptable, no new features in 5.1. We want to push it out
as soon as possible so we can move on with 6.x.

It has been discussed in this thread already, but I will repeat: the
main problem now is that we need to apply patches to both master and
5.1. This is fairly easy now, as there are no new features in the master
branch yet, but if we merged all the feature branches then I think we
would spend too much time resolving conflicts. There is no point nor
manpower to develop two branches in parallel.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Carsten Schoenert]

Am 24.07.18 um 15:01 schrieb Maciej Sumiński:
> At the moment the master branch contains all commits from 5.1 and a few
> more. It might be the right moment to drop 5.1 branch.

This depends on the achievements which are desired or wanted in my eyes.

The branch 5.1 was created to work on the planned releases 5.1.x, right?
Dropping this branch would mean all further work would done only in the
master branch. I'm not sure this is really wanted as it's need to be
ensured that all releases are backwards compatible to the current 5.0.0
release without breaking potential work done from people targeted post
5.x. KiCad will need some kine of release managing in the near future I
guess.

It seem to me that there are at least some potential confusion exists
about the intention of feature branches, nothing more are the existing
branches 5.1 and master.

But as long there is no agreement what should happen to which release it
will be messy all the time. Is this somewhere documented what will
happen to 5.1 especially?

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Maciej Sumiński]

...and also rename it to 5.1-dev (no rc yet).

On 07/24/2018 09:47 AM, Jeff Young wrote:
> +1
> 
>> On 24 Jul 2018, at 08:01, Maciej Sumiński  wrote:
>>
>> At the moment the master branch contains all commits from 5.1 and a few
>> more. It might be the right moment to drop 5.1 branch.
>>
>> Cheers,
>> Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Jeff Young]

+1

> On 24 Jul 2018, at 08:01, Maciej Sumiński  wrote:
> 
> At the moment the master branch contains all commits from 5.1 and a few
> more. It might be the right moment to drop 5.1 branch.
> 
> Cheers,
> Orson
> 
> On 07/20/2018 11:14 AM, Maciej Sumiński wrote:
>> We already have slightly diverged the branches, I think it shows that it
>> is hard to maintain two branches with cherry-picking. Details below:
>> 
>> Commits present in master, but not in 5.1:
>> commit c585964da98269db2cabf06daafb0b11cae3a4ec
>>fix coding style issues.
>> 
>> commit 840ad7f68053d000dc6d46661d05d9d4be074704
>>Add SH_ARC collisions
>> 
>> commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
>>Fix bug with duplicate columns in Edit Symbol Fields.
>> 
>> 
>> Commits present in 5.1, but not in master:
>> commit 42deb68575a5a415b0970be4a89676f1986fa196
>>Eeschema: minor fix in edit label dialog (incorrect unit value )
>> 
>> On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
>>> This was pretty much how I saw the development working which is why I
>>> created a separate 5.1 branch.  However, if we are not going to allow
>>> new features to be merged into the master branch (6.0-dev) (and it seems
>>> that is the consensus) then I propose that we do all of the 5.1
>>> development in the master branch.  I would rather not delete the 5.1
>>> branch because the tags and version strings are already in place and
>>> reverting all the changes thus far would be painful.  Assuming 5.1 and
>>> master are currently the same, we can either merge from master to 5.1 as
>>> we go or one big merge when we are ready to start creating 5.1 release
>>> candidates.  I would prefer that we merge as we go which will keep the
>>> two branches synced an minimize issues.  Is this acceptable to everyone?
>>> 
>>> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
 Hi,
 
 for me as a person which doesn't do any active source code development
 on KiCad it looks like there is some confusion in the wild what will or
 should happen in which branch.
 
 Sorry if I haven't get it until now, what are the goals of the branch
 5.1 the project wanted to archive?
 
 And what is 6.0, master or $(what else) are for?
 
 If these questions can be answered it will be much more clear what
 development should happen in which branch and what should be merged into
 which other branch.
 
 KiCad has now more active developers than ever I think, but I can't
 really see a branch model that is fitting the current and future
 situations. Out there are various branching models and the KiCad project
 needs to decide which will work best for the project. The classical
 master plus release branches isn't working great anymore if you want to
 work on multiple parts in parallel.
 
 I suggest to have a look at the following website.
 
 https://nvie.com/posts/a-successful-git-branching-model/
 
 It describes what options are count and how a workflow would look like,
 I think it would be also usable for KiCad (not in a full blown version).
 
 In the long term you wont do cherry-picking for the plain development as
 this wont work smoothly at one point anymore (as Wayne already
 mentioned). Single cherry-picking is fine, but in the end you will come
 to merge commits as you mostly want to have all the new code in a later
 release. Every upstream project I know is working this way.
 
 Backporting security or hot fixes are slightly different and require
 often cherry-picking with small or much modifications as you wont
 introduce new features into old code by merges. But also this can be
 done in a local feature branch which gets merged then into the stable
 release branch. Depends mostly on the amount of the needed backport.
 
 So to call it again, what is the branch 5.1 intended for? Only for the
 GTK+3 fixes? If yes it's fine to do it here and merged these changes
 (which will be needed also in the current ongoing nightly development)
 into master, develop, 6.0 or what ever named branch. Just renaming
 master into something different without a common and required workflow
 is nothing, then it's really just another name.
 
 So I would propose the following as there are already some branches out
 there which we all need to know and to handle.
 
 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
 will mostly get cherry-picked from master. Hopefully not that much.
 
 5.1 will get at least the GTK+3 adjustments and will finally cover all
 versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
 branch and will be merged into master. Any other changes than GTK+3
 which should be released with versions 5.1.x are also made here and get
 merged into master.
 
 master is and will be the main nightly development channel. 

Re: [Kicad-developers] Branches

[Maciej Sumiński]

At the moment the master branch contains all commits from 5.1 and a few
more. It might be the right moment to drop 5.1 branch.

Cheers,
Orson

On 07/20/2018 11:14 AM, Maciej Sumiński wrote:
> We already have slightly diverged the branches, I think it shows that it
> is hard to maintain two branches with cherry-picking. Details below:
> 
> Commits present in master, but not in 5.1:
> commit c585964da98269db2cabf06daafb0b11cae3a4ec
> fix coding style issues.
> 
> commit 840ad7f68053d000dc6d46661d05d9d4be074704
> Add SH_ARC collisions
> 
> commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
> Fix bug with duplicate columns in Edit Symbol Fields.
> 
> 
> Commits present in 5.1, but not in master:
> commit 42deb68575a5a415b0970be4a89676f1986fa196
> Eeschema: minor fix in edit label dialog (incorrect unit value )
> 
> On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
>> This was pretty much how I saw the development working which is why I
>> created a separate 5.1 branch.  However, if we are not going to allow
>> new features to be merged into the master branch (6.0-dev) (and it seems
>> that is the consensus) then I propose that we do all of the 5.1
>> development in the master branch.  I would rather not delete the 5.1
>> branch because the tags and version strings are already in place and
>> reverting all the changes thus far would be painful.  Assuming 5.1 and
>> master are currently the same, we can either merge from master to 5.1 as
>> we go or one big merge when we are ready to start creating 5.1 release
>> candidates.  I would prefer that we merge as we go which will keep the
>> two branches synced an minimize issues.  Is this acceptable to everyone?
>>
>> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
>>> Hi,
>>>
>>> for me as a person which doesn't do any active source code development
>>> on KiCad it looks like there is some confusion in the wild what will or
>>> should happen in which branch.
>>>
>>> Sorry if I haven't get it until now, what are the goals of the branch
>>> 5.1 the project wanted to archive?
>>>
>>> And what is 6.0, master or $(what else) are for?
>>>
>>> If these questions can be answered it will be much more clear what
>>> development should happen in which branch and what should be merged into
>>> which other branch.
>>>
>>> KiCad has now more active developers than ever I think, but I can't
>>> really see a branch model that is fitting the current and future
>>> situations. Out there are various branching models and the KiCad project
>>> needs to decide which will work best for the project. The classical
>>> master plus release branches isn't working great anymore if you want to
>>> work on multiple parts in parallel.
>>>
>>> I suggest to have a look at the following website.
>>>
>>> https://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> It describes what options are count and how a workflow would look like,
>>> I think it would be also usable for KiCad (not in a full blown version).
>>>
>>> In the long term you wont do cherry-picking for the plain development as
>>> this wont work smoothly at one point anymore (as Wayne already
>>> mentioned). Single cherry-picking is fine, but in the end you will come
>>> to merge commits as you mostly want to have all the new code in a later
>>> release. Every upstream project I know is working this way.
>>>
>>> Backporting security or hot fixes are slightly different and require
>>> often cherry-picking with small or much modifications as you wont
>>> introduce new features into old code by merges. But also this can be
>>> done in a local feature branch which gets merged then into the stable
>>> release branch. Depends mostly on the amount of the needed backport.
>>>
>>> So to call it again, what is the branch 5.1 intended for? Only for the
>>> GTK+3 fixes? If yes it's fine to do it here and merged these changes
>>> (which will be needed also in the current ongoing nightly development)
>>> into master, develop, 6.0 or what ever named branch. Just renaming
>>> master into something different without a common and required workflow
>>> is nothing, then it's really just another name.
>>>
>>> So I would propose the following as there are already some branches out
>>> there which we all need to know and to handle.
>>>
>>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
>>> will mostly get cherry-picked from master. Hopefully not that much.
>>>
>>> 5.1 will get at least the GTK+3 adjustments and will finally cover all
>>> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
>>> branch and will be merged into master. Any other changes than GTK+3
>>> which should be released with versions 5.1.x are also made here and get
>>> merged into master.
>>>
>>> master is and will be the main nightly development channel. All changes
>>> here are mainly for any releases greater than 5.x.x.
>>>
>>> This all are just my thoughts as I would like to see it, the above
>>> suggestion is based on some 

Re: [Kicad-developers] Branches

[Jeff Young]

The 3rd one (duplicate columns in Edit Symbol fields) is mine.  I’ll get it 
merged.

Cheers,
Jeff.


> On 20 Jul 2018, at 10:14, Maciej Sumiński  wrote:
> 
> We already have slightly diverged the branches, I think it shows that it
> is hard to maintain two branches with cherry-picking. Details below:
> 
> Commits present in master, but not in 5.1:
> commit c585964da98269db2cabf06daafb0b11cae3a4ec
>fix coding style issues.
> 
> commit 840ad7f68053d000dc6d46661d05d9d4be074704
>Add SH_ARC collisions
> 
> commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
>Fix bug with duplicate columns in Edit Symbol Fields.
> 
> 
> Commits present in 5.1, but not in master:
> commit 42deb68575a5a415b0970be4a89676f1986fa196
>Eeschema: minor fix in edit label dialog (incorrect unit value )
> 
> On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
>> This was pretty much how I saw the development working which is why I
>> created a separate 5.1 branch.  However, if we are not going to allow
>> new features to be merged into the master branch (6.0-dev) (and it seems
>> that is the consensus) then I propose that we do all of the 5.1
>> development in the master branch.  I would rather not delete the 5.1
>> branch because the tags and version strings are already in place and
>> reverting all the changes thus far would be painful.  Assuming 5.1 and
>> master are currently the same, we can either merge from master to 5.1 as
>> we go or one big merge when we are ready to start creating 5.1 release
>> candidates.  I would prefer that we merge as we go which will keep the
>> two branches synced an minimize issues.  Is this acceptable to everyone?
>> 
>> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
>>> Hi,
>>> 
>>> for me as a person which doesn't do any active source code development
>>> on KiCad it looks like there is some confusion in the wild what will or
>>> should happen in which branch.
>>> 
>>> Sorry if I haven't get it until now, what are the goals of the branch
>>> 5.1 the project wanted to archive?
>>> 
>>> And what is 6.0, master or $(what else) are for?
>>> 
>>> If these questions can be answered it will be much more clear what
>>> development should happen in which branch and what should be merged into
>>> which other branch.
>>> 
>>> KiCad has now more active developers than ever I think, but I can't
>>> really see a branch model that is fitting the current and future
>>> situations. Out there are various branching models and the KiCad project
>>> needs to decide which will work best for the project. The classical
>>> master plus release branches isn't working great anymore if you want to
>>> work on multiple parts in parallel.
>>> 
>>> I suggest to have a look at the following website.
>>> 
>>> https://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> It describes what options are count and how a workflow would look like,
>>> I think it would be also usable for KiCad (not in a full blown version).
>>> 
>>> In the long term you wont do cherry-picking for the plain development as
>>> this wont work smoothly at one point anymore (as Wayne already
>>> mentioned). Single cherry-picking is fine, but in the end you will come
>>> to merge commits as you mostly want to have all the new code in a later
>>> release. Every upstream project I know is working this way.
>>> 
>>> Backporting security or hot fixes are slightly different and require
>>> often cherry-picking with small or much modifications as you wont
>>> introduce new features into old code by merges. But also this can be
>>> done in a local feature branch which gets merged then into the stable
>>> release branch. Depends mostly on the amount of the needed backport.
>>> 
>>> So to call it again, what is the branch 5.1 intended for? Only for the
>>> GTK+3 fixes? If yes it's fine to do it here and merged these changes
>>> (which will be needed also in the current ongoing nightly development)
>>> into master, develop, 6.0 or what ever named branch. Just renaming
>>> master into something different without a common and required workflow
>>> is nothing, then it's really just another name.
>>> 
>>> So I would propose the following as there are already some branches out
>>> there which we all need to know and to handle.
>>> 
>>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
>>> will mostly get cherry-picked from master. Hopefully not that much.
>>> 
>>> 5.1 will get at least the GTK+3 adjustments and will finally cover all
>>> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
>>> branch and will be merged into master. Any other changes than GTK+3
>>> which should be released with versions 5.1.x are also made here and get
>>> merged into master.
>>> 
>>> master is and will be the main nightly development channel. All changes
>>> here are mainly for any releases greater than 5.x.x.
>>> 
>>> This all are just my thoughts as I would like to see it, the above
>>> suggestion is based on some experiences I have made 

Re: [Kicad-developers] Branches

[Maciej Sumiński]

We already have slightly diverged the branches, I think it shows that it
is hard to maintain two branches with cherry-picking. Details below:

Commits present in master, but not in 5.1:
commit c585964da98269db2cabf06daafb0b11cae3a4ec
fix coding style issues.

commit 840ad7f68053d000dc6d46661d05d9d4be074704
Add SH_ARC collisions

commit 01c5bdfb8f49a84f2e5fae5c7fc5729a47c8ef0f
Fix bug with duplicate columns in Edit Symbol Fields.


Commits present in 5.1, but not in master:
commit 42deb68575a5a415b0970be4a89676f1986fa196
Eeschema: minor fix in edit label dialog (incorrect unit value )

On 07/19/2018 07:08 PM, Wayne Stambaugh wrote:
> This was pretty much how I saw the development working which is why I
> created a separate 5.1 branch.  However, if we are not going to allow
> new features to be merged into the master branch (6.0-dev) (and it seems
> that is the consensus) then I propose that we do all of the 5.1
> development in the master branch.  I would rather not delete the 5.1
> branch because the tags and version strings are already in place and
> reverting all the changes thus far would be painful.  Assuming 5.1 and
> master are currently the same, we can either merge from master to 5.1 as
> we go or one big merge when we are ready to start creating 5.1 release
> candidates.  I would prefer that we merge as we go which will keep the
> two branches synced an minimize issues.  Is this acceptable to everyone?
> 
> On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
>> Hi,
>>
>> for me as a person which doesn't do any active source code development
>> on KiCad it looks like there is some confusion in the wild what will or
>> should happen in which branch.
>>
>> Sorry if I haven't get it until now, what are the goals of the branch
>> 5.1 the project wanted to archive?
>>
>> And what is 6.0, master or $(what else) are for?
>>
>> If these questions can be answered it will be much more clear what
>> development should happen in which branch and what should be merged into
>> which other branch.
>>
>> KiCad has now more active developers than ever I think, but I can't
>> really see a branch model that is fitting the current and future
>> situations. Out there are various branching models and the KiCad project
>> needs to decide which will work best for the project. The classical
>> master plus release branches isn't working great anymore if you want to
>> work on multiple parts in parallel.
>>
>> I suggest to have a look at the following website.
>>
>> https://nvie.com/posts/a-successful-git-branching-model/
>>
>> It describes what options are count and how a workflow would look like,
>> I think it would be also usable for KiCad (not in a full blown version).
>>
>> In the long term you wont do cherry-picking for the plain development as
>> this wont work smoothly at one point anymore (as Wayne already
>> mentioned). Single cherry-picking is fine, but in the end you will come
>> to merge commits as you mostly want to have all the new code in a later
>> release. Every upstream project I know is working this way.
>>
>> Backporting security or hot fixes are slightly different and require
>> often cherry-picking with small or much modifications as you wont
>> introduce new features into old code by merges. But also this can be
>> done in a local feature branch which gets merged then into the stable
>> release branch. Depends mostly on the amount of the needed backport.
>>
>> So to call it again, what is the branch 5.1 intended for? Only for the
>> GTK+3 fixes? If yes it's fine to do it here and merged these changes
>> (which will be needed also in the current ongoing nightly development)
>> into master, develop, 6.0 or what ever named branch. Just renaming
>> master into something different without a common and required workflow
>> is nothing, then it's really just another name.
>>
>> So I would propose the following as there are already some branches out
>> there which we all need to know and to handle.
>>
>> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
>> will mostly get cherry-picked from master. Hopefully not that much.
>>
>> 5.1 will get at least the GTK+3 adjustments and will finally cover all
>> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
>> branch and will be merged into master. Any other changes than GTK+3
>> which should be released with versions 5.1.x are also made here and get
>> merged into master.
>>
>> master is and will be the main nightly development channel. All changes
>> here are mainly for any releases greater than 5.x.x.
>>
>> This all are just my thoughts as I would like to see it, the above
>> suggestion is based on some experiences I have made with other projects
>> and work. Please remember that also the l10n and documentation trees are
>> related to this! The base for all future work for all side needs to be
>> clear early as possible.
>>
>> Anyhow ...
>>
>> (Hmm, I don't wanted to a top posting but my answer wasn't 

Re: [Kicad-developers] Branches

[Wayne Stambaugh]

This was pretty much how I saw the development working which is why I
created a separate 5.1 branch.  However, if we are not going to allow
new features to be merged into the master branch (6.0-dev) (and it seems
that is the consensus) then I propose that we do all of the 5.1
development in the master branch.  I would rather not delete the 5.1
branch because the tags and version strings are already in place and
reverting all the changes thus far would be painful.  Assuming 5.1 and
master are currently the same, we can either merge from master to 5.1 as
we go or one big merge when we are ready to start creating 5.1 release
candidates.  I would prefer that we merge as we go which will keep the
two branches synced an minimize issues.  Is this acceptable to everyone?

On 7/19/2018 12:15 PM, Carsten Schoenert wrote:
> Hi,
> 
> for me as a person which doesn't do any active source code development
> on KiCad it looks like there is some confusion in the wild what will or
> should happen in which branch.
> 
> Sorry if I haven't get it until now, what are the goals of the branch
> 5.1 the project wanted to archive?
> 
> And what is 6.0, master or $(what else) are for?
> 
> If these questions can be answered it will be much more clear what
> development should happen in which branch and what should be merged into
> which other branch.
> 
> KiCad has now more active developers than ever I think, but I can't
> really see a branch model that is fitting the current and future
> situations. Out there are various branching models and the KiCad project
> needs to decide which will work best for the project. The classical
> master plus release branches isn't working great anymore if you want to
> work on multiple parts in parallel.
> 
> I suggest to have a look at the following website.
> 
> https://nvie.com/posts/a-successful-git-branching-model/
> 
> It describes what options are count and how a workflow would look like,
> I think it would be also usable for KiCad (not in a full blown version).
> 
> In the long term you wont do cherry-picking for the plain development as
> this wont work smoothly at one point anymore (as Wayne already
> mentioned). Single cherry-picking is fine, but in the end you will come
> to merge commits as you mostly want to have all the new code in a later
> release. Every upstream project I know is working this way.
> 
> Backporting security or hot fixes are slightly different and require
> often cherry-picking with small or much modifications as you wont
> introduce new features into old code by merges. But also this can be
> done in a local feature branch which gets merged then into the stable
> release branch. Depends mostly on the amount of the needed backport.
> 
> So to call it again, what is the branch 5.1 intended for? Only for the
> GTK+3 fixes? If yes it's fine to do it here and merged these changes
> (which will be needed also in the current ongoing nightly development)
> into master, develop, 6.0 or what ever named branch. Just renaming
> master into something different without a common and required workflow
> is nothing, then it's really just another name.
> 
> So I would propose the following as there are already some branches out
> there which we all need to know and to handle.
> 
> 5.0 will get all the fixes which will reflect in versions 5.0.x, commits
> will mostly get cherry-picked from master. Hopefully not that much.
> 
> 5.1 will get at least the GTK+3 adjustments and will finally cover all
> versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
> branch and will be merged into master. Any other changes than GTK+3
> which should be released with versions 5.1.x are also made here and get
> merged into master.
> 
> master is and will be the main nightly development channel. All changes
> here are mainly for any releases greater than 5.x.x.
> 
> This all are just my thoughts as I would like to see it, the above
> suggestion is based on some experiences I have made with other projects
> and work. Please remember that also the l10n and documentation trees are
> related to this! The base for all future work for all side needs to be
> clear early as possible.
> 
> Anyhow ...
> 
> (Hmm, I don't wanted to a top posting but my answer wasn't fitting to
> any made statement.)
> 
> Am 19.07.2018 um 17:19 schrieb Wayne Stambaugh:
>> You are preaching to the choir.  I did most of the maintenance on the
>> 4.0 branch.  Initially it was easy but it didn't take long for it to
>> become a PITA.  If no one else objects, I would be more than happy to
>> make that the policy.  If that is indeed what we want to do, I would
>> delete the 5.1 branch.  It will push v6 development back significantly.
>>
>> On 7/19/2018 11:10 AM, Jon Evans wrote:
>>> FWIW, as someone who is also maintaining parallel feature branches, I
>>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>>> we should just make it happen in master.  I think if we keep both master
>>> and 5.1 

Re: [Kicad-developers] Branches

[Carsten Schoenert]

Hi,

for me as a person which doesn't do any active source code development
on KiCad it looks like there is some confusion in the wild what will or
should happen in which branch.

Sorry if I haven't get it until now, what are the goals of the branch
5.1 the project wanted to archive?

And what is 6.0, master or $(what else) are for?

If these questions can be answered it will be much more clear what
development should happen in which branch and what should be merged into
which other branch.

KiCad has now more active developers than ever I think, but I can't
really see a branch model that is fitting the current and future
situations. Out there are various branching models and the KiCad project
needs to decide which will work best for the project. The classical
master plus release branches isn't working great anymore if you want to
work on multiple parts in parallel.

I suggest to have a look at the following website.

https://nvie.com/posts/a-successful-git-branching-model/

It describes what options are count and how a workflow would look like,
I think it would be also usable for KiCad (not in a full blown version).

In the long term you wont do cherry-picking for the plain development as
this wont work smoothly at one point anymore (as Wayne already
mentioned). Single cherry-picking is fine, but in the end you will come
to merge commits as you mostly want to have all the new code in a later
release. Every upstream project I know is working this way.

Backporting security or hot fixes are slightly different and require
often cherry-picking with small or much modifications as you wont
introduce new features into old code by merges. But also this can be
done in a local feature branch which gets merged then into the stable
release branch. Depends mostly on the amount of the needed backport.

So to call it again, what is the branch 5.1 intended for? Only for the
GTK+3 fixes? If yes it's fine to do it here and merged these changes
(which will be needed also in the current ongoing nightly development)
into master, develop, 6.0 or what ever named branch. Just renaming
master into something different without a common and required workflow
is nothing, then it's really just another name.

So I would propose the following as there are already some branches out
there which we all need to know and to handle.

5.0 will get all the fixes which will reflect in versions 5.0.x, commits
will mostly get cherry-picked from master. Hopefully not that much.

5.1 will get at least the GTK+3 adjustments and will finally cover all
versions 5.1.x (like 5.0 for 5.0.x). The GTK stuff is developed in this
branch and will be merged into master. Any other changes than GTK+3
which should be released with versions 5.1.x are also made here and get
merged into master.

master is and will be the main nightly development channel. All changes
here are mainly for any releases greater than 5.x.x.

This all are just my thoughts as I would like to see it, the above
suggestion is based on some experiences I have made with other projects
and work. Please remember that also the l10n and documentation trees are
related to this! The base for all future work for all side needs to be
clear early as possible.

Anyhow ...

(Hmm, I don't wanted to a top posting but my answer wasn't fitting to
any made statement.)

Am 19.07.2018 um 17:19 schrieb Wayne Stambaugh:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
>> FWIW, as someone who is also maintaining parallel feature branches, I
>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>> we should just make it happen in master.  I think if we keep both master
>> and 5.1 branch running in parallel, inevitably one or the other of them
>> will be less tested / more broken unless people spend a bunch of time
>> doing the work of keeping them synchronized manually.  The cost of this
>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>> features into master sooner.
>>
>> On Thu, Jul 19, 2018 at 11:03 AM John Beard > > wrote:
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>> > Unless we are going to prohibit new features (new file formats,
>> new tool
>> > framework for eeschema, etc.) from being merged into the dev branch
>> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
>> > the dev branch, then I'm OK with this proposal.
>>
>> This is essentially my proposal - limit dev branch changes to 5.1
>> features, uncontroversial maintenance and bugfixes.
>>
>> If people want to work on 

Re: [Kicad-developers] Branches

[Jeff Young]

+1

> On 19 Jul 2018, at 16:57, Seth Hillbrand  wrote:
> 
> I'd be in favor of this but if we're going to focus exclusively on v5.1 GTK3 
> migration, can we push the current state, warts and all to the master?  We 
> have a bunch of bugs tagged to 5.1 but only one is GTK3-related.  I suspect 
> we have a number of things to work on here but without bug assignment, we'll 
> be stepping on each other's toes.
> 
> -S
> 
> Am Do., 19. Juli 2018 um 08:35 Uhr schrieb Wayne Stambaugh 
> mailto:stambau...@gmail.com>>:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
> > FWIW, as someone who is also maintaining parallel feature branches, I
> > agree with Orson and John.  Now that we have committed to this 5.1 idea,
> > we should just make it happen in master.  I think if we keep both master
> > and 5.1 branch running in parallel, inevitably one or the other of them
> > will be less tested / more broken unless people spend a bunch of time
> > doing the work of keeping them synchronized manually.  The cost of this
> > doesn't seem to outweigh the benefit of being able to merge some 6.0
> > features into master sooner.
> > 
> > On Thu, Jul 19, 2018 at 11:03 AM John Beard  > 
> > >> wrote:
> > 
> > On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com> 
> > >> wrote:
> > > Unless we are going to prohibit new features (new file formats,
> > new tool
> > > framework for eeschema, etc.) from being merged into the dev branch
> > > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > > the dev branch, then I'm OK with this proposal.
> > 
> > This is essentially my proposal - limit dev branch changes to 5.1
> > features, uncontroversial maintenance and bugfixes.
> > 
> > If people want to work on features for 6 now, that can be done in
> > separate branches, and the onus for keeping it rebased onto the 5.1
> > changes is on them, rather than forcing the 5.1 workers to deal with
> > conflicts. Otherwise, whoever is working on 5.1 features like the
> > GTK3/GAL stuff and printing, will have to continually port their work
> > between the two branches.
> > 
> > If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> > changes, then perhaps this limitation is not useful.
> > 
> > > There should be nothing in the 5.1 branch that is not also in the dev
> > > branch so everything in the 5.1 branch should be tested in the dev
> > > branch builds.
> > 
> > In theory, yes, but if fixes need to be manually ported as the
> > branches diverge, it's possible to fail to fix, or break in new ways,
> > one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> > someone will have to take responsibility to ensure the appropriate
> > fixes are identified, ported and tested as needed. In the Linux world,
> > this is the unglamorous, arduous (and vital) job of the stable branch
> > maintainers.
> > 
> > I'm not against parallel branches if someone is willing to step up to
> > be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> > nice new stuff dropping into the dev branch. However, changes that
> > need to be in both branches are not trivially rebasable, that job will
> > soon become decidedly not-fun.
> > 
> > Cheers,
> > 
> > John
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> >  > >
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> >  > >
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> >  > >
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> > 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : 

Re: [Kicad-developers] Branches

[Seth Hillbrand]

I'd be in favor of this but if we're going to focus exclusively on v5.1
GTK3 migration, can we push the current state, warts and all to the
master?  We have a bunch of bugs tagged to 5.1 but only one is
GTK3-related.  I suspect we have a number of things to work on here but
without bug assignment, we'll be stepping on each other's toes.

-S

Am Do., 19. Juli 2018 um 08:35 Uhr schrieb Wayne Stambaugh <
stambau...@gmail.com>:

> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
>
> On 7/19/2018 11:10 AM, Jon Evans wrote:
> > FWIW, as someone who is also maintaining parallel feature branches, I
> > agree with Orson and John.  Now that we have committed to this 5.1 idea,
> > we should just make it happen in master.  I think if we keep both master
> > and 5.1 branch running in parallel, inevitably one or the other of them
> > will be less tested / more broken unless people spend a bunch of time
> > doing the work of keeping them synchronized manually.  The cost of this
> > doesn't seem to outweigh the benefit of being able to merge some 6.0
> > features into master sooner.
> >
> > On Thu, Jul 19, 2018 at 11:03 AM John Beard  > > wrote:
> >
> > On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > > Unless we are going to prohibit new features (new file formats,
> > new tool
> > > framework for eeschema, etc.) from being merged into the dev branch
> > > until 5.1 is released, I disagree.  If we want to only work on 5.1
> in
> > > the dev branch, then I'm OK with this proposal.
> >
> > This is essentially my proposal - limit dev branch changes to 5.1
> > features, uncontroversial maintenance and bugfixes.
> >
> > If people want to work on features for 6 now, that can be done in
> > separate branches, and the onus for keeping it rebased onto the 5.1
> > changes is on them, rather than forcing the 5.1 workers to deal with
> > conflicts. Otherwise, whoever is working on 5.1 features like the
> > GTK3/GAL stuff and printing, will have to continually port their work
> > between the two branches.
> >
> > If 5.1 changes are unlikely to be substantially affected by
> 6.0-facing
> > changes, then perhaps this limitation is not useful.
> >
> > > There should be nothing in the 5.1 branch that is not also in the
> dev
> > > branch so everything in the 5.1 branch should be tested in the dev
> > > branch builds.
> >
> > In theory, yes, but if fixes need to be manually ported as the
> > branches diverge, it's possible to fail to fix, or break in new ways,
> > one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> > someone will have to take responsibility to ensure the appropriate
> > fixes are identified, ported and tested as needed. In the Linux
> world,
> > this is the unglamorous, arduous (and vital) job of the stable branch
> > maintainers.
> >
> > I'm not against parallel branches if someone is willing to step up to
> > be a stable branch maintainer for 5.1. In fact, I'd be thrilled to
> get
> > nice new stuff dropping into the dev branch. However, changes that
> > need to be in both branches are not trivially rebasable, that job
> will
> > soon become decidedly not-fun.
> >
> > Cheers,
> >
> > John
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Jeff Young]

I’m fine with it either way (my stuff is currently equivalent between the two).

> On 19 Jul 2018, at 16:28, Maciej Sumiński  wrote:
> 
> It will be a huge motivation for us to fix GTK3 problems as soon as
> possible. I assume you mean to drop the current master branch (or rename
> to 6.0?) and make 5.1 the new master branch?
> 
> On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
>> You are preaching to the choir.  I did most of the maintenance on the
>> 4.0 branch.  Initially it was easy but it didn't take long for it to
>> become a PITA.  If no one else objects, I would be more than happy to
>> make that the policy.  If that is indeed what we want to do, I would
>> delete the 5.1 branch.  It will push v6 development back significantly.
>> 
>> On 7/19/2018 11:10 AM, Jon Evans wrote:
>>> FWIW, as someone who is also maintaining parallel feature branches, I
>>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>>> we should just make it happen in master.  I think if we keep both master
>>> and 5.1 branch running in parallel, inevitably one or the other of them
>>> will be less tested / more broken unless people spend a bunch of time
>>> doing the work of keeping them synchronized manually.  The cost of this
>>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>>> features into master sooner.
>>> 
>>> On Thu, Jul 19, 2018 at 11:03 AM John Beard >> > wrote:
>>> 
>>>On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>>>mailto:stambau...@gmail.com>> wrote:
 Unless we are going to prohibit new features (new file formats,
>>>new tool
 framework for eeschema, etc.) from being merged into the dev branch
 until 5.1 is released, I disagree.  If we want to only work on 5.1 in
 the dev branch, then I'm OK with this proposal.
>>> 
>>>This is essentially my proposal - limit dev branch changes to 5.1
>>>features, uncontroversial maintenance and bugfixes.
>>> 
>>>If people want to work on features for 6 now, that can be done in
>>>separate branches, and the onus for keeping it rebased onto the 5.1
>>>changes is on them, rather than forcing the 5.1 workers to deal with
>>>conflicts. Otherwise, whoever is working on 5.1 features like the
>>>GTK3/GAL stuff and printing, will have to continually port their work
>>>between the two branches.
>>> 
>>>If 5.1 changes are unlikely to be substantially affected by 6.0-facing
>>>changes, then perhaps this limitation is not useful.
>>> 
 There should be nothing in the 5.1 branch that is not also in the dev
 branch so everything in the 5.1 branch should be tested in the dev
 branch builds.
>>> 
>>>In theory, yes, but if fixes need to be manually ported as the
>>>branches diverge, it's possible to fail to fix, or break in new ways,
>>>one branch or the other. If a 5.1 branch exists in parallel to 6.0,
>>>someone will have to take responsibility to ensure the appropriate
>>>fixes are identified, ported and tested as needed. In the Linux world,
>>>this is the unglamorous, arduous (and vital) job of the stable branch
>>>maintainers.
>>> 
>>>I'm not against parallel branches if someone is willing to step up to
>>>be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
>>>nice new stuff dropping into the dev branch. However, changes that
>>>need to be in both branches are not trivially rebasable, that job will
>>>soon become decidedly not-fun.
>>> 
>>>Cheers,
>>> 
>>>John
>>> 
>>>___
>>>Mailing list: https://launchpad.net/~kicad-developers
>>>
>>>Post to : kicad-developers@lists.launchpad.net
>>>
>>>Unsubscribe : https://launchpad.net/~kicad-developers
>>>
>>>More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Maciej Sumiński]

It will be a huge motivation for us to fix GTK3 problems as soon as
possible. I assume you mean to drop the current master branch (or rename
to 6.0?) and make 5.1 the new master branch?

On 07/19/2018 05:19 PM, Wayne Stambaugh wrote:
> You are preaching to the choir.  I did most of the maintenance on the
> 4.0 branch.  Initially it was easy but it didn't take long for it to
> become a PITA.  If no one else objects, I would be more than happy to
> make that the policy.  If that is indeed what we want to do, I would
> delete the 5.1 branch.  It will push v6 development back significantly.
> 
> On 7/19/2018 11:10 AM, Jon Evans wrote:
>> FWIW, as someone who is also maintaining parallel feature branches, I
>> agree with Orson and John.  Now that we have committed to this 5.1 idea,
>> we should just make it happen in master.  I think if we keep both master
>> and 5.1 branch running in parallel, inevitably one or the other of them
>> will be less tested / more broken unless people spend a bunch of time
>> doing the work of keeping them synchronized manually.  The cost of this
>> doesn't seem to outweigh the benefit of being able to merge some 6.0
>> features into master sooner.
>>
>> On Thu, Jul 19, 2018 at 11:03 AM John Beard > > wrote:
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
>> mailto:stambau...@gmail.com>> wrote:
>> > Unless we are going to prohibit new features (new file formats,
>> new tool
>> > framework for eeschema, etc.) from being merged into the dev branch
>> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
>> > the dev branch, then I'm OK with this proposal.
>>
>> This is essentially my proposal - limit dev branch changes to 5.1
>> features, uncontroversial maintenance and bugfixes.
>>
>> If people want to work on features for 6 now, that can be done in
>> separate branches, and the onus for keeping it rebased onto the 5.1
>> changes is on them, rather than forcing the 5.1 workers to deal with
>> conflicts. Otherwise, whoever is working on 5.1 features like the
>> GTK3/GAL stuff and printing, will have to continually port their work
>> between the two branches.
>>
>> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
>> changes, then perhaps this limitation is not useful.
>>
>> > There should be nothing in the 5.1 branch that is not also in the dev
>> > branch so everything in the 5.1 branch should be tested in the dev
>> > branch builds.
>>
>> In theory, yes, but if fixes need to be manually ported as the
>> branches diverge, it's possible to fail to fix, or break in new ways,
>> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
>> someone will have to take responsibility to ensure the appropriate
>> fixes are identified, ported and tested as needed. In the Linux world,
>> this is the unglamorous, arduous (and vital) job of the stable branch
>> maintainers.
>>
>> I'm not against parallel branches if someone is willing to step up to
>> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
>> nice new stuff dropping into the dev branch. However, changes that
>> need to be in both branches are not trivially rebasable, that job will
>> soon become decidedly not-fun.
>>
>> Cheers,
>>
>> John
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 
>> Post to     : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> 
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Wayne Stambaugh]

You are preaching to the choir.  I did most of the maintenance on the
4.0 branch.  Initially it was easy but it didn't take long for it to
become a PITA.  If no one else objects, I would be more than happy to
make that the policy.  If that is indeed what we want to do, I would
delete the 5.1 branch.  It will push v6 development back significantly.

On 7/19/2018 11:10 AM, Jon Evans wrote:
> FWIW, as someone who is also maintaining parallel feature branches, I
> agree with Orson and John.  Now that we have committed to this 5.1 idea,
> we should just make it happen in master.  I think if we keep both master
> and 5.1 branch running in parallel, inevitably one or the other of them
> will be less tested / more broken unless people spend a bunch of time
> doing the work of keeping them synchronized manually.  The cost of this
> doesn't seem to outweigh the benefit of being able to merge some 6.0
> features into master sooner.
> 
> On Thu, Jul 19, 2018 at 11:03 AM John Beard  > wrote:
> 
> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > Unless we are going to prohibit new features (new file formats,
> new tool
> > framework for eeschema, etc.) from being merged into the dev branch
> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > the dev branch, then I'm OK with this proposal.
> 
> This is essentially my proposal - limit dev branch changes to 5.1
> features, uncontroversial maintenance and bugfixes.
> 
> If people want to work on features for 6 now, that can be done in
> separate branches, and the onus for keeping it rebased onto the 5.1
> changes is on them, rather than forcing the 5.1 workers to deal with
> conflicts. Otherwise, whoever is working on 5.1 features like the
> GTK3/GAL stuff and printing, will have to continually port their work
> between the two branches.
> 
> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> changes, then perhaps this limitation is not useful.
> 
> > There should be nothing in the 5.1 branch that is not also in the dev
> > branch so everything in the 5.1 branch should be tested in the dev
> > branch builds.
> 
> In theory, yes, but if fixes need to be manually ported as the
> branches diverge, it's possible to fail to fix, or break in new ways,
> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> someone will have to take responsibility to ensure the appropriate
> fixes are identified, ported and tested as needed. In the Linux world,
> this is the unglamorous, arduous (and vital) job of the stable branch
> maintainers.
> 
> I'm not against parallel branches if someone is willing to step up to
> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> nice new stuff dropping into the dev branch. However, changes that
> need to be in both branches are not trivially rebasable, that job will
> soon become decidedly not-fun.
> 
> Cheers,
> 
> John
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Jon Evans]

FWIW, as someone who is also maintaining parallel feature branches, I agree
with Orson and John.  Now that we have committed to this 5.1 idea, we
should just make it happen in master.  I think if we keep both master and
5.1 branch running in parallel, inevitably one or the other of them will be
less tested / more broken unless people spend a bunch of time doing the
work of keeping them synchronized manually.  The cost of this doesn't seem
to outweigh the benefit of being able to merge some 6.0 features into
master sooner.

On Thu, Jul 19, 2018 at 11:03 AM John Beard  wrote:

> On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh 
> wrote:
> > Unless we are going to prohibit new features (new file formats, new tool
> > framework for eeschema, etc.) from being merged into the dev branch
> > until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> > the dev branch, then I'm OK with this proposal.
>
> This is essentially my proposal - limit dev branch changes to 5.1
> features, uncontroversial maintenance and bugfixes.
>
> If people want to work on features for 6 now, that can be done in
> separate branches, and the onus for keeping it rebased onto the 5.1
> changes is on them, rather than forcing the 5.1 workers to deal with
> conflicts. Otherwise, whoever is working on 5.1 features like the
> GTK3/GAL stuff and printing, will have to continually port their work
> between the two branches.
>
> If 5.1 changes are unlikely to be substantially affected by 6.0-facing
> changes, then perhaps this limitation is not useful.
>
> > There should be nothing in the 5.1 branch that is not also in the dev
> > branch so everything in the 5.1 branch should be tested in the dev
> > branch builds.
>
> In theory, yes, but if fixes need to be manually ported as the
> branches diverge, it's possible to fail to fix, or break in new ways,
> one branch or the other. If a 5.1 branch exists in parallel to 6.0,
> someone will have to take responsibility to ensure the appropriate
> fixes are identified, ported and tested as needed. In the Linux world,
> this is the unglamorous, arduous (and vital) job of the stable branch
> maintainers.
>
> I'm not against parallel branches if someone is willing to step up to
> be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
> nice new stuff dropping into the dev branch. However, changes that
> need to be in both branches are not trivially rebasable, that job will
> soon become decidedly not-fun.
>
> Cheers,
>
> John
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[John Beard]

On Thu, Jul 19, 2018 at 1:47 PM, Wayne Stambaugh  wrote:
> Unless we are going to prohibit new features (new file formats, new tool
> framework for eeschema, etc.) from being merged into the dev branch
> until 5.1 is released, I disagree.  If we want to only work on 5.1 in
> the dev branch, then I'm OK with this proposal.

This is essentially my proposal - limit dev branch changes to 5.1
features, uncontroversial maintenance and bugfixes.

If people want to work on features for 6 now, that can be done in
separate branches, and the onus for keeping it rebased onto the 5.1
changes is on them, rather than forcing the 5.1 workers to deal with
conflicts. Otherwise, whoever is working on 5.1 features like the
GTK3/GAL stuff and printing, will have to continually port their work
between the two branches.

If 5.1 changes are unlikely to be substantially affected by 6.0-facing
changes, then perhaps this limitation is not useful.

> There should be nothing in the 5.1 branch that is not also in the dev
> branch so everything in the 5.1 branch should be tested in the dev
> branch builds.

In theory, yes, but if fixes need to be manually ported as the
branches diverge, it's possible to fail to fix, or break in new ways,
one branch or the other. If a 5.1 branch exists in parallel to 6.0,
someone will have to take responsibility to ensure the appropriate
fixes are identified, ported and tested as needed. In the Linux world,
this is the unglamorous, arduous (and vital) job of the stable branch
maintainers.

I'm not against parallel branches if someone is willing to step up to
be a stable branch maintainer for 5.1. In fact, I'd be thrilled to get
nice new stuff dropping into the dev branch. However, changes that
need to be in both branches are not trivially rebasable, that job will
soon become decidedly not-fun.

Cheers,

John

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[Wayne Stambaugh]

Unless we are going to prohibit new features (new file formats, new tool
framework for eeschema, etc.) from being merged into the dev branch
until 5.1 is released, I disagree.  If we want to only work on 5.1 in
the dev branch, then I'm OK with this proposal.

On 7/19/2018 8:39 AM, John Beard wrote:
> I agree with Orson. It's unfortunate for people to not be able to dump
> new features onto master after such a long freeze. However, if 5.1 and
> master/6-dev diverge, there will be a lot of pain in porting bugs,
> especially if one branch has work that very is invasive and touches a
> lot of code, and one does not.
> 
> Moreover, testing efforts will be split, with some people only on
> 5.1-dev and some only using master. This can easily allow bugs to slip
> by into one branch or the other.

There should be nothing in the 5.1 branch that is not also in the dev
branch so everything in the 5.1 branch should be tested in the dev
branch builds.

> 
> I think there should only be master, which is the 5.1-dev branch. When
> that splits to become a release, 6.0-dev can start.
> 
> Big features that don't suit 5.1 will just have to wait for the start
> of 6, being maintained in separate branches if necessary, either under
> the KiCad aegis in the main repo, or less formally in any other Git
> repo. A list of ongoing known dev branches somewhere would be helpful
> (eeschema GAL and Cairo printing being two I can think would be useful
> to document).
> 
> Of course, people with new features can always petition the project
> lead for permission to put stuff into 5.1! Otherwise, focussing on 5.1
> issues now will get both 5.1 done and out of the way sooner (important
> to fix Python), and also get us to the state where 6.0-dev can receive
> the full attention from devs, lead and interested users.
> 
> Cheers,
> 
> John
> 
> 
> On Thu, Jul 19, 2018 at 10:25 AM, Maciej Sumiński
>  wrote:
>> I wonder if there is a point in keeping 5.1 and master branches
>> separated. In 5.1 there is a lot of new code that will need patches, and
>> they need to be applied to both branches now. If we keep adding more
>> features to the master branch, then at one point the branch may diverge
>> significantly enough to make patch porting non trivial.
>>
>> What do you think about replacing the current master branch with 5.1?
>> This way we can focus on the wxGTK3 problem, fix issues that we discover
>> and once 5.1 is out - keep adding new features to 6.0-dev? For the time
>> being new features might be developed in private branches.
>>
>> BTW. I really like 5.1 UI improvements, good job Jeff!
>>
>> Cheers,
>> Orson
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Branches

[John Beard]

I agree with Orson. It's unfortunate for people to not be able to dump
new features onto master after such a long freeze. However, if 5.1 and
master/6-dev diverge, there will be a lot of pain in porting bugs,
especially if one branch has work that very is invasive and touches a
lot of code, and one does not.

Moreover, testing efforts will be split, with some people only on
5.1-dev and some only using master. This can easily allow bugs to slip
by into one branch or the other.

I think there should only be master, which is the 5.1-dev branch. When
that splits to become a release, 6.0-dev can start.

Big features that don't suit 5.1 will just have to wait for the start
of 6, being maintained in separate branches if necessary, either under
the KiCad aegis in the main repo, or less formally in any other Git
repo. A list of ongoing known dev branches somewhere would be helpful
(eeschema GAL and Cairo printing being two I can think would be useful
to document).

Of course, people with new features can always petition the project
lead for permission to put stuff into 5.1! Otherwise, focussing on 5.1
issues now will get both 5.1 done and out of the way sooner (important
to fix Python), and also get us to the state where 6.0-dev can receive
the full attention from devs, lead and interested users.

Cheers,

John


On Thu, Jul 19, 2018 at 10:25 AM, Maciej Sumiński
 wrote:
> I wonder if there is a point in keeping 5.1 and master branches
> separated. In 5.1 there is a lot of new code that will need patches, and
> they need to be applied to both branches now. If we keep adding more
> features to the master branch, then at one point the branch may diverge
> significantly enough to make patch porting non trivial.
>
> What do you think about replacing the current master branch with 5.1?
> This way we can focus on the wxGTK3 problem, fix issues that we discover
> and once 5.1 is out - keep adding new features to 6.0-dev? For the time
> being new features might be developed in private branches.
>
> BTW. I really like 5.1 UI improvements, good job Jeff!
>
> Cheers,
> Orson
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Branches

[Maciej Sumiński]

I wonder if there is a point in keeping 5.1 and master branches
separated. In 5.1 there is a lot of new code that will need patches, and
they need to be applied to both branches now. If we keep adding more
features to the master branch, then at one point the branch may diverge
significantly enough to make patch porting non trivial.

What do you think about replacing the current master branch with 5.1?
This way we can focus on the wxGTK3 problem, fix issues that we discover
and once 5.1 is out - keep adding new features to 6.0-dev? For the time
being new features might be developed in private branches.

BTW. I really like 5.1 UI improvements, good job Jeff!

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp