Started 2.0 branch

[Jeff Mitchell]

Peter van Hardenberg wrote:
> Agreed! Let's not crap on the tree. (Just yet.) Let's start 2.0 over in Git-land.
> 
> If people want to start with our Songbird branch we can do that. The main differences are:
> 
> - control over how much of the file to look in for tags (great for remote files)
> - vastly expanded Tag:: interface
> - lots of bug fixes
> 
> I'm sure that we're missing some trunk patches too, but I can contribute some time to bringing things into sync. It may well be that there are some things we've done that people aren't particularly excited about in the world at large. Hopefully we can bring ourselves into sync with the rest of the world on anything that comes up, but if not we've been forked forever so life goes on.
> 
> On the other hand, if our changeset scares people we can work on trunking bits and pieces, but that'll be harder.
> 
> Jeff, if you want to get the ball rolling with me for this stuff, send me a message off-list and maybe I can spend a PST-afternoon/evening some time this week with you getting up and running?

Sure.  Although it may be best to wait -- probably no more than a couple
weeks. If people can wait that long, I hope to have the start of an
official KDE git repository system (on Gitorious, either on
Gitorious.org or self-hosted at git.kde.org) set up.  Then I'll migrate
a SVN snapshot over and we can start putting up branches and suggesting
merges and so on.  I could put it on Gitorious ahead of time, but I
figure just in terms of cruftiness, might be good to just wait until
things are more finalized.

If people can't wait that long, I could put it up on Gitorious, or I
have a Git server up and running that has been used by some Amarok
people in the interim (we're also chomping at the bit to use Git, but
have been trying to help get KDE set up with it as opposed to just
breaking off).  (There isn't much of a web interface, although I could
easily put one on, I just haven't yet because I haven't needed it.)
Then when things are ready, we can just clone and push the repo to
wherever KDE Git hosting ends up.

The reason I'd prefer the first option (waiting) is that if Scott is
amenable to it, I have a suggestion:

Scott releases when he has time to close all taglib bugs (which may mean
writing fixes), vet all taglib patches, and do the release.  Much of the
problem is that right now he has very little time to do this.

I'd like to propose that we make this easier on Scott -- if people with
a history of (good/solid) hacking on taglib that Scott trusts can figure
out the bugs (and leave comments, not close them) and vet the patches
(and leave comments, not apply them), he can just read through the bugs
and patches boom-boom-boom and close and them off.  By doing this, we
could maybe get a 1.6 release out, which is badly needed by those many
projects that are using taglib that do not have highly customized
versions or are running from trunk.  During that time I'd be working on
the Git stuff, and soon after 1.6 is out the door, we could start 2.0
development in a Git repo in a hopefully finalized place, so that people
don't have to swap around their remote locations in the middle of things
(which I know is easy, but that's not the point :-) )

Thoughts (especially from you, Scott)?  Anyone willing to step up if
Scott's okay with this?

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20090616/c5eff2ab/attachment.sig