Re: DDB patches

[Dan Partelly]

Hi Pedro,

I think you confuse blackmailing with something much simpler and pragmatic. 
One needs to asses how things work in your project for real before investing 
too much time. 

Adrian was contemplating the fact that none writes code,  so I had some code at 
the
hand with with I can see how things work around here. You want it, good. 
You don't want it, its also good. You want to trash it… also good. 
Its all the same to me. This process is aimed to  give me an idea , if your 
workflow 
works for me.  

 
> you discuss your idea and try to get some consensus in the 
> lists/IRC/conferences.

I am not particularly interested in promoting ideas and gathering consensus. I 
am not a 
politician. I happen to believe that translating some utilities from the  base 
to libraries 
 is a very valuable  addition to the project. Id rather spend time with my 
familty and walk
around the city in nature with my GSD dog than embarking on some twisted 
political
campaign. 

> We are particularly NOT interested in code where the original contributor 
> will walk
> away as soon as he/she receives criticism or has plans that do not match ours.

Undeerstandable. 

> 
> Libxo already went through this process.
> 


>> Libxo already went through this process.

It did, aint it ? And I seen what kind of “consensus” the xoification of base 
caused. Apparently, adopted for no better reason than “someone wrote code” .

> If this is not your ideal workflow … fork your own BSD, a lot of intelligent
> people do just that.

Not the best thing one can do… but I guess to each his own. 

>> 
> 
> Wrong approach. You can’t really blackmail someone into taking your changes.
> 
> Things work like this:
> 
> - You discuss your idea and try to get some consensus in the 
> lists/IRC/conferences.
> - You *write* a specific proof of concept and get it discussed.
> - You finish your prototype.
> - Your work gets rejected until you get something some committer is willing 
> to support.
> - When there are no objections and a committer feels like it, your work gets 
> committed,
> which doesn’t necessarily mean it will stay.
> - You are expected to maintain it.
> 
> Libxo already went through this process.
> 
> We are particularly NOT interested in code where the original contributor 
> will walk
> away as soon as he/she receives criticism or has plans that do not match ours.
> If this is not your ideal workflow … fork your own BSD, a lot of intelligent
> people do just that.
> 
> Pedro.
> 
>> 
>> Dan
>> 
>> 
>> 
>>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>> 
>>> 
>>> Hello;
>>> 
 Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly 
  ha scritto:
 
 Hey Pedro,
 
 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, 
 but last I know you cleaned it up and put it somewhere on freebsd.org 
 (prolly your page) up for review. 
 
>>> 
>>> It’s here:
>>> https://people.freebsd.org/~pfg/patches/ddb.patch
>>> 
>>> I haven’t tested it though.
>>> 
 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. 
 
>>> 
>>> I am having hardware issues so I won’t be able to do much in a while.
>>> Perhaps you should review it and submit it as a PR.
>>> 
>>> Pedro.
>>> 
>> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Pedro Giffuni]

On 11/20/15 08:54, Dan Partelly wrote:

Hi Pedro,

I think you confuse blackmailing with something much simpler and pragmatic.
One needs to asses how things work in your project for real before investing
too much time.



A template for blackmailing is usually in the form:

"I will do this (usually involving saving the world and/or your
evidently miserable life) but first you will have to do this
(unrelated) thing to see that you are worthy."


Adrian was contemplating the fact that none writes code,  so I had some code at 
the
hand with with I can see how things work around here. You want it, good.
You don't want it, its also good.


I don't know about the (new) libxo discussion, but the ddb thing is 
unrelated to such discussion, and when I first looked at it it was

not in good shape.

 You want to trash it… also good.

Its all the same to me. This process is aimed to  give me an idea , if your 
workflow
works for me.



In my experience it is always easier for new contributors to adapt to
the community than to re-shape it. You can try.. but there will likely
be pain.





you discuss your idea and try to get some consensus in the 
lists/IRC/conferences.


I am not particularly interested in promoting ideas and gathering consensus. I 
am not a
politician. I happen to believe that translating some utilities from the  base 
to libraries
  is a very valuable  addition to the project. Id rather spend time with my 
