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

List:       kde-release-team
Subject:    Re: pre-releases of rc1
From:       Sebastian =?iso-8859-15?q?K=FCgler?= <sebas () kde ! org>
Date:       2009-06-30 22:24:32
Message-ID: 200907010024.32278.sebas () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 30 June 2009 23:03:30 Tom Albers wrote:
> Op Monday 29 June 2009 15:44 schreef u:
> > On Monday 29 June 2009 13:52:34 Sebastian Kügler wrote:
> > > It's not so much stress, but usefulness of the RC for us. If people
> > > report against RC1, and it isn't what RC1 is, the bugreport (which is
> > > in principle exactly why we do an RC) becomes less useful.
> > >
> > > The problem would be solved if:
> > >
> > > - the packages are only spread when the RC is actually out
> > > - the packages that are spread before that are not called RC, but
> > > something indicating that it's indeed a more or less random snapshot
> >
> > In general:
> >
> > Sure, if you want us to not release anything before your announcement we
> > can do that. But making packages available to a limited amount of users
> > (in our case the repo is only known to those who read our developer
> > mailing list) increases the chance to find showstoppers and not just
> > build problems.
> >
> > If there would be a way to have drkonqi sent the build date or even
> > better the svn revision number this "problem" would be solved.
> >
> >
> > About the current RC1 packages:
> >
> > I don't see the problem of our current kde-unstable repo. We provide the
> > latest packages that were build from the sources available at ktown. The
> > release of RC1 is scheduled for today. So if there are no major retagging
> > planned our packages should be identical to what will be called RC1.
> > There are some unofficial repos for arch which provide svn snapshots for
> > Arch; maybe that's the source of the confusion.
> >
> > Maybe you could point us to some reports to make it easier to understand
> > the issue.

> In the end, it is all a matter of communicating. We should wrap up a small
> document with what we expect from distro's and what not in each stage of
> the process. Can be small and to the point. Anyone in writing mood?

If we manage to get a 'random snapshot' into 'releasable tarball with source 
code' in less than a week, and it distros are quicker shipping it, we could 
consider shortening the period between tagging and release (which currently 
effectively is 8 days). Maybe make it 4? That would mean we tag on Friday, and 
release on Tuesday, with possible slippage into wednesday.
Especially for -rc or -beta releases, that would mean "fresher" bugreports.

I might be missing a good reason to keep that period longer, in that case, 
speak up.
-- 
sebas

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

["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


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