Patrick Galbraith wrote:
> Ok, then, so when shall we divy tasks up ? ;) What of task 1 -- shall we
> use the whiteboard and divy it up there?
Sounds good.
> Also, same bzr URL as before?
>
> I'd be glad to take the first two tasks:
>
> - Replacing use of the MYSQL_TYPE_* constants to FIELD_*
> - Renaming MYSQL_* types in drizzle.h to DRIZZLE_*
Yours!
> Jay Pipes wrote:
>> Monty Taylor wrote:
>>
>>> Yes. That should be DRIZZLE *...
>>> Ok. I think I have officially drug this branch down the rathole. I'm
>>> terribly sorry for wrecking work and delaying DBD::drizzle...
>>>
>>
>> Don't apologize, there is no need to. :)
>>
>>
>>> Jay just sent me an email about his work in the tree today, which came
>>> to the sensible conclusion that the changes I was committing were too
>>> interwoven to be able to backtrack through them successfully... and he's
>>> totally right.
>>>
>>> Jay is going to look at starting from scratch from trunk and starting to
>>> apply the patches one bit at a time. (I think I know where it broke, but
>>> it's all too much atm)
>>>
>>> I think we should/can divvy this up a bit, so we don't (and by we, this
>>> week I seem to mean me) break each other's work.
>>>
>>> SO, I propose these related but unrelated tasks.
>>>
>>
>> Yes, small, bitesize tasks, each attached to a blueprint which can be
>> made dependent on each other. Create a branch for each small task,
>> attached to the blueprint. Merge proposals will go from small task
>> branch -> medium task branch -> large task branch ->trunk. I am happy
>> to manage the blueprint dependencies and simply assign them to you and
>> Patrick as you want them...I am also working on putting together a
>> buildbot master soon so we can start automating builds and tests.
>>
>>
>>> TASK ONE: Rename mysql to drizzle OR to something more generic where it
>>> will touch storage engines. This includes:
>>>
>>
>> The above is a medium task, composed of the below small tasks...
>>
>>
>>> - Replacing use of the MYSQL_TYPE_* constants to FIELD_*
>>> - Renaming MYSQL_* types in drizzle.h to DRIZZLE_*
>>> - Renaming MYSQL* defines to DRIZZLE*
>>> - Changing mysql_init() to drizzle_create()
>>>
>>
>> Cool. :)
>>
>>
>>> - Moving my_thread_init(), my_net_init(), etc. into drizzle_create()
>>>
>>
>> Excellent.
>>
>>
>>> - Rename mysql_real_* to just drizzle_*
>>>
>>
>> Or killing them off completely. If it smells like a hack, it probably
>> is...
>>
>>
>>> (I think I can re-do the first four bullets above pretty quickly now
>>> that I know where it's all hanging together. I'd like someone else to
>>> look at bullet 5 - I think it needs a different set of eyes.)
>>>
>>
>> Happy to.
>>
>>
>>> TASK TWO: Remove the mysys/mystrings depends from libdrizzle. The main
>>> depends are charsets, my_malloc/my_free, some lame string manipulation
>>> functions (and one nice one), bad header file organization and errors.
>>> (Could conceivably be done in parallel... but probably should wait for
>>> the above to be done and merged)
>>>
>>
>> Again, this is a medium task with the following smaller tasks. What
>> should be decided is whether indeed this can be done in parallel or this
>> is dependent on the above tasks being completed. I suspect that they
>> can be done in parallel but in separate, smaller trees.
>>
>>
>>> - Replacing my_malloc/my_free with normal malloc/free
>>>
>>
>> Sure, but some places should not be a blanket replacement. I noticed a
>> couple places in your tree where my_multi_malloc() was replaced with
>> many small malloc calls, which is not efficient...perhaps for now tackle
>> single malloc calls. IMHO, For this tree, it is essential that valgrind
>> be run cleanly before any merge into another tree...
>>
>>
>>> - Removing use of non-standard string functions
>>> - Removing charset references from libdrizzle (make the lib send the
>>> bytes the programmer sends)
>>>
>>
>> Heh, these two might have to wait a bit...
>>
>>
>>
>>> - Moving some stuff around in headers (I think I did this mostly
>>> right, so most of this can be copied verbatim)
>>> - Removing use of MEM_ROOT in libdrizzle. This most affects
>>> MYSQL_FIELD and MYSQL_ROWS. While we're at it, we curse the
>>> MYSQL_ROWS implementation. (BTW Stewart - the first time I did
>>> this, I was yearning for talloc...)
>>>
>>
>> This is a medium task in itself in my opinion, even if only for
>> libdrizzle. Messing with MEM_ROOT is a serious undertaking. I would
>> recommend moving this to a separate medium task and branch.
>>
>>
>>> TASK THREE: Figuring out what to do with the ER() macros and
>>> client_errors[] (NOT RELATED TO THE ABOVE... CAN BE PARALLEL)
>>> (I didn't do this right the first time at all)
>>> This whole thing is a mess, as there are global static arrays that are
>>> shared between client and server, and we generate these things with
>>> comp_err. I'd say it's a later design issue to be solved, but it's
>>> keeping libdrizzle tied to mysys... and it's a spiderweb anyway.
>>>
>>
>> This task should be dependent on both medium task 1 and 2 (b/c of
>> changes to the same files in #1 and movement of header files in #2)
>>
>>
>>> Once all of that is done and all still compiles and is merged, _then_ we
>>> can tackle (instead of doing it all in one fell swoop):
>>>
>>> - Removing references to deprecated things in client/
>>>
>>> - Password support functions
>>> - Unix Domain Sockets
>>> - Shared Memory
>>> - Embedded Server
>>> (but keeping the command line options as null-ops for now)
>>>
>>
>> Yep, medium task with subtasks all dependent on #1,2,3.
>>
>>
>>> - Removing mysys/mystrings from client/
>>>
>>
>> This is going to be a larger debate. ;)
>>
>>
>>> - moving mysqlbinlog to a binlog dir, which will eventually also house
>>> binlong related files from server/ for a libbinlog ... but that's a
>>> whole other thing.
>>>
>>
>> Sure.
>>
>>
>>> Hopefully if we do it right, dormando and krow can continue working on
>>> the blocking/non-blocking IO issue, and possibly krow's interest in
>>> removing vio...
>>>
>>
>> Sure.
>>
>>
>>> At this point, libdrizzle can become a source package with no external
>>> depends. and we can:
>>>
>>> - Rearrange/split up header files and code for libdrizzle - sort of like
>>> how libmemcached is - file for DRIZZLE_ROW, file for DRIZZLE_FIELD, etc.
>>>
>>
>> Yep, this is the last major task...
>>
>>
>>> Thoughts/comments? Bricks to the head? If this sounds good to you guys,
>>> I'll transfer it to the blueprint...
>>>
>>
>> Happy to help. Shall we get going? :)
>>
>> -jay
>>
>>
>>> Monty
>>>
>>> Patrick Galbraith wrote:
>>>
>>>> Monty,
>>>>
>>>> Now I get this error:
>>>>
>>>> o -MD -MP -MF ".deps/linktest.Tpo" -c -o linktest.o linktest.c; \
>>>> then mv -f ".deps/linktest.Tpo" ".deps/linktest.Po"; else rm -f
>>>> ".deps/linktest.Tpo"; exit 1; fi
>>>> linktest.c:2:25: error: mysql/mysql.h: No such file or directory
>>>> linktest.c: In function ‘main’:
>>>> linktest.c:13: error: ‘MYSQL’ undeclared (first use in this function)
>>>> linktest.c:13: error: (Each undeclared identifier is reported only once
>>>> linktest.c:13: error: for each function it appears in.)
>>>> linktest.c:13: error: expected ‘;’ before ‘my’
>>>> linktest.c:15: error: ‘my’ undeclared (first use in this function)
>>>> make[1]: *** [linktest.o] Error 1
>>>>
>>>> So, linktest.c has:
>>>>
>>>> nt main(int argc, char** argv) {
>>>>
>>>> (void)argc;
>>>> (void)argv;
>>>>
>>>> MYSQL my;
>>>>
>>>> ...
>>>>
>>>> Shouldn't it be DRIZZLE my ?
>>>>
>>>> Monty Taylor wrote:
>>>>
>>>>> Patrick Galbraith wrote:
>>>>>
>>>>>
>>>>>> Monty Taylor wrote:
>>>>>>
>>>>>>> I stuck a file called "linktest.c" into the libdrizzle dir to
>>>>>>> test for
>>>>>>> missing symbols in libdrizzle while we were removing depends. Sounds
>>>>>>> like it got removed.
>>>>>>>
>>>>>>> Patrick Galbraith wrote:
>>>>>>>
>>>>>>>> I have all the client calls renamed to drizzle_xxx and when
>>>>>>>> compiling, get this error that doesn't tell me much:
>>>>>>>>
>>>>>>>> creating libdrizzle.la
>>>>>>>> (cd .libs && rm -f libdrizzle.la && ln -s ../libdrizzle.la
>>>>>>>> libdrizzle.la)
>>>>>>>> make[1]: *** No rule to make target `linktest.o', needed by
>>>>>>>> `linktest'. Stop.
>>>>>>>>
>>>>>>>> That's the only error, everything else seems to go fine. Any
>>>>>>>> thoughts? I could push this to a special tree if anyone wants to
>>>>>>>> look
>>>>>>>> at it.
>>>>>>>>
>>>>>>>> --Patrick
>>>>>>>>
>>>>>>>>
>>>>>> Monty,
>>>>>>
>>>>>> Could you please re-commit/push ? ;)
>>>>>>
>>>>> Yes! Committing-pushing right now!
>>>>>
>>>>> Monty
>>>>>
>
>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
