Re: Better testing of tagged tars
El Dimecres, 13 de febrer de 2013, a les 08:02:16, Martin Gräßlin va escriure: > On Wednesday 13 February 2013 01:00:13 Albert Astals Cid wrote: > > El Dimarts, 12 de febrer de 2013, a les 22:05:00, Martin Gräßlin va > > escriure: > > > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > > > This whole thread was about stable tars, not RC or Beta. > > > > > > Sorry at least to me that was not obvious. (thread started on 31. of > > > January, doesn't mention minor releases, so I assumed it meant the > > > upcoming > > > release of 4.10) - all I wrote so far was explicitly for the case of a > > > 4.x.0 release. > > > > > > > What was found > > > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > > > 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. > > > > > > status quo is that currently the branches are basically untested. > > > > That is *your* thinking, i.e. you don't test them, but i think it is a bit > > off a stretch to present that as the reality. Although i agree more users > > of the stable branch would help. > do you know any developer running branch instead of master? I don't I do run the stable branch of okular. Cheers, Albert > -- > Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
On Wed, Feb 13, 2013 at 9:42 AM, Myriam Schweingruber wrote: > On Wed, Feb 13, 2013 at 1:24 AM, Albert Astals Cid wrote: >> El Dimecres, 13 de febrer de 2013, a les 01:21:07, Andreas K. Huettel va >> escriure: >>> Am Dienstag, 12. Februar 2013, 22:05:00 schrieb Martin Gräßlin: >>> > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: >>> > > This whole thread was about stable tars, not RC or Beta. >>> > >>> > Sorry at least to me that was not obvious. (thread started on 31. of >>> > January, doesn't mention minor releases, so I assumed it meant the >>> > upcoming release of 4.10) - all I wrote so far was explicitly for the case >>> > of a 4.x.0 release. >>> > >>> > > What was found >>> > > and reported often, is regressions from say, 4.x.2 to 4.x.3. >>> > > 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. >>> > >>> > status quo is that currently the branches are basically untested. Here >>> > personally I would love to get more testing as I never like pushing to >>> > branch (let's push to master, if nobody screams in two weeks, let's >>> > backport). >>> >>> [shameless plug] Use Gentoo, it's trivial here since the install process is >>> basically the same whether git (any branch) or tarball. Our packager team >>> mostly runs live builds, and adapts the packaging instructions there first, >>> which is then copied to the release version. [/shameless plug] >> >> I can't, as Canonical employee I am kind of obliged to use the company's >> distro :D > > And why don't you use the Neon builds? nvm, I misread that Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
On Wed, Feb 13, 2013 at 1:24 AM, Albert Astals Cid wrote: > El Dimecres, 13 de febrer de 2013, a les 01:21:07, Andreas K. Huettel va > escriure: >> Am Dienstag, 12. Februar 2013, 22:05:00 schrieb Martin Gräßlin: >> > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: >> > > This whole thread was about stable tars, not RC or Beta. >> > >> > Sorry at least to me that was not obvious. (thread started on 31. of >> > January, doesn't mention minor releases, so I assumed it meant the >> > upcoming release of 4.10) - all I wrote so far was explicitly for the case >> > of a 4.x.0 release. >> > >> > > What was found >> > > and reported often, is regressions from say, 4.x.2 to 4.x.3. >> > > 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. >> > >> > status quo is that currently the branches are basically untested. Here >> > personally I would love to get more testing as I never like pushing to >> > branch (let's push to master, if nobody screams in two weeks, let's >> > backport). >> >> [shameless plug] Use Gentoo, it's trivial here since the install process is >> basically the same whether git (any branch) or tarball. Our packager team >> mostly runs live builds, and adapts the packaging instructions there first, >> which is then copied to the release version. [/shameless plug] > > I can't, as Canonical employee I am kind of obliged to use the company's > distro :D And why don't you use the Neon builds? Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Wednesday 13 February 2013 01:00:13 Albert Astals Cid wrote: > El Dimarts, 12 de febrer de 2013, a les 22:05:00, Martin Gräßlin va escriure: > > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > > This whole thread was about stable tars, not RC or Beta. > > > > Sorry at least to me that was not obvious. (thread started on 31. of > > January, doesn't mention minor releases, so I assumed it meant the > > upcoming > > release of 4.10) - all I wrote so far was explicitly for the case of a > > 4.x.0 release. > > > > > What was found > > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > > 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. > > > > status quo is that currently the branches are basically untested. > > That is *your* thinking, i.e. you don't test them, but i think it is a bit > off a stretch to present that as the reality. Although i agree more users > of the stable branch would help. do you know any developer running branch instead of master? I don't -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dimarts, 12 de febrer de 2013, a les 19:15:50, Anke Boersma va escriure: > > 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. Well I think noone is against responsible reporting from people in the know (like you or other Chakra core developers). > > 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. Ok, my bad, confused Chakra and Arch here. But the fact that you have different package publishing rules confuses me a bit in why the shared email, since obviously I can't see any issue with what you do, but I can see some problems happening with widely distributed packages in Arch. Cheers, Albert > > On Tue, Feb 12, 2013 at 6:59 PM, Albert Astals Cid 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 > > > > 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 > > > > __
Re: Better testing of tagged tars
El Dimecres, 13 de febrer de 2013, a les 01:21:07, Andreas K. Huettel va escriure: > Am Dienstag, 12. Februar 2013, 22:05:00 schrieb Martin Gräßlin: > > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > > This whole thread was about stable tars, not RC or Beta. > > > > Sorry at least to me that was not obvious. (thread started on 31. of > > January, doesn't mention minor releases, so I assumed it meant the > > upcoming release of 4.10) - all I wrote so far was explicitly for the case > > of a 4.x.0 release. > > > > > What was found > > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > > 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. > > > > status quo is that currently the branches are basically untested. Here > > personally I would love to get more testing as I never like pushing to > > branch (let's push to master, if nobody screams in two weeks, let's > > backport). > > [shameless plug] Use Gentoo, it's trivial here since the install process is > basically the same whether git (any branch) or tarball. Our packager team > mostly runs live builds, and adapts the packaging instructions there first, > which is then copied to the release version. [/shameless plug] I can't, as Canonical employee I am kind of obliged to use the company's distro :D Thanks for the offer though! Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
Am Dienstag, 12. Februar 2013, 22:05:00 schrieb Martin Gräßlin: > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > This whole thread was about stable tars, not RC or Beta. > > Sorry at least to me that was not obvious. (thread started on 31. of > January, doesn't mention minor releases, so I assumed it meant the > upcoming release of 4.10) - all I wrote so far was explicitly for the case > of a 4.x.0 release. > > > What was found > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > 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. > > status quo is that currently the branches are basically untested. Here > personally I would love to get more testing as I never like pushing to > branch (let's push to master, if nobody screams in two weeks, let's > backport). [shameless plug] Use Gentoo, it's trivial here since the install process is basically the same whether git (any branch) or tarball. Our packager team mostly runs live builds, and adapts the packaging instructions there first, which is then copied to the release version. [/shameless plug] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
> > 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 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 > 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@kde.org > > > https://mail.kde.org/mailman/listinfo/release-team > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
Am Montag, 11. Februar 2013, 00:24:51 schrieb Albert Astals Cid: > 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? > Actually, I think the current procedure is OK as it is. Sure, things can go wrong sometime, but as long as someone of the knowledgeable upstream developers cares and quickly codes a fix or workaround, that is not really a big problem. No distro will stick with "vanilla tarballs" just for the fun of it if upstream has accepted a patch that solves a real problem into the stable/bugfix branch. [As for the longer testing... well, 1) in the case of .0 versions, that's what betas and rc's are for, and 2) in the case of .X versions, X>0, well, it's called the "stable branch" for a reason- don't mess with it! [Actually I've been working on automatically extracting some statistics how large a percentage of the code is changed between git tags, since I was curious how well "the code converges" in different packages. Will finish this once I get around to it... (No Perl.)]] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dimarts, 12 de febrer de 2013, a les 22:05:00, Martin Gräßlin va escriure: > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > This whole thread was about stable tars, not RC or Beta. > > Sorry at least to me that was not obvious. (thread started on 31. of > January, doesn't mention minor releases, so I assumed it meant the upcoming > release of 4.10) - all I wrote so far was explicitly for the case of a > 4.x.0 release. > > What was found > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > 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. > > status quo is that currently the branches are basically untested. That is *your* thinking, i.e. you don't test them, but i think it is a bit off a stretch to present that as the reality. Although i agree more users of the stable branch would help. Cheers, Albert > Here > personally I would love to get more testing as I never like pushing to > branch (let's push to master, if nobody screams in two weeks, let's > backport). > > For this situation I would suggest to coordinate with the quality team (e.g. > Myriam). > > -- > Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
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 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@kde.org > > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dimarts, 12 de febrer de 2013, a les 14:37:22, Anke Boersma va escriure: > To get a clear picture then, our early tar builds should be completely > hidden (not possible on our server), even-though no regular user has access > to them, 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? > and 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. Release blocking bugs should be reported immediately to this list or CC'ed to this list (I still remember in the 4.10 cycle someone reported what he thought was a blocker bug and assigned it to a regular developer in bugzilla and told noone else, yes, that's not helpful at all) Regular bugs I don't really care, Martin seems to want after the release, but he is "only" one developer. Cheers, Albert > On Tue, Feb 12, 2013 at 1:59 PM, Martin Gräßlin wrote: > > On Tuesday 12 February 2013 19:25:46 Myriam Schweingruber wrote: > > > Hi Anke, > > > > > > On Tue, Feb 12, 2013 at 7:07 PM, Anke Boersma > > > > > > wrote: > > > > But this is the exact point I'm trying to make. Educate early testers > > > > to > > > > > > report any issues they find within the distro. We have done that for > > > > 3 > > > > years, and is well known and accepted by our testers (this includes > > > > testing > > > > all beta and rc builds for Chakra). > > > > > > I think the point is: we don't have enough testers for the Beta and RC > > > release, if these people would join the Quality Team during testing > > > this would be far more valuable than only for the final tarball. So > > > far we are only a handful, and maybe you have testers that do test but > > > they don't report upstream, nor do they coordinate with us. The KDE > > > Quality team would welcome a few more hands for that, for the final > > > tarball it's just a bit late IMHO. > > > > +1000 - that's exactly the point. We don't need the testers when the final > > tarballs are already done, we need them months before. And if you have > > many > > testers for your beta packages you also get most of the distro issues > > early. > > > > -- > > Martin Gräßlin > > ___ > > release-team mailing list > > release-team@kde.org > > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dimarts, 12 de febrer de 2013, a les 19:27:49, Ralf Jung va escriure: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > > Now let's assume we would have the packages out in the wild for > > 4.11 prior to release. The version information reported by DrKonqui > > is 4.11.0 - no matter which tarball is currently running. At the > > same time there's still an RC out (4.10.98). Which means we cannot > > yet enable the version field 4.11.0 as that could result in > > incorrect data from bug reporters (we all know our users, it would > > end up in you have to ask each time whether it's really, really > > 4.11.0). No 4.11.0 in the versions means that the DrKonqui version > > matching magic doesn't work and the bug ends up as unspecified, but > > says in the initial comment 4.11.0. That creates additional work as > > all bugs reported like that needs to be re-triaged once 4.11.0 is > > released. > > As far as I understand you, the issue here is that there are several > "4.11.0" versions. If tarballs were handled like git tags, where > nothing can be changed after they are created, and a re-spin would get > a new version number, then it would again be clear against which state > of the application the bug was reported. That is *mostly* true, we never change released tarballs. > > Would a solution like introducing dedicated versions help here: > > maybe. It would require each developer working with such issues to > > track the release team mailing list to get the notification of a > > respin, the new version number and the matching git hash. Tricky > > and again with lots of work. > > Just to be sure I understand this properly: Currently, there are no > bug reports *at all* against these pre-release tarballs - all bugs are > to be reported to the release team (i.e. this list)? And only after > the tarballs are official, bugreports may be created for this release, > so the developers know that bugzilla version numbers always refer to > the ultimately released tarballs? > > A solution which would not require developers to follow the release > list or anything, while still permitting bugreports against > pre-releases, might be to > * always use new version numbers for re-spinned tarballs (after all, > this should really not happen that often) That would mean using versions with 4 numbers, which i would like to totally avoid. Cheers, Albert > * add git tags and bugzilla versions at the same time as tarballs are > created > A developer now just has to do "git fetch" after getting a bugreport > to find out the exact git hash the user used. git tags should be added > in any case, so that should not be any additional work. I do not know > how bugzilla versions are handled currently, do they have to be added > manually? Maybe a git hook to add bugzilla versions for tags called > "v\d+\.\d+\.\d+" would be appropriate (if possible). Finally, the > version number DrKonqui uses could also be derived from the git tag > (maybe by creating the tarball after tagging, so that the script which > does the tar-magic can get he version number from git?). This should > prevent mismatches between the Bugzilla and DrKonqui version numbers. > > Disclaimer: I am neither a KDE developer nor a packager (though I do > create my own local Debian packages from the KDE upstream git > sources), just a user and occasional contributor who is interested in > KDE getting better :D (and trying to find a good place to contribute > which is compatible with university...) > > Kind regards, > Ralf > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRGomcAAoJEEAdTZ0mjB1W6GYH/2THazuw1y3HGD+CGcugdJYa > ViuC+MUjpe66oeMhBozJ2xsTrTdeBH9Ny8hvj9d1WAYqG5M61so57+Dp3OeAKD0f > a3sOjNZq9ZCb7ymO1OteOBvOVjFZVkm8d2lowjojF6ED3ZZwDOiSO/FoSRYvJDsa > PLp2kkv7uOP06zopwiFT2OVtz20F2K2hvJyS1kVxw7mBI+WpaEPeHGEC7ZOq4ql0 > w7HWnzil3xxeba90FEWJX6zlvSP5HRRz4bfAkAgYTu890ER/zQCDYVoaX8gAtmFw > CjsCCpBw/qL4OqjuCRz1hgHa2cypotqFlbjucDaZF+iswbGilsaAMEJPwP5JfGA= > =PzJ4 > -END PGP SIGNATURE- > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dimarts, 12 de febrer de 2013, a les 18:32:32, Martin Gräßlin va escriure: > On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote: > > 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? > > The problem here is DrKonqui and the automatic version matching. For someone > running master it does not matter. Most products have a version field > called "git master" and while DrKonqui is not able to match it, the users > normally tell so. > > Now let's assume we would have the packages out in the wild for 4.11 prior > to release. The version information reported by DrKonqui is 4.11.0 - no > matter which tarball is currently running. At the same time there's still > an RC out (4.10.98). Which means we cannot yet enable the version field > 4.11.0 as that could result in incorrect data from bug reporters (we all > know our users, it would end up in you have to ask each time whether it's > really, really 4.11.0). No 4.11.0 in the versions means that the DrKonqui > version matching magic doesn't work and the bug ends up as unspecified, but > says in the initial comment 4.11.0. That creates additional work as all > bugs reported like that needs to be re-triaged once 4.11.0 is released. That sounds like we need better tools in the bugzilla side so users can screw it up less. Cheers, Albert > > Now the problem of re-spin tarballs. Let's assume we have a crash in KWin > (driver related) not present in the RC, but in the final tars. We fix it > (based on general assumptions on what might have caused the crash - yeah > driver bugs for which you don't have the hardware tend to end up like that) > and cause the release team to do a respin. But we still get the crash > reports. What does it mean now? Issue not fixed? User not yet updated the > package? Looking at backtrace doesn't help - if it is driver related they > look all different for each distribution. > > Would a solution like introducing dedicated versions help here: maybe. It > would require each developer working with such issues to track the release > team mailing list to get the notification of a respin, the new version > number and the matching git hash. Tricky and again with lots of work. Also > problematic once the final version is created because the version > information must be exactly the same otherwise Dr.Konqui magic doesn't > work. > > For me as the product maintainer at the point between last RC and final > release it's extremely important to get correct information as if there is a > crash introduced after last RC, I would have to run to the release team to > call stop. > > I can understand the need for distros to put out the packages for greater > usage early. But from my developer perspective I must say that I would not > want bugreports for this intermediate state. I also don't think that it in > general would help much to have bug reports for this special stage. It > should be only to find showstoppers and for that I doubt our bugzilla is > suited at the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went > unnoticed on this list). > > That said: it would be much more help if users would test the betas and RCs > more - I think from our perspective that's more help. > > -- > Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
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 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@kde.org > > https://mail.kde.org/mailman/listinfo/release-team ___
Re: Re: Re: Re: Re: Better testing of tagged tars
Same holds up for 4.x.0 too. Again, this is about the time between tagging the tars, and announced release. Regressions found between RC3 and the tagged tar for kde 4.10.0 in the last case. On Tue, Feb 12, 2013 at 4:05 PM, Martin Gräßlin wrote: > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > This whole thread was about stable tars, not RC or Beta. > Sorry at least to me that was not obvious. (thread started on 31. of > January, > doesn't mention minor releases, so I assumed it meant the upcoming release > of > 4.10) - all I wrote so far was explicitly for the case of a 4.x.0 release. > > What was found > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > 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. > status quo is that currently the branches are basically untested. Here > personally I would love to get more testing as I never like pushing to > branch > (let's push to master, if nobody screams in two weeks, let's backport). > > For this situation I would suggest to coordinate with the quality team > (e.g. > Myriam). > > -- > Martin Gräßlin > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > This whole thread was about stable tars, not RC or Beta. Sorry at least to me that was not obvious. (thread started on 31. of January, doesn't mention minor releases, so I assumed it meant the upcoming release of 4.10) - all I wrote so far was explicitly for the case of a 4.x.0 release. > What was found > and reported often, is regressions from say, 4.x.2 to 4.x.3. > 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. status quo is that currently the branches are basically untested. Here personally I would love to get more testing as I never like pushing to branch (let's push to master, if nobody screams in two weeks, let's backport). For this situation I would suggest to coordinate with the quality team (e.g. Myriam). -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: Better testing of tagged tars
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. 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 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@kde.org > https://mail.kde.org/mailman/listinfo/release-team > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: Better testing of tagged tars
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 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Better testing of tagged tars
To get a clear picture then, our early tar builds should be completely hidden (not possible on our server), even-though no regular user has access to them, and 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. On Tue, Feb 12, 2013 at 1:59 PM, Martin Gräßlin wrote: > On Tuesday 12 February 2013 19:25:46 Myriam Schweingruber wrote: > > Hi Anke, > > > > On Tue, Feb 12, 2013 at 7:07 PM, Anke Boersma > > > > wrote: > > > But this is the exact point I'm trying to make. Educate early testers > to > > > report any issues they find within the distro. We have done that for 3 > > > years, and is well known and accepted by our testers (this includes > > > testing > > > all beta and rc builds for Chakra). > > > > I think the point is: we don't have enough testers for the Beta and RC > > release, if these people would join the Quality Team during testing > > this would be far more valuable than only for the final tarball. So > > far we are only a handful, and maybe you have testers that do test but > > they don't report upstream, nor do they coordinate with us. The KDE > > Quality team would welcome a few more hands for that, for the final > > tarball it's just a bit late IMHO. > +1000 - that's exactly the point. We don't need the testers when the final > tarballs are already done, we need them months before. And if you have many > testers for your beta packages you also get most of the distro issues > early. > > -- > Martin Gräßlin > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 19:25:46 Myriam Schweingruber wrote: > Hi Anke, > > On Tue, Feb 12, 2013 at 7:07 PM, Anke Boersma > > wrote: > > But this is the exact point I'm trying to make. Educate early testers to > > report any issues they find within the distro. We have done that for 3 > > years, and is well known and accepted by our testers (this includes > > testing > > all beta and rc builds for Chakra). > > I think the point is: we don't have enough testers for the Beta and RC > release, if these people would join the Quality Team during testing > this would be far more valuable than only for the final tarball. So > far we are only a handful, and maybe you have testers that do test but > they don't report upstream, nor do they coordinate with us. The KDE > Quality team would welcome a few more hands for that, for the final > tarball it's just a bit late IMHO. +1000 - that's exactly the point. We don't need the testers when the final tarballs are already done, we need them months before. And if you have many testers for your beta packages you also get most of the distro issues early. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 10:43:37 Ian Monroe wrote: > On Tue, Feb 12, 2013 at 9:32 AM, Martin Gräßlin wrote: > > Would a solution like introducing dedicated versions help here: maybe. It > > would require each developer working with such issues to track the release > > team mailing list to get the notification of a respin, the new version > > number and the matching git hash. Tricky and again with lots of work. > > Also problematic once the final version is created because the version > > information must be exactly the same otherwise Dr.Konqui magic doesn't > > work. > > Wouldn't much of the problem be solved if the git sha was directly > appended to the version number? It wouldn't even need to be all that > many digits - like 3 or 4 - since it would just need to differentiate > between commits around the time of the release. Traceability would be > for free. You wouldn't be able to tell which tarball of the same > version but different sha was the newest, but you can't tell that > currently anyways. If DrKonqui can handle that (perform proper version matching) it would be in general a very good thing to have. But I don't know whether that can work at all that it really points to the right sha given the way how git works. One would need to know the hash of the commit being created by inserting the hash into the version information in CMakeLists.txt. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 19:27:49 Ralf Jung wrote: > * add git tags and bugzilla versions at the same time as tarballs are > created gues who creates the bugzilla versions and no I don't think it would scale to burden that to the release team. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Tue, Feb 12, 2013 at 9:32 AM, Martin Gräßlin wrote: > Would a solution like introducing dedicated versions help here: maybe. It > would require each developer working with such issues to track the release > team mailing list to get the notification of a respin, the new version number > and the matching git hash. Tricky and again with lots of work. Also > problematic once the final version is created because the version information > must be exactly the same otherwise Dr.Konqui magic doesn't work. Wouldn't much of the problem be solved if the git sha was directly appended to the version number? It wouldn't even need to be all that many digits - like 3 or 4 - since it would just need to differentiate between commits around the time of the release. Traceability would be for free. You wouldn't be able to tell which tarball of the same version but different sha was the newest, but you can't tell that currently anyways. Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, > Now let's assume we would have the packages out in the wild for > 4.11 prior to release. The version information reported by DrKonqui > is 4.11.0 - no matter which tarball is currently running. At the > same time there's still an RC out (4.10.98). Which means we cannot > yet enable the version field 4.11.0 as that could result in > incorrect data from bug reporters (we all know our users, it would > end up in you have to ask each time whether it's really, really > 4.11.0). No 4.11.0 in the versions means that the DrKonqui version > matching magic doesn't work and the bug ends up as unspecified, but > says in the initial comment 4.11.0. That creates additional work as > all bugs reported like that needs to be re-triaged once 4.11.0 is > released. As far as I understand you, the issue here is that there are several "4.11.0" versions. If tarballs were handled like git tags, where nothing can be changed after they are created, and a re-spin would get a new version number, then it would again be clear against which state of the application the bug was reported. > Would a solution like introducing dedicated versions help here: > maybe. It would require each developer working with such issues to > track the release team mailing list to get the notification of a > respin, the new version number and the matching git hash. Tricky > and again with lots of work. Just to be sure I understand this properly: Currently, there are no bug reports *at all* against these pre-release tarballs - all bugs are to be reported to the release team (i.e. this list)? And only after the tarballs are official, bugreports may be created for this release, so the developers know that bugzilla version numbers always refer to the ultimately released tarballs? A solution which would not require developers to follow the release list or anything, while still permitting bugreports against pre-releases, might be to * always use new version numbers for re-spinned tarballs (after all, this should really not happen that often) * add git tags and bugzilla versions at the same time as tarballs are created A developer now just has to do "git fetch" after getting a bugreport to find out the exact git hash the user used. git tags should be added in any case, so that should not be any additional work. I do not know how bugzilla versions are handled currently, do they have to be added manually? Maybe a git hook to add bugzilla versions for tags called "v\d+\.\d+\.\d+" would be appropriate (if possible). Finally, the version number DrKonqui uses could also be derived from the git tag (maybe by creating the tarball after tagging, so that the script which does the tar-magic can get he version number from git?). This should prevent mismatches between the Bugzilla and DrKonqui version numbers. Disclaimer: I am neither a KDE developer nor a packager (though I do create my own local Debian packages from the KDE upstream git sources), just a user and occasional contributor who is interested in KDE getting better :D (and trying to find a good place to contribute which is compatible with university...) Kind regards, Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRGomcAAoJEEAdTZ0mjB1W6GYH/2THazuw1y3HGD+CGcugdJYa ViuC+MUjpe66oeMhBozJ2xsTrTdeBH9Ny8hvj9d1WAYqG5M61so57+Dp3OeAKD0f a3sOjNZq9ZCb7ymO1OteOBvOVjFZVkm8d2lowjojF6ED3ZZwDOiSO/FoSRYvJDsa PLp2kkv7uOP06zopwiFT2OVtz20F2K2hvJyS1kVxw7mBI+WpaEPeHGEC7ZOq4ql0 w7HWnzil3xxeba90FEWJX6zlvSP5HRRz4bfAkAgYTu890ER/zQCDYVoaX8gAtmFw CjsCCpBw/qL4OqjuCRz1hgHa2cypotqFlbjucDaZF+iswbGilsaAMEJPwP5JfGA= =PzJ4 -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
Hi Anke, On Tue, Feb 12, 2013 at 7:07 PM, Anke Boersma wrote: > But this is the exact point I'm trying to make. Educate early testers to > report any issues they find within the distro. We have done that for 3 > years, and is well known and accepted by our testers (this includes testing > all beta and rc builds for Chakra). I think the point is: we don't have enough testers for the Beta and RC release, if these people would join the Quality Team during testing this would be far more valuable than only for the final tarball. So far we are only a handful, and maybe you have testers that do test but they don't report upstream, nor do they coordinate with us. The KDE Quality team would welcome a few more hands for that, for the final tarball it's just a bit late IMHO. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
But this is the exact point I'm trying to make. Educate early testers to report any issues they find within the distro. We have done that for 3 years, and is well known and accepted by our testers (this includes testing all beta and rc builds for Chakra). It is just a 3-4 day period, many early test runs pick up issues that can be distro specific build errors. True bugs can be relayed to the release team. Once a version is final, then official bug reports can be filed again. But if any KDE dev here feels the negatives far outweigh any issue fixes before a new release is final, then there will be no other way for us but to stop building early tars, since there is just no way to hide our early builds on the server. On Tue, Feb 12, 2013 at 12:32 PM, Martin Gräßlin wrote: > On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote: > > 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? > The problem here is DrKonqui and the automatic version matching. For > someone > running master it does not matter. Most products have a version field > called > "git master" and while DrKonqui is not able to match it, the users normally > tell so. > > Now let's assume we would have the packages out in the wild for 4.11 prior > to > release. The version information reported by DrKonqui is 4.11.0 - no matter > which tarball is currently running. At the same time there's still an RC > out > (4.10.98). Which means we cannot yet enable the version field 4.11.0 as > that > could result in incorrect data from bug reporters (we all know our users, > it > would end up in you have to ask each time whether it's really, really > 4.11.0). > No 4.11.0 in the versions means that the DrKonqui version matching magic > doesn't work and the bug ends up as unspecified, but says in the initial > comment 4.11.0. That creates additional work as all bugs reported like that > needs to be re-triaged once 4.11.0 is released. > > Now the problem of re-spin tarballs. Let's assume we have a crash in KWin > (driver related) not present in the RC, but in the final tars. We fix it > (based on general assumptions on what might have caused the crash - yeah > driver bugs for which you don't have the hardware tend to end up like that) > and cause the release team to do a respin. But we still get the crash > reports. > What does it mean now? Issue not fixed? User not yet updated the package? > Looking at backtrace doesn't help - if it is driver related they look all > different for each distribution. > > Would a solution like introducing dedicated versions help here: maybe. It > would require each developer working with such issues to track the release > team mailing list to get the notification of a respin, the new version > number > and the matching git hash. Tricky and again with lots of work. Also > problematic once the final version is created because the version > information > must be exactly the same otherwise Dr.Konqui magic doesn't work. > > For me as the product maintainer at the point between last RC and final > release it's extremely important to get correct information as if there is > a > crash introduced after last RC, I would have to run to the release team to > call stop. > > I can understand the need for distros to put out the packages for greater > usage early. But from my developer perspective I must say that I would not > want bugreports for this intermediate state. I also don't think that it in > general would help much to have bug reports for this special stage. It > should > be only to find showstoppers and for that I doubt our bugzilla is suited at > the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went unnoticed on > this list). > > That said: it would be much more help if users would test the betas and RCs > more - I think from our perspective that's more help. > > -- > Martin Gräßlin > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote: > 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? The problem here is DrKonqui and the automatic version matching. For someone running master it does not matter. Most products have a version field called "git master" and while DrKonqui is not able to match it, the users normally tell so. Now let's assume we would have the packages out in the wild for 4.11 prior to release. The version information reported by DrKonqui is 4.11.0 - no matter which tarball is currently running. At the same time there's still an RC out (4.10.98). Which means we cannot yet enable the version field 4.11.0 as that could result in incorrect data from bug reporters (we all know our users, it would end up in you have to ask each time whether it's really, really 4.11.0). No 4.11.0 in the versions means that the DrKonqui version matching magic doesn't work and the bug ends up as unspecified, but says in the initial comment 4.11.0. That creates additional work as all bugs reported like that needs to be re-triaged once 4.11.0 is released. Now the problem of re-spin tarballs. Let's assume we have a crash in KWin (driver related) not present in the RC, but in the final tars. We fix it (based on general assumptions on what might have caused the crash - yeah driver bugs for which you don't have the hardware tend to end up like that) and cause the release team to do a respin. But we still get the crash reports. What does it mean now? Issue not fixed? User not yet updated the package? Looking at backtrace doesn't help - if it is driver related they look all different for each distribution. Would a solution like introducing dedicated versions help here: maybe. It would require each developer working with such issues to track the release team mailing list to get the notification of a respin, the new version number and the matching git hash. Tricky and again with lots of work. Also problematic once the final version is created because the version information must be exactly the same otherwise Dr.Konqui magic doesn't work. For me as the product maintainer at the point between last RC and final release it's extremely important to get correct information as if there is a crash introduced after last RC, I would have to run to the release team to call stop. I can understand the need for distros to put out the packages for greater usage early. But from my developer perspective I must say that I would not want bugreports for this intermediate state. I also don't think that it in general would help much to have bug reports for this special stage. It should be only to find showstoppers and for that I doubt our bugzilla is suited at the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went unnoticed on this list). That said: it would be much more help if users would test the betas and RCs more - I think from our perspective that's more help. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
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@chakra-project On Mon, Feb 11, 2013 at 9:11 AM, Torgny Nyblom 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@kde.org > https://mail.kde.org/mailman/listinfo/release-team > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
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@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
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? Albert > > -- > Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
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. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dissabte, 9 de febrer de 2013, a les 19:19:24, Pierre Schmitz va escriure: > Am 05.02.2013 20:42, schrieb Albert Astals Cid: > > El Dilluns, 4 de febrer de 2013, a les 21:26:31, Andrea Scarpino va escriure: > >> We'd like to know if we can put the packages in a repository not enabled, > >> neither available, at install time. The instructions on how to enable > >> this > >> repo are in a dedicated thread in the official forum and/or in the > >> official > >> wiki. Oh, and in the KDE wiki page "how to install betas" as well. > > > > To me that looks too widely available. > > > > People will read random wikis, do random things and then you end up with > > them reporting bugs about packages that don't really exist yet. > > This has been an issue for a long time. It is good to have the packages > tested before release but the requirement to keep these private till the > official release makes it hard for distributions. Our vcs and package > distribution system is public and open by design. Trying to restrict > this just for KDE would be hard and wont happen. Right now this means > the pre-releases are only tested by the packager himself. > > I see several solutions here: > 1) We spin our own tars right from the git repos. I don't see why this is an improvement. Can you elaborate? > 2) We don't start packaging before the official release Depending on how much your build time is, that might be a solution, after all the days we give in advance is so that packagers can create the packages so that when we release you can switch the button and have the packages ready. OTOH if building is fast enough for you, you can very well do it on the release day. > 3) Release the new tars in public but don't announce them yet. If there > are issues, don't retag but release a point update; e.g. 4.1.0.1 etc.. > Once the major build errors have been ironed out after a few days, > announce the final release. This is an option, and if other people agree this is a solution we might pursue it, though I'm sure introducing four numbers in the releases will be a pain somewhere :D > We may remove old broken tars then, but > please let's keep real git tags. > And also never alter a tagged release. We never alter a tagged release (exception of human errors of course) > I don't wanted to sound too aggressive here, but right now the > pre-releases are not widely tested and we would all benefit if we can > improve that situation. pre-releases are not there for testing, they are there so packagers can have packages ready for the annoucement date. For testing we do Betas and RCs. 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. Cheers, Albert > > Greetings, > > Pierre ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
Am 05.02.2013 20:42, schrieb Albert Astals Cid: > El Dilluns, 4 de febrer de 2013, a les 21:26:31, Andrea Scarpino va escriure: >> We'd like to know if we can put the packages in a repository not enabled, >> neither available, at install time. The instructions on how to enable this >> repo are in a dedicated thread in the official forum and/or in the official >> wiki. Oh, and in the KDE wiki page "how to install betas" as well. > > To me that looks too widely available. > > People will read random wikis, do random things and then you end up with them > reporting bugs about packages that don't really exist yet. This has been an issue for a long time. It is good to have the packages tested before release but the requirement to keep these private till the official release makes it hard for distributions. Our vcs and package distribution system is public and open by design. Trying to restrict this just for KDE would be hard and wont happen. Right now this means the pre-releases are only tested by the packager himself. I see several solutions here: 1) We spin our own tars right from the git repos. 2) We don't start packaging before the official release 3) Release the new tars in public but don't announce them yet. If there are issues, don't retag but release a point update; e.g. 4.1.0.1 etc.. Once the major build errors have been ironed out after a few days, announce the final release. We may remove old broken tars then, but please let's keep real git tags. And also never alter a tagged release. I don't wanted to sound too aggressive here, but right now the pre-releases are not widely tested and we would all benefit if we can improve that situation. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dilluns, 4 de febrer de 2013, a les 21:26:31, Andrea Scarpino va escriure: > On Monday 04 February 2013 21:03:48 Albert Astals Cid wrote: > > Can you provide an easier way to find Dirk's mail, like a webarchive mail > > or at least an approximate date of the email and the subject? > > ATM I can't find it neither (the discussion about this "issue" forked from > the original topic), but take a look to Martin's thread "Why are 4.8.80 > packages already out in the wild?" in date 3th July '12. > > > Avaliable is a very broad word. Please define exactly what you want to do. > > We'd like to know if we can put the packages in a repository not enabled, > neither available, at install time. The instructions on how to enable this > repo are in a dedicated thread in the official forum and/or in the official > wiki. Oh, and in the KDE wiki page "how to install betas" as well. To me that looks too widely available. People will read random wikis, do random things and then you end up with them reporting bugs about packages that don't really exist yet. Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
On Saturday 02 February 2013 08:17:15 Rex Dieter wrote: > Has anyone ever explicitly said making packages available to targetted > testers was a *bad* idea? Yes, take a look to Martin's thread in date 3th June 2012. Also, I've been 'call back' time ago (about two years ago or less) from a KDE dev privately. > Keep in mind when I said "targetted testers", they need to be aware that > these are not public or release builds yet, that is all. Well, the installation instructions are not sent by mail privately, but shared with the community. -- Andrea Arch Linux Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
On Monday 04 February 2013 21:03:48 Albert Astals Cid wrote: > Can you provide an easier way to find Dirk's mail, like a webarchive mail or > at least an approximate date of the email and the subject? ATM I can't find it neither (the discussion about this "issue" forked from the original topic), but take a look to Martin's thread "Why are 4.8.80 packages already out in the wild?" in date 3th July '12. > Avaliable is a very broad word. Please define exactly what you want to do. We'd like to know if we can put the packages in a repository not enabled, neither available, at install time. The instructions on how to enable this repo are in a dedicated thread in the official forum and/or in the official wiki. Oh, and in the KDE wiki page "how to install betas" as well. -- Andrea Arch Linux Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
El Dijous, 31 de gener de 2013, a les 22:42:20, Andrea Scarpino va escriure: > LS > > Since there is not a clear answer yet, and both the undersigned Distro's > feel a better way of testing the tagged tars is needed during the 4-5 days > before they are officially released, we'd like to make a proposal on behalf > of the Linux distributions Arch Linux and the Chakra-Project. > > Consistently we are the first to warn and report about bugs in just > released tars, but neither distro has a good way of building these > packages, store them safely on their servers, and keep them completely > hidden from the public. Big question truly is why they should be hidden. > Both these distro's do not make it possible for the regular user to find > these packages. The repo's where they are placed are not on any official > repo list made available to any regular user installing these distro's, > only those with inside info how to edit the needed files, will be able to > find these packages. > We also know there is a fear bug reports for non-released KDE version will > surface, but we both educate our testers to report any issues found > internally, and if it is clear it is not a distro specific bug, not testers > but a distro developer will convey the found bug/issue to the appropriate > channel. > > We, as Arch Linux and Chakra-Project developers would like to propose now > to follow the recommendation set by Dirk Mueller in the last long ml thread > regarding this issue Can you provide an easier way to find Dirk's mail, like a webarchive mail or at least an approximate date of the email and the subject? > , and have the build packages from the tagged tars > available to our testers during the time period between tagging and release. Avaliable is a very broad word. Please define exactly what you want to do. Cheers, Albert > > Arch Linux: > Andrea Scarpino > and...@archlinux.org > > Chakra-Project: > Manuel Tortosa > manutort...@chakra-project.org > Anke Boersma > abveri...@chakra-project.org > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Better testing of tagged tars
On 01/31/2013 03:42 PM, Andrea Scarpino wrote: We, as Arch Linux and Chakra-Project developers would like to propose now to follow the recommendation set by Dirk Mueller in the last long ml thread regarding this issue, and have the build packages from the tagged tars available to our testers during the time period between tagging and release. Has anyone ever explicitly said making packages available to targetted testers was a *bad* idea? I'm not aware of any, and if they had, I would disagree with them. In short, more testing is a "good thing(tm)" and is encouraged. Keep in mind when I said "targetted testers", they need to be aware that these are not public or release builds yet, that is all. -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Better testing of tagged tars
LS Since there is not a clear answer yet, and both the undersigned Distro's feel a better way of testing the tagged tars is needed during the 4-5 days before they are officially released, we'd like to make a proposal on behalf of the Linux distributions Arch Linux and the Chakra-Project. Consistently we are the first to warn and report about bugs in just released tars, but neither distro has a good way of building these packages, store them safely on their servers, and keep them completely hidden from the public. Big question truly is why they should be hidden. Both these distro's do not make it possible for the regular user to find these packages. The repo's where they are placed are not on any official repo list made available to any regular user installing these distro's, only those with inside info how to edit the needed files, will be able to find these packages. We also know there is a fear bug reports for non-released KDE version will surface, but we both educate our testers to report any issues found internally, and if it is clear it is not a distro specific bug, not testers but a distro developer will convey the found bug/issue to the appropriate channel. We, as Arch Linux and Chakra-Project developers would like to propose now to follow the recommendation set by Dirk Mueller in the last long ml thread regarding this issue, and have the build packages from the tagged tars available to our testers during the time period between tagging and release. Arch Linux: Andrea Scarpino and...@archlinux.org Chakra-Project: Manuel Tortosa manutort...@chakra-project.org Anke Boersma abveri...@chakra-project.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
