From kde-release-team  Tue Jun 30 22:24:32 2009
From: Sebastian =?iso-8859-15?q?K=FCgler?= <sebas () kde ! org>
Date: Tue, 30 Jun 2009 22:24:32 +0000
To: kde-release-team
Subject: Re: pre-releases of rc1
Message-Id: <200907010024.32278.sebas () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-release-team&m=124653894519735
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1842062237=="

--===============1842062237==
Content-Type: multipart/signed;
  boundary="nextPart6613834.CuAtLHAhX2";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6613834.CuAtLHAhX2
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

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=FCgler 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 retaggi=
ng
> > 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 sourc=
e=20
code' in less than a week, and it distros are quicker shipping it, we could=
=20
consider shortening the period between tagging and release (which currently=
=20
effectively is 8 days). Maybe make it 4? That would mean we tag on Friday, =
and=20
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,=
=20
speak up.
=2D-=20
sebas

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

--nextPart6613834.CuAtLHAhX2
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAABAgAGBQJKSpCgAAoJEGdNh9WRGQ75/kwH/R3yaLtYD4vsfy3UEtti0uAv
z8H+ge83F5fb2H9TrgHkKZKE2ftxemvr1KeALa4L59swVXed5MSpyJyfqFBdVLrv
hitOFT0jc1jqulxWiJQuqS0i2WUrq4Dz5iItbvj/Lx3VR3FuF8U9PQ/rezYUG1iW
t4YcaVS/yGg8YscORec33UIwNZw5+BQxN+hxWRc2F89hqPljC+sRbq7b+ZPVff3u
5FxZr0Tk1oswYo8ppT3SC0fhaACz10RspxjrbYfJtNMRrxOf3HFEqhKWK5UP+m5k
3tWPPC5cx+lVhRHysBATMnsvYeHsDCwMrgrCQzNpnpCH3Bthn6PmC/fUoUORnMc=
=HAOl
-----END PGP SIGNATURE-----

--nextPart6613834.CuAtLHAhX2--

--===============1842062237==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1842062237==--