[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: 2.1.1 RELEASE SCHEDULE (proposal)
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-01 15:59:51
[Download RAW message or body]

On Thursday 01 March 2001 14:42, Christian A Strømmen [Number1/NumeroUno] wrote:
> On Thursday  1. March 2001 02:06, Waldo Bastian wrote:
> > Also unavailable from
> > http://developer.kde.org/development-versions/kde-2.1.1-release-plan.html
> >
> > KDE 2.1.1 Release Plan
> > ==================
> >
> > The following is the outline for our KDE 2.1.1 release schedule.
> >
> > The primary goals of the 2.1.1 release are:
> > * Critical bugfixes
> > * Completion of the translations in many languages
> > * Documentation for almost all applications
> > * Improvement of the icons (yes?)
> >
> > All dates given here are subject to revision, but we will try out best to
> > stick to them if possible.
> >
> > David Faure is acting as release coordinator for the KDE 2.1.1 and 2.2
> > releases
> >
> > Monday March 19
> > =============
> > Last day for translations, documentation, icons and critical bugfixes
> > commits to the KDE_2_1_BRANCH.
> >
> > Tuesday morning (GMT) March 20
> > =========================
> > The CVS is tagged KDE_2_1_1_RELEASE, tarballs are released to the packagers
> >
> > The rest of the week is spent testing the tarballs, packaging and writing
> > the announcement and changelog.
> 
> Is this such a good idea?  Why make tarballs for testing?  Couldn't we just 
> freeze the cvs for a couple of days (from Monday March 19), and then when we 
> feel it's tested enough we send it off to the packagers... ?
> 
> For every release now, the packages have had to be rebuilt, this is 
> unnecessary and frustrating work.  Let's try to avoid it this time...

Of course that the code is to be tested before being put in tarballs,
but the tarballs themselves always need to be "tested" a bit, even if
only in terms of compilation and packaging.

The real testing (and associated bugfixing) is obviously to be done BEFORE
the tagging & tarballing. You're right that "last day for committing" doesn't
really push people to freeze it though.... The problem is that as long as the
tagging hasn't been done, even saying "it's completely frozen" won't stop
people from committing... I'll try again - to declare a hard freeze - but
it's never 100%.
For sure there will be less last-minute big commits - there couldn't 
be more !

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]