Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Nov 2015 16:29:39 +0200
From:      Dan Partelly <dan_partelly@rdsor.ro>
To:        Willem Jan Withagen <wjw@digiware.nl>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: DDB patches
Message-ID:  <78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B@rdsor.ro>
In-Reply-To: <564DD856.6030007@digiware.nl>
References:  <B6FDC307-13EB-48AC-8130-C597AB8C06F4@rdsor.ro> <B6BF97C8-9FE3-4ADE-A047-33AF0B879781@freebsd.org> <22918FB9-4DC2-438D-B9F0-C295DD273B50@rdsor.ro> <564DD241.9020801@digiware.nl> <AF0417C8-B129-49D8-A813-3618B527B88D@rdsor.ro> <564DD856.6030007@digiware.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
> Unlike what you suggest here, I see lots of issues in Bugzilla which
> exactly what you describe: enhancements on already available tools.
> I've even submitted a few myself.

Thats great Willem.=20

But no matter what you find odd or not, I am simply following what Ive =
read on some=20
page on freebsd.org that one of the ways of contributing is by =
submitting code=20
on the mailing-lists , where =E2=80=9Csomebody will happily pick up =
changes=E2=80=9D.=20

So, if you continue to find this odd, please take it up with the =
web-masters on=20
freebsd.org to update the resources regarding contributing to the =
project.=20



> On 19 Nov 2015, at 16:10, Willem Jan Withagen <wjw@digiware.nl> wrote:
>=20
> On 19-11-2015 14:53, Dan Partelly wrote:
>>> So not submitting a PR for an issue sound real strange to my ears.
>>=20
>>=20
>> It is NOT a patch for an issue, bug, anything on those lines at all.=20=

>> It adds new features to DDB. Specifically it adds relational=20
>> operators.=20
>>=20
>> Since it doesn't solve any problems, I don't see why it should be =
added=20
>> to a problem database which is used for bug reports.=20
>>=20
>=20
> Unlike what you suggest here, I see lots of issues in Bugzilla which
> exactly what you describe: enhancements on already available tools.
> I've even submitted a few myself.
>=20
> An alternative for this might be submission to Phabricator if you'd =
like
> a more reviewing type of evaluation.
>=20
> --WjW
>=20
>> But then again, it may be just me.
>>=20
>> Dan
>>=20
>>=20
>>=20
>>> On 19 Nov 2015, at 15:44, Willem Jan Withagen <wjw@digiware.nl> =
wrote:
>>>=20
>>> On 19-11-2015 10:57, Dan Partelly wrote:
>>>> Hey Pedro,
>>>>=20
>>>> Thanks a lot , mate.
>>>>=20
>>>> I=E2=80=99m reluctant to put it up as a PR, since some PR are =
outstanding for
>>>> years.
>>>=20
>>> What a strange argument....
>>>=20
>>> Some PR's are fixed within hours/days....
>>> Letting it linger in your mailbox after mental evaluation is not =
going
>>> to do anybody any good.
>>>=20
>>> As far as I understand is the PR database also the collective memory =
of
>>> things on/for/by/near/around the FreeBSD source code. People are
>>> explicitly asked to fill a PR so the issue at hand is not forgotten.
>>>=20
>>> So not submitting a PR for an issue sound real strange to my ears.
>>>=20
>>> But then again that's me.
>>>=20
>>> --WjW
>>>=20
>>>=20
>>>> Adrian,
>>>>=20
>>>> since Pedro has issue with hardware, could you try the patch and =
give
>>>> a resolution on it ? I reviewed it mentally (no FreeBSD atm machine
>>>> on which I could actually  patch the kernel)  and apart style =
changes
>>>> it looks OK . Physically i can test it again fro a couple of days.
>>>> Getting this reviewed & tested / committed or rejected would give =
me
>>>> an idea on how things actually work around here. This is actual =
code
>>>> which you can commit or reject not commentaries only like in the
>>>> thread regarding the binary code reuse.
>>>>=20
>>>>=20
>>>> [qute from libxo thread ]
>>>>>> It's all fine and good making technical decisions based on
>>>>>> drawings and handwaving and philosophizing, but at some point
>>>>>> someone has to do the code. The reason is simple - someone
>>>>>> offered to do the work and push it through. This isn't a
>>>>>> commercial thing where we get to make project >>decisions and
>>>>>> allocate resources - the juniper folk came up with a solution
>>>>>> that
>>>>=20
>>>> Once I see how things work around here once someone wrote  the =
code,
>>>> and get this done one way or another , we could proceed to the
>>>> libification of ifconfig, should you so desire, and you believe we
>>>> can all benefit from it.
>>>>=20
>>>>=20
>>>> Dan
>>>>=20
>>>>=20
>>>>=20
>>>>> On 19 Nov 2015, at 11:17, Pedro Giffuni <pfg@freebsd.org> wrote:
>>>>=20
>>>>>=20
>>>>> Hello;
>>>>>=20
>>>>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
>>>>>> <dan_partelly@rdsor.ro> ha scritto:
>>>>>>=20
>>>>>> Hey Pedro,
>>>>>>=20
>>>>>> some times ago you got some DDB patches from me in which I added
>>>>>> relational ops support from it. The patch was a bit clobbered,=20
>>>>>> but last I know you cleaned it up and put it somewhere on
>>>>>> freebsd.org (prolly your page) up for review.
>>>>>>=20
>>>>>=20
>>>>> It=E2=80=99s here: =
https://people.freebsd.org/~pfg/patches/ddb.patch
>>>>>=20
>>>>> I haven=E2=80=99t tested it though.
>>>>>=20
>>>>>> Could you or Adrian review the patch set , and if it is OK
>>>>>> potentially proceed with a commit ? Or if it is not ok for a
>>>>>> commit , please advice on a follow up.
>>>>>>=20
>>>>>=20
>>>>> I am having hardware issues so I won=E2=80=99t be able to do much =
in a
>>>>> while. Perhaps you should review it and submit it as a PR.
>>>>>=20
>>>>> Pedro.
>>>>>=20
>>>>=20
>>>> _______________________________________________=20
>>>> freebsd-current@freebsd.org mailing list=20
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
>>>> unsubscribe, send any mail to
>>>> "freebsd-current-unsubscribe@freebsd.org"
>>>>=20
>>>=20
>>> _______________________________________________
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to =
"freebsd-current-unsubscribe@freebsd.org"
>>=20
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78FDD0DE-5CA0-44AB-B46C-9C95E4F8DA5B>