Jay Pipes wrote:
> 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?
Yes ... except I think that in some cases we might be able to merge
directly back to trunk, depending on the blueprint and the state of
other work, etc... but that's what communication is all about!
> -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
