On 06/01/17 17:14, Alec Warner wrote:
>
> Treecleaning to me is really two things:
>
> 1) developer maintenance time.
> a) It costs nothing to add packages to the tree, and the tree grows
> in size every year.
> b) Removals occur due to obsolescence (X replaces Y, etc) but these
> are strictly le
On 06/01/17 15:01, Rich Freeman wrote:
> On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote:
>> If packages had a field called "BUGS=" it could contain an array of
>> bugs a package is known to contain, but can be conditionally avoided if
>> you're careful.
>>
>> Packages with non-empty BUGS= fie
On 06/01/17 04:27, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman wrote:
>
>> I tend to be firmly in the camp that a package shouldn't be removed
>> unless there is evidence of a serious bug (and that includes things
>> blocking other Gentoo packages).
> I would probably go
On Friday, January 6, 2017 9:13:20 AM EST Michael Mol wrote:
>
> The bigger resource drain, I suspect, will come from maintaining new ebuilds
> of old packages; as eclass development and maintenance seeks to eliminate
> old and buggy code, old ebuilds will need to be dragged along for the ride.
Th
On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>
> The nice thing about ::graveyard or similar is that its a clear demarcation
> between maintained (in tree) and unmaintained (graveyard.) It also means
> that people doing actual maintenance work can basically ignore the
> graveyard as
# Mart Raudsepp (06 Jan 2017)
# No releases of this API version since April 2001, abandoned
# in favour of gtk+:2 for 14 years.
# Masked for removal in 30 days. Bug 604862.
x11-libs/gtk+:1
On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner wrote:
>
> So my understanding of the status quo is that maintainers get to make the
> call with regard to what is reasonable to keep or drop. I'm loathe to add
> additional policy here; mostly because the expectation is that the
> maintainer has the mo
On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman wrote:
>
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packages).
>
>
On 01/06/2017 08:08 AM, Gokturk Yuksek wrote:
> Hi,
>
> Daniel Campbell:
>> On 01/02/2017 09:27 AM, Gokturk Yuksek wrote:
>>> Alexander Shorin:
Hi!
Thanks for sharing. Would be nice see updated README file (it contains
outdated links to Not Found pages) and add few notes about
On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for th
On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
>
> Rich Freeman wrote:
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packa
The "frontbase" USE flag has no consumers that I can find:
gentoo.git $ grep -irl frontbase *
profiles/arch/x86/use.mask
profiles/use.desc
profiles/base/use.mask
If no one objects, I'll drop the flag and its masks.
Ühel kenal päeval, N, 05.01.2017 kell 22:00, kirjutas Daniel Campbell:
> I'm in favor of keeping software around until it breaks. When there's
> a
> non-existent upstream and nobody's willing to take up the helm
> themselves, it's a clear indication that it's in danger of being
> treecleaned. In so
13 matches
Mail list logo
