[Kopete-devel] Post 3.2 Kopete and packagers

[Lauri Watts]

On Tuesday 25 November 2003 22.14, Martijn Klingens wrote:
> On Tuesday 25 November 2003 21:40, Jason Keirstead wrote:
> > Being part of the release cycle is *better* for features. You get a
> > longer time period to implement and test new features properly, and get
> > proper planning of what features are needed via release schedules so you
> > can properly focus your time.
>
> Sure, we could (and probably should) have a release cycle for Kopete as
> well. Until now we didn't really have a release _cycle_, we just
> implemented stuff and when the new stuff was considered finished we began
> evaluating a new release. And while having a more formal Kopete release
> cycle is a good thing, how is it better to use the KDE release cycle rather
> than having our own at twice the rate? As long as you have a cycle in the
> first place it's ok.

Martijn, it boils down to this:

Some of us package the modules as they are released (one released tarball from 
KDE == one package from us)  Please don't start an argument over the relative 
benefits of this, that's not the point, the point is *that is how it is done* 
and there's not a distribution or OS out there that will change their 
packaging policy to suit Kopete.

For those of us who do this, if you plan to make interim releases that leaves 
us these choices:

1: We will disable kopete from kdenetwork, and keep the existing standalone 
packages.

2: We will ignore interim releases, and release only updates to kdenetwork as 
a whole.

3: We package both, but have them conflict with each other, so they can't be 
installed at the same time.

4: One of our developers might backport such updates into the current -STABLE 
branch as patches.

Historically, on FreeBSD we have taken option 2, because interim releases for 
apps have amounted to 'CVS Snapshots' or 'previews' and not actual increase 
in version releases.  I could give you a run down of the pros and cons of 
each, but they should be fairly obvious (think, POLA, and having users 
download large tarballs that aren't needed.)

If the interim releases were security releases, we would seriously consider 
them.  However, security fixes are traditionally backported into the stable 
branch, and re-packaging a module is not a big deal.  Serious bug fixes, 
again, might be worth considering, but again, these are traditionally 
backported into the -STABLE branch.  Of course, we could choose option 4 (and 
have done so in the past a few times) but if we can do it ourselves, why the 
objection to *you* doing it, so everyone can benefit easily?  Option 3 is a 
last resort, and just problematic in so many ways, I only add it here for 
completeness.  I personally consider protocol updates to be a special case of 
a big bugfix, that's probably up for debate though.

Special cases:
KDEPim is possibly planning an interim release, but, since it will be the 
whole module, it's not a big problem for us to deal with, and it seems to be 
a one time only occurrence.  Quanta also does out-of-schedule releases, as 
has KDevelop, but those are entire modules to themselves, and again, this 
isn't such a problem.  

KStars and KBabel are examples of single applications that are part of a 
larger module, and have made interim releases - *FreeBSD does not package 
these* and will not be starting.  We have, occasionally, made packages of 
them available for savvy users to download, but they are not official and not 
released into FreeBSD the way official ones are.  

In the end, you guys can do what you like, we can't stop you.  Just like you 
have no influence over our packaging policies, and shoving interim releases 
out the door "because we added a lot of stuff" is not going to influence us 
into actually adding it to our distribution.

Regards,
-- 
Lauri Watts
KDE Documentation: http://i18n.kde.org/doc/
KDE on FreeBSD: http://freebsd.kde.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031125/4217384d/attachment.sig>