On 2012.01.19. 3:06, Igor Mozolevsky wrote:
You mean something like:http://people.freebsd.org/~edwin/gnats/ ?
It is not up to date. I have not closed too many PRs in the last 3
months and I'm still on the top PR closers list.
Gabor
___
freebsd
Igor Mozolevsky wrote:
On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote:
Idea 2: Give it status. Set up a web page with PR fixing stats
name/handle..total PRs fixed...fixed in last 12 months...average fixed/year
Sheldon..150...90
On Wed, 18 Jan 2012 19:57:33 -0500, Dieter BSD wrote:
Andriy writes:
And dealing with PRs is not always exciting.
Neither is brushing your teeth or cleaning the kitchen, but most of
us
manage to do them at least occasionally. Part of being a grown up.
Instead of looking for a stick to hold
On Thu, Jan 19, 2012 at 06:23:00AM +, Pegasus Mc Cleaft wrote:
Idea 1: Fix 'n' PRs, get a tee-shirt, fridge magnet, plush daemon, ...
Idea 2: Give it status. Set up a web page with PR fixing stats
name/handle..total PRs fixed...fixed in last 12 months...average
On 19 January 2012 11:55, Julian H. Stacey j...@berklix.com wrote:
Igor Mozolevsky wrote:
On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote:
Idea 2: Give it status. Set up a web page with PR fixing stats
name/handle..total PRs fixed...fixed in last 12 months...average
PR's than newer PR's.
Older might be harder, or it might mean boring, or seen as less important.
It might be worth giving more points for old PRs regardless, to help
get the old ones fixed. The main goal here is to get PRs fixed.
It just feels wrong to have PRs sitting around for years on end
On Thu, Jan 19, 2012 at 5:30 PM, Dieter BSD dieter...@engineer.com wrote:
One problem is PRs that are closed without being fixed. Some of these
are legitimate (dups, submitter error, already fixed in newer release, ...)
but some shouldn't have been closed.
Please let me know which ones
Andriy writes:
And dealing with PRs is not always exciting.
Neither is brushing your teeth or cleaning the kitchen, but most of us
manage to do them at least occasionally. Part of being a grown up.
Instead of looking for a stick to hold over developers to get them
to fix PRs, let's look
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Dieter BSD
Sent: Wednesday, January 18, 2012 4:58 PM
To: freebsd-hackers@freebsd.org
Subject: Getting PRs fixed (was: Re: ...focus, longevity, and lifecycle
On 19 January 2012 00:57, Dieter BSD dieter...@engineer.com wrote:
Idea 2: Give it status. Set up a web page with PR fixing stats
name/handle..total PRs fixed...fixed in last 12 months...average fixed/year
Sheldon..150...9072
Leonard..131
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Igor Mozolevsky
Sent: Wednesday, January 18, 2012 6:06 PM
To: Dieter BSD
Cc: freebsd-hackers@freebsd.org
Subject: Re: Getting PRs fixed (was: Re: ...focus, longevity
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Igor Mozolevsky
Sent: Wednesday, January 18, 2012 6:06 PM
To: Dieter BSD
Cc: freebsd-hackers@freebsd.org
Subject: Re: Getting PRs fixed (was: Re: ...focus, longevity
On 01/18/2012 06:57 PM, Dieter BSD wrote:
Andriy writes:
And dealing with PRs is not always exciting.
Neither is brushing your teeth or cleaning the kitchen, but most of us
manage to do them at least occasionally. Part of being a grown up.
Instead of looking for a stick to hold over
On Wed, Jan 18, 2012 at 07:59:48PM -0600, Stephen Montgomery-Smith wrote:
On 01/18/2012 06:57 PM, Dieter BSD wrote:
Andriy writes:
And dealing with PRs is not always exciting.
Neither is brushing your teeth or cleaning the kitchen, but most of us
manage to do them at least
Idea 1: Fix 'n' PRs, get a tee-shirt, fridge magnet, plush daemon, ...
Idea 2: Give it status. Set up a web page with PR fixing stats
name/handle..total PRs fixed...fixed in last 12 months...average
fixed/year Sheldon..150...9072
a lot of PRs for obsolete hardware and
versions will get closed up, thereby making it easier for those of us
trying to pick our way through and see what is still new and relevant
and in need of some love and care and attention. If somebody still has
the problem and it's an issue, it just gets
to
see if the problem still exists?
It's just that way, I think a lot of PRs for obsolete hardware and
versions will get closed up, thereby making it easier for those of us
trying to pick our way through and see what is still new and relevant
and in need of some love and care
Paul Robinson [EMAIL PROTECTED] writes:
How about everything that hasn't been touched in 3 years gets put into
a special state of closed-believed-dead, everything over 12 months
(or 6?) gets the same AFTER an e-mail has been sent out to the
originator to see if the problem still exists?
The
Hi!
For a long time I'v been disapointed with features in ports system. No ports
conflicts checking and other stuff.
Last year I'v begun make some things - I'v found obsoleted bin/13649 and
ports/13650 PRs that introduce a ports conflics checking, I'v asked in
freebsd-ports and portmgr about
make some things - I'v found obsoleted bin/13649
and
ports/13650 PRs that introduce a ports conflics checking, I'v asked in
freebsd-ports and portmgr about this patches fortune. I'v got an
answer from
portmgr: it's good features and could I adapt this patches for current
bsd.port.mk and pkg_tools
On Thu, Jan 16, 2003 at 08:15:44PM +0300, Sergey Matveychuk wrote:
It was 1 December 2002. Till now there is no reactions.
I'v wrote a few mails to portmgr but I'v just ignored.
You've forgotten that we've been deep in the middle of a release cycle
for the past several months. I want to look
There are two open PRs relating to portmap (in 4.x) not allowing you to
specify on the command line that it should bind only to the localhost
interface (bin/30235, bin/34919). Of the two, I think the patch included
with 30235 is the cleaner solution.
However, it appears that -CURRENT doesn't
I created an address to use with send-pr, and it's been getting spam.
Perhaps mail sent with send-pr can have the addresses slightly munged
before they're placed on a web page?
Is there a more appropriate list for discussing this?
--
Ben
An art scene of delight
I created this to be ...
Hello,
could someone please close kern/24628. This has been fixed.
And could please somebody commit the one-liner in kern/27906.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To
* Harti Brandt [EMAIL PROTECTED] [010713 03:03] wrote:
Hello,
could someone please close kern/24628. This has been fixed.
closed.
And could please somebody commit the one-liner in kern/27906.
Assigned to Julian.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn
On Sat, Mar 10, 2001 at 12:03:18PM -0800, Jordan Hubbard wrote:
The handbook is wrong. Unidiffs are a far more advanced lifeform
than context diffs. :)
- Jordan
[scads of other replies deleted]
Okay, okay, okay...
docs/25735 is a patch for this. I assume one of the -doc team will
pick
with PRs. I've had several people claim that unified diffs are the
way to go, and that the handbook is just wrong.
Is the Handbook correct, or are unified diffs preferred? I'll be
happy to fix my article and submit a PR to correct the Handbook if
this is the case.
Thanks,
Michael
--
Michael Lucas
diffs were the correct way to submit patches
with PRs. I've had several people claim that unified diffs are the
way to go, and that the handbook is just wrong.
Unified diffs are also context diffs.
Context diffs are named such because they contain undisturbed context
around the changed lines
O'Reilly published yesterday, I stated (per the
Handbook) that context diffs were the correct way to submit patches
with PRs. I've had several people claim that unified diffs are the
way to go, and that the handbook is just wrong.
Unified diffs are also context diffs.
Context diffs are named
the correct way to submit patches
with PRs. I've had several people claim that unified diffs are the
way to go, and that the handbook is just wrong.
Is the Handbook correct, or are unified diffs preferred? I'll be
happy to fix my article and submit a PR to correct the Handbook if
this is the case
The handbook is wrong. Unidiffs are a far more advanced lifeform
than context diffs. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Unified diffs are also context diffs.
Context diffs are named such because they contain undisturbed context
around the changed lines, unlike normal diffs.
Erm, no. :)
Both context and unidiffs show surrounding context, it's simply the
meta-data format which changes. In the case of
In message [EMAIL PROTECTED], Jordan Hubbard writes:
Unified diffs are also context diffs.
Context diffs are named such because they contain undisturbed context
around the changed lines, unlike normal diffs.
Erm, no. :)
Both context and unidiffs show surrounding context, it's simply the
On 10-Mar-01 Jordan Hubbard wrote:
The handbook is wrong. Unidiffs are a far more advanced lifeform
than context diffs. :)
- Jordan
As phk explained, a unified diff is a context diff. :)
If many changed lines are interleaved with unchanged lines, I find that a
context diff is far easier
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Jordan Hubbard writes:
Both context and unidiffs show surrounding context, it's simply the
meta-data format which changes. [...]
I repeat, with added emphasis: [...]
You're both either slightly off, or not expressing
In message [EMAIL PROTECTED] Michael Lucas writes:
: Is the Handbook correct, or are unified diffs preferred? I'll be
: happy to fix my article and submit a PR to correct the Handbook if
: this is the case.
diff -c or diff -u is 1000% better than palin diff. That's what is
ment by "context" in
diffs were the correct way to submit patches
with PRs. I've had several people claim that unified diffs are the
way to go, and that the handbook is just wrong.
Is the Handbook correct, or are unified diffs preferred? I'll be
happy to fix my article and submit a PR to correct the Handbook
37 matches
Mail list logo
