Re: [gentoo-dev] QA: package.mask policies
On Sun, 8 Nov 2009 18:20:00 +0100 Tomáš Chvátal wrote: > But if we look on tag of screen-4.0.3 or its release: > screen-4.0.2.tar.gz27-Jan-2004 05:46 821K > screen-4.0.2.tar.gz.sig27-Jan-2004 05:47 65 > screen-4.0.3.tar.gz07-Aug-2008 06:30 821K > screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 > You see the pattern? It is 1 year newer than it. Correct. The snapshot should have been named _pre20070403. Regards, jer
Re: [gentoo-dev] QA: package.mask policies
Dne neděle 08 Listopad 2009 17:57:10 Jeroen Roovers napsal(a): > On Sat, 7 Nov 2009 18:24:10 +0100 > > Tomáš Chvátal wrote: > > * Masking beta... > > This masks are good if the software release is KNOWN to break > > previous behaviour or degrade user experience. Otherwise the software > > should not be masked (its TESTING for purpose, not stable). > > Also the maintainer should watch if the testing branch is still > > relevant (why on earth we have masked 4.0.3_p20070403 version of > > screen when newer 4.3 is stable ;]) and remove the branch+mask when > > needed. > > I agree with your criticism (i.e. that the mask should not be there, > especially not for "testing" as what the mask does is *prevent* testing > instead of enabling it), but must note that your version sorting > algorithm appears to be flawed: pkg-vX_pY (for patch level) is always > greater than pkg-vX. > > > Regards, > jer > I agree that _p is newer than that. But if we look on tag of screen-4.0.3 or its release: screen-4.0.2.tar.gz27-Jan-2004 05:46 821K screen-4.0.2.tar.gz.sig27-Jan-2004 05:47 65 screen-4.0.3.tar.gz07-Aug-2008 06:30 821K screen-4.0.3.tar.gz.sig07-Aug-2008 06:30 65 You see the pattern? It is 1 year newer than it. Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] QA: package.mask policies
On Sat, 7 Nov 2009 18:24:10 +0100 Tomáš Chvátal wrote: > * Masking beta... > This masks are good if the software release is KNOWN to break > previous behaviour or degrade user experience. Otherwise the software > should not be masked (its TESTING for purpose, not stable). > Also the maintainer should watch if the testing branch is still > relevant (why on earth we have masked 4.0.3_p20070403 version of > screen when newer 4.3 is stable ;]) and remove the branch+mask when > needed. I agree with your criticism (i.e. that the mask should not be there, especially not for "testing" as what the mask does is *prevent* testing instead of enabling it), but must note that your version sorting algorithm appears to be flawed: pkg-vX_pY (for patch level) is always greater than pkg-vX. Regards, jer
Re: [gentoo-dev] QA: package.mask policies
В Сбт, 07/11/2009 в 18:24 +0100, Tomáš Chvátal пишет: > * Masking beta... > This masks are good if the software release is KNOWN to break previous > behaviour or degrade user experience. Otherwise the software should not be > masked (its TESTING for purpose, not stable). God no! If we'll start to do this way we'll loose a way to test packages that are supposed to go stable. It was told many times that testing branch is for testing ebuilds, not for packages and if upstream conciders them beta mask them. Or do you want Gentoo to have upstream suggested _only for testers_ versions end in stable tree? > Also the maintainer should watch if the testing branch is still relevant (why > on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is > stable ;]) and remove the branch+mask when needed. Yup, such things happen, but this does not mean we should stop using package.mask for beta software. -- Peter.
Re: [gentoo-dev] QA: package.mask policies
Hi all, I'm not QA, but I'll go ahead and add my comments to this also. On Sat, Nov 07, 2009 at 06:24:10PM +0100, Tom Chv??tal wrote: > * Masking beta... > This masks are good if the software release is KNOWN to break previous > behaviour or degrade user experience. Otherwise the software should not be > masked (its TESTING for purpose, not stable). Agreed. If it works and does not cause issues for users or degrade their experience, it should be in ~arch, not in p.mask. > Also the maintainer should watch if the testing branch is still relevant (why > on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is > stable ;]) and remove the branch+mask when needed. Definitely. If a newer version of a package is stable, or in ~arch for that matter, why do we still have the old version in the tree and masked while the newer version is unmasked? > * Masking live... > Heck no. This is not proper usage. Just use keywords mask. KEYWORDS="". > Problem solved and the package.mask is smaller. (Note, in overlays do what > ever you want, since it does not polute the main mask from g-x86). True. If we mask live ebuilds with KEYWORDS="", there isn't a reason to put them in p.mask that I can think of. > * Masking stable releases... > Here i found most interesting stuff around (for example mask for testing from > 2006, yeah not ~ material after 3 years?! :P) > There should be policy defined that you can add the new release under p.mask > if > you see it fit, but the mask can stay only for 6 months (less/more, > suggestions?) and then it must be unmasked, or have really high activity on > tracker bug and good reasoning (mask for ruby-1.9 and so on). Off the top of my head, I think this falls under category 1 above as well. If a new release of a package and everything that uses the new package can be installed in a way that does not degrade the user's experience if they want to use the older release, it doesn't need to be in p.mask. In general, I don't think a new release of a package should be added to p.mask unless it fits category 1 above. Things that have been "masked for testing" for years need to have a decision made about them -- keep them in the tree and unmask them or remove them. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpOXpVFPLLey.pgp Description: PGP signature
[gentoo-dev] QA: package.mask policies
Hi, since I aint got blag i will polute our lovely mailing list (sorry if i hit some in-middle flame :P). Currently i've been reviewing the package.mask file (since we have to keep with it for a while [no package.mask folder near us :)] we have to trim it down and keep sane). NOTE: The p.mask as folder situation was agreed upon so dont reply about THAT but focus on what follows below this point in your replies. While i was reading it there are 5 major use cases for stuff in it. - Masking beta/rc/alpha/development_branch stuff - Masking live ebuild - Masking stable releases for testing - Masks for removal (those are quite moving in and out ;]) - Masks for security issues (mostly games) So lets go one by one and rationalize on wether we need it or not. * Masking beta... This masks are good if the software release is KNOWN to break previous behaviour or degrade user experience. Otherwise the software should not be masked (its TESTING for purpose, not stable). Also the maintainer should watch if the testing branch is still relevant (why on earth we have masked 4.0.3_p20070403 version of screen when newer 4.3 is stable ;]) and remove the branch+mask when needed. * Masking live... Heck no. This is not proper usage. Just use keywords mask. KEYWORDS="". Problem solved and the package.mask is smaller. (Note, in overlays do what ever you want, since it does not polute the main mask from g-x86). * Masking stable releases... Here i found most interesting stuff around (for example mask for testing from 2006, yeah not ~ material after 3 years?! :P) There should be policy defined that you can add the new release under p.mask if you see it fit, but the mask can stay only for 6 months (less/more, suggestions?) and then it must be unmasked, or have really high activity on tracker bug and good reasoning (mask for ruby-1.9 and so on). * Masks for removal... Nothing to say here, they are done quite well right now, and treecleaners kill them when they got time :] * Masks for security... These are the only one masks that are permanent (probably none will fix the nethack,...). They should be maybe even kept on the bottom of the package.mask file all together and separated with some comment, so they are always easy to spot from first look on that file. Any more ideas/suggestions to the above? Cheers Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/Sunrise/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 signature.asc Description: This is a digitally signed message part.
