Better testing of tagged tars

[Anke Boersma]

>
> The problem is that this is most of the times "this is too late". We
> usually
> have like 5 days between tag and release, meaning you start reporting bugs
> at
> day 2 or 3 which gives the developer a highly stressful 1-2 days to try to
> fix
> bug.
>
> If you want to help with testing, i think that having "unofficial" daily
> builds of the stable branches and telling your testers to use that is much
> more helpful since it will probably give an earlier warning.
>
> I asked that to the kubuntu guys so i could use it myself, but it seems
> packaging is too hard in ubuntu land and they never got back to me.
>
> Cheers,
>   Albert


It is not that we have time for extra testing, even more full KDE builds,
nor do we ask to be able to file official bug reports.
This is about using info early builds of tagged tars can bring at times,
using the time between tagging and final release that some distro's have
available after early compilation.
Relaying info about found regressions (this info was discussed either on
IRC or to the rls-team ml).  At times it was as simple as reverting a
commit, other times, no option but providing (communicated either on the
rls-team ml, or kde-packagers ml) a needed patch was possible.

Can you please clarify if your tarballs are public or not? A few mails ago
> you
> you said the instructions to get the packages where on a publicly
> accessible
> wiki, and now you are saying say users don't have acces to them?


That was not a mail from Chakra, but from Arch, there is no Wiki in Chakra
for this.  But as stated many times, if you start looking into our server,
the repo's are not hidden, you can find any early builds.

On Tue, Feb 12, 2013 at 6:59 PM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dimarts, 12 de febrer de 2013, a les 15:28:35, Anke Boersma va escriure:
> > This whole thread was about stable tars, not RC or Beta.  What was found
> > and reported often, is regressions from say, 4.x.2 to 4.x.3.
>
> Right, regressions are bad, we all have them, but as said, raising the
> flag 2
> days before the release is going to happen is most of the times too late,
> if
> you guys really want to help, we have to find a way to find them earlier.
>
> Cheers,
>   Albert
>
> > Reported not in bug reports, but more a discussion on IRC, see if anyone
> > was aware, sometimes ml, again, just checking if it was a known/accepted
> > regression.
> >
> > On Tue, Feb 12, 2013 at 3:17 PM, Martin Gräßlin <mgraesslin at kde.org>
> wrote:
> > > On Tuesday 12 February 2013 14:37:22 Anke Boersma wrote:
> > > >  any bugs found in the early tars (not build related) should
> > > >
> > > > be kept quiet, until the tars are officially announced.  It is
> better to
> > > > have final tars that have bugs that were known for a few days, than
> > > > reporting.
> > >
> > > What kind of bugs are you expecting to find:
> > > 1) Regressions from the last RC -> escalate
> > > 2) Bugs already present in the RC and reported
> > > 3) Bugs already present in the RC and not reported
> > >
> > > From experience of our users and their usage with bugzilla. 90 % is
> > > category 2
> > > (that obviously includes experienced users). Given that we release with
> > > known
> > > bugs (bug free software is impossible) it hardly matters whether there
> are
> > > a
> > > few more or less and it wouldn't change anything because we are post
> final
> > > tagging (except it's a showstopper -> escalate).
> > >
> > > That said: I keep to what I wrote. For me as a heavy bugzilla user
> (just
> > > look
> > > at commit-digest) getting bug reports for an unreleased version would
> > > cause
> > > more work and confusion. My first comment would be "this version is not
> > > yet
> > > released, where do you have it from? Are you sure you are running
> exactly
> > > that
> > > version?" - if I don't know the user and that he is an experienced
> Chakra
> > > user
> > > having access to pre-released packages, I have to assume he entered
> junk
> > > which
> > > happens more often than you would expect.
> > >
> > > For everything else of your mail: sorry, I'm not qualified to
> > > answer/comment
> > > on that :-)
> > > --
> > > Martin Gräßlin
> > > _______________________________________________
> > > release-team mailing list
> > > release-team at kde.org
> > > https://mail.kde.org/mailman/listinfo/release-team
> _______________________________________________
> 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/b4d4f65f/attachment-0001.html>