Is there any need for us all to switch to the same DVCS, as long as we all switch to something that jhbuild understands? It’s a huge, huge job to convert the whole of GNOME from one VCS to another, as I’m sure everyone who was around at the time we switched from CVS can attest, but it’s less of a vast job to switch between VCSs for one project. So perhaps we can all stop attempting to convince the whole Foundation and start just trying to convince one group of maintainers; that seems more likely to happen, since the groups are far smaller. Then later if a project decides it wants to change to another DVCS, we’ll have a lot of good information to help it do so, and changing DVCSs isn’t really all that hard, is it? And in the end perhaps we’ll reach a consensus. Where would the bzr/git/hg repositories be kept? I don’t know. Maybe there could be an official GNOME place to keep them; maybe people could make use of launchpad or github or repo or freehg or whatever for now.
I think this turned into a bikeshed discussion a while ago. Maybe some tools are slightly better or worse than others, but I think any of them would be better than none of them, and I’d like it if everyone could get on with making awesome software rather than wasting energy arguing about where we keep it.
And now another subject: People were asking questions about how well Metacity co-exists with AWN. Someone (I forget who, sorry) was saying it works very well, and I have been playing with it and can confirm this. I also think AWN is very nifty and will probably continue using it. I’ve also been playing with Anjuta, and it’s rather nice. I wasted quite some time trying to get its GtkSourceView plugin to work: stick to Scintilla for now.
I should also tell you what’s going on in my life in general, but I am busy. Later.
And now, some other links, while I’m here:
- NO FREEDOM on the Patco subway
- Tarsem Singh was interviewed about The Fall (which you should all go and see, for it is awesome).
Photo by Judy Baxter, cc-by-nc-sa.
> Is there any need for us all to switch to the same DVCS
It’s a huge advantage for account management. Getting write access is so beaurocratic for every repository (gnome.org, gstreamer.org, freedesktop.org for cairo, o-hand.org for clutter, etc), and will likely remain so, that it’s very convenient having everything in one place.
I know the standard response is that DVCS makes it unnecessary to have write access to the main repository. But that’s wrong, no matter how often people say it. Certain people do need to directly commit to the one official version of the code. Easy branches are a useful extra, not a reason to celebrate chaos as a cool new paradigm and forget about making releases.
@Murray:
I understand your first paragraph, but your second is confusing to me. It’s certainly true that “certain people do need to directly commit to the one official version of the code”, but:
1) does that mean that the certain people should be chosen by a centralised group? I know I’ve had times, when the relevant people were busy, when we’ve had Metacity contributors waiting weeks for check-in rights. The maintainers presumbly know who should or shouldn’t be trusted in that instance. (On the flip side of the coin, you, for example, can commit random things to Metacity merely through having commit rights on a different project, although of course you don’t because that would be rude.)
2) it would be solved if there was a centralised place to have repositories. If people want to have $DVCS so much, let them maintain the infrastructure for it. GNOME maintainers generally *already* have shell accounts (on master, for making releases), and the sky hasn’t fallen; I can imagine another host existing which was for pushing bzr+ssh: and so on onto, and having some way of having their repo visible over http for everyone else. *handwaves*
Oh, and I know it would be an *advantage* if we all switched to the same DVCS; I’m just afraid it’ll never happen and we’ll be on svn forever because of the ongoing argument, and I think any of the three obvious answers would be an improvement.
Thomas: It will be more work for sysadmins to support multiple version control systems. And more difficult for people who want to join. If I count the active sysadmins and round it up, then perhaps we have 2 active GNOME sysadmins. There are no magical bunch of sysadmins or something.
A lot of infrastructure *depends* on SVN ATM. It doesn’t support multiple stuff like jhbuild. It requires *work*. If the infrastructure is split in multiple places, how do you propose the release team will do its work? Translators? I am willing to handle the infrastructure side of it, but I will not continue talking if nobody is listening.
Regarding account process problems: More time spend on some stuff, means the accounts process will not get fixed. As well as a bunch of other stuff. Oh well.
@ovitters:
Good points :/ I wonder why so few people are interested in helping out with being sysadmins. This certainly wasn’t intended as a knock to the sysadmin team, who are doing a fine job under difficult circumstances.
And I wasn’t proposing anything. I’m just asking
1) whether it would get us the (perceived) benefits of DVCS faster and stop this argument if we didn’t all have to change at the same time to the same thing, and
2) whether the advantages of doing so outweigh the disadvantages of being all in the same place on the same system.
I didn’t think I’d heard these point answered yet. I’m certainly not proposing any solutions.
> I understand your first paragraph, but your second is confusing to me.
> It’s certainly true that “certain people do need to directly commit to the > one official version of the code”, but:
>
> 1) does that mean that the certain people should be chosen by a > centralised group?
Yes, there’s obviously meant to be restrictions about who can easily get things into tarballs with minimal review. For the rest, easy branches are useful, like I said.
I like what git (and similar) can add to our processes to make people’s live easier. I don’t like the irrational tendency to use their adoption as an excuse to break perfectly good processes.
> I’ve also been playing with Anjuta, and it’s rather nice. I wasted quite some time trying to get its GtkSourceView plugin to work: stick to Scintilla for now.
Could you give us some details about this so we can try to fix it for you and for others? In theorie it should just work if you have gtksourceview-2.0 < 2.2 installed.