Re: Git branches etc.

[John Stowers <john stowers gmail com>]

On Thu, Feb 12, 2009 at 6:24 PM, Alexandre <airmind gmail com> wrote:

Hi,

On Thu, Feb 12, 2009 at 1:39 AM, John Stowers <john stowers gmail com> wrote:

Hi,

I see the UI branch in github. Looks nice. I am just wondering if that was a git-svn import, or a branch of git-mirror.gnome.org?

The master branch was created using git svn, and all others branches were created from the master branch. I think the UI branch still has the git svn metadata. I just update the master to the latest SVN and then merge the master into the other branches.

Ok, I am a little worried because the github import has no mapping between my jstowers gnome svn account, and my nzjrs github account, so I was a little nervous about what would happen if I was to then merge or interact with my git-svn imported master in which I mapped jstowers -> nzjrs github I guess I need to play to find out....

I took a look at that link you gave, it had some very interesting things. Like the stash thing.
What I do now is use the micro-commits availiable in bzr and git, and when I want to commit into SVN I do a manual merge with Meld, creating a single commit into SVN. This allows me to use the prepare-Changelog script just fine, and even allows me to visualize what I've done so I can write better Changelog entries. My idea was to use the git master tree to merge what I wanted to commit and just use dcommit. But prepare-Changelog needs the changes to be between the tree and HEAD (or the index, not sure), and a merge command, instead of creating these changes, it merges all the commits inside the tree, so the tree is clean, and prepare-Changelog doesnt find anything.

Have you seen http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/prepare-ChangeLog ? I have not tried it yet.

I'm not sure the stash thing can help, but maybe if I merge all my micro-commits into one, it helps to get the changes into the master branch as one commit.
Anyway, most of time I just want to be safe and dont screw up the SVN repo ;) So the manual merge is still the safest so far.

I agree. I am sure we will get better at this!

About the UI branch, I wrote this http://wiki.github.com/airmind/conduit/ui-changes to explain the UI changes. It's by no means finished, but I think it improves the UI a lot.

I think so too, I really like having a selected rectangle, although I think changing the whole background might be a little harsh, I might experiment with just painting a bordering line around the selected conduit, or some other more subtle effects. I also like the toolbar, especially if it features a number of useful buttons. The bad thing about GtkToolbar is it is so massive, so it always looked silly with just one "Sync" button on it.
 

Also, I have created a modules/UNSUPPORTED directory, and I am moving some of the unfinished crap there. It speeds up load time a little, because it does not have to scan the unfinished modules. I dont think it will make too much difference in merging the dataproviders that have moved to the new config system because ;

This is a great idea. I was just thinking about this.
Maybe we could create some kind of plugin system. The modules are already very indenpendant, we can already load modules from different places and the API is fairly stable. If we think about it, modules are already plugins. But calling them like that, and actually opening up some kind of way for other people to contribute with modules would increase contributions and decrease the load on us. I was just using Gnome Do, and they have this section in their preferences dialog which would look a lot like what I'm thinking. There is a set of official modules, which we trust are stable and we can support very well, and a set of modules that are user contributed, but they can be very easily downloaded and enabled.

Agree completely. I thought about doing this once before, but never got around to solving the "where to host the plugins" problem. I even considered pulling them out of known good svn revisions, or somthing equally weird like that. If you look through the ModuleManager code, there is almost enough hooks there to handle conditional enable and disabling of plugins (see whitelist and blacklist). Some preferences UI code would need to be added, and then perhaps some other smarts for dealing with plugin versions (should system plugins of the same name override user plugins in case of conflict?)

I already did some work to create a website that can handle user submitted packages, with Google AppEngine, and can generate a repository information XML. I was using Capuchin to handle the client-side, but we can easily create one inside Conduit if we dont want the dependency on Mono.

I think that will be easy enough to recreate. I dont really want to depend on Mono. Your website sounds great. The thing I fear is that a system like new-stuff-manager/Capuchin will never really take off because distros want to be in control of packaging, and it doesnt seem consistant with that to install ones own plugins. However now that software like GnomeDo, and AWN have similar systems, we might as well join the party.
 

I think we would need some kind of way of telling for which version a plugin was made. Rhythmbox uses a very simple INI-like file which we could use, that has the plugin name as the filename, and includes information like Interface version and language. And if the version matches, we load the modules inside the plugin.
This is a blog post I did about a plugin I was developing for Rhythmbox: http://blog.arosenfeld.net/2007/12/rhythmbox-plugins-and-newstuffmanager.html
I never actually released it and it's not working anymore, but it's similar to what I've been thinking.

You are correct, the problem of loading plugins from external repositories is that we must be sure not to change, or to at least version the interface. Once we have done that,  everything else should follow easily enough. There is already a user writable conduit plugin directory (~/.config/conduit/plugins), so we could install the plugins to that.

Anyway, what do you think?

BTW, about the unsupported dataproviders, make sure the Rhythmbox DBus modules is moved to that folder too.

Done
 

1) I expect that the appropriate commits to BZR can just be recreated (in the loosest sense of the word) by copying the modified *Module.py file over the  new ones
2) You probbably didnt bother converting the broken dataproviders anyway! 

There is no problem with that. The dataproviders code is already different from what I based them on, so a simple diff isnt enough anymore. With Meld I can merge the dataproviders with the new code without problems. I was planning on doing it already.

Thanks.

What is the plan for merging the dataproviders that have updated to the new system? Do you want me to do it by copying in from your bzr branch, or do you want to do it? I think it makes sense to have ~1 svn commit and changelog entry per dataprover converted

I can do it. It'll just take some time, there is a lot of changes. I didnt know what to do about the commits, so I'll do 1 commit per dataprovider. It's not much work. Just the log messages will get repetitive (New config system convertion ;) Maybe I could to be more descriptive, like Flickr Config System Conversion.

I dont mind if the log messages are repeditive (see the ones about moving to UNSUPPORTED, etc). I have plenty of bugs in bugzilla I need to get through. I am happy enough bug fixing for the moment.
 

By the way, I'm having some troubles with dataproviders that require authentication. The browser window appears below the configuration dialog, and it can't be clicked, because the configuration dialog is modal to the main window, and probably the browser window is also modal to the main window or it isnt modal. So the configuration dialog must be closed for the browser window to be accessible.
What is strange is that the old configuration dialog is also modal, but I didnt notice it had this problem. Any ideas how to fix this? Could the browser window be modal to the configuration dialog?

I will have to look into this. I remember jumping through all sorts of hoops to fake modality and other things. The other dataprovider that is going to be the hardest to port is the FileModule one - I am still thinking about how to do this adequitely.

John
 

Excellent work.

Thanks!
 

John

Alexandre