Better testing of tagged tars

Tue Feb 12 23:49:21 UTC 2013

El Dimarts, 12 de febrer de 2013, a les 11:57:21, Anke Boersma va escriure:
> 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.

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

> 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