maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

I agree with your intent but some of the motivation is wrong. The
public Google patch has always been a gigantic diff except for a few
large features that were extracted. The Facebook patch isn't really a
patch. It is a launchpad branch. Percona maintained patches. That must
have been a lot of work on their part. Maybe they won't spend as much
time on it going forward now that there is Percona server.

On Wed, Sep 22, 2010 at 11:27 PM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Zardosht Kasheff <zardosht@xxxxxxxxx> writes:
>
>> I have spent some of my spare time looking into this. It turns out
>> that MySQL Cluster already has this ability. They have the following
>> handler functions listed below. I spent a weekend trying to port MySQL
>> Cluster's alter table function (mysql_alter_table) over to 5.1.46.
>
>>  - All storage engines use the new alter table, I want storage engines
>> to opt in, to reduce the risk of bugs
>>
>> Any thoughts?
>
> Yes. I think you should use the new interface for everything. I remember when
> we did this work in cluster (I did the low-end table change part), and the
> alter table interface was designed as a general solution, not something to be
> used only for some special engines.
>
> I understand of course why you want to "reduce risk". This has been the
> approach taken with much community development in the last couple of years
> (Percona patches, Google patches, Facebook patches, etc): maintain isolated
> patches, trying to minimise the impact of each patch on the code base to keep
> things manageable as individual patches and reduce risk and effort needed.
>
> But recently I see so much community development happening that I believe it
> is necessary to move to the next phase. With your work, the Facebook group, my
> group at Monty Program, Perconas work, and other stuff, the development effort
> outside of MySQL@Oracle is on the same order of magnitude as that
> inside. Maintaining individual patches does not scale to that level of effort,
> in my opinion.
>
> Until MySQL@Oracle opens up their development to outside groups, we need
> another solution. I spend the first year on MariaDB just working to make
> everything we need available for full-scale development on the MySQL codebase
> for just this reason.
>
> But I recognise that there is still something missing for MariaDB to be
> useable for Facebook, Percona, you, etc. I think maybe it is the release
> model, if so we can fix it. Or use something else, it does not have to be
> MariaDB, but I strongly believe we need to coordinate our efforts. Within the
> next 6 months or so we have the merge with all of our still into MySQL 5.5
> coming up, that will take considerable effort and is not something we should
> each repeat individually.
>
> So we need to find a model that works for all you people out in the trenches
> needing to put things in production use ASAP. But you guys also need at some
> point to start spending the extra effort to test, fix, and integrate new
> things properly, otherwise we end up with a huge spaghetti of patches that
> cannot be maintained.

Define "properly"? I suspect you mean that you want us to spend the
time to get our changes into MariaDB. While that would be a good thing
to do, I don't think that makes it proper. Getting changes from my
team into MariaDB is more about helping others use those changes than
it is about making my work easier.

I maintain a branch on launchpad, not a set of patches. It isn't that
hard to maintain them although merging to 5.5 might be some work.
Pushing patches from Facebook to anybody else is extra work. I don't
have time to do it. I try to make it easy to pull them.

-- 
Mark Callaghan
mdcallag@xxxxxxxxx