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@chakra-project > > On Mon, Feb 11, 2013 at 9:11 AM, Torgny Nyblom <[email protected]> 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 > > [email protected] > > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
