Peter Volkov wrote:
> В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
>> Peter Volkov wrote:
We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
the default ACCEPT_KEYWORDS setting for all profiles, and instruct
unstable users to add "~noarch" to ACCEPT_KEYWORDS.
>
В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
> Peter Volkov wrote:
> >> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> >> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> >> unstable users to add "~noarch" to ACCEPT_KEYWORDS.
> >
> > Looks like this
В Вск, 08/11/2009 в 10:05 +0100, Fabian Groffen пишет:
> On 07-11-2009 17:54:25 +0300, Peter Volkov wrote:
> > > We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> > > the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> > > unstable users to add "~noarch" to ACCE
Nirbheek Chauhan wrote:
> On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico wrote:
>> Peter Volkov wrote:
>>> Looks like this will not work for all noarch packages. Stardict
>>> dictionary itself is noarch, but it RDEPENDS on stardict package which
>>> is keyworded only on some archs. So we'll be forced
On 07-11-2009 17:54:25 +0300, Peter Volkov wrote:
> > > Sounds like we could benefit from the "noarch" approach known in the RPM
> > > world, such that all these packages can also be immediately keyworded
> > > and stabilised for all arches. Would greatly simplify things for a
> > > great deal of
On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico wrote:
> Peter Volkov wrote:
>> Looks like this will not work for all noarch packages. Stardict
>> dictionary itself is noarch, but it RDEPENDS on stardict package which
>> is keyworded only on some archs. So we'll be forced either to keyword
>> stardict
Peter Volkov wrote:
>> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
>> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
>> unstable users to add "~noarch" to ACCEPT_KEYWORDS.
>
> Looks like this will not work for all noarch packages. Stardict
> dictionary i
В Птн, 06/11/2009 в 14:07 -0800, Zac Medico пишет:
> Fabian Groffen wrote:
> > On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> >> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty wrote:
> >>> In the past when smaller arches were not that active we used to mark
> >>> Java packages stable after
Hi!
On Thu, 05 Nov 2009, Petteri Räty wrote:
> In the past when smaller arches were not that active we used to
> mark Java packages stable after testing by at least one arch
> team. The probability to find arch specific issues in something
> like Java is not so high so I think arrangements like t
On Fri, 2009-11-06 at 23:52 +0100, Rémi Cardona wrote:
> I just don't see how "noarch" will help the portage tree.
I would propose to use it for the 100+ app-xemacs packages, all of which
run within the virtual machine that is xemacs. Obviously
app-editors/xemacs, the editor itself, will still be
> In the past when smaller arches were not that active we used to mark
> Java packages stable after testing by at least one arch team. The
> probability to find arch specific issues in something like Java is not
> so high so I think arrangements like this are acceptable when the arch
> teams have
Tobias Klausmann wrote:
> Hi!
>
> On Wed, 04 Nov 2009, Ryan Hill wrote:
>> Is there any interest in allowing certain packages to be stabilized by the
>> maintainer without going through the arch teams? I always feel guilty when i
>> file stabilization bugs for app-doc pkgs.
>
> I think for bugs
Ben de Groot wrote:
> What about ppc64? They are MONTHS behind on stabilization,
> even for security bugs (see bug 281821 for example). The Qt team
> feels this is no longer acceptable. We propose that any arch that
> can't keep up will be demoted to experimental status.
>
>
ppc is also fairly f
On Wed, Nov 4, 2009 at 11:31 PM, Tobias Klausmann wrote:
> [0] Yes, armin76 helps, but he does so for many arches (and
> around of applause for that), but the majority of bugs for alpha
> are on my plate.
>
+++, armin76 does an awesome job of keywording/stabilizing. I really
love how he comes dow
Hi!
On Wed, 04 Nov 2009, Christian Faulhammer wrote:
> Ben de Groot :
> > What about ppc64? They are MONTHS behind on stabilization,
> > even for security bugs (see bug 281821 for example). The Qt team
> > feels this is no longer acceptable. We propose that any arch that
> > can't keep up will be
Hi,
Ben de Groot :
> What about ppc64? They are MONTHS behind on stabilization,
> even for security bugs (see bug 281821 for example). The Qt team
> feels this is no longer acceptable. We propose that any arch that
> can't keep up will be demoted to experimental status.
I surely subscribe to th
What about ppc64? They are MONTHS behind on stabilization,
even for security bugs (see bug 281821 for example). The Qt team
feels this is no longer acceptable. We propose that any arch that
can't keep up will be demoted to experimental status.
--
Ben de Groot
Gentoo Linux developer (qt, media, lx
Hi,
Markos Chandras :
> This is way I keep asking for a complete report of manpower at least
> for amd64 and x86 arch teams ( and update the project pages as
> well ). We need real numbers so we adjust respectively the number of
> stabilization bugs we assign to them.
x86
On Monday 02 November 2009 16:17:07 Christian Faulhammer wrote:
> Hi,
>
> Arfrever Frehtes Taifersar Arahesis :
> > Some packages have new releases more than once a month and sometimes
> > it's reasonable to not skip stabilization of any version. Given
> > version of a package is usually no longer
Hi,
Arfrever Frehtes Taifersar Arahesis :
> Some packages have new releases more than once a month and sometimes
> it's reasonable to not skip stabilization of any version. Given
> version of a package is usually no longer tested by users after
> release of a newer version, so I suggest the follo
On Sun, 1 Nov 2009 17:36:30 +0100
Arfrever Frehtes Taifersar Arahesis wrote:
> Some packages have new releases more than once a month and sometimes it's
> reasonable
> to not skip stabilization of any version. Given version of a package is
> usually no
> longer tested by users after release of
21 matches
Mail list logo
