Re: fast-forward only policy
Hi, On Mon, May 4, 2009 at 9:38 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: Hi, I was one of the happiest person on this planet the day we moved to git and i can't thanks the people involved enough. Although overall i am pretty happy with the migration, I do have one concern: The policy of disallowing non-fastforward pushes to any branch. I understand that this is good for master and other stable branches, but otoh I think it breaks the usual git workflow for feature branches. I don't think it does break the usual git workflow. See [1] and [2]. In particular: Rebasing is clearly a useful technique, though. Linus does not tell developers not to use it; in fact, he encourages it sometimes. The key rule that was passed down is this: Thou Shalt Not Rebase Trees With History Visible To Others This means: if you're still in the git rebase phase, you don't push it out. If it's not ready, you send patches around, or use private git trees (just as a patch series replacement) that you don't tell the public at large about. git.gnome.org is quite public. There is email and IRC spam and everything. Suppose you could use heuristics to turn that off, but not really a fan of that. I for one want the spam on all my branches (if im still in rebase phase im not pushing to GNOME). I had a little chat with Owen regarding this: == IRC LOG BEGIN== zeenix owen: hi, are we sure about this 'only fastforward for all branches' policy? owen zeenix: Well, if we had a way of figuring out that some branches where feature branches not maintenance branches, then we could conceivablly allow rebasing those branches zeenix: But not sure how to do that. I suppose we could say if there are no numbers in the branch name it's a feature branch, but that would make thigns weird if you had a branch 'bonobo-removal-2' or something zeenix owen: or you could make developer put some specific prefix in the name of feature branches? owen would be a bit ugly if all our branches were named feature-* owen zeenix: feel free to mail suggestions for a policy to gnome-infrastructure zeenix ok, will do ==IRC LOG END== I am sending this mail here cause I thought it might be better to have a discussion on this and so that other developers can speak-up if they (dis)agree. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 John [1] http://lwn.net/Articles/328436/ [2] http://lwn.net/Articles/328438/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Personal branches [Was: Re: fast-forward only policy]
Behdad Esfahbod wrote: I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. A bit like what Zeeshan proposes then. Or the pusher's login name as prefix? That fixes the issue of user repos. The maintainer will have push power to all user branches (including deleting them). Some weird thing like that... The plans to have a gitorious instance have been abandoned ? Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
ma., 04.05.2009 kl. 12.43 -0500, skrev Brian Cameron: Kjartan: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Won't clutter-0.9.x work with clutter-gtk-0.8.x? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 9:37 AM, John Carr john.c...@unrouted.co.uk wrote:
Hi,
On Mon, May 4, 2009 at 9:38 PM, Zeeshan Ali (Khattak) zee...@gmail.com
wrote:
Hi,
I was one of the happiest person on this planet the day we moved to
git and i can't thanks the people involved enough. Although overall i
am pretty happy with the migration, I do have one concern: The policy
of disallowing non-fastforward pushes to any branch. I understand that
this is good for master and other stable branches, but otoh I think it
breaks the usual git workflow for feature branches.
I don't think it does break the usual git workflow. See [1] and [2].
In particular:
Rebasing is clearly a useful technique, though. Linus does not tell
developers not to use it; in fact, he encourages it sometimes. The key
rule that was passed down is this: Thou Shalt Not Rebase Trees With
History Visible To Others
And git.git doesn't follow that rule. Why?
Linux is developed with the chain of trust model; there is no master
repository, every developer has his own repo and they push only to
their own repo. Instead of pushing they send either patches or pull
requests to the relevant maintainer who will review the changes and
ack or nack them. The maintainer then will send his accumulated
patches (or pull request) to the next level up, and so on until it
reaches Linus' tree which is the one most people use, but by no means
the only one.
Note that in Linus' repo there's only one branch ('master'), where the
latest stuff is being developed. If you want the stable kernel, then
you must use another repository that is not maintained by Linus.
git.git doesn't follow that model, instead there is only one master
repository with many branches and there's only one maintainer (Junio).
Everyone must send their changes as patches and only Junio can push
them. Here there are multiple branches, including a moving branch 'pu'
(proposed updates). The 'pu' branch is simply a collection of the
patches sent to the mailing list which are relatively OK but will
possibly change since they still have comments and must be re-send.
This has the advantage that you don't have to hunt down the mailing
list for all the relatively good patches, you can just pick them from
the repository, or just use the 'pu' branch.
GNOME will not follow any of these models, there will be multiple
people pushing to the same repo, so in that sense it's less
distributed. There's another project following a similar model: X.Org.
I'm not sure they even have branch guidelines, but at least they have
user repositories where I guess each developer can do whatever they
want.
So I think you should either allow moving branches such as
'za-transcoding-rework' or have personal repositories on
git.gnome.org.
Cheers.
--
Felipe Contreras
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Mon, 2009-05-04 at 20:58 +0200, Luca Ferretti wrote: Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. If GNOME adopts WebKit as a standard component, I'm sure the distributions (including Ubuntu) will adapt. Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
Pierre-Luc Beaudoin wrote: In this email, I hope I made my case that libchamplain could be a nice addition to the GNOME family. Thanks for the detailed proposal, I updated the wiki page and added libchamplain to the jhbuild moduleset. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, 2009-05-05 at 10:57 +0200, Kjartan Maraas wrote: Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? I could roll a 0.9.0 release of clutter-gtk right now, but it still would be a moving target since we still have changes in clutter core that will undoubtedly reflect on clutter-gtk. also, using clutter-0.9.2 is strongly discouraged; you should be using git. this is quite like using glib and gtk+ from the master branch during the development cycle. Won't clutter-0.9.x work with clutter-gtk-0.8.x? no. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
Le mardi 05 mai 2009 à 11:49 +0200, Frederic Peters a écrit : Thanks for the detailed proposal, I updated the wiki page and added libchamplain to the jhbuild moduleset. I feel obliged to mention that libchamplain is a dep of eog-plugins, which has never been released yet and it not part of GNOME AFAIK. Pierre-Luc signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 12:29 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, May 5, 2009 at 9:37 AM, John Carr john.c...@unrouted.co.uk wrote: So I think you should either allow moving branches such as 'za-transcoding-rework' or have personal repositories on git.gnome.org. I arrived at the same conclusion after reading John's and your arguments. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Le mardi 05 mai 2009, à 01:51 +0300, Felipe Contreras a écrit : On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. Yes, I meant why project-major-minor (gtk-2-17) when you already know 'project'. What information would be lost with a '2-17' branch name? Why should we change a policy we had for ages and which works fine? Note that for GNOME modules specifically, having gnome-2-26 is important since it makes it clear that this is a branch for GNOME 2.26. Even if gvfs is at version 1.2, for example. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. You should read http://live.gnome.org/MaintainersCorner#branches Just read it. I'm not sure exactly what you wanted to highlight. Stable branches are useful! Most projects have mostly stable branches, afaik. Hmm, I'm not sure we are talking about the same thing. My understanding is that in most projects there's only one 'stable' branch, as in the most stable branch we have at the moment. Some projects have 'devel' (we are currently working on it, but it's not that sable) and some have 'next' (this is what you'll get on the next big release, it's probably stable enough). After reading that link (and some email searching), I think you do a branching process where you create a branch for the stable release and keep the development on the master branch. In that case I would suggest instead of creating a gtk-2-16 branch just use a stable branch, which will jump (or merge) from what you now call gtk-2-14 to gtk-2-16 when you do this branching process. The gtk-2-14 commits won't be lost as long as they are tagged. Some people are using the old stable branches, so we definitely want to keep them. While GNOME only officially supports only one stable branch at any time (which is what you seem to propose), enabling people to do more than that is a good thing. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
Le lundi 04 mai 2009, à 20:58 +0200, Luca Ferretti a écrit : Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. But they have a constraint on size, 700MB. Due to this, Ubuntu don't provide the GIMP own help browser. WebKit is already on the openSUSE live CD, iirc. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Le mardi 05 mai 2009, à 11:02 +0100, Emmanuele Bassi a écrit : also, using clutter-0.9.2 is strongly discouraged; you should be using git. this is quite like using glib and gtk+ from the master branch during the development cycle. Hrm, then what's the point of the development tarballs? :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, 2009-05-05 at 13:40 +0200, Vincent Untz wrote: Le mardi 05 mai 2009, à 11:02 +0100, Emmanuele Bassi a écrit : also, using clutter-0.9.2 is strongly discouraged; you should be using git. this is quite like using glib and gtk+ from the master branch during the development cycle. Hrm, then what's the point of the development tarballs? :-) providing snapshots, just like glib and gtk+ :-) but the API might change during the development cycle, so you should be aware of that. as far as I know, jhbuild does not build glib and gtk+ from tarballs either. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Emmanuele Bassi wrote: Hrm, then what's the point of the development tarballs? :-) providing snapshots, just like glib and gtk+ :-) but the API might change during the development cycle, so you should be aware of that. as far as I know, jhbuild does not build glib and gtk+ from tarballs either. Clutter is an external dependency, while glib and gtk+ are part of the platform. Policy (and experience) tells to build external dependencies from released tarballs. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, May 5, 2009 at 7:37 AM, Frederic Peters fpet...@gnome.org wrote: Emmanuele Bassi wrote: Hrm, then what's the point of the development tarballs? :-) providing snapshots, just like glib and gtk+ :-) but the API might change during the development cycle, so you should be aware of that. as far as I know, jhbuild does not build glib and gtk+ from tarballs either. Clutter is an external dependency, while glib and gtk+ are part of the platform. Policy (and experience) tells to build external dependencies from released tarballs. It seems that we're well on our way to making Clutter part of our platform so this formal distinction seems relatively meaningless at this point. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Am Dienstag, den 05.05.2009, 10:02 -0500 schrieb Jason D. Clinton: On Tue, May 5, 2009 at 7:37 AM, Frederic Peters fpet...@gnome.org wrote: Clutter is an external dependency, while glib and gtk+ are part of the platform. Policy (and experience) tells to build external dependencies from released tarballs. It seems that we're well on our way to making Clutter part of our platform so this formal distinction seems relatively meaningless at this point. It's not only a formal distinction. Such policies do not exist just because people are bored. It's based on bad experiences in the past. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, May 5, 2009 at 11:01 AM, Andre Klapper ak...@gmx.net wrote: It's not only a formal distinction. Such policies do not exist just because people are bored. It's based on bad experiences in the past. Why are we having this argument? Is release team going to veto Clutter for 2.28? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, 2009-05-05 at 14:37 +0200, Frederic Peters wrote: Hrm, then what's the point of the development tarballs? :-) providing snapshots, just like glib and gtk+ :-) but the API might change during the development cycle, so you should be aware of that. as far as I know, jhbuild does not build glib and gtk+ from tarballs either. Clutter is an external dependency, while glib and gtk+ are part of the platform. Policy (and experience) tells to build external dependencies from released tarballs. I'll make a clutter-gtk 0.9.0 release tarball tomorrow, then. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Am Dienstag, den 05.05.2009, 11:21 -0500 schrieb Jason D. Clinton: On Tue, May 5, 2009 at 11:01 AM, Andre Klapper ak...@gmx.net wrote: It's not only a formal distinction. Such policies do not exist just because people are bored. It's based on bad experiences in the past. Why are we having this argument? Basically because GNOME releases are shipped as tarballs. Is release team going to veto Clutter for 2.28? clutter, clutter-gtk/-cairo *ARE* already blessed external dependencies, see http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies . andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Kjartan: Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Won't clutter-0.9.x work with clutter-gtk-0.8.x? What do you mean by work? You need clutter 0.8 to build clutter-gtk 0.8. They are parallel installable, so if you want jhbuild to build both clutter 0.8 and 0.9, then that's one aproach. However, it seems it would be nice to just move over to 0.9 in one step if possible. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Emmanuele: I'll make a clutter-gtk 0.9.0 release tarball tomorrow, then. Will it include gobject-introspection support? http://bugzilla.o-hand.com/show_bug.cgi?id=1490 Would be nice to support gnome-shell with this, I think. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, 2009-05-05 at 13:32 -0500, Brian Cameron wrote: Emmanuele: I'll make a clutter-gtk 0.9.0 release tarball tomorrow, then. Will it include gobject-introspection support? http://bugzilla.o-hand.com/show_bug.cgi?id=1490 Would be nice to support gnome-shell with this, I think. yes, I'll land that patch first thing tomorrow before doing the release. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Platform
Hey folks, I'm taking a hard look at the Platform Overview and how we can improve our message to ISDs through better documentation. Our release sets, unfortunately, don't really reflect what we really recommend to developers. That role has more or less been delegated to the Platform Overview. The problem is that what's in the Platform Overview is based entirely on what I happened to think was worth mentioning at some point. I should not be the arbiter of our platform. I would like to get people's opinions on what technologies we should be pushing. I'm interested both in the here and now and in what people think the Gnome 3 message should be. I've organized my thoughts into three categories: Platform contains technologies that are currently in our Developer Platform release; Recommended contains thing that we seem to agree we should push, but are either in the Desktop release or just in our external dependencies; and Others contains stuff that I think is cool and could be part of our core offering some time in the indeterminate future. The list is what came to mind as I was writing this email. Please feel free to discuss libraries I forgot. Platform GTK+ -- The core of how we make graphical applications. Pango -- Internationalized text rendering system. You love it and you know it. GLib -- The foundation for pretty much everything we do. GIO -- Part of GLib, but worth a separate mention in the Platform Overview. GConf -- Configuration system. There is talk of a new system (see below). But I think it's obvious that we need to be pushing something here. So as long as GConf is what we have, it's what we push. ATK -- Accessibility toolkit. Used by GTK+. Should be used by anything else that does UIs. Recommended === Cairo -- Incredible drawing library, used by GTK+. There seems to be general agreement that developers should use Cairo when they need to do custom drawing. GStreamer -- All things multimedia. I don't think there's any argument against GStreamer being the Gnome-blessed way to do multimedia. D-Bus -- Inter-process messaging system. Lots of stuff is built on it. How much do we want to push it directly? Avahi -- Service discovery. This is used in quite a few places. I know some people in the past had talked about having a simple wrapper in GLib. How much do we push it? gnome-keyring -- Storing passwords and other secrets. I think this is an important thing to offer ISDs, but this seems to be languishing as a desktop-only thing. evolution-data-server -- Address book and calendaring. I've seen half a dozen projects come and go that aim to augment or replace e-d-s. We seem to like the idea, but I'm not sure we all love the implementation. libsoup -- HTTP library. Honestly, HTTP is such a core thing these days, we need to offer something. Everybody seems generally happy with libsoup in general. Should it be in the Platform? Should its functionality just live in GLib alongside fancy new networking stuff? libxml2/libxslt -- We put these into the external deps a couple release cycles back. Do we want to continue pushing them as part of our platform? Others == GSettings -- GConf replacement to live in GLib. Telepathy -- Instant messaging and beyond. I think there is a lot of really cool potential here. Libchamplain -- Wicked cool mapping library. This is not something I would have thought of as something we need to offer. But now that it's here, it's a really compelling technology with a lot of potential. Clutter -- Are we actively embracing Clutter, or is it just something we're OK with people using? The message is unclear. Tracker -- I don't think we can afford to be without a search system. This isn't just about having file search as a feature. It's about providing something that ISDs can leverage to make their applications better. GNIO -- Networking library for GLib. WebKit -- More and more applications are finding uses for an embedded HTML rendering widget. I think we need to provide one with a solid API. WebKit seems to be the direction people are heading in. Various D-Bus services and APIs -- DeviceKit, PolicyKit, ConsoleKit, I think there's something for power management, etc. Are these things we expect applications developers to use directly? What's our message? All right, that's what's come to mind so far. I'd also like to discuss what we're pushing on the mobile front, but that's another can of worms. I'm really curious to hear what the community thinks. Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 2009-05-05 at 14:05 -0500, Shaun McCance wrote: Hey folks, I'm taking a hard look at the Platform Overview http://library.gnome.org/devel/platform-overview/stable/index.html For those who don't know. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto: Hey folks, [...] The list is what came to mind as I was writing this email. Please feel free to discuss libraries I forgot. Thanks Shaun, you're wonderful as always. I also think it would be nice to mention gobject-introspection in a separate part, because using it we can easily provide bindings to other languages and many other nifty things. As for other things: is GNOME pushing tracker, beagle or just xesam (now that it's published)? Maybe I'm a bit confused about all this. Please help me understand. seed may be worth mentioning. Also libcanberra. Another question: what about inserting a section about gtk-doc and/or doxygen? Documenting source code is quite important. Thanks, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 2009-05-05 at 21:25 +0200, Matteo Settenvini wrote: Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto: Hey folks, [...] The list is what came to mind as I was writing this email. Please feel free to discuss libraries I forgot. Thanks Shaun, you're wonderful as always. Aw shucks. :) I also think it would be nice to mention gobject-introspection in a separate part, because using it we can easily provide bindings to other languages and many other nifty things. There's a section on bindings. I'd like to put more in there, but I'd need some help. Perhaps it could be discussed in the lead-in? As for other things: is GNOME pushing tracker, beagle or just xesam (now that it's published)? Maybe I'm a bit confused about all this. Please help me understand. I am too. Throw Nepomuk into the list of things to be confused about. seed may be worth mentioning. Also libcanberra. I did think about Seed. And there's GJS. I'm not entirely sure how we imagine this fitting in. Is it just another binding, or is it something we want to push as a framework to be used no matter what core language your application is written in? Good catch on libcanberra. It's clearly good for us to have a convenient API for this. Do we really want to push another micro-library for that? Should GTK+ just learn to do it? Another question: what about inserting a section about gtk-doc and/or doxygen? Documenting source code is quite important. I've thought about doing a section on development tools in general. This would fit nicely there. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Shaun: Shouldn't GStreamer be included for media support? If not in the Platform, then at least Recommended? Also, what about gvfs, libdaemon, and libunique? Brian On 05/05/09 14:05, Shaun McCance wrote: Hey folks, I'm taking a hard look at the Platform Overview and how we can improve our message to ISDs through better documentation. Our release sets, unfortunately, don't really reflect what we really recommend to developers. That role has more or less been delegated to the Platform Overview. The problem is that what's in the Platform Overview is based entirely on what I happened to think was worth mentioning at some point. I should not be the arbiter of our platform. I would like to get people's opinions on what technologies we should be pushing. I'm interested both in the here and now and in what people think the Gnome 3 message should be. I've organized my thoughts into three categories: Platform contains technologies that are currently in our Developer Platform release; Recommended contains thing that we seem to agree we should push, but are either in the Desktop release or just in our external dependencies; and Others contains stuff that I think is cool and could be part of our core offering some time in the indeterminate future. The list is what came to mind as I was writing this email. Please feel free to discuss libraries I forgot. Platform GTK+ -- The core of how we make graphical applications. Pango -- Internationalized text rendering system. You love it and you know it. GLib -- The foundation for pretty much everything we do. GIO -- Part of GLib, but worth a separate mention in the Platform Overview. GConf -- Configuration system. There is talk of a new system (see below). But I think it's obvious that we need to be pushing something here. So as long as GConf is what we have, it's what we push. ATK -- Accessibility toolkit. Used by GTK+. Should be used by anything else that does UIs. Recommended === Cairo -- Incredible drawing library, used by GTK+. There seems to be general agreement that developers should use Cairo when they need to do custom drawing. GStreamer -- All things multimedia. I don't think there's any argument against GStreamer being the Gnome-blessed way to do multimedia. D-Bus -- Inter-process messaging system. Lots of stuff is built on it. How much do we want to push it directly? Avahi -- Service discovery. This is used in quite a few places. I know some people in the past had talked about having a simple wrapper in GLib. How much do we push it? gnome-keyring -- Storing passwords and other secrets. I think this is an important thing to offer ISDs, but this seems to be languishing as a desktop-only thing. evolution-data-server -- Address book and calendaring. I've seen half a dozen projects come and go that aim to augment or replace e-d-s. We seem to like the idea, but I'm not sure we all love the implementation. libsoup -- HTTP library. Honestly, HTTP is such a core thing these days, we need to offer something. Everybody seems generally happy with libsoup in general. Should it be in the Platform? Should its functionality just live in GLib alongside fancy new networking stuff? libxml2/libxslt -- We put these into the external deps a couple release cycles back. Do we want to continue pushing them as part of our platform? Others == GSettings -- GConf replacement to live in GLib. Telepathy -- Instant messaging and beyond. I think there is a lot of really cool potential here. Libchamplain -- Wicked cool mapping library. This is not something I would have thought of as something we need to offer. But now that it's here, it's a really compelling technology with a lot of potential. Clutter -- Are we actively embracing Clutter, or is it just something we're OK with people using? The message is unclear. Tracker -- I don't think we can afford to be without a search system. This isn't just about having file search as a feature. It's about providing something that ISDs can leverage to make their applications better. GNIO -- Networking library for GLib. WebKit -- More and more applications are finding uses for an embedded HTML rendering widget. I think we need to provide one with a solid API. WebKit seems to be the direction people are heading in. Various D-Bus services and APIs -- DeviceKit, PolicyKit, ConsoleKit, I think there's something for power management, etc. Are these things we expect applications developers to use directly? What's our message? All right, that's what's come to mind so far. I'd also like to discuss what we're pushing on the mobile front, but that's another can of worms. I'm really curious to hear what the community thinks. Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___
Re: Platform
Il giorno mar, 05/05/2009 alle 14.41 -0500, Brian Cameron ha scritto: Shaun: Shouldn't GStreamer be included for media support? It's in the list (second item of the Recommended section) :-) Also, what about gvfs, libdaemon, and libunique? gvfs could be introduced along with GIO; as for libunique, I gather that plans were there to put that functionality inside Gtk+. Any update on that? I don't know about libdaemon. Brian Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 2:35 PM, Vincent Untz vu...@gnome.org wrote: Le mardi 05 mai 2009, à 01:51 +0300, Felipe Contreras a écrit : On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. Yes, I meant why project-major-minor (gtk-2-17) when you already know 'project'. What information would be lost with a '2-17' branch name? Why should we change a policy we had for ages and which works fine? Because you just switched your SCM and it's the best time to do that? Note that for GNOME modules specifically, having gnome-2-26 is important since it makes it clear that this is a branch for GNOME 2.26. Even if gvfs is at version 1.2, for example. I'm not sure the guidelines I've read mention that usage, but in any case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. You should read http://live.gnome.org/MaintainersCorner#branches Just read it. I'm not sure exactly what you wanted to highlight. Stable branches are useful! Most projects have mostly stable branches, afaik. Hmm, I'm not sure we are talking about the same thing. My understanding is that in most projects there's only one 'stable' branch, as in the most stable branch we have at the moment. Some projects have 'devel' (we are currently working on it, but it's not that sable) and some have 'next' (this is what you'll get on the next big release, it's probably stable enough). After reading that link (and some email searching), I think you do a branching process where you create a branch for the stable release and keep the development on the master branch. In that case I would suggest instead of creating a gtk-2-16 branch just use a stable branch, which will jump (or merge) from what you now call gtk-2-14 to gtk-2-16 when you do this branching process. The gtk-2-14 commits won't be lost as long as they are tagged. Some people are using the old stable branches, so we definitely want to keep them. While GNOME only officially supports only one stable branch at any time (which is what you seem to propose), enabling people to do more than that is a good thing. As I said, the commits won't be lost, people that want to work on an old version can do that: git checkout -b my-incredibly-old-branch LIBGNOME_2_0_0 Tags and branches are simply commit references (pointers); tags are for fixed targets, while branches are for moving ones. If the branch is not going to move any more there isn't much point in keeping it, specially when there's a tag pointing to the same commit. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Hi Shaun Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto: Recommended === Cairo -- Incredible drawing library, used by GTK+. There seems to be general agreement that developers should use Cairo when they need to do custom drawing. I do not think that putting cairo (and to some lesser extent d-bus and libxml) in the same bucket of gstreamer or e-d-s is an accurate representation to communicate to ISDs: cairo is used by any app which is using gtk and offers (at least afaik) the same api and abi guarantees. It just happens to be an external dependency because its developement extends beyond gnome and its schedule. I feel it should be mentioned in a separate section (Foundations?) along with xorg, xlib, fontconfig, pixman and maybe even d-bus and libxml Ciao Paolo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 05, 2009 at 10:53:55PM +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 2:35 PM, Vincent Untz vu...@gnome.org wrote: Le mardi 05 mai 2009, à 01:51 +0300, Felipe Contreras a écrit : On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. Yes, I meant why project-major-minor (gtk-2-17) when you already know 'project'. What information would be lost with a '2-17' branch name? Why should we change a policy we had for ages and which works fine? Because you just switched your SCM and it's the best time to do that? To state more clearly: What is the benefit of switching? Does it outweigh the inconsistency of breaking current usage? Note that for GNOME modules specifically, having gnome-2-26 is important since it makes it clear that this is a branch for GNOME 2.26. Even if gvfs is at version 1.2, for example. I'm not sure the guidelines I've read mention that usage, but in any case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. IMO you should make a good argument to switch, not the other way around. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 10:57 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 10:53:55PM +0300, Felipe Contreras wrote:
On Tue, May 5, 2009 at 2:35 PM, Vincent Untz vu...@gnome.org wrote:
Le mardi 05 mai 2009, à 01:51 +0300, Felipe Contreras a écrit :
On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
Hi
On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
[...] what is the point of having 'project' in the branch
name? Branches are per-repository, so you would never have a non
'gtk-' branch in the GTK+ repo.
Not project but really [project]-[MAJOR]-[MINOR]..
Yes, I meant why project-major-minor (gtk-2-17) when you already
know 'project'. What information would be lost with a '2-17' branch
name?
Why should we change a policy we had for ages and which works fine?
Because you just switched your SCM and it's the best time to do that?
To state more clearly: What is the benefit of switching? Does it
outweigh the inconsistency of breaking current usage?
Note that for GNOME modules specifically, having gnome-2-26 is important
since it makes it clear that this is a branch for GNOME 2.26. Even if
gvfs is at version 1.2, for example.
I'm not sure the guidelines I've read mention that usage, but in any
case that's not a compelling argument; you can still have branches
'1-2' and 'gnome-2-26'.
IMO you should make a good argument to switch, not the other way around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
--
Felipe Contreras
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 11:00 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. Yeap, IMHO pango-1-2 1-2 1.2 stable -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, May 5, 2009 at 3:05 PM, Shaun McCance sha...@gnome.org wrote: Hey folks, [...] I would like to get people's opinions on what technologies we should be pushing. I'm interested both in the here and now and in what people think the Gnome 3 message should be. Hi, Great time to brain-storm what we have... I think we should put some emphasis on the devtools suite in general, a basic we have tools message is called for. Personally, I always compile gnome relocated by hand, I tried jhbuild years ago and found it clunky then, Im trying MacPorts now and find it works awesome, where are we with jhbuild ? theres also another one out there iirc, cant remember the name... I would be interested to know, what do we all generally recommend in terms of a tool/setup to compile gnome ? ... anyway, that should also be part of this message, we have tools and we can make it easy for you to build... [...] GConf -- Configuration system. There is talk of a new system (see below). But I think it's obvious that we need to be pushing something here. So as long as GConf is what we have, it's what we push. ditto GConf as dbus below, settings, setting observations and messaging to into a need-to-have bundle IMO [...] D-Bus -- Inter-process messaging system. Lots of stuff is built on it. How much do we want to push it directly? I think we want to push this alot, applications need IPCs, I would expect a book about developing with GNOME technologies to include a chapter on IPC/settings and an observer model (something like GConf I guess, we have GConf over dbus ? or GSettings now ? sorry for not knowing all the details ...). From what I gather... which is a little vague... using some language bindings you can observe the state of an object even if its in another process, GObject mapping over dbus is something I heard of... does that really exist ? if so, its something people need to hear about.. Anyway IMO we need to have an IPC to use in the platform. [...] libxml2/libxslt -- We put these into the external deps a couple release cycles back. Do we want to continue pushing them as part of our platform? I think its important to have an xml library, what is here to replace libxml2 ? (maybe I'm missing something...) [...] Libchamplain -- Wicked cool mapping library. This is not something I would have thought of as something we need to offer. But now that it's here, it's a really compelling technology with a lot of potential. +1 for the ooh-aah factor heh Clutter -- Are we actively embracing Clutter, or is it just something we're OK with people using? The message is unclear. I am privately embracing Clutter myself, I think its wrong to consider it as a drop in replacement for GTK+, right now I would probably recommend Clutter or another leading canvas like hippo-canvas, to do anything really fancy in a UI... WebKit -- More and more applications are finding uses for an embedded HTML rendering widget. I think we need to provide one with a solid API. WebKit seems to be the direction people are heading in. just pointing out that the next generation mozilla (xulrunner) will also sport a portable embeddable GTK+ widget... although I dont really have an opinion about what we should push in this regard... Anyway I should get back to work... thanks for starting this thread, Im also interested to hear what people have to say ;-) Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On 05/05/2009 04:12 PM, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:00 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. Yeap, IMHO pango-1-2 1-2 1.2 stable It's nice to have stable, but we need a fixed name for those branches too. I'd love to see stable always be an alias for the latest stable branch, but that doesn't obviate the need for 1.2 or pango-1-2. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 2009-05-05 at 21:59 +0200, Paolo Borelli wrote: Hi Shaun Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto: Recommended === Cairo -- Incredible drawing library, used by GTK+. There seems to be general agreement that developers should use Cairo when they need to do custom drawing. I do not think that putting cairo (and to some lesser extent d-bus and libxml) in the same bucket of gstreamer or e-d-s is an accurate representation to communicate to ISDs: cairo is used by any app which is using gtk and offers (at least afaik) the same api and abi guarantees. It just happens to be an external dependency because its developement extends beyond gnome and its schedule. Sorry, I should have been more clear. The sections in this email were just for this email. I didn't intend for them to reflect sections in the Overview itself. I feel it should be mentioned in a separate section (Foundations?) along with xorg, xlib, fontconfig, pixman and maybe even d-bus and libxml That's the kind of input I'm looking for. There are numerous technologies that we build on but don't push. So, for instance, X is certainly at the core of of all our graphical technologies, but it's almost completely hidden from an API perspective. We don't spend a lot of documentation effort telling people about all the cool things they can do with X. So do we treat Cairo as an implementation detail, or is it something we talk up? My thoughts are that if you're doing anything non-trivial, you're probably going to need to do some custom drawing outside of what GTK+ provides. Cairo is extremely cool, and I think we should communicate that. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 2009-05-05 at 14:41 -0500, Brian Cameron wrote: Shaun: Shouldn't GStreamer be included for media support? If not in the Platform, then at least Recommended? It's in there. Also, what about gvfs, libdaemon, and libunique? GVFS doesn't provide API. On the other hand, it does make GIO much more awesome. It's currently discussed in the section on GIO, and I don't have any plans to change that. Shouldn't libunique be a part of GLib? What's libdaemon? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 05, 2009 at 11:10:42PM +0300, Felipe Contreras wrote:
IMO you should make a good argument to switch, not the other way around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
You gave as reason 'you just switched your SCM and it's the best time to
do that'. That is what I was referring to. Now you give another argument
to the same question.
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Very strong -1 to 'stable'.
Can we rename branches? What breaks? Gentoo?
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc
are stable. So it isn't clear.
--
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On 05/05/2009 04:20 PM, Shaun McCance wrote: So do we treat Cairo as an implementation detail, or is it something we talk up? My thoughts are that if you're doing anything non-trivial, you're probably going to need to do some custom drawing outside of what GTK+ provides. Cairo is extremely cool, and I think we should communicate that. We really want to advertise it as part of developing with GTK+. It's your one-stop shop for all drawing (*and* printing). So, it's a great relief that it's a separate component, but one that we need to extensively invest on. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On tis, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? If I want the sources for the gedit in Gnome 2.26, cloning gedit's repository and checking out the branch 'gnome-2-26' sounds like an easy-to-remember way to do it. If I want the sources for gedit in Gnome 2.24, I can probably deduce that 'gnome-2-24' sounds like a branch to look for. To more-or-less completely replace the contents of the branch 'stable' every six months, and keep tags to those revisions to make sure they can be retrieved and turned into their own branches if anyone wants, sounds like branch abuse to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote:
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
And what if I'm still actively developing and making
releases for the 2.24 series and the 2.26 series?
What if I backport fixes to the old stable branch?
Now I'm likely to have merge conflicts when I try
to copy master over stable.
Note that it is not at all uncommon to branch early.
That is, a maintainer wants to get hacking on 2.27
stuff before we've release 2.26.0, so he makes the
gnome-2-26 branch, announces it to the appropriate
people, and gets hacking on master.
I just don't think a single stable branch accurately
reflects history, and it can cause various logistical
problems. As it is, I can easily see the history of
whatever ought to be in Gnome 2.26, including stuff
that's been committed but not yet tagged in a release.
--
Shaun
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 05.05.09 16:33, Matthias Clasen (matthias.cla...@gmail.com) wrote: What's libdaemon? libdaemon is an implementation detail of pulseaudio as far as I am concerned. Just for correctness' sake: it's an implementation detail of Avahi, not of PulseAudio. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Hi, I am trying to put some git wishes pros/cons in http://live.gnome.org/Git/Wishes. I surely missed things, but I tried to be neutral. regards, -- Marc-André Lureau Sent from Helsinki, Southern Finland, Finland ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 11:18 PM, Behdad Esfahbod beh...@behdad.org wrote: On 05/05/2009 04:12 PM, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:00 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. Yeap, IMHO pango-1-2 1-2 1.2 stable It's nice to have stable, but we need a fixed name for those branches too. I'd love to see stable always be an alias for the latest stable branch, but that doesn't obviate the need for 1.2 or pango-1-2. Yes, if you *must* have a branch for each single stable major release you have, then it would be nice to have another branch (pointer) to the latest one. However, why do you need a 1.2 branch when you already have a PANGO_1_2_4 tag? -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Hi On Tue, May 5, 2009 at 11:33 PM, Matthias Clasen matthias.cla...@gmail.com wrote: libdaemon is an implementation detail of pulseaudio as far as I am concerned. PulseAudio does not use libdaemon, afaik. Avahi, maybe? regards, -- Marc-André Lureau Sent from Helsinki, Southern Finland, Finland ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, May 5, 2009 at 4:22 PM, Shaun McCance sha...@gnome.org wrote: Also, what about gvfs, libdaemon, and libunique? GVFS doesn't provide API. On the other hand, it does make GIO much more awesome. It's currently discussed in the section on GIO, and I don't have any plans to change that. Shouldn't libunique be a part of GLib? Unique application and session support should be moving into GTK+, eventually. For that to happen, we need to sort out dbus support in glib first. See current gtk-devel-list discussions, and http://bugzilla.gnome.org/show_bug.cgi?id=579571 What's libdaemon? libdaemon is an implementation detail of pulseaudio as far as I am concerned. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 11:17 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:10:42PM +0300, Felipe Contreras wrote:
IMO you should make a good argument to switch, not the other way around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
You gave as reason 'you just switched your SCM and it's the best time to
do that'. That is what I was referring to. Now you give another argument
to the same question.
There are many reasons, I thought it was obvious that 'stable' is
simpler than '1-2'.
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Very strong -1 to 'stable'.
Can we rename branches? What breaks? Gentoo?
Gentoo is using your tarball releases. Or what do you mean?
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc
are stable. So it isn't clear.
The latest one, of course.
You don't need branches for targets that are not going to move.
Branches are for moving targets, tags are for fixed ones.
--
Felipe Contreras
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 05, 2009 at 11:52:54PM +0300, Felipe Contreras wrote:
On Tue, May 5, 2009 at 11:17 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:10:42PM +0300, Felipe Contreras wrote:
IMO you should make a good argument to switch, not the other way around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
You gave as reason 'you just switched your SCM and it's the best time to
do that'. That is what I was referring to. Now you give another argument
to the same question.
There are many reasons, I thought it was obvious that 'stable' is
simpler than '1-2'.
Not to me when there are multiple stable branches. It then just is
latest-stable.
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Very strong -1 to 'stable'.
Can we rename branches? What breaks? Gentoo?
Gentoo is using your tarball releases. Or what do you mean?
They complain when stuff isn't branched/tagged properly. Forgot which.
You didn't address the rest of my question.
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc
are stable. So it isn't clear.
The latest one, of course.
You don't need branches for targets that are not going to move.
Branches are for moving targets, tags are for fixed ones.
That is just confusing. Really, I don't see why you don't see this.
--
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
git and trailing whitespace
Heya! Trailing whitespace sucks. git is only half as much fun when people have trailing whitespace in their code. diffs get cluttered up by changes that actually aren't changes. Many other project these days enforce pretty rigid whitespace regimes and I wonder if that would be something to enforce globally on git.gnome.org, too? This is not a question of coding style. Whatever kind of indenting you choose, trailing whitespace cleanliness is about making git more fun without losing anything. Of course, enforcing this is a controversial issue and there are many different ways one could implement this: One could have a receive hook on the server side that refuses commits with trailing whitespace. One could instead have a commit hook that is installed by autogen.sh on the client side. One could have one that automatically removes trailing whitespace on commit. One could have a combination of these hooks. Then there is the question what to do with the current repos: add commits that clean up the whitespace sitaution once and from the on enforce cleanliness, or just enforce cleanliness on added lines and leave everything else as it is? Then there is the question about editors. emacs has stuff like this: http://www.splode.com/~friedman/software/emacs-lisp/src/whitespace.el. vim has something similar I heard. Not sure if other editors do. Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On 05/05/2009 05:00 PM, Lennart Poettering wrote: Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? The default git pre-commit scripts (disabled by default) has a check for that. In cairo, we recommend enabling it (by way of chmod +x .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that off at times. Something to keep in mind. I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. behdad Lennart ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 11:55 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:52:54PM +0300, Felipe Contreras wrote:
On Tue, May 5, 2009 at 11:17 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:10:42PM +0300, Felipe Contreras wrote:
IMO you should make a good argument to switch, not the other way around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
You gave as reason 'you just switched your SCM and it's the best time to
do that'. That is what I was referring to. Now you give another argument
to the same question.
There are many reasons, I thought it was obvious that 'stable' is
simpler than '1-2'.
Not to me when there are multiple stable branches. It then just is
latest-stable.
To me one would be 'stable' the other one would be 'maint'. If you are
going to argue that there could be 3 stable branches at the same time
then I would say: 'stable' (1-4), '1-2' and '1-0' make sense, but as
soon as the branch stops being active it should be deleted.
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Very strong -1 to 'stable'.
Can we rename branches? What breaks? Gentoo?
Gentoo is using your tarball releases. Or what do you mean?
They complain when stuff isn't branched/tagged properly. Forgot which.
Well, ask them. I think they would be perfectly fine with a 'stable'
branch. That way they don't need to update their ebuild each time
there's a new major GNOME release.
You didn't address the rest of my question.
I'm not sure what exactly you mean:
Can we rename branches? - Yes
What breaks? - Huh?
Gentoo? - Huh?
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc
are stable. So it isn't clear.
The latest one, of course.
You don't need branches for targets that are not going to move.
Branches are for moving targets, tags are for fixed ones.
That is just confusing. Really, I don't see why you don't see this.
That's just how git works: branches and tags are mere pointers.
There's no difference in the object storage, the only difference is
logical, you use branches in a way, tags in another way.
You can do stuff like:
git update-ref refs/heads/foobar 68b2aee # creates foobar branch
git update-ref refs/tags/foobar 68b2aee # creates foobar tag
git update-ref refs/taggybranch/foobar 68b2aee # creates foobar weird ref
--
Felipe Contreras
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, 2009-05-05 at 23:47 +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:18 PM, Behdad Esfahbod beh...@behdad.org wrote: On 05/05/2009 04:12 PM, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:00 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. Yeap, IMHO pango-1-2 1-2 1.2 stable It's nice to have stable, but we need a fixed name for those branches too. I'd love to see stable always be an alias for the latest stable branch, but that doesn't obviate the need for 1.2 or pango-1-2. Yes, if you *must* have a branch for each single stable major release you have, then it would be nice to have another branch (pointer) to the latest one. However, why do you need a 1.2 branch when you already have a PANGO_1_2_4 tag? Because somebody might want to commit something for Pango 1.2.5. Bear in mind that, even if developers aren't planning anything else for a stable series, translators and documentation writers might still add things. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 06, 2009 at 12:33:59AM +0300, Felipe Contreras wrote:
On Tue, May 5, 2009 at 11:55 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:52:54PM +0300, Felipe Contreras wrote:
On Tue, May 5, 2009 at 11:17 PM, Olav Vitters o...@bkor.dhs.org wrote:
On Tue, May 05, 2009 at 11:10:42PM +0300, Felipe Contreras wrote:
IMO you should make a good argument to switch, not the other way
around.
What I'm proposing makes things simpler. Do I need to make a good
argument of why simple things are good?
You gave as reason 'you just switched your SCM and it's the best time to
do that'. That is what I was referring to. Now you give another argument
to the same question.
There are many reasons, I thought it was obvious that 'stable' is
simpler than '1-2'.
Not to me when there are multiple stable branches. It then just is
latest-stable.
To me one would be 'stable' the other one would be 'maint'. If you are
going to argue that there could be 3 stable branches at the same time
then I would say: 'stable' (1-4), '1-2' and '1-0' make sense, but as
soon as the branch stops being active it should be deleted.
Multiple stable things? Just confusing. Don't agree with deleting branch
names.
To be clear on what I'm proposing: there's no need to add 'project' to
branch names when you already know the project ('1-2' is fine). But
going into the next level, there's no need to have '1-2', '1-4' and
'1-0', 'stable' and 'master' are more than enough.
Very strong -1 to 'stable'.
Can we rename branches? What breaks? Gentoo?
Gentoo is using your tarball releases. Or what do you mean?
They complain when stuff isn't branched/tagged properly. Forgot which.
Well, ask them. I think they would be perfectly fine with a 'stable'
I'm not going to do your work.
'I think'... we must be sure.
branch. That way they don't need to update their ebuild each time
there's a new major GNOME release.
You didn't address the rest of my question.
I'm not sure what exactly you mean:
Can we rename branches? - Yes
What breaks? - Huh?
Is What breaks really that unclear?
Gentoo? - Huh?
Imagine someone who has been on a GNOME hiatus or is a new comer. What
would be easier to understand? '1-2' or 'stable'?
'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc
are stable. So it isn't clear.
The latest one, of course.
You don't need branches for targets that are not going to move.
Branches are for moving targets, tags are for fixed ones.
That is just confusing. Really, I don't see why you don't see this.
That's just how git works: branches and tags are mere pointers.
There's no difference in the object storage, the only difference is
logical, you use branches in a way, tags in another way.
Don't care about Git workings. I care about understanding a branch name.
Deleting branches sounds really bad (aside from purely symbolical
'stable').
You can do stuff like:
I don't understand Git.
--
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, 2009-05-06 at 00:33 +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:55 PM, Olav Vitters o...@bkor.dhs.org wrote: [...] That's just how git works: branches and tags are mere pointers. There's no difference in the object storage, the only difference is logical, you use branches in a way, tags in another way. You can do stuff like: git update-ref refs/heads/foobar 68b2aee # creates foobar branch git update-ref refs/tags/foobar 68b2aee # creates foobar tag git update-ref refs/taggybranch/foobar 68b2aee # creates foobar weird ref Are you assuming that all changes in stable branches get merged in development branches? How should it work the following development? a--a---a---a---a (2-20) +---b---b---b---b---b (2-22) +---c---c---c---c---c---c (2-24) +---d---d---d---d---d---d---d--... (master) If delete the branch 2-22 I will loose the latest 3 commits, same for 2-20, and so on. Regards, -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 11:29 PM, Robin Sonefors ozam...@flukkost.nu wrote: On tis, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? If I want the sources for the gedit in Gnome 2.26, cloning gedit's repository and checking out the branch 'gnome-2-26' sounds like an easy-to-remember way to do it. If I want the sources for gedit in Gnome 2.24, I can probably deduce that 'gnome-2-24' sounds like a branch to look for. Right, 'gnome-2-24' does actually point to the latest release (2.24.3) which is good and I think all the GNOME projects should have such branches (perhaps 'gnome-2.24' instead) so it's easier to manually checkout the sources you want. But that's not in the guidelines, and it seems not even GTK+ is following that. I believe right now in order to find out all the latest stable packages for a certain GNOME release you need to use something like jhbuild. Also note that in gedit's repo 'gnome-2-22' is not even pointing to a release, so it might not even work and therefore not exactly what you want. But 'gedit-2-8' on the other hand (project-major-minor), that's what I'm suggesting to replace with 'stable'. To more-or-less completely replace the contents of the branch 'stable' every six months, and keep tags to those revisions to make sure they can be retrieved and turned into their own branches if anyone wants, sounds like branch abuse to me. That's exactly what people do with linux's repos, and I wouldn't call it abuse, it's a perfectly natural git operation. Note that you still need to create a local branch anyway: git checkout -b gedit-2-8 origin/gedit-2-8 There's not much difference to: git checkout -b gedit-2-8 GEDIT_2_8_2 -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 12:46 AM, Germán Póo-Caamaño g...@gnome.org wrote: On Wed, 2009-05-06 at 00:33 +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:55 PM, Olav Vitters o...@bkor.dhs.org wrote: [...] That's just how git works: branches and tags are mere pointers. There's no difference in the object storage, the only difference is logical, you use branches in a way, tags in another way. You can do stuff like: git update-ref refs/heads/foobar 68b2aee # creates foobar branch git update-ref refs/tags/foobar 68b2aee # creates foobar tag git update-ref refs/taggybranch/foobar 68b2aee # creates foobar weird ref Are you assuming that all changes in stable branches get merged in development branches? How should it work the following development? a--a---a---a---a (2-20) +---b---b---b---b---b (2-22) +---c---c---c---c---c---c (2-24) +---d---d---d---d---d---d---d--... (master) If delete the branch 2-22 I will loose the latest 3 commits, same for 2-20, and so on. If you care about them, you'll make a tag that points to the head (and make a release). If you have a tag, a branch, or any other reference pointing to the commits then you'll never loose them (nor their ancestors). -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Wed, May 6, 2009 at 12:06 AM, Behdad Esfahbod beh...@behdad.org wrote: On 05/05/2009 05:00 PM, Lennart Poettering wrote: Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? Strongly agree with you. :) The default git pre-commit scripts (disabled by default) has a check for that. In cairo, we recommend enabling it (by way of chmod +x .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that off at times. Something to keep in mind. I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. I do the same and AFAIK this is common practice amongst many developer who have been using git. However, not everyone does that and therefore the need for a rule for this. I said rule rather than policy since I seriously doubt anyone can point out any positive points of trailing whitespace, it only causes annoyance. Corrections to my strong opinions always welcomed of course. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Le mercredi 06 mai 2009, à 00:48 +0300, Felipe Contreras a écrit : On Tue, May 5, 2009 at 11:29 PM, Robin Sonefors ozam...@flukkost.nu wrote: On tis, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? If I want the sources for the gedit in Gnome 2.26, cloning gedit's repository and checking out the branch 'gnome-2-26' sounds like an easy-to-remember way to do it. If I want the sources for gedit in Gnome 2.24, I can probably deduce that 'gnome-2-24' sounds like a branch to look for. Right, 'gnome-2-24' does actually point to the latest release (2.24.3) No. It points to the latest code in the 2.24 branch. There might be code after the release. It's a branch, it's not a tag. So, maybe I don't understand what you're saying because I misunderstand git? which is good and I think all the GNOME projects should have such branches (perhaps 'gnome-2.24' instead) so it's easier to manually checkout the sources you want. But that's not in the guidelines, and it seems not even GTK+ is following that. I believe right now in order to find out all the latest stable packages for a certain GNOME release you need to use something like jhbuild. Again, it's in the guidelines. Not for GTK+ since GTK+ is an independent project. But it is for GNOME modules. See http://live.gnome.org/MaintainersCorner#branches Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 12:37 AM, Shaun McCance sha...@gnome.org wrote: On Tue, 2009-05-05 at 23:47 +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:18 PM, Behdad Esfahbod beh...@behdad.org wrote: On 05/05/2009 04:12 PM, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:00 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: case that's not a compelling argument; you can still have branches '1-2' and 'gnome-2-26'. Quick note. If we're going to have short branch names (as I'm planning to use for pango), it should be 1.2, not 1-2. Yeap, IMHO pango-1-2 1-2 1.2 stable It's nice to have stable, but we need a fixed name for those branches too. I'd love to see stable always be an alias for the latest stable branch, but that doesn't obviate the need for 1.2 or pango-1-2. Yes, if you *must* have a branch for each single stable major release you have, then it would be nice to have another branch (pointer) to the latest one. However, why do you need a 1.2 branch when you already have a PANGO_1_2_4 tag? Because somebody might want to commit something for Pango 1.2.5. Bear in mind that, even if developers aren't planning anything else for a stable series, translators and documentation writers might still add things. You don't need a branch to make commits, tag them and push them. $ git checkout PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 But if you feel icky about not working on a branch you can create a local branch: $ git checkout -b work-for-1.2.5 PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 $ git branch -D work-for-1.2.5 Both cases are exactly the same. You push a tag (reference) and all the objects in the hierarchy of the head of that reference that is still not on the remote repo. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On 05/05/2009 05:59 PM, Zeeshan Ali (Khattak) wrote: On Wed, May 6, 2009 at 12:06 AM, Behdad Esfahbodbeh...@behdad.org wrote: On 05/05/2009 05:00 PM, Lennart Poettering wrote: Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? Strongly agree with you. :) The default git pre-commit scripts (disabled by default) has a check for that. In cairo, we recommend enabling it (by way of chmod +x .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that off at times. Something to keep in mind. I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. I do the same and AFAIK this is common practice amongst many developer who have been using git. However, not everyone does that and therefore the need for a rule for this. I said rule rather than policy since I seriously doubt anyone can point out any positive points of trailing whitespace, it only causes annoyance. Corrections to my strong opinions always welcomed of course. :) As I tried to point out, gtk-doc introduces them, and having people manually rip that off is a pain. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Tue, May 5, 2009 at 5:06 PM, Behdad Esfahbod beh...@behdad.org wrote: I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. Have your gnome terminal/bash preferences been tweaked? I did a test with git diff after adding some trailing white space and it didn't show up in red. It looked like normal terminal text. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
Le mardi 05 mai 2009, à 23:00 +0200, Lennart Poettering a écrit : Heya! Trailing whitespace sucks. git is only half as much fun when people have trailing whitespace in their code. diffs get cluttered up by changes that actually aren't changes. Many other project these days enforce pretty rigid whitespace regimes and I wonder if that would be something to enforce globally on git.gnome.org, too? This is not a question of coding style. Whatever kind of indenting you choose, trailing whitespace cleanliness is about making git more fun without losing anything. Of course, enforcing this is a controversial issue and there are many different ways one could implement this: Are there places where trailing whitespaces are valid (ie, we want them)? Or are the checks only looking at code files? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
Le lundi 04 mai 2009 à 16:22 +0100, Alp Toker a écrit : And finally, are there any unported projects remaining? I helped port a few applications and the patches have been integrated, and you've kept things active on the Epiphany side. GIMP, DevHelp, Yelp, Epiphany, Epiphany Extensions, Blam, Conduit and externally various Mono applications, Lifearea. http://trac.webkit.org/wiki/ApplicationsGtk has a more complete list. But with so many projects, are there any we've missed? Any patches still waiting to be merged from a branch? Maintainers, please speak up! Empathy has a pending branch implementing adium themes using WebkitGtk. AFAIK the branch should be ported to latest webkit releases and reviewed. http://bugzilla.gnome.org/show_bug.cgi?id=522069 G. -- Guillaume Desmottes c...@skynet.be Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Le mercredi 06 mai 2009, à 01:01 +0300, Felipe Contreras a écrit : You don't need a branch to make commits, tag them and push them. $ git checkout PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 But if you feel icky about not working on a branch you can create a local branch: $ git checkout -b work-for-1.2.5 PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 $ git branch -D work-for-1.2.5 Both cases are exactly the same. You push a tag (reference) and all the objects in the hierarchy of the head of that reference that is still not on the remote repo. I might misunderstand things but... with those commands, aren't you releasing pango 1.2.5 after just one commit? This is not what we do. We might have a few commits, not on the same day. In this case I think we'll need a branch anyway, won't we? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
On Mon, 2009-05-04 at 22:37 -0400, Pierre-Luc Beaudoin wrote: Hi, I would like to propose libchamplain as an external dependency to GNOME 2.28. If you never heard about this project, it is a Clutter based map widget for your application. It currently uses downloaded image tiles as map data but there is a Google Summer of Code project to render the tiles locally. More information available at: http://projects.gnome.org/libchamplain Hi As the maintainer of osm-gps-map [1], a non-clutter mapping library with comparable features, I support libchamplain's proposal. I do not intend to add clutter support to osm-gps-map, it will remain a Gdk/Cairo only library as its intended, and my current, use of it is on embedded devices with no OpenGl support. Clutter is the new cool, so I support all ways to get this into the platform. However, looking over the libchamplain API (quickly, sorry if I mis-characterize something) I have a few comments * It is good to see you have added support for specifying map uri's. I would also like to see you support quadtree encoding, and randomization of hosts. See osm-gps-map for what I mean... * Where is the simple API? It seems like quite a few lines of code are required to get something to show. In osm-gps-map one can write map = osm_gps_map_new() or map = g_object_new (OSM_TYPE_GPS_MAP, repo-uri,http://www.bla.com, tile-cache,cachedir, tile-cache-is-full-path,TRUE, proxy-uri,g_getenv(http_proxy), NULL); and they are done. If this sort of scheme is not possible because libchamplain returns a Clutter actor, what about adding a call map = libchamplain_new_gtk_widget(xxx) Which at least returns the widget wrapped already setup in a Gtk+ widget. Is this possible or does that add some dependecy to clutter-gtk? * What is the sqlite dependecy for? Cache? Did you feel that using a database for cache was a performance benefit? In osm-gps-map we use an in memory cache of the last N tiles + a border around what is already showing, and just load the rest of the tiles from disk. Performance of that approach is more than sufficient (on any of the embedded targets I have tried, for example) Regards John [1] http://nzjrs.github.com/osm-gps-map/ Libchamplain 0.3 (a development release) has just been released. A 0.4 stable release will be made before or in sync with GNOME 2.28. libchamplain follows Clutter numbering and API/ABI stability plan. Since it is a young project, errors in the API are corrected in the next even release until maturity is achieved and 1.0 is released. Libchamplain would not introduce any new dependencies. It currently depends on Clutter 0.8 but will be ported to Clutter 1.0 as soon as it is announced. Or depandancies include: libsoup(-gnome), cairo, sqlite and Gtk+. It doesn't depend on deprecated libraries for Gnome 3.0. libchamplain already use a lot of the GNOME infrastructure: bugzilla, mailing list, wiki and web hosting. Migrating the git repository from gitorious to git.gnome.org is planned. Releases are stored on libchamplain.pierlux.com for now but it is also planned to move to GNOME. libchamplain is already used by an EOG-plugin to display where an image has been taken. There are pending branches for Empathy (being reviewed, to be optionally available for 2.28) to display a map of where your contacts are. There is also an embryonic plug-in for F-Spot. Other non-GNOME applications are using it too but none have made releases using it so far. libchamplain has bindings for Perl, Python, C# and C++. You can find packages (or work has started) on Debian, Ubuntu, Gentoo, ArchLinux, RedHat and OpenSuse. There is a port to FreeBSD. While libchamplain isn't integrated with any of the GNOME sub-projects, it shouldn't feel alien to them either. There is little i18n to be done, no user documentation needed and I bugtriage myself. There has been some talk about A11y, but these plans will have to wait until the SoC is over. Developer documentation is very important and that's why a full API reference is available: http://libchamplain.pierlux.com/doc/unstable/ libchamplain would contribute to improve the User Experience desired in GNOME 3.0 by bringing blingy map information to the desktop. Teamed with GeoClue you get a geolocation framework to build tomorrow's location aware applications. 7 SoC projects were submitted in regard to geolocation in GNOME this year only (2 were accepted, 5 were releated directly to libchamplain). libchamplain is available under LGPL 2.1. The project started in August 2008 and has enjoyed a nice growth since. There is a good community starting to build on the IRC channel and we can count 16 different contributors to the code. See https://www.ohloh.net/p/libchamplain for more interesting stats. In this email, I hope I
Re: fast-forward only policy
On Wed, May 6, 2009 at 12:46 AM, Olav Vitters o...@bkor.dhs.org wrote: On Wed, May 06, 2009 at 12:33:59AM +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? 'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc are stable. So it isn't clear. The latest one, of course. You don't need branches for targets that are not going to move. Branches are for moving targets, tags are for fixed ones. That is just confusing. Really, I don't see why you don't see this. That's just how git works: branches and tags are mere pointers. There's no difference in the object storage, the only difference is logical, you use branches in a way, tags in another way. Don't care about Git workings. Don't you think that is much more relevant here than your opinions? I care about understanding a branch name. Deleting branches sounds really bad (aside from purely symbolical 'stable'). You can do stuff like: I don't understand Git. If you haven't noticed, we are talking of *GIT* branches and tags here. The discussion was actually about a rule on *GIT* pushes. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 2009-05-05 at 14:36 -0500, Shaun McCance wrote: Good catch on libcanberra. It's clearly good for us to have a convenient API for this. Do we really want to push another micro-library for that? Should GTK+ just learn to do it? yeah, in fact, libcanberra provides a libcanberra-gtk lib which could be part of GTK. libcanberra itself, I guess, would need to keep as a separate lib for KDE and others to use it (if they do or plan to, which I'm not sure about) -- Rodrigo Moya rodr...@gnome-db.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Wed, May 6, 2009 at 1:02 AM, Behdad Esfahbod beh...@behdad.org wrote: On 05/05/2009 05:59 PM, Zeeshan Ali (Khattak) wrote: On Wed, May 6, 2009 at 12:06 AM, Behdad Esfahbodbeh...@behdad.org wrote: On 05/05/2009 05:00 PM, Lennart Poettering wrote: Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? Strongly agree with you. :) The default git pre-commit scripts (disabled by default) has a check for that. In cairo, we recommend enabling it (by way of chmod +x .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that off at times. Something to keep in mind. I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. I do the same and AFAIK this is common practice amongst many developer who have been using git. However, not everyone does that and therefore the need for a rule for this. I said rule rather than policy since I seriously doubt anyone can point out any positive points of trailing whitespace, it only causes annoyance. Corrections to my strong opinions always welcomed of course. :) As I tried to point out, gtk-doc introduces them, and having people manually rip that off is a pain. Sorry i misread that part. Stefan, Is that really needed? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 1:00 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 06 mai 2009, à 00:48 +0300, Felipe Contreras a écrit : On Tue, May 5, 2009 at 11:29 PM, Robin Sonefors ozam...@flukkost.nu wrote: On tis, 2009-05-05 at 23:10 +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? If I want the sources for the gedit in Gnome 2.26, cloning gedit's repository and checking out the branch 'gnome-2-26' sounds like an easy-to-remember way to do it. If I want the sources for gedit in Gnome 2.24, I can probably deduce that 'gnome-2-24' sounds like a branch to look for. Right, 'gnome-2-24' does actually point to the latest release (2.24.3) No. It points to the latest code in the 2.24 branch. There might be code after the release. It's a branch, it's not a tag. So, maybe I don't understand what you're saying because I misunderstand git? I'm talking about that specific branch in that specific repo: gnome-2-24 - GEDIT_2_24_3 - 8372af3 On the other hand 'gnome-2-0' is not pointing to any release, there where commits after the last release. So my question here is: who would care about those commits? They were done 6 years ago and nobody made a tag that contains them. The arguments I've heard apply to the stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0 build, or make GEDIT_2_0_6 release, they'll probably go for the latest code that was actually released and used. which is good and I think all the GNOME projects should have such branches (perhaps 'gnome-2.24' instead) so it's easier to manually checkout the sources you want. But that's not in the guidelines, and it seems not even GTK+ is following that. I believe right now in order to find out all the latest stable packages for a certain GNOME release you need to use something like jhbuild. Again, it's in the guidelines. Not for GTK+ since GTK+ is an independent project. But it is for GNOME modules. See http://live.gnome.org/MaintainersCorner#branches Ok, now I looked more closely and yeah, it's in that guideline, but not on this one: http://live.gnome.org/Git/Developers#head-48e4d2e1d946ed26fa5401c9b9a0c7f5152c0161 Now, let's suppose GTK+ is a truly independent project, and their independent repo (non-gnome) is in git.gtk.org. Just like you can create arbitrary branches in your local repo, you can do the same in git.gnome.org. So what I'm trying to say is: even if GTK+ is an independent project, GNOME maintainers can still add their own branches in their own repos. After all you are prefixing the branches with 'gnome-' so it should not conflict with GTK+ branches. Right? -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On 05/05/2009 06:05 PM, Adam Schreiber wrote: On Tue, May 5, 2009 at 5:06 PM, Behdad Esfahbodbeh...@behdad.org wrote: I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. Have your gnome terminal/bash preferences been tweaked? I did a test with git diff after adding some trailing white space and it didn't show up in red. It looked like normal terminal text. $ git config --global diff.color auto That's recommended in: http://live.gnome.org/Git/Developers Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
On Wed, 2009-05-06 at 10:12 +1200, John Stowers wrote: As the maintainer of osm-gps-map [1], a non-clutter mapping library with comparable features, I support libchamplain's proposal. Thanks for your support. I do not intend to add clutter support to osm-gps-map, it will remain a Gdk/Cairo only library as its intended, and my current, use of it is on embedded devices with no OpenGl support. Clutter is the new cool, so I support all ways to get this into the platform. Clutter will be supported on Maemo 5, I hope to make it useful on this platform at some point! However, looking over the libchamplain API (quickly, sorry if I mis-characterize something) I have a few comments * It is good to see you have added support for specifying map uri's. I would also like to see you support quadtree encoding, and randomization of hosts. See osm-gps-map for what I mean... I will have a look, but little code can be shared as osm-gps-map is GPL :) but if the method is generic enough method I'll see how to reproduce it. * Where is the simple API? It seems like quite a few lines of code are required to get something to show. Actually, you should be able to have something show up with: ChamplainView *view = champlain_view_new (); ChamplainViewEmbed *embed = champlain_view_embed_new (view); // put that embed in a GtkContainer That should bring a OpenStreetMap Mapnik centered at 0,0 at zoom level 0 in PUSH mode. Which are boring defaults for demos :) * What is the sqlite dependecy for? Cache? Did you feel that using a database for cache was a performance benefit? In osm-gps-map we use an in memory cache of the last N tiles + a border around what is already showing, and just load the rest of the tiles from disk. Performance of that approach is more than sufficient (on any of the embedded targets I have tried, for example) sqlite got introduced when we figured out that we'll need a place to save a 20 char string for every tiles downloaded. OpenStreetMaps send an ETag in their http headers along with the tile. You can reuse that ETag to validate your cache. The sqlite db is also used to maintain statistics about the tiles so that tiles that are the most used are not the first to be purged from the cache. Finally, it is used to determine the cache size, since all tiles are in the db anyway. -- Pierre-Luc signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 1:12 AM, Frederic Peters fpet...@gnome.org wrote: Felipe Contreras wrote: You don't need a branch to make commits, tag them and push them. The current workflow is well understood, works well for translators and other contributors, and is supported by all our tools (damned lies, jhbuild, pulse...). I really don't see the point in changing it, especially when it adds some new commands contributors will have to learn. That was just an example for a very unlikely situation. Do you really think someone's ever going to make a release adding translations to 1.2.5? 1.2.4 was released 6 years ago. Now, I'm not proposing to get rid of 'gnome-major-minor', now that I realize it's a guideline I think it should be enforced for all the repos. What I'm proposing is to drop 'project-major-minor'. I think translators and other contributors would find it easier to have a 'gnome-2.26' branch on all the repos, plus a 'stable' and 'master' branch, and not a 'pango-1-20' one. After some years nobody would be working on the 'gnome-2.26', just like nobody is working on 'gnome-2-0' now, so there's no harm in dropping the branch. If somebody really wants to make a release for that, the maintainer would still be able to do it, either by creating a temporary local branch, or a temporary branch on the official repo, if he doesn't know how, he can ask. That would be an exceptional situation though. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Le mercredi 06 mai 2009, à 01:24 +0300, Felipe Contreras a écrit : On Wed, May 6, 2009 at 1:00 AM, Vincent Untz vu...@gnome.org wrote: No. It points to the latest code in the 2.24 branch. There might be code after the release. It's a branch, it's not a tag. So, maybe I don't understand what you're saying because I misunderstand git? I'm talking about that specific branch in that specific repo: gnome-2-24 - GEDIT_2_24_3 - 8372af3 On the other hand 'gnome-2-0' is not pointing to any release, there where commits after the last release. So my question here is: who would care about those commits? They were done 6 years ago and nobody made a tag that contains them. The arguments I've heard apply to the stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0 build, or make GEDIT_2_0_6 release, they'll probably go for the latest code that was actually released and used. Some distributions might have shipped those patches. The fact that they are in the vcs made it easy to share with other distributions who might have needed it. Even if there was no release with those changes. Or maybe the maintainer really intended to do a release and found out it wasn't really needed in the end. [...] Now, let's suppose GTK+ is a truly independent project, and their independent repo (non-gnome) is in git.gtk.org. Just like you can create arbitrary branches in your local repo, you can do the same in git.gnome.org. So what I'm trying to say is: even if GTK+ is an independent project, GNOME maintainers can still add their own branches in their own repos. After all you are prefixing the branches with 'gnome-' so it should not conflict with GTK+ branches. Right? I guess I'm lost here, since this seems to be another topic (or maybe you're getting back to the original topic in the thread). Sure, maintainers are free to push any branches they want. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 1:34 AM, Shaun McCance sha...@gnome.org wrote: On Wed, 2009-05-06 at 01:28 +0300, Felipe Contreras wrote: On Wed, May 6, 2009 at 1:04 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 06 mai 2009, à 01:01 +0300, Felipe Contreras a écrit : You don't need a branch to make commits, tag them and push them. $ git checkout PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 But if you feel icky about not working on a branch you can create a local branch: $ git checkout -b work-for-1.2.5 PANGO_1_2_4 # make changes $ git commit -a $ git tag PANGO_1_2_5 $ git push origin PANGO_1_2_5 $ git branch -D work-for-1.2.5 Both cases are exactly the same. You push a tag (reference) and all the objects in the hierarchy of the head of that reference that is still not on the remote repo. I might misunderstand things but... with those commands, aren't you releasing pango 1.2.5 after just one commit? This is not what we do. We might have a few commits, not on the same day. In this case I think we'll need a branch anyway, won't we? You can create as many commits as you want in any fashion you want. What I tried to explain is that you can push a tag without pushing a branch. It's not about pushing a tag without pushing a branch. It's about pushing a commit without pushing a branch. Which yes, is possible. But absolutely useless. When I make a release, the last thing I want to do is sift through all the commits looking for those I might want to merge into this release. You cannot push commits, you can only push refs. Anyhow, you need to push the tag any way, right? When you push the tag, all the commits will be pushed. If you also push the branch then you would simply create a reference in the remote repo pointing to a commit that it's already there. If nobody is going to use that branch, why push it? (note that this particular example is about an extremely old release) -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Tue, 05.05.09 17:06, Behdad Esfahbod (beh...@behdad.org) wrote: On 05/05/2009 05:00 PM, Lennart Poettering wrote: Anyway, Owen said he didn't want to fight this fight. I guess I can understand that, and I don't really want to fight this fight either. Nonetheless I think this would be good to have and the least I can do is mentioning this on desktop-devel and asking for opinions. So here I go. Opinions? The default git pre-commit scripts (disabled by default) has a check for that. In cairo, we recommend enabling it (by way of chmod +x .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that off at times. Something to keep in mind. Maybe autogen.sh should include a test -f .git/hooks/pre-commit chmod +x .git/hooks/pre-commit or so to automatically enable it by default? Would be an easy change and folks who think they have a right to override this could just move that file away. I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. I just have these lines in my ~/.emacs: (autoload 'nuke-trailing-whitespace nuke-trailing-whitespace nil t) (add-hook 'write-file-hooks 'nuke-trailing-whitespace) And then I don't have to think about anything. Except that it breaks my patches for other peoples' project which don't care about trailing whitespace. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 6, 2009 at 1:53 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 06 mai 2009, à 01:24 +0300, Felipe Contreras a écrit : On Wed, May 6, 2009 at 1:00 AM, Vincent Untz vu...@gnome.org wrote: No. It points to the latest code in the 2.24 branch. There might be code after the release. It's a branch, it's not a tag. So, maybe I don't understand what you're saying because I misunderstand git? I'm talking about that specific branch in that specific repo: gnome-2-24 - GEDIT_2_24_3 - 8372af3 On the other hand 'gnome-2-0' is not pointing to any release, there where commits after the last release. So my question here is: who would care about those commits? They were done 6 years ago and nobody made a tag that contains them. The arguments I've heard apply to the stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0 build, or make GEDIT_2_0_6 release, they'll probably go for the latest code that was actually released and used. Some distributions might have shipped those patches. The fact that they are in the vcs made it easy to share with other distributions who might have needed it. Even if there was no release with those changes. Debian patches are debian patches, they control them, and they make debian releases. If GNOME decides to remove those commits the distributions will not loose their patches. Or maybe the maintainer really intended to do a release and found out it wasn't really needed in the end. That's a very unlikely situation, it make no sense that everybody suffers (having gazillions of branches) just because of that. If you really want to be safe you can create legacy (hidden) repos in the case someone might need those commits. They will not waste any space because git uses hard links when you clone locally. Then you can delete all the legacy branches in the public (visible) repos while still be confident no commit will be lost. [...] Now, let's suppose GTK+ is a truly independent project, and their independent repo (non-gnome) is in git.gtk.org. Just like you can create arbitrary branches in your local repo, you can do the same in git.gnome.org. So what I'm trying to say is: even if GTK+ is an independent project, GNOME maintainers can still add their own branches in their own repos. After all you are prefixing the branches with 'gnome-' so it should not conflict with GTK+ branches. Right? I guess I'm lost here, since this seems to be another topic (or maybe you're getting back to the original topic in the thread). Sure, maintainers are free to push any branches they want. There's nothing wrong with adding gnome-major-minor branches on independent projects on the git.gnome.org repos. Maybe this would help. Let's say we have git.maemo.org where we have a GTK+ repo, we don't have any changes on top of that (hypothetical), but we want some branches to keep track of our releases, so we add a 'maemo-2.0' branch that essentially points to 'gnome-2-24'. Should GNOME care what branches are in git.maemo.org that are not in git.gnome.org? No. It's DSCM, the owner of the repo can do whatever they want, so GNOME can add any 'gnome-' branches they want to git.gnome.org because GNOME owns those repos. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GConf branched
I've just created a gnome-2-26 branch for GConf. I had to remove a single translation from ne.po before being able to do so, since msgfmt -c was complaining about it. The reason for branching is that I want to fix http://bugzilla.gnome.org/show_bug.cgi?id=558619 which will allow the defaults service to be used with gconf-editor. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Hi, On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On the other hand 'gnome-2-0' is not pointing to any release, there where commits after the last release. So my question here is: who would care about those commits? They were done 6 years ago and nobody made a tag that contains them. The arguments I've heard apply to the stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0 build, or make GEDIT_2_0_6 release, they'll probably go for the latest code that was actually released and used. I disagree; I think they'd check out the branch and use it; particularly since that has been the practice for a number of years now. But that's only one side of the issue, and the less interesting one at that... The reason these branches were created and kept was not merely because subversion and cvs suck and can't reasonably delete old branches. Due to the various enterprise distributions, developers needed to continue to apply patches and make other fixes to versions of the code that were several years old and they were duplicating each others' work. They had trouble discovering when others were doing similar backports and where their work was. So there was an effort to standardize old branch names to make it easy to know where to put their fixes, and where other developers could go to find them; these fixes were often not straightforward backports given the divergence of the development branch and these old versions. (I believe it was started by an email from Federico on desktop-devel-list, but it's been so many years that my memory may be faulty there.) Yes, people decided that it was okay for developers to commit their fixes without maintainer approval to otherwise unsupported branches for this particular use. Think what you will of that solution, but if you delete these old branches you will make finding and/or recording such fixes harder. Those 6 patches that are not part of any tag are evidence that the old system was being used. (I don't know if this is the optimal solution to the problem, particularly given the better VCS available to us today, but it was certainly low cost and made people happy. I believe this email thread is the first time in years anyone has expressed any issues with that decision.) Even in git.git there were maint-1.5.1, maint-1.5.4, maint-1.6.0, and maint-1.6.1 branches, in addition to the standard pu, next, master, and maint (check the log; you'll see the evidence these were there). Since only Junio can push to git.git, he can create or delete branches as he wants without affecting others; so he can (and did) delete these branches once he knew they were no longer active. But we have multiple people accessing git.gnome.org, and others may be using these old branches for years after most consider them to no longer be 'active'. Since they were particularly there for people who were _not_ the maintainer, the maintainer can't really know when they aren't being used anymore. (Maybe we could try to find out when a particular version is no longer being used in *any* stable or enterprise distribution? I bet we could kill the 1.x branches, but Solaris would probably cause us to keep all the 2.x ones around.) Yes, I understand the desire to clean things up; it's nice to prune stuff that's not used in git, especially since it is so easy to recreate or even work without it. However, these branches really do have a reason and do have an important (though infrequent) use; so unless you can come up with a convincing proposal for an alternate way to handle these issues (and I may not be remembering all the issues either), *and* can convince others that adopting a new mechanism and trying to get it disseminated to everyone (which isn't easy due to this being an infrequent use case and the fact of how few read desktop-devel-list and even devel-announce-list) and show that it should be less of a cost than keeping some branches around that appear to be unused, then it's really unlikely that such a change will occur. I think you could easily come up with such a proposal that I would not have a problem with in my personal use (I don't like lots of branches for the public repositories either); however, I'm not sure that others are going to see changing a policy that will take time to communicate to everyone is worth the cost of making things a little bit tidier for you and me. So I'm betting on a very uphill battle if you want to pursue this; I certainly don't see the cost/benefit tradeoff as being very encouraging and wouldn't put my time into it. Anyway, I hope that at least provides some perspectives on why these things exist and why you're seeing people oppose your proposal. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Wed, May 06, 2009 at 01:13:07AM +0300, Zeeshan Ali (Khattak) wrote: On Wed, May 6, 2009 at 12:46 AM, Olav Vitters o...@bkor.dhs.org wrote: On Wed, May 06, 2009 at 12:33:59AM +0300, Felipe Contreras wrote: Imagine someone who has been on a GNOME hiatus or is a new comer. What would be easier to understand? '1-2' or 'stable'? 'stable' was already discussed. Within GNOME 2.20, 2.22, 2.24, 2.26 etc are stable. So it isn't clear. The latest one, of course. You don't need branches for targets that are not going to move. Branches are for moving targets, tags are for fixed ones. That is just confusing. Really, I don't see why you don't see this. That's just how git works: branches and tags are mere pointers. There's no difference in the object storage, the only difference is logical, you use branches in a way, tags in another way. Don't care about Git workings. Don't you think that is much more relevant here than your opinions? Why should it? I can ask if branches/tags can be renamed and so on. Plus if stuff can be explained in text instead of git commands. I don't like the suggestion that I am not allowed to say that I want an explanation. I care about understanding a branch name. Deleting branches sounds really bad (aside from purely symbolical 'stable'). You can do stuff like: I don't understand Git. If you haven't noticed, we are talking of *GIT* branches and tags here. The discussion was actually about a rule on *GIT* pushes. Don't suggest I didn't knew that. I want to know implications for users of git.gnome.org. Just because it is Git, doesn't mean we shouldn't be careful when changing things or I am not allowed to make comments. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
