Proposing libgdata as a new desktop module
Hi, I would like to propose libgdata as a new desktop module for GNOME 2.28. libgdata is a GLib-based library for accessing online service APIs using the GData protocol — most notably, Google's services. It provides APIs to access the common Google services (at this stage, only Google Calendar, YouTube and Google Contacts; PicasaWeb support is in the works), and has full asynchronous support. You might have already heard a little about it on my blog[1]; a little more information is available on its l.g.o page[2]. libgdata 0.2 was released a few weeks ago, and a 0.3 release will be made in a few more weeks' time. Until version 1.0, there are no guarantees as to API stability, with errors in the API being corrected with each release. libgdata will not introduce any new dependencies; it depends on only: * glib-2.0 >= 2.16.3 * libxml-2.0 * gio-2.0 >= 2.17.3 * libsoup-2.4 >= 2.24.0 It can optionally depend on libsoup-gnome-2.4 for GNOME integration (such as automagic proxy support). libgdata uses GNOME resources exclusively: Bugzilla, git, damned-lies and GNOME FTP. The library is already in use in the Totem YouTube plugin, and I'm in the process of porting evolution-data-server to use libgdata[3]. As a consequence of being used in Totem, the library is already packaged for Fedora 11[4]. As far as community is concerned, libgdata is mostly there. There is full API documentation, and the few strings which can be localised, are. libgdata fits (I think) nicely into the GNOME 3.0 vision, allowing tighter web–desktop integration. It doesn't use any deprecated libraries or API. There were two SoC projects this year which were related to integrating Google services in applications, and I have high hopes that libgdata will be able to help in that area. libgdata is licenced under LGPL 2.1. The project started in January 2009, and has already had two person-years invested in it, according to Ohloh[5]. I suppose this should be taken with a pinch of salt, but it gives the general idea. If libgdata does not make it as a desktop module, for whatever reason, it needs to be listed as an external dependency, due to its use in Totem and upcoming use in evolution-data-server. Regards, Philip Withnall Maintainer of libgdata [1]: http://tecnocode.co.uk/2009/04/07/libgdata/ [2]: http://live.gnome.org/libgdata [3]: http://bugzilla.gnome.org/show_bug.cgi?id=580021 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=493432 [5]: https://www.ohloh.net/p/libgdata 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
Hi, On Wed, May 6, 2009 at 3:52 PM, Felipe Contreras wrote: > On Wed, May 6, 2009 at 6:44 AM, Elijah Newren wrote: >> On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras >> 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... > > *sigh* > > Do this command: > $git checkout GEDIT_2_0_5 > > Then do 'git branch'. What do you see? "(no branch)" Of course, > completely unintuitive, how contributors are expected to create a > 2.0.6 release under such hard conditions! > > Well, now do this command: > $git checkout origin/gnome-2-0 > > What does 'git branch' show this time? "(no branch)" Ah, much better! > Now contributors will be on their element. > > Creating a local branch is a step that you need to do on both cases, > there's no difference whatsoever. That's kind of orthogonal to the point I was making and responding to. I was responding to your two comments, "who would care about those commits" and "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." Using the GEDIT_2_0_5 tag vs. the origin/gnome-2-0 branch give you different answers, since the branch may have advanced past the tag; so there's a decision to be made. You have consistently claimed that those commits on the branch were useless and no one would even look at them, and I was pointing out historical precedent that was in conflict with this assumption of yours. > I express concern because when you use git properly branches are a > central part of development (unlike other SCMs) therefore you *see* > these branches all the time, which is annoying. I agree. > I understand the need for such branches like 'gnome-2-20'. It's > unlikely, but some one might make a release out of that. But > 'gnome-2-0'? Maybe I missed your switch, but I thought you had been advocating 'master' and 'devel' and getting rid of 'gnome-2-x' branches until today. So I was responding to that. I agree it'd be nice to move known-to-be-unused branches to some archival or legacy area (refs/archive/*, refs/legacy/*?). You just have to be reasonably certain they are really unused (no enterprise distro could possibly be using them anymore, etc.). I'm guessing there's very few gnome-2-x branches that are ready for archiving by now. > Do you seriously think because git.git is maintained by Junio nobody > else has a clone of that repo? Of course not! Every git developer had > a clone, and they all saw the maint branches. Some might have have > work on top of those branches. > > Why didn't the world fell to pieces when Junio removed those branches? > git is *distributed* if you have local main-1.6.0 branch with 4 > commits and Junio removes the branch what happens? Nothing, you only > see that "origin/main-1.6.0" was removed, big deal. Your local > main-1.6.0 remains intact. I must have done a really poor job communicating; sorry about that. You had been advocating only having 'master' and 'stable' branches. I was pointing out that even git.git went further than that and had the equivalent of stable-x.y branches, and that I thought we would need those too. I figured you'd say, "yes, but they have since been deleted in git.git", and so I proceeded to point out why I think gnome is different and would need to keep several of those stable-x.y branches around for a long time and not delete them. > Yes, but what about branches like CORBA_ENABLED, GEDIT_VIEW, GNOME_MDI. Oh, I'm a big fan of archiving old branches like these; that sounds great. I just think the gnome-2-x branches will need to be around longer (e.g. rhel4 is still supported and ships with gnome 2.8), but it sounds like you're now in agreement with that. I hope this email is a bit clearer than my last; sorry about that. 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 Tue, 2009-05-05 at 16:00 -0400, Behdad Esfahbod 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". Why? Surely this makes the branches harder to spot on a quick glance (short non-word strings are harder for the eye to spot), possibly breaks grouping in lists (i.e. they all start pango-), and with tab completion doesn't really gain you much in terms of typing time. I've always liked our consistency with branch and tag names. There is so much implicit information available there, without you having to look at other things. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
I have to admit, there is probably some advantage to moving these very old branches into an archive (either refs/archive/foo or a complete archive clone) after some amount of time. Mostly because I thought "new IM? What new IM?". Also permit the deletion of branches that have been merged with master (i.e. something that could be deleted with `git branch -d`). This would probably help people who are not core contributors get an idea of the state of the project, we have master, a bunch of stable branches (perhaps we can hack cgit to move stable branches to their own category on the summary?) and a bunch of active feature branches that show where people are getting their hands dirty. On Thu, 2009-05-07 at 01:11 +0300, Felipe Contreras wrote: > I've already explained that having a gazillion of branches is not > clear, it creates noise. > > Let's take a look at these from the GTK+ repo: > > themes: 11 years > themes-2: 11 years > rendering-demo: 4 years > ps-mf: 10 years > master-UNNAMED-BRANCH: 10 years > kris-async-branch: 3 years > hp-patches: 9 years > havoc-patches: 9 years > gtk-printing: 3 years > gtk-pango: 9 years > gtk-no-flicker: 9 years > gtk-new-im: 9 years > gtk-multihead: 7 years > gtk-hp-patches: 9 years > gdk-object-with-pango: 9 years > gdk-object: 3 years > federico-filename-entry: 3 years > cancelation-changes: 3 years > AUTO_DENATTIFYING: 3 years > > If you move them to a historic repo, what do you loose? -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ 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 Thu, May 7, 2009 at 12:01 PM, Christian Persch wrote: > Hi; > > John Stowers wrote: > > Unfortunately, the original TangoGPS author, [...], ignores any > > emails from me, other osm-gps-map developers, or users, that request > > permission to change the license of osm-gps-map to LGPL. > > > > I guess the lesson here is to never create a library, derived from a > > GPL project, unless you are sure that the original copy write holders > > are open to re-licensing those parts of the code to LGPL, aka mature > > and reasonable people. > > There are good reasons to choose GPL even for a library[1]. The > code's author not agreeing to relicense his GPL'd code under LGPL does > not give you permission to insult him as ›unreasonable‹ or ›immature‹ > like you did above. > > I think just ignoring such relicencing requests is perfectly > fine behaviour, esp. if, as you seem to imply above, multiple > persons have pestered the author about it. About 6-10 emails over 12 months is not really pestering either. I can assure you that I was polite in all my emails, and also had contact with the author early in the project, keeping him in the loop with some design decions, asking for his opinion, etc. It was only when the issue of license arose that the ignoring started. I did not just turn up and say "hey I forked your project, you should relicense it". I do not believe that ignoring a polite request for considering a licensing change is a mature response. Anyway, this thread is OT now. John > > > >Christian > > [1] http://www.gnu.org/licenses/why-not-lgpl.html > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ 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
Hi; John Stowers wrote: > Unfortunately, the original TangoGPS author, [...], ignores any > emails from me, other osm-gps-map developers, or users, that request > permission to change the license of osm-gps-map to LGPL. > > I guess the lesson here is to never create a library, derived from a > GPL project, unless you are sure that the original copy write holders > are open to re-licensing those parts of the code to LGPL, aka mature > and reasonable people. There are good reasons to choose GPL even for a library[1]. The code's author not agreeing to relicense his GPL'd code under LGPL does not give you permission to insult him as ›unreasonable‹ or ›immature‹ like you did above. I think just ignoring such relicencing requests is perfectly fine behaviour, esp. if, as you seem to imply above, multiple persons have pestered the author about it. Christian [1] http://www.gnu.org/licenses/why-not-lgpl.html ___ 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 Thu, May 7, 2009 at 12:52 AM, Les Harris wrote: > On Wed, May 6, 2009 at 2:14 PM, Felipe Contreras > wrote: >> Would you fight to keep alive the branch Linus just found too crappy >> and just killed it? If a commit never made it to a release and >> probably never would, is it really that important? > > It seems to me whatever Linus decided to do for the kernel is > completely orthogonal to what we, the gnome project, decide to do. Germán argued that the commits are kept for archaeological reasons and I just showed how the linux project managed to both keep historical commits and have a clean slate. How is that not relevant? >> I guess this is like the abortion debate. When is a commit really >> alive? Does commits feel pain when they are killed before being >> pushed? > > It's probably for the best to keep technical arguments based on > technical details and not conflate the issue with highly charged and > emotional topics. > > The consensus so far seems to be that losing commits is a non-starter. > It's not clear to me what benefit dropping these ossified branches > gives us. What is the problem you're trying to solve Felipe? I've already explained that having a gazillion of branches is not clear, it creates noise. Let's take a look at these from the GTK+ repo: themes: 11 years themes-2: 11 years rendering-demo: 4 years ps-mf: 10 years master-UNNAMED-BRANCH: 10 years kris-async-branch: 3 years hp-patches: 9 years havoc-patches: 9 years gtk-printing: 3 years gtk-pango: 9 years gtk-no-flicker: 9 years gtk-new-im: 9 years gtk-multihead: 7 years gtk-hp-patches: 9 years gdk-object-with-pango: 9 years gdk-object: 3 years federico-filename-entry: 3 years cancelation-changes: 3 years AUTO_DENATTIFYING: 3 years If you move them to a historic repo, what do you loose? -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
END OF THREAD (Was: Re: fast-forward only policy)
Hi! Welcome to the end of the thread. It certainly has been fun, but in order to conserve our precious electrons in these hard economic times, we must regretfully now close this thread. As the kids say, you don't have to go home, but you can't post here. Thank you and good night. ___ 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 Thu, May 7, 2009 at 12:52 AM, Les Harris wrote: > On Wed, May 6, 2009 at 2:14 PM, Felipe Contreras > wrote: > > The consensus so far seems to be that losing commits is a non-starter. > It's not clear to me what benefit dropping these ossified branches > gives us. What is the problem you're trying to solve Felipe? To me, the objective is to make branch-based development easier. For that, we should maintain public repo that only have "active" branches. Otherwise it's confusing for everybody, we need to flag them somehow to tell "don't worry about, it was just X years ago, but nobody cares". And public branch _should_ be active, and rebased if necessary. That would be a good sign of vitality. Also, merged branches will have to be deleted. Hiding the work on github, gitorious or any other public place is one way to avoid talking about this pb. I believe it's not the best way to keep the work coherent, in one place (although I am certainly not saying it has to be centralized, rather the contrary!). Finally, doing the move to git while using *only* old practices, and keeping old habits do not make much sense. Not that I care so much, but that's my 2 cents, regards, -- Marc-André Lureau ___ 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 2:14 PM, Felipe Contreras wrote: > Would you fight to keep alive the branch Linus just found too crappy > and just killed it? If a commit never made it to a release and > probably never would, is it really that important? It seems to me whatever Linus decided to do for the kernel is completely orthogonal to what we, the gnome project, decide to do. > I guess this is like the abortion debate. When is a commit really > alive? Does commits feel pain when they are killed before being > pushed? It's probably for the best to keep technical arguments based on technical details and not conflate the issue with highly charged and emotional topics. The consensus so far seems to be that losing commits is a non-starter. It's not clear to me what benefit dropping these ossified branches gives us. What is the problem you're trying to solve Felipe? Les ___ 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 6:44 AM, Elijah Newren wrote: > Hi, > > On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras > 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... *sigh* Do this command: $git checkout GEDIT_2_0_5 Then do 'git branch'. What do you see? "(no branch)" Of course, completely unintuitive, how contributors are expected to create a 2.0.6 release under such hard conditions! Well, now do this command: $git checkout origin/gnome-2-0 What does 'git branch' show this time? "(no branch)" Ah, much better! Now contributors will be on their element. Creating a local branch is a step that you need to do on both cases, there's no difference whatsoever. > 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.) I express concern because when you use git properly branches are a central part of development (unlike other SCMs) therefore you *see* these branches all the time, which is annoying. I understand the need for such branches like 'gnome-2-20'. It's unlikely, but some one might make a release out of that. But 'gnome-2-0'? > 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.) Do you seriously think because git.git is maintained by Junio nobody else has a clone of that repo? Of course not! Every git developer had a clone, and they all saw the maint branches. Some might have have work on top of those branches. Why didn't the world fell to pieces when Junio removed those branches? git is *distributed* if you have local main-1.6.0 branch with 4 commits and Junio removes the branch what happens? Nothing, you only see that "origin/main-1.6.0" was removed, big deal. Your local main-1.6.0 remains intact. > 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 in
Re: fast-forward only policy
On Wed, May 6, 2009 at 11:34 PM, Germán Póo-Caamaño wrote: > On Wed, 2009-05-06 at 23:26 +0300, Felipe Contreras wrote: >> On Wed, May 6, 2009 at 2:04 PM, Ross Burton wrote: >> > On Wed, 2009-05-06 at 12:27 +0200, Vincent Untz wrote: >> >> Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : >> >> > 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. >> >> >> >> I think this summarize well the whole thing: we do not want to remove >> >> commits. >> > >> > Agreed. All the way through this thread I've been wondering what >> > possible reason there would be for throwing away a commit on a >> > historical branch. >> >> It's not about throwing away commits, it's about throwing away unused >> branches. >> >> I've already explained two ways in which the branches can be thrown >> away without loosing the commits although personally I would just >> throw the commits away. >> >> My feeling is that if GNOME were using git at the time of those legacy >> commits where made, the people developing them would have kept the >> changes locally, and by this time, the commits would have been thrown >> away anyway. In practice there's no difference between throwing away >> local commits and throwing away public commits that nobody will use. > > They are used by software archeologist's, for mining purposes. It is > part of the project's history, and you should never regret of your > history. Am I denying my inheritance when I do undo? When I do 'git commit --amend', or 'git rebase'? Nah. Did the linux project made a fatal mistake when they decided to drop *all* history (from bitkeeper) and start from scratch (in git)? Nah. You can find all the history of the linux project divided into 3 repos, even from the very first release, for archaeologists or whatever reason. Would you fight to keep alive the branch Linus just found too crappy and just killed it? If a commit never made it to a release and probably never would, is it really that important? I guess this is like the abortion debate. When is a commit really alive? Does commits feel pain when they are killed before being pushed? -- 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 11:47 PM, Ross Burton wrote: > On Wed, 2009-05-06 at 23:15 +0300, Felipe Contreras wrote: >> Are you going to argue that this branch is desirable to keep alive for >> all eternity? >> http://git.gnome.org/cgit/gedit/log/?h=CORBA_ENABLED > > I think most reasonable people will say that there is a difference > between branches which were used for development forks and have been > merged (such as this, "feature branches" in git), and maintenance > branches such as gnome-2-26. Feature branches which have been merged > can and probably should be killed from the repository unless there is a > reason to keep them, but long term maintenance branches should be > preserved. Ok, I agree that gnome-major-minor branches have some merit (the older the less merit) but I cannot really see any merit on branches such as CORBA_ENABLED, so at least we have some kind of agreement there. But note that CORBA_ENABLED wasn't completely merged, if you drop the branch you'll loose 2 commits. =O -- 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, 2009-05-06 at 23:15 +0300, Felipe Contreras wrote: > Are you going to argue that this branch is desirable to keep alive for > all eternity? > http://git.gnome.org/cgit/gedit/log/?h=CORBA_ENABLED I think most reasonable people will say that there is a difference between branches which were used for development forks and have been merged (such as this, "feature branches" in git), and maintenance branches such as gnome-2-26. Feature branches which have been merged can and probably should be killed from the repository unless there is a reason to keep them, but long term maintenance branches should be preserved. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.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: fast-forward only policy
On Wed, 2009-05-06 at 23:26 +0300, Felipe Contreras wrote: > On Wed, May 6, 2009 at 2:04 PM, Ross Burton wrote: > > On Wed, 2009-05-06 at 12:27 +0200, Vincent Untz wrote: > >> Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : > >> > 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. > >> > >> I think this summarize well the whole thing: we do not want to remove > >> commits. > > > > Agreed. All the way through this thread I've been wondering what > > possible reason there would be for throwing away a commit on a > > historical branch. > > It's not about throwing away commits, it's about throwing away unused > branches. > > I've already explained two ways in which the branches can be thrown > away without loosing the commits although personally I would just > throw the commits away. > > My feeling is that if GNOME were using git at the time of those legacy > commits where made, the people developing them would have kept the > changes locally, and by this time, the commits would have been thrown > away anyway. In practice there's no difference between throwing away > local commits and throwing away public commits that nobody will use. They are used by software archeologist's, for mining purposes. It is part of the project's history, and you should never regret of your history. -- 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 Wed, May 6, 2009 at 2:04 PM, Ross Burton wrote: > On Wed, 2009-05-06 at 12:27 +0200, Vincent Untz wrote: >> Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : >> > 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. >> >> I think this summarize well the whole thing: we do not want to remove >> commits. > > Agreed. All the way through this thread I've been wondering what > possible reason there would be for throwing away a commit on a > historical branch. It's not about throwing away commits, it's about throwing away unused branches. I've already explained two ways in which the branches can be thrown away without loosing the commits although personally I would just throw the commits away. My feeling is that if GNOME were using git at the time of those legacy commits where made, the people developing them would have kept the changes locally, and by this time, the commits would have been thrown away anyway. In practice there's no difference between throwing away local commits and throwing away public commits that nobody will use. -- 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 1:27 PM, Vincent Untz wrote: > Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : >> 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. > > I think this summarize well the whole thing: we do not want to remove > commits. I have already explained how you can remove commits from the visible repositories while keeping them safe in legacy repositories. If somebody really needs those commits that are not part of any release (which I seriously doubt) they will still be available. Marc-André gave me another idea. You are not limited to tags and branches, you can have any ref you want. For example "refs/legacy/gedit-0-6", it's not a branch, it's not a tag, but it will make the commits not disappear and will unclutter cgit and other visualization tools. >> 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. > > If gazillions of branches/tags/whatever is an issue with git, then I'd > say this is a git bug... I can see it being an issue when doing "git > checkout " and I'd very much prefer to have git let me filter the > branches/tags/whatever that are of interest to me via an option. Git is perfectly able to handle gazillions of branches, it's sane human beings the ones that don't. Filtering branches and tags is a good idea, but sweeping dirt under the carpet doesn't make it disappear. And you *do have* garbage. Are you going to argue that this branch is desirable to keep alive for all eternity? http://git.gnome.org/cgit/gedit/log/?h=CORBA_ENABLED I doesn't even need to disappear, it can be hidden. What's wrong with that? -- Felipe Contreras ___ 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
> > > > * 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. Tell me about it. osm-gps-map was originally created out of TangoGPS [1]. I forked the code, made it into a library, and have been improving it ever since. Unfortunately, the original TangoGPS author, Marcus Bauer, ignores any emails from me, other osm-gps-map developers, or users, that request permission to change the license of osm-gps-map to LGPL. I guess the lesson here is to never create a library, derived from a GPL project, unless you are sure that the original copy write holders are open to re-licensing those parts of the code to LGPL, aka mature and reasonable people. So good luck with libchamplain, and I am genuinely sorry that I cannot contribute any code from osm-gps-map to it. Regards John [1] http://www.tangogps.org ___ 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 Wed, May 6, 2009 at 7:58 PM, Joanmarie Diggs wrote: > Right now, my answer is "gosh, I sure hope so." :-) Admittedly, not as > good as a "heck yes!", but better than "no." > > Where things stand as of today is that WebKit needs quite a bit of work > to ready as far as a11y is concerned. HOWEVER, I've arranged my DayJob > schedule in such a way as to be able to devote around 3 days per week on > the GNOME side of WebKit a11y, and Xan is already providing patches for > the critical issues I've identified thus far. So if we can keep this up, > and if we do not run across any really complicated issues, I believe > that things will at least be "good enough" -- and ideally "good" -- in > time for 2.28. But it is hard to predict the future, especially this > early on in my (active) involvement, hence my optimistic maybe. > > Xan, what are your thoughts? Vincent and others, when do you need a > definite yea or nay by? I think that's a pretty good summary. Things are already much better than they were a few weeks ago, and I think we have a promising set up to improve them much more in the coming months. It's difficult to predict how things will work out, and as usual I'm sure we'll find problems we didn't expect and so on, but that shouldn't make us deny the fact that things WILL get much better by 2.28. In any case let's try to do our best here, and in a few more weeks I'm sure we'll have a clearer picture of where we'll stand by 2.28. Cheers, Xan ___ 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
Hey Will, all. On Wed, 2009-05-06 at 09:58 -0400, Willie Walker wrote: > Vincent Untz wrote: > > Willie: do you have any idea when the a11y team would be able to give a > > +1 for webkit? Being able to know it's okay as soon as possible would > > definitely help us organize things. > > I'm CC'ing Joanie, who'll be the person doing most of the work on the > assistive technology side of the house. Joanie has been plugging away > with testing and providing feedback while Xan has been plugging away at > the implementation. > > Joanie and Xan, how are things looking? Given an assessment of the > known solutions so far and the fact that you two will probably be the > ones working on this, do you think this is something that might be ready > for 2.28? Right now, my answer is "gosh, I sure hope so." :-) Admittedly, not as good as a "heck yes!", but better than "no." Where things stand as of today is that WebKit needs quite a bit of work to ready as far as a11y is concerned. HOWEVER, I've arranged my DayJob schedule in such a way as to be able to devote around 3 days per week on the GNOME side of WebKit a11y, and Xan is already providing patches for the critical issues I've identified thus far. So if we can keep this up, and if we do not run across any really complicated issues, I believe that things will at least be "good enough" -- and ideally "good" -- in time for 2.28. But it is hard to predict the future, especially this early on in my (active) involvement, hence my optimistic maybe. Xan, what are your thoughts? Vincent and others, when do you need a definite yea or nay by? Take care. --joanie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
Behdad Esfahbod schrieb: > On 05/05/2009 05:59 PM, Zeeshan Ali (Khattak) wrote: >> On Wed, May 6, 2009 at 12:06 AM, Behdad Esfahbod >> 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. Where do you *need* them? Are you reffering to: "All lines (outside program-listings and CDATA sections) just containing a ' *' (blank-asterisk) are converted to paragraph breaks. If you don't want a paragraph break, change that into ' * ' (blank-asterisk-blank-blank)." If so, then imho this is quite a corner case. Please can use CDATA and fix it, or we introduce a new syntax in gtk-doc. If this is in generated tmpl files - they are deprecated, please get rid of them. gtk-doc offers even support for the migration. I can't do this for whole of gnome. Stefan > > behdad > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ 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, 2009-05-06 at 10:40 +0100, Bastien Nocera wrote:
> On Wed, 2009-05-06 at 11:18 +0200, Loïc Minier wrote:
> > On Wed, May 06, 2009, Lennart Poettering wrote:
> > > 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)
> >
> > This sounds like it would remove all trailing whitespace in any file
> > you touch; that sounds like a pretty bad idea for thinks like "blame"
> > and will probably generate huge diffs for small changes -- or is this
> > only about new code you're writing?
> >
> > I use vim and it displays trailing whitespaces as blue dots for me:
> > set list
> > set listchars=tab:>-,trail:.,extends:>,precedes:<,nbsp:%
> > (the relevant config above is "trail:."; I find the other ones useful
> > as well)
>
> Eek. That'd look bad. I believe this line is from Xavier's vimrc:
> set listchars=eol:•,tab:↦\ ,trail:»,extends:↷,precedes:↶
Another alternative is just highlight them in red.
highlight BadWhitespace ctermbg=red guibg=red
if has("autocmd")
autocmd FileType c,cpp syntax match BadWhitespace /\s\+$/
endif
--
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: WebKitGTK+ as an external dependency
Vincent Untz wrote: Willie: do you have any idea when the a11y team would be able to give a +1 for webkit? Being able to know it's okay as soon as possible would definitely help us organize things. I'm CC'ing Joanie, who'll be the person doing most of the work on the assistive technology side of the house. Joanie has been plugging away with testing and providing feedback while Xan has been plugging away at the implementation. Joanie and Xan, how are things looking? Given an assessment of the known solutions so far and the fact that you two will probably be the ones working on this, do you think this is something that might be ready for 2.28? Will ___ 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
Hi, Le lundi 04 mai 2009, à 14:50 +0300, Xan Lopez a écrit : > Hello, > > the aim of the Epiphany team is to make 2.28 our first WebKit release. > For this to happen we need to replace our external dependency on Gecko > with WebKitGTK+, so consider this a request to do so. > > In the post 2.26 module decision discussion (see > http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00115.html), > where WebKitGTK+ was rejected, the two major perceived problems that I > could see were accessibility support and the lack of releases or other > means of communicating the progress of the project. Let me give you an > update on those issues. Thanks a lot for the update, it's great to see that things are moving! Willie: do you have any idea when the a11y team would be able to give a +1 for webkit? Being able to know it's okay as soon as possible would definitely help us organize things. Cheers, 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 Tue, May 5, 2009 at 11:44 PM, Elijah Newren wrote: > Hi, > > On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras > 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. +1. Luis ___ 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 12:27 +0200, Vincent Untz wrote: > Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : > > 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. > > I think this summarize well the whole thing: we do not want to remove > commits. Agreed. All the way through this thread I've been wondering what possible reason there would be for throwing away a commit on a historical branch. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.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: fast-forward only policy
Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : > 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. I think this summarize well the whole thing: we do not want to remove commits. [...] > 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. If gazillions of branches/tags/whatever is an issue with git, then I'd say this is a git bug... I can see it being an issue when doing "git checkout " and I'd very much prefer to have git let me filter the branches/tags/whatever that are of interest to me via an option. 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
Hi, On Wed, May 6, 2009 at 8:54 AM, Olav Vitters wrote: > 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 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. You are free to do whatever pleases you and I appreciate you participating in this discussion but I am also free to point out that it's not smart to put your hands on your ears when someone is describing something that is very relevant to the discussion. :) -- 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: git and trailing whitespace
On Wed, 2009-05-06 at 11:18 +0200, Loïc Minier wrote: > On Wed, May 06, 2009, Lennart Poettering wrote: > > 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) > > This sounds like it would remove all trailing whitespace in any file > you touch; that sounds like a pretty bad idea for thinks like "blame" > and will probably generate huge diffs for small changes -- or is this > only about new code you're writing? > > I use vim and it displays trailing whitespaces as blue dots for me: > set list > set listchars=tab:>-,trail:.,extends:>,precedes:<,nbsp:% > (the relevant config above is "trail:."; I find the other ones useful > as well) Eek. That'd look bad. I believe this line is from Xavier's vimrc: set listchars=eol:•,tab:↦\ ,trail:»,extends:↷,precedes:↶ > The blue dots are not intrusive when I'm actually typing text or > reading code with trailing whitespace, yet allow me to see the issue > and fix it. > > > 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. > > These people could use "patch -l" to apply your patches, but then I > think you shouldn't be stripping all trailing whitespace gratuitously. > ___ 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 06, 2009, Lennart Poettering wrote: > 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) This sounds like it would remove all trailing whitespace in any file you touch; that sounds like a pretty bad idea for thinks like "blame" and will probably generate huge diffs for small changes -- or is this only about new code you're writing? I use vim and it displays trailing whitespaces as blue dots for me: set list set listchars=tab:>-,trail:.,extends:>,precedes:<,nbsp:% (the relevant config above is "trail:."; I find the other ones useful as well) The blue dots are not intrusive when I'm actually typing text or reading code with trailing whitespace, yet allow me to see the issue and fix it. > 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. These people could use "patch -l" to apply your patches, but then I think you shouldn't be stripping all trailing whitespace gratuitously. -- Loïc Minier ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
