Early Branch.

[Volker Krause]

On Friday 21 May 2010 01:05:00 Sebastian Kügler wrote:
> Hey,
>
> On Thu May 20 2010 19:11:38 Tom Albers wrote:
> > The KDEPIM whishes to branch early, as there are lots of development in
> > KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I
> > suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM
> > releases will come from that 4.5 branch. Feature development can then
> > continue in trunk.
>
> Why not create a work branch for the feature development?
>
> I'm actually not too happy with individual modules branching off for
> bugfixing and using trunk for feature development. We have a freeze for a
> reason (common rythm of development, reaching acceptable level of quality),
> and if we need to explain SVN users which trunk branches are frozen, which
> ones are open for features, and which ones should get the bugfixes, we're
> making things *really* complicated, as policies are KDE SC-wide, not only
> apply to a subset of the modules within it. I get it that feature
> development in trunk is easier, but the main focus is getting our current
> trunk release ready. That holds true for other modules as well, and it
> requires a bit of discipline from all or us. Opening up parts of trunk for
> feature development just sends out the wrong message, and I fear it might
> have negative effect on the quality of the upcoming release. We're in
> release mode now, and it's not like that should come as a surprise to
> anyone.
> I'm not convinced we should open up trunk for development on features we're
> not even planning to release inside KDE SC now (i.e. akonadi / kmail
> mobile).
>
> Also, asking for delaying the PIM release because there's not enough time
> to get it to an acceptable level of quality in time for 4.5.0, and at the
> same time requesting opening trunk for new features is a bit odd. 

There are two things happening in KDE PIM right now, stabilizing the desktop 
applications and completing their port to Akonadi and the development of the 
KDE PIM mobile applications. Since the latter share the vast majority or 
their code with the desktop applications, most work done here directly 
benefits the desktop as well.

> I do know 
> the business background here, but I would highly appreciate if KDE
> schedules were taken into account as well.

We (KDAB/Intevation) not only take them into account, but also take them very 
seriously. However, we cannot just stop working on features if KDE freezes 
since our deadlines unfortunately don't align perfectly. So, we will do that 
work in a branch in the meantime, like we always have in the past.

When hearing about EDU branching early for 4.5 we (KDE PIM) decided to follow 
that scheme during the meeting last week since it simplifies the branch 
maintenance considerably and doesn't mess up svn history that much.

If it now turns out that this approach is not supported by KDE then we will of 
course go back to the old one using a development branch. In fact, that's 
what we will do until this discussion is resolved.

> I get it that lots of stuff is happening in PIM, and I'm really happy about
> that, but we need to keep things sane for others as well, and maintain a
> leveled community.
>
> > Any objections to this request? If not, Dirk, can you set that up?
>
> I'd like to find a better solution for the above problems.

We (KDAB/Intevation) have a intermediate deadline for the kdepim mobile work 
next week Wednesday, so we will go with the work branch until then and 
hopefully the situation will be resolved by then and I'll adapt our workflow 
to whatever is decided here.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20100521/da13e65f/attachment.sig