Andrew D Kirch a écrit :
Here's the script that I used to generate this. I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch
Jeroen Roovers wrote:
On Wed, 13 Aug 2008 16:13:26 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:
What is the benefit?
There is none really. Allow all use flags to exist in metadata.xml.
It's really more of a clarification to the GLEP if this is allowed.
snip
[1]
On 13:11 Wed 13 Aug , Doug Goldstein wrote:
Further questions regarding use.desc have come up with regard to this
GLEP. My proposed solution would be a potential amendment to the GLEP to
state that
flag name='png' /
Would be allowed. This syntax is not actually disallowed or allowed
Good afternoon fellow developers,
There are three ebuilds that I used to maintain that I no longer have the
hardware for.
I'm hoping that one of you could give them some love. Do assign the bugs to
yourself,
and please drop me from the relevant metadata.xml once you do.
They are:
On Mon, Aug 18, 2008 at 04:18:53PM +0100, Tony Chainsaw Vroon wrote:
There are three ebuilds that I used to maintain that I no longer have the
hardware for.
I'm hoping that one of you could give them some love. Do assign the bugs to
yourself,
and please drop me from the relevant
On Mon, 2008-08-18 at 16:18 +0100, Tony Chainsaw Vroon wrote:
sys-auth/thinkfinger
I have a thinkpad with the right hardware, so I can take this one, did
you already pimp out your other thinkpad packages?
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
signature.asc
Description: This is
On Mon, 2008-08-18 at 15:14 -0400, Olivier Crête wrote:
I have a thinkpad with the right hardware, so I can take this one, did
you already pimp out your other thinkpad packages?
I don't recall of other thinkpad packages that are still mine, but if
you see my name on them, they're all yours.
Doug Goldstein wrote:
What is the benefit?
Regards,
There is none really. Allow all use flags to exist in metadata.xml. It's
really more of a clarification to the GLEP if this is allowed.
Agreed, it has no benefit at all plus would lead to some kind of useless
duplication of
Santiago M. Mola wrote:
I think that's all we need in order to know how were things when the
patch was added and if it needs to be pushed/tracked upstream, removed
in the next version of the package, etc.
Some of us already put these kind of headers, or at least an URL to
upstream bug or a
On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum
[EMAIL PROTECTED] wrote:
Santiago M. Mola wrote:
However, tracking the status of every patch since its inclusion in
portage until it's removed would be a huge work overhead... and I
doubt it's worthy.
I don't think it's a huge work
John Brooks wrote:
Random idea: How about a different bug assignee for maintainer-needed
packages with provided ebuilds/patches? Either something generic, or
try to go for something more category/package specific (herds, etc).
Lots of work for bugwranglers, though. There is a huge difference
Santiago M. Mola wrote:
On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum
[EMAIL PROTECTED] wrote:
Santiago M. Mola wrote:
However, tracking the status of every patch since its inclusion in
portage until it's removed would be a huge work overhead... and I
doubt it's worthy.
I
Zac Medico wrote:
Does package.keywords seem like a good solution for the types of
problems it's meant to solve? Would anybody like to discuss any
alternative approaches?
I think it's a good and easy solution to the problem(s) solar described
in #55321. But as Marius [1] said this can become
On Mon, Aug 18, 2008 at 5:12 PM, Tobias Scherbaum [EMAIL PROTECTED] wrote:
John Brooks wrote:
Random idea: How about a different bug assignee for maintainer-needed
packages with provided ebuilds/patches? Either something generic, or
try to go for something more category/package specific
Jeremy Olexa wrote:
Also, devs willing to maintain
packages but then later retiring and leaving the packages in limbo.
Maybe there should be some policy such as, when devs retire if no one
else steps up to maintain the package, then it automatically gets
moved to sunrise overlay and only
I agree that packages shouldn't be removed or moved because they have no
active developer maintaining them - that is going to take the value of
portage down quite a lot. Outdated packages do too, but not in quite the
same way.
I like the idea of a list or mailing list of developers willing to
Lukasz Damentko [EMAIL PROTECTED] said:
Fair enough. Let me wrap up the IRC part.
1. I'd like to ask Council to discuss possible reactions to our
developer being banned from Freenode without providing us with a
reason. The situation looks like one of Freenode staffers overreacted
over
Ben de Groot [EMAIL PROTECTED] said:
2) Continued presence of forcefully retired devs
It really baffles me that some developers are forcefully retired for
anti-social behavior, but are not consequently banned from the places
where they display this behavior, such as our MLs and IRC channels.
18 matches
Mail list logo