familty and walk
around the city in nature with my GSD dog than embarking on some twisted 
political
campaign.


We are particularly NOT interested in code where the original contributor will 
walk
away as soon as he/she receives criticism or has plans that do not match ours.


Undeerstandable.



Libxo already went through this process.





Libxo already went through this process.


It did, aint it ? And I seen what kind of “consensus” the xoification of base
caused. Apparently, adopted for no better reason than “someone wrote code” .




There was a GSoC that did a different implementation but libxo was
specifically made for FreeBSD after a long discussion.

That doesn't mean everyone is happy with it or that it is perfect
but it went in through an open process. The process, call it politics
or consensus or community building, is important in any opensource
effort that aims to be sustainable.

These days github makes it pretty easy for anyone to play with their
new ideas to the limit. When I mean you can fork your own BSD, I
mean it. You can experiment on your own without waiting on us to decide:
eventually we may decide to bring it in ...

Pedro.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Dan Partelly]

> A template for blackmailing is usually in the form:
> 
> "I will do this (usually involving saving the world and/or your
> evidently miserable life) but first you will have to do this
> (unrelated) thing to see that you are worthy.”


It is interesting how much you dwell on this.  I just told you what reasons 
I have to take this path, and that it doesn't include the intent to blackmail 
anyone. I want to experience the process with already existing code, 
before contemplating more in the future. Is this:
 1. So hard to understand ?
 2. Wrong in the eyes of god, or something ?

Leaving aside saving the world, and / or miserable lives , damsels in distress 
and other 
fantasies, you will just have to  accept what I said, instead of insisting you 
know better what
is in my head. 

> . You can try.. but there will likely
> be pain.

You see this from a very interesting angle. I am not trying to change you or 
your community. 
No sane person would do that,  knowing how powerful social forces are. Do you 
really think
I would embark on such a fool’s errand ? I told you, I like to spend time with 
walking with my dog :P 
What I am trying to determine where to position myself. 

> That doesn't mean everyone is happy with it or that it is perfect
> but it went in through an open process. 

Ill take your word for it. But in my opinion the result of this open process is 
that:
1. A distasteful solution was adopted into the base. 
2. Still people think that it was adopted only because someone had the code 
(Juniper)
3. While others seems to think Junpier ppl pushed it (Im not saying they did, 
but you can certainly push something pressing the correct political buttons.

> You can experiment on your own without waiting on us to decide:
> eventually we may decide to bring it in …

You tell me nothing new, but thank you.



> On 20 Nov 2015, at 17:56, Pedro Giffuni  wrote:
> 
> 
> 
> On 11/20/15 08:54, Dan Partelly wrote:
>> Hi Pedro,
>> 
>> I think you confuse blackmailing with something much simpler and pragmatic.
>> One needs to asses how things work in your project for real before investing
>> too much time.
>> 
> 
> A template for blackmailing is usually in the form:
> 
> "I will do this (usually involving saving the world and/or your
> evidently miserable life) but first you will have to do this
> (unrelated) thing to see that you are worthy."
> 
>> Adrian was contemplating the fact that none writes code,  so I had some code 
>> at the
>> hand with with I can see how things work around here. You want it, good.
>> You don't want it, its also good.
> 
> I don't know about the (new) libxo discussion, but the ddb thing is unrelated 
> to such discussion, and when I first looked at it it was
> not in good shape.
> 
> You want to trash it… also good.
>> Its all the same to me. This process is aimed to  give me an idea , if your 
>> workflow
>> works for me.
>> 
> 
> In my experience it is always easier for new contributors to adapt to
> the community than to re-shape it. You can try.. but there will likely
> be pain.
> 
> 
>> 
>>> you discuss your idea and try to get some consensus in the 
>>> lists/IRC/conferences.
>> 
>> I am not particularly interested in promoting ideas and gathering consensus. 
>> I am not a
>> politician. I happen to believe that translating some utilities from the  
>> base to libraries
>>  is a very valuable  addition to the project. Id rather spend time with my 
>> familty and walk
>> around the city in nature with my GSD dog than embarking on some twisted 
>> political
>> campaign.
>> 
>>> We are particularly NOT interested in code where the original contributor 
>>> will walk
>>> away as soon as he/she receives criticism or has plans that do not match 
>>> ours.
>> 
>> Undeerstandable.
>> 
>>> 
>>> Libxo already went through this process.
>>> 
>> 
>> 
 Libxo already went through this process.
