Early Branch.

[Sebastian Kügler]

Hi Volker, *,

On Friday 21 May 2010 11:10:55 Volker Krause wrote:
> On Friday 21 May 2010 01:05:00 Sebastian Kügler wrote:
> > 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 don't think it's an ideal situation, but I trust you guys to do the right thing and 
to be diligent enough to not cause havoc and not endanger a stable release of our 
beloved KMail "as soon as possible after 4.5.0".

> > 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.

Sure, nobody expects you guys to stop working, but during freezes, this should happen 
in a branch. Luckily, this all will become a lot easier once we've moved to Git. 
(Which of course is one of the reasons to migrate in the first place.)

> 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 think it's fine to delay the freeze when such a sprint happens right after a 
freeze, but after that, the freeze needs to take effect, and it needs to be in trunk, 
since that's what people are testing and stabilizing for the release.

> > 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.

Thanks for understanding the concerns! I hope it doesn't create too much extra work 
for you guys.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9