On Sat, 2022-12-03 at 09:19 +0100, Ulrich Mueller wrote:
> > > > > > On Sat, 03 Dec 2022, Michał Górny wrote:
>
> > --- /dev/null
> > +++ b/eclass/app-alternatives.eclass
> > @@ -0,0 +1,84 @@
> > +# Copyright 2022 Gentoo Authors
> > +# Distributed under the terms of the GNU General Public License
> On Sat, 03 Dec 2022, Michał Górny wrote:
> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED
> bug states with a simple NEW state. Why?
> 1. Only a handful of developers actually uses these two statuses
> in a meaningful way.
> 2. Some users are confused and demotivated
> On Sat, 03 Dec 2022, Michał Górny wrote:
> --- /dev/null
> +++ b/eclass/app-alternatives.eclass
> @@ -0,0 +1,84 @@
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: app-alternatives.eclass
> +# @MAINTAINER:
> +# Michał
On 12/3/22 10:53, Michał Górny wrote:
On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote:
Then rename UNCONFIRMED to NEW-WITH-SUGAR-ON-TOP-WE-ARE-A-HAPPY-
COMMUNITY,
Done.
I do search for bugs using pybugz and gre3p for CONFIRMED and do wonder
if/when I shall grep for NEW too ?
--
On 03/12/2022 12.34, Michał Górny wrote:
On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote:
On 03/12/2022 08.09, Michał Górny wrote:
Hi,
I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
states with a simple NEW state. Why?
1. Only a handful of developers
On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote:
> On 03/12/2022 12.34, Michał Górny wrote:
> > On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote:
> > > On 03/12/2022 08.09, Michał Górny wrote:
> > > > Hi,
> > > >
> > > > I'd like to propose replacing the current UNCONFIRMED and
On 03/12/2022 14.50, Michał Górny wrote:
On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote:
I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and
other (affected) persons, to decide if they need to "chase" the issue's
assigned entity.
Assume looking at the open bugs
On Sat, 2022-12-03 at 09:39 +0100, Ulrich Mueller wrote:
> > > > > > On Sat, 03 Dec 2022, Michał Górny wrote:
>
> > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED
> > bug states with a simple NEW state. Why?
>
> > 1. Only a handful of developers actually uses these two
# Andreas Sturmlechner (2022-12-03)
# No purpose anymore after
signature.asc
Description: This is a digitally signed message part.
> On Sat, 03 Dec 2022, Ulrich Mueller wrote:
> Some people found that not satisfactory, so NEW and ASSIGNED were
> replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED
> which was removed with the same change.) Unfortunately, I cannot find
> the old discussion, but [1] suggests
On 03/12/2022 13.20, Michał Górny wrote:
On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote:
On 03/12/2022 12.34, Michał Górny wrote:
On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote:
On 03/12/2022 08.09, Michał Górny wrote:
Hi,
I'd like to propose replacing the current
On 12/3/22 08:59, Florian Schmaus wrote:
On 03/12/2022 14.50, Michał Górny wrote:
On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote:
I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and
other (affected) persons, to decide if they need to "chase" the issue's
assigned
On 03/12/2022 08.09, Michał Górny wrote:
Hi,
I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
states with a simple NEW state. Why?
1. Only a handful of developers actually uses these two statuses
in a meaningful way.
2. Some users are confused and demotivated by having
On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote:
> On 03/12/2022 08.09, Michał Górny wrote:
> > Hi,
> >
> > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
> > states with a simple NEW state. Why?
> >
> > 1. Only a handful of developers actually uses these two
> On Sat, 03 Dec 2022, Michał Górny wrote:
>> > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED
>> > bug states with a simple NEW state. Why?
>>
>> > 1. Only a handful of developers actually uses these two statuses
>> > in a meaningful way.
>>
>> > 2. Some users are
On Sat, 2022-12-03 at 14:45 +0100, Florian Schmaus wrote:
> I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and
> other (affected) persons, to decide if they need to "chase" the issue's
> assigned entity.
>
> Assume looking at the open bugs list of a developer. If the
Requires sample files from tree-sitter-c to be available, but these
files are not installed with dev-libs/tree-sitter-c, and are instead
expected to be pulled down via making the tree-sitter-c javascript
wrapper package a dependency in package.json. However since we invoke
"tree-sitter test"
These packages have a standard way of implementing a test corpus that
can be invoked by "tree-sitter test" from dev-util/tree-sitter-cli.
Some have additional platform-specific tests that are invoked in a
custom manner, but these are on top of the basic test corpus.
See:
On Sat, Dec 3, 2022 at 2:09 AM Michał Górny wrote:
>
> Hi,
>
> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
> states with a simple NEW state. Why?
>
> 1. Only a handful of developers actually uses these two statuses
> in a meaningful way.
>
> 2. Some users are confused
dev-util/tree-sitter-cli will now be a conditional test dep for packages
inheriting tree-sitter-grammar.eclass, which is written in rust, so mask
it on rustless profiles.
Bug: https://bugs.gentoo.org/844223
See: https://github.com/gentoo/gentoo/pull/28529
Signed-off-by: Matoro Mahri
---
Hi all,
I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug
states with a simple NEW state. Why?
1. Only a handful of developers actually uses these two statuses
in a meaningful way.
2. Some users are confused and demotivated by having their bugs stay
UNCONFIRMED for a
These packages have a standard way of implementing a test corpus that
can be invoked by "tree-sitter test" from dev-util/tree-sitter-cli.
Some have additional platform-specific tests that are invoked in a
custom manner, but these are on top of the basic test corpus.
See:
> On Sat, 03 Dec 2022, Sam James wrote:
> # Oz Tiram (2022-12-03)
> # Mate-desktop no longer supports gtk+:2, so there is
> # no need for this package. Removal on 2023-01-03.
> x11-themes/mate-themes-meta
Is x11-themes/mate-themes obsolete then? mate-base/mate[themes] no
longer depends on
# Hans de Graaff (2022-12-03)
# ruby27-only packages with no other reverse dependencies.
# Last releases in 2013 and 2015. Removal in 30 days.
dev-ruby/textpow
dev-ruby/ultraviolet
signature.asc
Description: This is a digitally signed message part
24 matches
Mail list logo