>> 
>> It did, aint it ? And I seen what kind of “consensus” the xoification of base
>> caused. Apparently, adopted for no better reason than “someone wrote code” .
>> 
> 
> 
> There was a GSoC that did a different implementation but libxo was
> specifically made for FreeBSD after a long discussion.
> 
> That doesn't mean everyone is happy with it or that it is perfect
> but it went in through an open process. The process, call it politics
> or consensus or community building, is important in any opensource
> effort that aims to be sustainable.
> 
> These days github makes it pretty easy for anyone to play with their
> new ideas to the limit. When I mean you can fork your own BSD, I
> mean it. You can experiment on your own without waiting on us to decide:
> eventually we may decide to bring it in ...
> 
> Pedro.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Pedro Giffuni]

On 11/20/2015 11:28 AM, Dan Partelly wrote:

A template for blackmailing is usually in the form:

"I will do this (usually involving saving the world and/or your
evidently miserable life) but first you will have to do this
(unrelated) thing to see that you are worthy.”


It is interesting how much you dwell on this.


Ugh ... yeah ... I am wondering exactly how I got into this.


 I just told you what reasons
I have to take this path, and that it doesn't include the intent to 
blackmail

anyone. I want to experience the process with already existing code,
before contemplating more in the future.


And that's fine with me ... let's leave it at that.

Have fun, that's what FreeBSD is about,

Pedro.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Pedro Giffuni]

Hello;

> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly  
> ha scritto:
> 
> Hey Pedro,
> 
> 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, 
> but last I know you cleaned it up and put it somewhere on freebsd.org (prolly 
> your page) up for review. 
> 

It’s here:
https://people.freebsd.org/~pfg/patches/ddb.patch

I haven’t tested it though.

> 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. 
> 

I am having hardware issues so I won’t be able to do much in a while.
Perhaps you should review it and submit it as a PR.

Pedro.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Dan Partelly]

Hey Pedro,

Thanks a lot , mate. 

I’m reluctant to put it up as a PR, since some PR are outstanding for years.  

Adrian,

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.  


[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

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. 


Dan



> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:

> 
> Hello;
> 
>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly  
>> ha scritto:
>> 
>> Hey Pedro,
>> 
>> 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, 
>> but last I know you cleaned it up and put it somewhere on freebsd.org 
>> (prolly your page) up for review. 
>> 
> 
> It’s here:
> https://people.freebsd.org/~pfg/patches/ddb.patch
> 
> I haven’t tested it though.
> 
>> 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. 
>> 
> 
> I am having hardware issues so I won’t be able to do much in a while.
> Perhaps you should review it and submit it as a PR.
> 
> Pedro.
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Adrian Chadd]

[snip snip snippety snip]

Hi Dan!

Yeah, turns out trying to get a bunch of burnt out, time-poor
developers with commit bits to commit stuff will typically end up with
(a) things getting neglected, or (b) getting you a commit bit. :)

Please grab the patch from pedro (which I reviewed, and it looks fine
at a first pass) and dump it into reviews.freebsd.org. You'll have to
create an account first. That way we can solicit some further
reviews/comments before I just commit it. :)


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Justin Hibbits]

On Thu, Nov 19, 2015 at 8:29 AM, Dan Partelly  wrote:
>> 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.
>
> But no matter what you find odd or not, I am simply following what Ive read 
> on some
> page on freebsd.org that one of the ways of contributing is by submitting code
> on the mailing-lists , where “somebody will happily pick up changes”.
>
> So, if you continue to find this odd, please take it up with the web-masters 
> on
> freebsd.org to update the resources regarding contributing to the project.

