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:
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
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
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,
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
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,
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
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
...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.
>>
>>
+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
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
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
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
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
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
+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
>
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,
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
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
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
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
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
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
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
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
25 matches
Mail list logo
