Re: DDB patches

From: Pedro Giffuni <pfg_at_freebsd.org>
Date: Thu, 19 Nov 2015 10:08:57 -0500
> Il giorno 19/nov/2015, alle ore 04:57, Dan Partelly <dan_partelly_at_rdsor.ro> 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 <pfg_at_freebsd.org> wrote:
> 
>> 
>> Hello;
>> 
>>> Il giorno 19/nov/2015, alle ore 02:34, Dan Partelly <dan_partelly_at_rdsor.ro> 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.
>> 
> 
Received on Thu Nov 19 2015 - 14:09:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:01 UTC