Dan,

I think a lot of people tend to use the 'one-two punch' of both PR and
mailing list.  Mailing list to flesh it out and discuss the idea, and
the PR when it's ready to go in.  I've done a very cursory review of
your patch, and it looks pretty good.  Unfortunately, my time is
booked for more projects than I really have time for, so I'd be unable
to test it.  If you submit it as a PR in bugzilla, at the very least
the patch won't get lost when someone else comes looking for the
feature, and more likely it'll get picked up by someone rather quickly
or in the next triage phase (some people like to do bug triaging
periodically, where things like this get their basic testing and
commit).

When you said it's not a patch for an issue/bug/etc, one could say the
bug is that the patch isn't already in the tree :) .

- Justin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Pedro Giffuni]

> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly  
> ha scritto:
> 
> Hey Pedro,
> 
> Thanks a lot , mate. 
> 
> I’m reluctant to put it up as a PR, since some PR are outstanding for years.  
> 

Well, that’s the way the project works: you cannot really depend on me, or
anyone else keeping old patches around. If you want a record of your
submission bugzilla is the place to keep it. And of course there is no guarantee
anyone will look at it but your chances are much better in bugzilla than
in a mailinglist.



> Adrian,
> 
> 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.

Mental reviews don’t count much: if you are not running FreeBSD and standing
behind your patch the chances of being taking seriously are slim.


>  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.  
> 
> 

I recall you stated the patch was “not ready” when you posted it. I haven’t 
really
done anything to say it is ready. Unless someone else finds time to do real
testing it won’t happen.

Adrian tends to do some particularly valuable contributions to the project. I
would prefer if he spends his time on more important tasks.

