OK, Patrick and MontyT, I have set up all the tasks and subtasks on
Launchpad as blueprints, and added dependencies between them. Some have
already been assigned to each of you.
Like I mentioned to Monty on IRC, here is what I propose for development
process of these interrelated tasks:
The easiest way to work on this stuff is bzr branch from trunk into a
local branch named the same as the blueprint task (takes care of
uniqueness there!) and then push to ~mordred/drizzle/blueprint-name. I
will then take care of merges into the depending branches locally,
resolve conflicts, and push a branch to the
~drizzle-developers/drizzle/medium-blueprint-name
Work for everyone?
-jay
Monty Taylor wrote:
> 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. :)
>
> Thanks guys.
>
>>> 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.
>
> I mostly agree, but I'm not 100% sure each of the bullet points needs to
> be a full blueprint/branch on its own, since some of the bullet points
> weren't split by task as much as just to try to remember each bit... but
> I'm good either way.
>
>>> 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()
> Forgot to add:
>
> - Rename mysql_* functions to drizzle_*
>
> doh.
>
>> 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....
>
> Yes... most of the *_real_* methods are stupid wrappers around old calls
> in an attempt to ease ABI transitions. But I don't care about that...
>
> Also, might want to add:
>
> - Rename functions starting with cli_*
>
> that might be short for "client" (which is overused word anyway) but it
> makes me think "Command Line Interface", so I hate it.
>
>>> (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.
>
> Yes, you are probably right here.
>
>>> - 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...
>
> Agree. What do you think we should do with my_multi_malloc? Also, some
> of the my_free calls when replaced need to be prefixed with a
> if (bla!=NULL) protection.
>
>>> - 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...
>
> Non-standard string functions in libdrizzle turned out to be surpisingly
> easy to eradicate.
>
> The charset references actually also aren't _too_ terrible... but I
> agree, there is a larger conversation here... but it's got to go if we
> want libsys out of libdrizzle - or we've got to figure out a way to
> sensibly pull in only the bits we absolutely have to have
>
>>> - 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.
>
> Agree. There are a couple of places where it especially sucks. But
> definitely only talking about libdrizzle.
>
>>> 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)
>
> Agree.
>
> I should also mention that there are a couple of places where the IMPL
> code of libdrizzle references mysqld errors (ER_*) as a protocol
> library, this is insane... either the error codes are ones defined by
> the protocol (in which case they should be defined by the lib) or they
> are internal mysqld errors, in which case the client should never see them.
>
>>> 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.
>
> Agree.
>
>>> - Removing mysys/mystrings from client/
>> This is going to be a larger debate. ;)
>
> Tell me about it. :)
>
>>> - 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? :)
>
> Hell yes.
>
>> -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
