Better testing of tagged tars

[Anke Boersma]

Since the original email in this thread came from the Chakra-Project, and
we asked if the Arch Linux devs would co sign and send, seems it is needed
we explain/respond one more time.

At Chakra-Project we do not feel there is any need to change the way the
release is handled, 4-5 days in between tar tagging, and announced release
is a very sensible work flow.
We just feel those 4-5 days should be better utilized for those distro's
that have no issues getting the tars build in one or two days.

It seems now there are two objections regarding making these builds
available to early testers:
1)  There is no need for testing, early tars are only to be used to make
sure they build correctly.
2)  Early testers will create wrong bug reports for non-existing kde
versions.

Regarding point 1, why not use this time for additional testing?  For me
personally, I've been building KDE for the Chakra-Project for almost 3
years, in that time, almost any early tar some issues were reported to the
release-team, issues were gladly accepted by that team, but what was
reported was maybe 50 % build issues, the other 50% was bugs found on
running the early builds.  Seems counter-intuitive to state, there is no
need or use in this time period to test.

As to point 2, having a much clearer set policy, that any distro can convey
to their testers must surely result in less badly placed bug reports.
 Testers who have to read documentation just to be able to use a certain
repo, are far more likely to also read about reporting issues correctly.
Any users that builds KDE from git, those don't result in often misplaced
bug-reports?  Or any user who really has no idea what version they are
running, just choose one for a bug report, isn't that more likely to happen
then an educated testers filing an incorrect bug report?

Anke Boersma
abveritas at chakra-project

On Mon, Feb 11, 2013 at 9:11 AM, Torgny Nyblom <nyblom at kde.org> wrote:

> On Monday 11 February 2013 00.24.51 Albert Astals Cid wrote:
> > El Diumenge, 10 de febrer de 2013, a les 08:15:40, Martin Gräßlin va
> escriure:
> > > On Saturday 09 February 2013 23:08:50 Albert Astals Cid wrote:
> > > > Of course another option is lifting the requirement for the
> pre-packages
> > > > not being publicly available, after all the packages will most
> likely be
> > > > the real thing, so if everyone agrees it is better lifting this
> > > > requirement, we can do it, the fact that *I* personally like it the
> way
> > > > it is doesn't mean it's the better way.
> > >
> > > With my bugzilla user hat on I'm afraid of that. It would mean we get
> bug
> > > reports for an unreleased version. That's bound to create confusion  -
> we
> > > would not be able to trust the version field any more. In case of a
> > > re-spin
> > > it will get just worse - different tar balls with the same version
> > > information.
> >
> > Another option is just release the tarballs once and don't do any respin
> at
> > all. After all we have build.kde.org that builds the stuff so we are
> kind of
> > "confident" it builds, if anything fails to build or something big is
> found
> > we can add it as a note (+ kde-packager mail) to the info page like we
> did
> > with the nepomuk thing for 4.10.0 http://kde.org/info/4.10.0.php
> >
> > That seems like a "sensible" compromise to me.
> >
> >  * We release only one tarball
> >  * Distros still can pick up build or bugfixes (as they will do anyway
> > either we include them in a respin tarball or not)
> >  * We can "silently" release the *only one* tarball a few days in
> advance to
> > get distros to package for the release day
> >
> > Comments?
>
> Sounds like a sensible alternative.
>
> Perhaps open the door for a patch level release (ex: 4.10.0.1) if something
> really important comes up.
>
> /Regards
> Torgny
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130212/d9e2b4fa/attachment.html>