[debian-mysql] factoring out mysql-common

[Robie Basak]

On Tue, Jun 14, 2016 at 04:26:25PM +0300, Otto Kekäläinen wrote:
> 2016-06-14 14:58 GMT+03:00 Andreas Beckmann <anbe at debian.org>:
> >> I've just looked at this now. I'm disappointed that the history is lost.
> >> Can we instead base this tree from mysql-5.7's tree - just strip out
> >> everything not wanted in a branch, and refactor the remaining into a
> >> mysql-common? Then "git blame" etc will still work.
> 
> I don't mind either way. Git blame will anyway not go beyond mysql-5.5
> contents, but at least we would have the history for the last couple
> of years and maybe indeed the majority of changes to mysql-common
> contents was done in recent years. If Andreas or Robie wants to
> refactor the mysql-common repo to be based on the mysql-5.7 repo,
> please do it.

Great, thanks. Andreas, shall I leave this to you? Or if you'd like me
to do it, I'd be happy to push my result somewhere, but I'll need a DD
to clean up the repos when I'm done (since AIUI I can't force push to
Alioth).

>               All the git magic works as long the repos have a common
> ancestor, they don't need to permanently live on branches in the same
> repo.

Right. So a decision to keep everything in the same git repository is
entirely independent of decisions about how we keep history, providing
that we can decide how to avoid branch and tag name collisions. I think
we all agree that keeping all history is preferable if possible.

> >> Second, can we start keeping things in a single git repo rather than
> >> creating yet another one? How about we continue to use mysql-5.7 but
> >> have a "common" branch? Then eventually perhaps we can move mariadb into
> >> the same git tree too.
> 
> This would work if we would have been vice enough to forsee this
> layout and base MariaDB work on the MySQL 5.5. or 5.6 repo so that
> they would have a common git ancestor, but we didn't, and I don't
> think it is feasible to convert at this point anymore.

I agree that it is not practical to consider trying to do anything about
changing the MariaDB git branch histories. What I'm proposing though is
that in time we put them in the same repository anyway (without
rewriting history). Then we might (in the very long term) be able to
bring the debian/ directories for MySQL and MariaDB back in line with
each other.

Of course putting them in the same repository is not a requirement for
this to happen, but I think it would be easier for us to work more
closely together if we do. Then the packaging for the other variant
would be "right there" and easier to examine when considering making any
changes. Sort of like an Inverse Conway Maneuver[1].

I don't feel as strongly about this as I feel about preserving
mysql-common's history and not creating yet another repository for it,
so if you would prefer not to do this, then that's fine. I also don't
think there's any need to do it right now.

On Tue, Jun 14, 2016 at 01:58:30PM +0200, Andreas Beckmann wrote:
> That would require a well defined scheme for naming branches and tags.
> DEP14 comes into my mind (http://dep.debian.net/deps/dep14/), but it
> needs an additional level for the source package, what do you think about
> 
> Upstream branches:
>    <package>/upstream
> Upstream tags:
>    <package>/upstream/<version>
> 
> Master branches:
>    <package>/<vendor>/master
>    (maybe just <package>/master)
> Release branches:
>    <package>/<vendor>/<codename>
> Tags:
>    <package>/<vendor>/<version>
> 
> User branches:
>    <user>/<whatever>
> User tags:
>    None
> 
> "Merging" the repositories should work as well if we rename the branches
> first. I don't expect collisions in the tags (but the tags will be
> cluttered since it is not clear which package they belong to), but we
> can't rename tags (especially signed ones).

I hadn't considered tag collisions. Thank you for bringing this up. I
think your solution above would be fine, and as you say we could leave
existing tags alone. Perhaps we could create a fresh set of tags to
match the old ones but in the new namespace, but still leave the old
ones alone? Then we will have an unambigious way of finding old stuff.

> So src:mysql-defaults could live in
> 
>   mysql-defaults/master
> 
> tagged as
> 
>   mysql-defaults/debian/<version>
> 
> and in case you need to do modifications for Ubuntu, you could create
> 
>   mysql-defaults/ubuntu/master
> 
> tagged as
> 
> mysql-defaults/ubuntu/<version>

I would be happy with this. In fact this would be much better than the
current situation, where jumping around and asking for diffs, etc
between MySQL 5.5, 5.6 and 5.7, eg. for security updates, has been quite
painful because all the branch names collide.

Thanks,

Robie

[1] https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20160614/6fb3f433/attachment.sig>