Re: [gentoo-dev] QA: package.mask policies

2009-11-11 Thread Jeroen Roovers
On Sun, 8 Nov 2009 18:20:00 +0100
Tomáš Chvátal scarab...@gentoo.org 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

2009-11-08 Thread Peter Volkov
В Сбт, 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

2009-11-08 Thread Jeroen Roovers
On Sat, 7 Nov 2009 18:24:10 +0100
Tomáš Chvátal scarab...@gentoo.org 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

2009-11-08 Thread Tomáš Chvátal
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 scarab...@gentoo.org 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

2009-11-07 Thread William Hubbs
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