Re: [Easytag-mailing] A weekend of EasyTAG hacking, and a request for review

[David King <amigadave amigadave com>]

On 2012-11-26 14:50, Kip Warner <kip thevertigo com> wrote:
> Hey David. Thanks a lot for all the work you've done. Although I haven't
> taken a look at your branch, I am a bit worried because, as you said,
> Santtu's also been patching EasyTAG in his own branch to migrate to GTK
> +3. I'm not very good with Git, my background's more with SVN and Bzr,
> so I am pretty weak with merges into our mainline.
Hi Kip, thanks for your reply. I think Santtu's work is less of a 
migration and more of an update, which is great because it means that 
his port and my branch share a lot of code, as a significant amount of 
GTK+ 3 porting is simply using the latest GTK+ 2 features. I am of 
course making sure that any of my changes will be easy to merge into 
EasyTAG master, in that my branch is a fast-forward from master, so 
simply pulling the changes and committing them to master will result in 
no conflicts and a linear history. I am very comfortable with git, and a 
goal was to make my work as easy to review and merge as possible. Please 
let me know if you need a hand with merging anything, as I would be 
happy to help.
> I think maybe the best thing to do would be for you to merge Santtu's
> GTK+3 updates into your repository, combining with your updates of code
> fixes and upgrading the build environment. If you can get a clean merge
> and build, I'll then try to pull your changes into mainline.
It will not be trivial to merge Santtu's changes into my branch, as they 
were done as (mainly) one large commit. Luckily, as the difference 
between the two branches is not so large, I can do the necessary changes 
with a bit of manual intervention. Regarding getting a clean build, a 
major benefit of the autotools changes that I did is that EasyTAG now 
passes a "make distcheck" (master does not, currently), which makes it 
significantly easier to verify that a working and buildable tarball is 
produced from the code in git.
This leads me to a suggestion, which is that maybe it would be better to 
take the GTK+ 2 and build system updates that I have, together with some 
distribution patches, and make a release containing those, releasing a 
GTK+ 3-compatible version after that. I think that this would be better 
for distributions and users, as it is a phased migration away from the 
old GTK+ 2 UI and dependency, and should hopefully remove the need for 
most of the current distribution patches. As an example roadmap:
* merge my GTK+ 2 and build system changes, fix outstanding open bugs
  (https://github.com/stsquad/easytag/issues?page=1&state=open) and
  release 2.1.8
* merge GTK+ 3 changes (I should complete those within a week or two) 
  and release a 2.1.9 with an optional GTK+ 3 UI
* make a 2.2.0 release with a GTK+ 3-only UI, where GTK+ 3-only features 
  are used for the first time
I think such a roadmap gives plenty of scope for testing each release to 
shake out any problems, and gives users and distributions something to 
look forward to. For 2.2.0, I see things like GtkApplication and 
associated facilities (application menu support with GMenu, for example) 
as the driving GTK+ 3-only features. Anyway, it is merely a suggestion 
and it would be good to start some discussion about it.
> If the community is comfortable with the resulting build, I will build
> and upload a new release on the site.
Thanks, I will keep hacking away and update you when I have more to 
show!
--
http://amigadave.com/