> [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
> 
> 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. 
> 

Wrong approach. You can’t really blackmail someone into taking your changes.

Things work like this:

- You discuss your idea and try to get some consensus in the 
lists/IRC/conferences.
- You *write* a specific proof of concept and get it discussed.
- You finish your prototype.
- Your work gets rejected until you get something some committer is willing to 
support.
- When there are no objections and a committer feels like it, your work gets 
committed,
 which doesn’t necessarily mean it will stay.
- You are expected to maintain it.

Libxo already went through this process.

We are particularly NOT interested in code where the original contributor will 
walk
away as soon as he/she receives criticism or has plans that do not match ours.
If this is not your ideal workflow … fork your own BSD, a lot of intelligent
people do just that.

Pedro.

> 
> Dan
> 
> 
> 
>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
> 
>> 
>> Hello;
>> 
>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly  
>>> ha scritto:
>>> 
>>> Hey Pedro,
>>> 
>>> 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, 
>>> but last I know you cleaned it up and put it somewhere on freebsd.org 
>>> (prolly your page) up for review. 
>>> 
>> 
>> It’s here:
>> https://people.freebsd.org/~pfg/patches/ddb.patch
>> 
>> I haven’t tested it though.
>> 
>>> 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. 
>>> 
>> 
>> I am having hardware issues so I won’t be able to do much in a while.
>> Perhaps you should review it and submit it as a PR.
>> 
>> Pedro.
>> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[dan_partelly]

Hi Pedro,


Sure, no worries , I am grateful for all you did, couldn't ask for more.

I have yet no idea how the projects works, but in the thread in which I
questioned the wisdom of having 
utilities in base spitting out JSON -- instead of properly libyifing some
utilities -- Adrian has
stated something which I perceived to be on the line "everybody talks,
noone codes". So I expressed
my willingness to participate to libifing some utilities from base, but ,
understandingly I  hope,
I want to see how this process goes with code which already existed , 
before investing  time in created new code

So once again, I thank you !




On Thu, 19 Nov 2015 10:08:57 -0500, Pedro Giffuni  wrote:
>> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly
>>  ha scritto:
>> 
>> Hey Pedro,
>> 
>> Thanks a lot , mate. 
>> 
>> I’m reluctant to put it up as a PR, since some PR are outstanding for
>> years.
>> 
> 
> Well, that’s the way the project works: you cannot really depend on me,
or
> anyone else keeping old patches around. If you want a record of your
> submission bugzilla is the place to keep it. And of course there is no
> guarantee
> anyone will look at it but your chances are much better in bugzilla than
> in a mailinglist.
> 
> 
> 
>> Adrian,
>> 
>> 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.
> 
> Mental reviews don’t count much: if you are not running FreeBSD and
> standing
> behind your patch the chances of being taking seriously are slim.
> 
> 
>>  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.
>> 
>> 
> 
> I recall you stated the patch was “not ready” when you posted it. I
> haven’t really
> done anything to say it is ready. Unless someone else finds time to do
real
> testing it won’t happen.
> 
> Adrian tends to do some particularly valuable contributions to the
> project. I
> would prefer if he spends his time on more important tasks.
> 
>> [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
>> 
>> 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.
>> 
> 
> Wrong approach. You can’t really blackmail someone into taking your
> changes.
> 
> Things work like this:
> 
> - You discuss your idea and try to get some consensus in the
> lists/IRC/conferences.
> - You *write* a specific proof of concept and get it discussed.
> - You finish your prototype.
> - Your work gets rejected until you get something some committer is
> willing to support.
> - When there are no objections and a committer feels like it, your work
> gets committed,
>  which doesn’t necessarily mean it will stay.
> - You are expected to maintain it.
> 
> Libxo already went through this process.
> 
> We are particularly NOT interested in code where the original
contributor
> will walk
> away as soon as he/she receives criticism or has plans that do not match
> ours.
> If this is not your ideal workflow … fork your own BSD, a lot of
> intelligent
> people do just that.
> 
> Pedro.
> 
>> 
>> Dan
>> 
>> 
>> 
>>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>> 
>>> 
>>> Hello;
>>> 
 Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
  ha scritto:
 
 Hey Pedro,
 
 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,
 but last I know you cleaned it up and put it somewhere on freebsd.org
 (prolly your page) up for review.
 
>>> 
>>> It’s here:
>>> https://people.freebsd.org/~pfg/patches/ddb.patch
>>> 
>>> I haven’t tested it though.
>>> 
 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.
 
>>> 
>>> I am having hardware issues so I won’t be able to do much in a while.
>>> Perhaps you should review it and submit it as a PR.
>>> 
>>> Pedro.
>>> 
>> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> 

Re: DDB patches

[Willem Jan Withagen]

On 19-11-2015 15:29, Dan Partelly wrote:
>> 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. 
> 
> But no matter what you find odd or not, I am simply following what Ive read 
> on some 
> page on freebsd.org that one of the ways of contributing is by submitting 
> code 
> on the mailing-lists , where “somebody will happily pick up changes”. 
> 
> So, if you continue to find this odd, please take it up with the web-masters 
> on 
> freebsd.org to update the resources regarding contributing to the project. 

I have to admit that you have read more of the freebsd.org website than
that I have

Most of the time I lurk on the lists here. Probably since the 1.0
incarnation of FreeBSD. And what I tried to explain, was that the
bugtracker is used for more than just bugs. I've learnt that from
several responses on the lists.

I also saw that Justin picked up with a functional answers on your
patch, so I'll go back into lurking mode.

--WjW


> 
> 
> 
>> On 19 Nov 2015, at 16:10, Willem Jan Withagen  wrote:
>>
>> On 19-11-2015 14:53, Dan Partelly wrote:
 So not submitting a PR for an issue sound real strange to my ears.
>>>
>>>
>>> It is NOT a patch for an issue, bug, anything on those lines at all. 
>>> It adds new features to DDB. Specifically it adds relational 
>>> operators. 
>>>
>>> Since it doesn't solve any problems, I don't see why it should be added 
>>> to a problem database which is used for bug reports. 
>>>
>>
>> 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.
>>
>> An alternative for this might be submission to Phabricator if you'd like
>> a more reviewing type of evaluation.
>>
>> --WjW
>>
>>> But then again, it may be just me.
>>>
>>> Dan
>>>
>>>
>>>
 On 19 Nov 2015, at 15:44, Willem Jan Withagen  wrote:

 On 19-11-2015 10:57, Dan Partelly wrote:
> Hey Pedro,
>
> Thanks a lot , mate.
>
> I’m reluctant to put it up as a PR, since some PR are outstanding for
> years.

 What a strange argument

 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.

 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.

 So not submitting a PR for an issue sound real strange to my ears.

 But then again that's me.

 --WjW


> Adrian,
>
> 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.
>
>
> [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
>
> 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.
>
>
> Dan
>
>
>
>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>
>>
>> Hello;
>>
>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
>>>  ha scritto:
>>>
>>> Hey Pedro,
>>>
>>> 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, 
>>> but last I know you cleaned it up and put it somewhere on
>>> freebsd.org (prolly your page) up for review.
>>>
>>
>> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch
>>
>> I haven’t tested it though.
>>
>>> 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.

Re: DDB patches

[Dan Partelly]

> So not submitting a PR for an issue sound real strange to my ears.


It is NOT a patch for an issue, bug, anything on those lines at all. 
It adds new features to DDB. Specifically it adds relational 
operators. 

 Since it doesn't solve any problems, I don't see why it should be added 
to a problem database which is used for bug reports. 

But then again, it may be just me.

Dan



> On 19 Nov 2015, at 15:44, Willem Jan Withagen  wrote:
> 
> On 19-11-2015 10:57, Dan Partelly wrote:
>> Hey Pedro,
>> 
>> Thanks a lot , mate.
>> 
>> I’m reluctant to put it up as a PR, since some PR are outstanding for
>> years.
> 
> What a strange argument
> 
> 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.
> 
> 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.
> 
> So not submitting a PR for an issue sound real strange to my ears.
> 
> But then again that's me.
> 
> --WjW
> 
> 
>> Adrian,
>> 
>> 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.
>> 
>> 
>> [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
>> 
>> 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.
>> 
>> 
>> Dan
>> 
>> 
>> 
>>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>> 
>>> 
>>> Hello;
>>> 
 Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
  ha scritto:
 
 Hey Pedro,
 
 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, 
 but last I know you cleaned it up and put it somewhere on
 freebsd.org (prolly your page) up for review.
 
>>> 
>>> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch
>>> 
>>> I haven’t tested it though.
>>> 
 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.
 
>>> 
>>> I am having hardware issues so I won’t be able to do much in a
>>> while. Perhaps you should review it and submit it as a PR.
>>> 
>>> Pedro.
>>> 
>> 
>> ___ 
>> freebsd-current@freebsd.org mailing list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
>> unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
>> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Willem Jan Withagen]

On 19-11-2015 10:57, Dan Partelly wrote:
> Hey Pedro,
> 
> Thanks a lot , mate.
> 
> I’m reluctant to put it up as a PR, since some PR are outstanding for
> years.

What a strange argument

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.

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.

So not submitting a PR for an issue sound real strange to my ears.

But then again that's me.

--WjW


> Adrian,
> 
> 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.
> 
> 
> [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
> 
> 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.
> 
> 
> Dan
> 
> 
> 
>> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
> 
>> 
>> Hello;
>> 
>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
>>>  ha scritto:
>>> 
>>> Hey Pedro,
>>> 
>>> 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, 
>>> but last I know you cleaned it up and put it somewhere on
>>> freebsd.org (prolly your page) up for review.
>>> 
>> 
>> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch
>> 
>> I haven’t tested it though.
>> 
>>> 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.
>>> 
>> 
>> I am having hardware issues so I won’t be able to do much in a
>> while. Perhaps you should review it and submit it as a PR.
>> 
>> Pedro.
>> 
> 
> ___ 
> freebsd-current@freebsd.org mailing list 
> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
> unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: DDB patches

[Dan Partelly]

> 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. 

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

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



> On 19 Nov 2015, at 16:10, Willem Jan Withagen  wrote:
> 
> On 19-11-2015 14:53, Dan Partelly wrote:
>>> So not submitting a PR for an issue sound real strange to my ears.
>> 
>> 
>> It is NOT a patch for an issue, bug, anything on those lines at all. 
>> It adds new features to DDB. Specifically it adds relational 
>> operators. 
>> 
>> Since it doesn't solve any problems, I don't see why it should be added 
>> to a problem database which is used for bug reports. 
>> 
> 
> 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.
> 
> An alternative for this might be submission to Phabricator if you'd like
> a more reviewing type of evaluation.
> 
> --WjW
> 
>> But then again, it may be just me.
>> 
>> Dan
>> 
>> 
>> 
>>> On 19 Nov 2015, at 15:44, Willem Jan Withagen  wrote:
>>> 
>>> On 19-11-2015 10:57, Dan Partelly wrote:
 Hey Pedro,
 
 Thanks a lot , mate.
 
 I’m reluctant to put it up as a PR, since some PR are outstanding for
 years.
>>> 
>>> What a strange argument
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> So not submitting a PR for an issue sound real strange to my ears.
>>> 
>>> But then again that's me.
>>> 
>>> --WjW
>>> 
>>> 
 Adrian,
 
 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.
 
 
 [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
 
 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.
 
 
 Dan
 
 
 
> On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
 
> 
> Hello;
> 
>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
>>  ha scritto:
>> 
>> Hey Pedro,
>> 
>> 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, 
>> but last I know you cleaned it up and put it somewhere on
>> freebsd.org (prolly your page) up for review.
>> 
> 
> It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch
> 
> I haven’t tested it though.
> 
>> 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.
>> 
> 
> I am having hardware issues so I won’t be able to do much in a
> while. Perhaps you should review it and submit it as a PR.
> 
> Pedro.
> 
 
 ___ 
 freebsd-current@freebsd.org mailing list 
 https://lists.freebsd.org/mailman/listinfo/freebsd-current To
 unsubscribe, send any mail to
 "freebsd-current-unsubscr...@freebsd.org"
 
>>> 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> 

Re: DDB patches

[Willem Jan Withagen]

On 19-11-2015 14:53, Dan Partelly wrote:
>> So not submitting a PR for an issue sound real strange to my ears.
> 
> 
> It is NOT a patch for an issue, bug, anything on those lines at all. 
> It adds new features to DDB. Specifically it adds relational 
> operators. 
> 
>  Since it doesn't solve any problems, I don't see why it should be added 
> to a problem database which is used for bug reports. 
> 

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.

An alternative for this might be submission to Phabricator if you'd like
a more reviewing type of evaluation.

--WjW

> But then again, it may be just me.
> 
> Dan
> 
> 
> 
>> On 19 Nov 2015, at 15:44, Willem Jan Withagen  wrote:
>>
>> On 19-11-2015 10:57, Dan Partelly wrote:
>>> Hey Pedro,
>>>
>>> Thanks a lot , mate.
>>>
>>> I’m reluctant to put it up as a PR, since some PR are outstanding for
>>> years.
>>
>> What a strange argument
>>
>> 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.
>>
>> 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.
>>
>> So not submitting a PR for an issue sound real strange to my ears.
>>
>> But then again that's me.
>>
>> --WjW
>>
>>
>>> Adrian,
>>>
>>> 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.
>>>
>>>
>>> [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
>>>
>>> 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.
>>>
>>>
>>> Dan
>>>
>>>
>>>
 On 19 Nov 2015, at 11:17, Pedro Giffuni  wrote:
>>>

 Hello;

> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly
>  ha scritto:
>
> Hey Pedro,
>
> 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, 
> but last I know you cleaned it up and put it somewhere on
> freebsd.org (prolly your page) up for review.
>

 It’s here: https://people.freebsd.org/~pfg/patches/ddb.patch

 I haven’t tested it though.

> 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.
>

 I am having hardware issues so I won’t be able to do much in a
 while. Perhaps you should review it and submit it as a PR.

 Pedro.

>>>
>>> ___ 
>>> freebsd-current@freebsd.org mailing list 
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
>>> unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"