[Kde-pim] Re: Opening kdepim master for feature commits, branching kdepim 4.6

Allen Winter winter at kde.org
Thu Apr 21 22:32:27 BST 2011


On Thursday 21 April 2011 11:46:29 AM David Jarvie wrote:
> On Thu, April 21, 2011 4:27 pm, Kevin Krammer wrote:
> > On Thursday, 2011-04-21, David Jarvie wrote:
> >> The hard feature freeze for KDE 4.7 is now only 3 weeks away, but as far
> >> as I understand, kdepim master is still frozen pending a kdepim 4.6
> >> release. If it is still intended to issue kdepim 4.6, kdepim needs to be
> >> branched very soon so that master can be opened up for feature commits
> >> before the 4.7 deadline runs out.
> >
> > Since we are out of sync with the rest of KDE anyway, I don't think the
> > common release cycle dates apply to use in any meaningful way.
> >
> > But since the topic of branching came up:
> >
> > do we want to continue to do feature development in master?
> > or more precisely in the branch we release from?
> >
> > Given how separated our components become once this transition is finally
> > done
> > (e.g. KOrganizer no longer depending on KMail for Kolab access), we might
> > want
> > to consider a strategy more like the Linux kernel's staging branches and
> > merge windows.
> >
> > I.e. so that we can always release on time because we don't merge anything
> > that hasn't reached RC status yet.
> 
> This could be the way to go forward.
> 
> Kdepim has now been frozen for 5 months for new features. This is really
> not satisfactory - we need a kdepim branch where new features can be
> committed, and if kdepim is to continue to diverge from the KDE release
> schedule, we also need a separate, published, kdepim release schedule for
> feature freezes.
> 
> KAlarm will have some new features ready in time for the KDE 4.7 release
> date. Apart from its Akonadi conversion (which is unlikely to be ready
> earlier), there will be some other new features and new strings which, at
> the rate things are going, could be in kdepim 4.6 or 4.7. But until the
> freeze is lifted, I can't commit them to any kdepim branch.
> 

What about the following:
- branch kdepim4/.6 and kdepim-runtime/4.6
- open kdepim/master and kdepim-runtime/master for new features, strings, etc
- bug fixes are backported to the 4.6 branches

i.e. the normal situation.

If/when we make a KDEPIM4.6 release, I will use the 4.6 branches.  no problem at all.

I just need to coordinate with the translators if we want to do this.

Any objections?

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list