Hi Daniel,
Just to cut to the chase (time is precious ;) ):
1) discussions are welcomed, but before doing it we should have
first a fully understand of the subject (technically) and second, we
should have a pertinent understanding of the implementation
2) my impression is that you got a wrong idea about the purpose of
this new route (based on your technical arguments form the previous email)
3) we should focus more a the creative side of the work, rather on
bullshit-bing discussions like : how long before a freeze a major commit
should be allowed? how do I define a major commit ? etcc....
Otherwise we are just wasting our time.
Regards,
Bogdan
PS: if someone does not know how to play "bullshit-bing" game, let me
know - it is fine :D
Daniel-Constantin Mierla wrote:
> Hello,
>
> On 06/06/08 21:39, Bogdan-Andrei Iancu wrote:
>> Hi Daniel,
>>
>> We do not have to overlook the fact that an open source project is a
>> result of common contributions from multiple people. So, it is about
>> more than one person and we should not have a selfish view on the
>> matter - maybe some new code does not solve anything for you, but
>> certainly it does for other people. As I detailed in the email
>> announcing this functionality, this new code addresses the multiple
>> needs, coming from multiple people.
>>
>> New functionalities and features are among the main definitions of
>> the project, so any new commit, even before last minute is welcome -
>> as time as it does not break anything.
>>
>> With the risk of repeating myslef, if you have some technical issue
>> with this new code, I'm open to discussions. But please, before that,
>> try to understand what this new functionality is about - if you have
>> un-clarities please let me how, I will work them out with you. Maybe
>> diving a bit into the code will help you formulating an opinion.
>>
>> But just to bring more light (as I see it is a big misunderstanding
>> on what this route is about) : This route is TM specific and is used
>> only for the stateful requests that are internally generated by TM
>> (with no UAS side); it has nothing to do with the core or with any
>> reply or anything else; it provides a mechanism to catch in script
>> requests generated by openser, requests which otherwise will be
>> totally transparent - for more, again, please refer to the info email
>> I previously sent.
>>
>> Opinions may vary, but in a truly fair and respectful environment,
>> applying labels to other people work just because you personally do
>> not agree or find useful is not constructive at all.
> repeating myself again, I didn't claim at all the current code is not
> good at all, and I haven't labeled anyone. My answer to Henning was to
> show that it is not nailed down that last minute commits are not to be
> discussed just that we meet the freezing deadline and that is, we have
> to live with them (again, that is at general view, not really tied to
> this case)
>
>
> I just said that a proper discussion would have solved lot more. The
> current code is not really bound to TM, in the future such route can
> be added, as you wrote in the announcement, all bindings to TM are
> going to be implemented -- that is the right time for such route. Now,
> the same code can be easily moved a bit around to bring more
> functionality and flexibility.
>
> Cheers,
> Daniel
>
>>
>> Regards,
>> Bogdan
>>
>> Daniel-Constantin Mierla wrote:
>>> Hello Henning,
>>>
>>> On 06/06/08 20:42, Henning Westerholt wrote:
>>>> On Friday 06 June 2008, Daniel-Constantin Mierla wrote:
>>>>
>>>>> [..]
>>>>> I have to second Henning here in regard to a proper discussion may
>>>>> lead
>>>>> to better solution. Maybe I am missing something, but from what I
>>>>> have
>>>>> seen in the description and the code, binding this route to TM solve
>>>>> just few of the demands. It is called after the buffer of the
>>>>> message to
>>>>> be sent is built.
>>>>>
>>>>> IMO such route shall be available for all messages sent by
>>>>> openser, so
>>>>> we get access in it to what is going to be sent on the network. There
>>>>> are solutions to detect that the message is locally generated (e.g.,
>>>>> only one via header), to decide there what to do. Apart of the
>>>>> benefits
>>>>> brought now, siptrace will work for all messages, we can get make
>>>>> available the destination ip and port, therefore filtering is more
>>>>> flexible, also logging/accounting get access to this information.
>>>>>
>>>>> I believe that this is a real topic for discussion, and if it is
>>>>> really
>>>>> important, we can postpone one or two days the freeze for the right
>>>>> decision. Leaving a half solution for a full release is not a right
>>>>> approach.
>>>>>
>>>>
>>>> Hello Daniel,
>>>>
>>>> i agree here to you, of course. But i think that further delaying
>>>> of the freeze is also not a good solution. So i think we'll
>>>> probably need to live with this solution for 1.4.
>>>>
>>> by midnight I can have lot of new code pushed in to the tree, which
>>> can solve couple of my issues, so this is not the point here.
>>> Committing something wrong just before freeze does not mean we have
>>> to live with it. Doing major changes in the last minute is exposed
>>> to further delays.
>>>
>>> I really do not see the full benefits of that route as it is now,
>>> just placing that code in another file, with a bit of caring some
>>> other aspects solves lot of other demands requested by users, fixes
>>> some existing limitations, by not dropping anything that code
>>> provides now.
>>>
>>> If in the future, such route is going to be bound to TM by some
>>> specific hooks, then it is time to introduce it there. I think
>>> renaming it in send_route, or eventually having two of them:
>>> request_send_route and reply_send_route, with barely same code but
>>> in core, is better.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>>
>>>> Cheers,
>>>>
>>>> Henning
>>>>
>>>>
>>>
>>
>
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
