kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature