Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. There is another advantage of git (and I guess other DSCMs). If you start hacking locally on some cracked up idea that you have no idea if you will ever publish to the world you can still just run git init in the source dir and instantly have a revision control system. When you then want to publish this to the world it is very easy to push it to a central repo. This means git projects tend to have full history from first file creation, wheras cvs/svn project have a huge first import checkin and no history before that. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evince hard code freeze break request
Hi all, evince 2.19.92 was released depending on poppler 0.6, so I removed a lot of #ifdefs for the features that were already implemented in evince but not yet in a poppler release. The thing is that I removed from the configure the HAVE_FORMS macro but I forgot to remove one of the #ifdefs in the code. In summary, evince 2.19.92 doesn't support interactive forms :-P So, here is the trivial path to fix it: http://carlosgc.linups.org/files/ev-forms-macro.diff Ok to commit? -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince hard code freeze break request
Le mercredi 12 septembre 2007 à 11:05 +0200, Carlos Garcia Campos a écrit : Hi all, evince 2.19.92 was released depending on poppler 0.6, so I removed a lot of #ifdefs for the features that were already implemented in evince but not yet in a poppler release. The thing is that I removed from the configure the HAVE_FORMS macro but I forgot to remove one of the #ifdefs in the code. In summary, evince 2.19.92 doesn't support interactive forms :-P So, here is the trivial path to fix it: http://carlosgc.linups.org/files/ev-forms-macro.diff Ok to commit? Approval 1 of 2. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Qua, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. I don't completely agree. Personally, I have a GNOME SVN account but I still want to use DSCM. It's not at all related to giving more power to 3rd party contributors (although I admit it's an advantage). It's about giving more power to _us_ GNOME developers. For me, it's about: 1- Getting rid of ChangeLog and instead do lots of micro commits and then using whatever log --format=GnuChangeLog ChangeLog 2- Really Fast commit and history vizualization without network lag; 3- Branching and merging that works correctly out of the box a) without having to learn to use band-aid tools like svnmerge b) without having to deal with conflicts in the ChangeLog file, since it is generated from log messages; 4- Oh, in one of my projects[1] I even got my package to automatically derive its own version number from the last tag registered in the branch, so that I only have to tag the source tree and make a release tarball, not update some version string in some file; how cool is that? ;-) [1] https://launchpad.net/pybindgen -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
Le mardi 11 septembre 2007 à 22:37 +0200, Soeren Sandmann a écrit : This is true. There are issues with git, most importantly that it was written by someone for whom usability is not, um, a core competence, but is has a couple of killer features over CVS/SVN: * The abilty to commit offline You can already do it with svk or git-svn. * Bisect, as Behdad says This is definitely a killer feature, but there is no design limitation preventing implementation of such a feature in subversion. A working svn-bisect script would definitely be a worthwhile contribution. There are also a couple of non-killer improvements: * Performance: git is consistently fast; svn is slow. It should be noted this is only the case for git, not for other DSCMs. Furthermore, svk also noticeably improves performance on svn repositories. As several people already stated, most of git's improvements are already available to those who love git thanks to git-svn. It strikes me that we would actually lose svn's killer feature (simplicity) if the whole repository is migrated to git. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom 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: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 12:10 +0200, Josselin Mouette wrote: As several people already stated, most of git's improvements are already available to those who love git thanks to git-svn. It strikes me that we would actually lose svn's killer feature (simplicity) if the whole repository is migrated to git. Agreed. What is so bad with keeping svn as the master repository (easy to use, fast enough, very popular) and if people want to use git or bzr for dvcs, then they use git-svn or bzr-svn? Many people can use those to branch a svn repository and then merge between themselves, so there is no hard requirement for a central repository. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 12 Sep 2007 12:10:11 +0200, Josselin Mouette wrote: Le mardi 11 septembre 2007 à 22:37 +0200, Soeren Sandmann a écrit : This is true. There are issues with git, most importantly that it was written by someone for whom usability is not, um, a core competence, but is has a couple of killer features over CVS/SVN: * The abilty to commit offline You can already do it with svk or git-svn. svk is crap though. ;) And presumably doing a full checkout of a package's history from a subversion server is far more resource-intensive on the server side than doing the same thing with git. For example, I maintain a git-svn checkout of the Django web framework. Checking out all ~6100 revisions takes about five hours, whereas cloning the git mirror of the project from repo.or.cz takes just 27 seconds. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince hard code freeze break request
Am Mittwoch, den 12.09.2007, 11:05 +0200 schrieb Carlos Garcia Campos: In summary, evince 2.19.92 doesn't support interactive forms :-P So, here is the trivial path to fix it: http://carlosgc.linups.org/files/ev-forms-macro.diff Ok to commit? approval 2 of 2. andre -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/12/07, Ross Burton [EMAIL PROTECTED] wrote: Agreed. What is so bad with keeping svn as the master repository (easy to use, fast enough, very popular) and if people want to use git or bzr for dvcs, then they use git-svn or bzr-svn? Many people can use those to branch a svn repository and then merge between themselves, so there is no hard requirement for a central repository. I might slightly agree on this, but at the same time disagree, this definitely will work and doesn't require any change to the current situation, what I don't agree about is that you are using only 10% of what DRCS bring by doing this, what I mean is that if GNOME moves to a DRCS, it will require setting up an infrastructure that makes working with DRCS even better, for example a branch viewer, a publish/subscribe infrastructure that helps keeping track of the interesting branches Maybe the best approach is to keep svn as you suggest, but at the same time lay down a DRCS infrastructure that will improve the current GNOME project workflow while not requiring any deep surgery :) -- Cheers, Ali http://asabil.wordpress.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: How to download the API references pages?]
Hi, This is Tim from Sun desktop team. I'm looking for some GNOME2.20 API references pages/packages/tarballs. Would anyone please give me a hint where I could download them all on page http://library.gnome.org/devel/references ? Thanks for your information! Best regards. -Tim Miao ---BeginMessage--- Hi All, The API references pages are changed, the links of doc packages for downloading have been removed from this page. How could we get this latest references pages? Any idea? (References link: http://library.gnome.org/devel/references) Thanks! -Tim ---End Message--- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Orca hard code freeze break request for pychecker errors
Hi All: In prepping for a different problem we're investigating with the Firefox team, we've been running pychecker on the Orca sources. We came across two serious problems. The first is that one of our scripts (the one for nautilus) was importing a module that no longer exists. The second is that the superclass of all our scripts is returning a non-existent value for one of its methods. I'm not sure how we missed either of these. :-( These are high-benefit low-risk fixes. They are high-benefit because they will avoid abnormal behavior from Orca when these particular features are encountered (e.g., the nautilus one would be encountered each time Orca interacted with nautilus). They are low risk because the changes are isolated to just the problems in question. Patch attached. OK to commit? Will PS - We are busily hammering away at our regression tests to more easily catch things like this in the GNOME 2.21 development timeframe. Index: src/orca/scripts/nautilus.py === --- src/orca/scripts/nautilus.py (revision 2816) +++ src/orca/scripts/nautilus.py (working copy) @@ -1,6 +1,6 @@ # Orca # -# Copyright 2006 Sun Microsystems Inc. +# Copyright 2006-2007 Sun Microsystems Inc. # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Library General Public @@ -22,7 +22,7 @@ __id__= $Id:$ __version__ = $Revision:$ __date__ = $Date:$ -__copyright__ = Copyright (c) 2007 Sun Microsystems Inc. +__copyright__ = Copyright (c) 2006-2007 Sun Microsystems Inc. __license__ = LGPL import orca.atspi as atspi @@ -31,7 +31,6 @@ import orca.default as default import orca.rolenames as rolenames import orca.speech as speech -import orca.util as util from orca.orca_i18n import _ # for gettext support from orca.orca_i18n import ngettext # for ngettext support @@ -78,7 +77,7 @@ itemCount = -1 itemCountString = -allScrollPanes = util.findByRole(frame, rolenames.ROLE_SCROLL_PANE) +allScrollPanes = self.findByRole(frame, rolenames.ROLE_SCROLL_PANE) rolesList = [rolenames.ROLE_SCROLL_PANE, \ rolenames.ROLE_FILLER, \ rolenames.ROLE_FILLER, \ @@ -93,7 +92,7 @@ # Create a string of the number of items in the folder. # for pane in allScrollPanes: -if util.isDesiredFocusedItem(pane, rolesList): +if self.isDesiredFocusedItem(pane, rolesList): for i in range(0, pane.childCount): child = pane.child(i) if child.role == rolenames.ROLE_LAYERED_PANE: @@ -119,8 +118,6 @@ event, event.source.toString()) -#util.printAncestry(event.source) - if event.source.role == rolenames.ROLE_FRAME: # If we've changed folders, announce the new folder name and @@ -142,7 +139,7 @@ allTokens = event.source.name.split( - ) newFolderName = allTokens[0] -allPanels = util.findByRole(event.source, rolenames.ROLE_PANEL) +allPanels = self.findByRole(event.source, rolenames.ROLE_PANEL) rolesList = [rolenames.ROLE_PANEL, \ rolenames.ROLE_FILLER, \ rolenames.ROLE_PANEL, \ @@ -152,7 +149,7 @@ rolenames.ROLE_APPLICATION] locationBarFound = False for panel in allPanels: -if util.isDesiredFocusedItem(panel, rolesList): +if self.isDesiredFocusedItem(panel, rolesList): locationBarFound = True break @@ -162,7 +159,7 @@ child = panel.child(i) if child.role == rolenames.ROLE_TOGGLE_BUTTON and \ child.state.count(atspi.Accessibility.STATE_CHECKED): -if not util.isSameObject(child, self.pathChild): +if not self.isSameObject(child, self.pathChild): self.pathChild = child shouldAnnounce = True break Index: src/orca/script.py === --- src/orca/script.py (revision 2816) +++ src/orca/script.py (working copy) @@ -230,7 +230,7 @@ - pronunciations: the dictionary of pronunciations for this script. -return pronunciationDict +return pronunciations def getAppState(self): Returns an object that can be passed to setAppState. This ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Orca hard code freeze break request for pychecker errors
Le mercredi 12 septembre 2007 à 10:52 -0400, Willie Walker a écrit : Hi All: In prepping for a different problem we're investigating with the Firefox team, we've been running pychecker on the Orca sources. We came across two serious problems. The first is that one of our scripts (the one for nautilus) was importing a module that no longer exists. The second is that the superclass of all our scripts is returning a non-existent value for one of its methods. I'm not sure how we missed either of these. :-( These are high-benefit low-risk fixes. They are high-benefit because they will avoid abnormal behavior from Orca when these particular features are encountered (e.g., the nautilus one would be encountered each time Orca interacted with nautilus). They are low risk because the changes are isolated to just the problems in question. Patch attached. OK to commit? Approval 1 of 2. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Orca hard code freeze break request for pychecker errors
Le mercredi 12 septembre 2007, à 17:03 +0200, Frederic Crozat a écrit : Le mercredi 12 septembre 2007 à 10:52 -0400, Willie Walker a écrit : Hi All: In prepping for a different problem we're investigating with the Firefox team, we've been running pychecker on the Orca sources. We came across two serious problems. The first is that one of our scripts (the one for nautilus) was importing a module that no longer exists. The second is that the superclass of all our scripts is returning a non-existent value for one of its methods. I'm not sure how we missed either of these. :-( These are high-benefit low-risk fixes. They are high-benefit because they will avoid abnormal behavior from Orca when these particular features are encountered (e.g., the nautilus one would be encountered each time Orca interacted with nautilus). They are low risk because the changes are isolated to just the problems in question. Patch attached. OK to commit? Approval 1 of 2. 2 of 2. 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: Orca hard code freeze break request for pychecker errors
Thanks everyone! Committed the patch to exactly as it was given to you. Will On Wed, 2007-09-12 at 18:05 +0200, Vincent Untz wrote: Le mercredi 12 septembre 2007, à 17:03 +0200, Frederic Crozat a écrit : Le mercredi 12 septembre 2007 à 10:52 -0400, Willie Walker a écrit : Hi All: In prepping for a different problem we're investigating with the Firefox team, we've been running pychecker on the Orca sources. We came across two serious problems. The first is that one of our scripts (the one for nautilus) was importing a module that no longer exists. The second is that the superclass of all our scripts is returning a non-existent value for one of its methods. I'm not sure how we missed either of these. :-( These are high-benefit low-risk fixes. They are high-benefit because they will avoid abnormal behavior from Orca when these particular features are encountered (e.g., the nautilus one would be encountered each time Orca interacted with nautilus). They are low risk because the changes are isolated to just the problems in question. Patch attached. OK to commit? Approval 1 of 2. 2 of 2. Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/12/07, Kalle Vahlman [EMAIL PROTECTED] wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Yes, lets be clear that I think a DSCM is going to be an excellent upgrade to GNOME infrastructure, and from what I've read I think Git will do us well. Switching from SVN to Git will help to dissolve part of the issues related to the SVN account creation but doesn't actually solve the problem. There will still be a lag in account access, we'll still be missing visibility among ourselves and the work we're doing, are we going to have to initiate a request to create a new repository?; Git doesn't solve that! Here's the original clip of Damien's message that I think started this spawn of the thread Matthias requested an SVN account several months ago, and never got one. When he went on IRC to ask for the account activation, people replied to him that he had to make a new request and wait. One month later, the account is not active yet. Matthias has been contributing thousands of lines of code to Ekiga since several months, and I still need to commit his patches myself. This is inadmissible. Sure, you can argue that Git might allow for easier merging from one repo to another, but that's not the issue at all. The issue is account lag. There will still be a need for accounts on git.gnome.org and the switch to a DSCM didn't solve that at all. I'm not pushing to stop or slow down this switch, I think we should move to Git as it has a lot of advantages and I'm willing to try learning the new system so I can take advantage. I'm trying to stop talking the merits of Git. If I could put on my GNOME Benevolent Dictator (GBD) hat on right now I'd say: Git looks like a good move, it's technologically sound, has the backing of a large community similar to ours, and will have lots of added benefits to our community because of it's distributed nature. Someone needs to layout a plan for migration to Git, determine a specific time line for the change and the requirements needed to meet that time line. Also, we will need to start making large changes to our developer documents and community access methods. Someone needs to start designing a system for our translators to access our source code using Git. Someone needs to help develop our account system (this is Mango, right?) around Git; I made some previous notes about it and Olav had comments, I believe that's a good start. And finally someone needs to design ways for us all to have a next generation cvs-commits list, where we can keep accountability and community activity at the center of all our attentions; I listed some notes on that earlier. Go Go GO! ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
quote who=Bryan Clark I'm trying to stop talking the merits of Git. If I could put on my GNOME Benevolent Dictator (GBD) hat on right now I'd say: Bryan, surely you would be saying something closer to, Where did everyone lose their sense of taste? Git is almost antithetical to GNOME's desires for 'just works', usability and tastefulness. What the hell is going on here? :-) I'd like to suggest we split these ideas back up again: DSCM will be great, but why not think about clever things we can do with our infrastructure to drive participation *now*, independently of the SCM platform? This is the direction Havoc was attempting handwave towards. - Jeff -- GNOME.conf.au 2008: Melbourne, Australia http://live.gnome.org/Melbourne2008 Old timers will tell you what a pain unstable was during the new testament transition. - Jon Corbet on Debian's KJV packages ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
External deps: update Rarian
Hi, I've just released Rarian 0.6.0 and would like to update the external dependence for GNOME to this. Current version (minimum and recommended): 0.5.8 Suggested version: 0.6.0 Reasons: GNOME bug #474556 [1] Fixes various other minor problems As suggested by the version number, this is the final release in this series. Future work (excluding bug fixes) will begin in the 0.7 branch. Thanks Don [1] http://bugzilla.gnome.org/show_bug.cgi?id=474556 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? Just my 2p John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. Once the Changelog is removed, or no longer updated, this argument goes away. So what other problems are there with bzr-svn / git-svn? John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 21:40 +0100, John Carr wrote: On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. It's not the same. You don't want your ChangeLog messages to have bulleted items including a list of changed files, because if you do that then when you generate a full ChangeLog from the stored commit messages things will appear all unaligned. Once the Changelog is removed, or no longer updated, this argument goes away. Like I tried to explain, no maintainer will want to give up on manually written ChangeLog files because: 1- bundling lots of changes in a single commit log message will make the generated changelog look really bad; 2- not bundling lots of changes in a single commit log message implies making lots small commits (i call it micro commits), which is very slow with subversion due to network roundtrips. So what other problems are there with bzr-svn / git-svn? Cloning from svn to bzr (or git or whatever) takes ages, so you want to have an official bzr branch version of your project to make branching fast and easy for everyone else. Hence you want hosting of bzr branches in a GNOME server, and all my remaining reasons still apply. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
[Freeze Break Request] deskbar, history crasher
Hi Release Team et al. - sorry for cross posting to release-team, but I had some technical problems... Deskbar trunk has a crasher in the history extension that makes it crash on every query once it is enabled. I get this consistently on my work machine, but not in my own laptop, so it is likely caused by some undertermined bug in the history file. The following patch fixes it in a one-liner, but it will only fix the symptoms (and that is guaranteed), not the cause. I have OK from Sebastian (the SoC guy doing the rewrite). PATCH: Index: deskbar/handlers/history.py === --- deskbar/handlers/history.py (revision 1660) +++ deskbar/handlers/history.py (working copy) @@ -16,7 +16,7 @@ self._action = action def get_hash(self, text=None): -return history_+self._action.get_hash() +return history_+str(self._action.get_hash()) def get_icon(self): return self._action.get_pixbuf() There is no bug report open on this. Is it OK to commit? Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 21:58 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 21:40 +0100, John Carr wrote: On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. It's not the same. You don't want your ChangeLog messages to have bulleted items including a list of changed files, because if you do that then when you generate a full ChangeLog from the stored commit messages things will appear all unaligned. Your changelog text file will be intact in each revision log node. svn can give the log in XML format, meaning that you can style it how the heck you please. This could easily be an identity type transformation that just put the changelog messages in order and dumped them out without touching the format of the actual text. Once the Changelog is removed, or no longer updated, this argument goes away. Like I tried to explain, no maintainer will want to give up on manually written ChangeLog files because: 1- bundling lots of changes in a single commit log message will make the generated changelog look really bad; 2- not bundling lots of changes in a single commit log message implies making lots small commits (i call it micro commits), which is very slow with subversion due to network roundtrips. But wait, if they aren't going to give up on manually written ChangeLogs, won't merge problems still apply? I thought
Re: Git vs SVN (was: Can we improve things?)
[moving thread to d-d-l] On Mon, 2007-09-10 at 23:33 +0200, Olav Vitters wrote: On Mon, Sep 10, 2007 at 03:05:18PM -0500, Federico Mena Quintero wrote: Because it is no longer possible to create new SVN modules easily, as it was when we used CVS. By easily I mean that it you want to create a module, you don't need to ask anyone to do it for you. So ehr, we should have svn.gnome.org/svn/testingground ? (or whatever?) I don't know how Subversion repositories work. Why can't people simply do svn import mynewmodule svn://svn.gnome.org/svn/mynewmodule ? [Just tested it - doesn't work.] [During the days of cvs.gnome.org, /cvs/gnome was group-writable by member of the cvsusers group; that was enough for people to be able to import new modules. Not everyone had a full shell account; they were restricted to cvs only.] http://developer.gnome.org/tools/svn.html - which leads you to http://developer.gnome.org/doc/tutorials/import.html if you want to import your code, but THAT WON'T WORK because it still talks about cvs import. Feel free to fix it and point to NewSVNRepos. Sure, I'll do that. I was just describing the sort of experience that developers get when trying to use our infrastructure. [Straw poll: how many people here *don't* know that developer.gnome.org is a module on SVN? How many people don't know the corresponding module name?] svn in the search box. Great, the first search hit is http://live.gnome.org/NewSVNRepos - which tells you mail an admin with this list of requirements. Download page? Project homepage? Come on, this is my first it barely works release - I don't have all that set up yet! Ehr? Doesn't it tell you that *if you have a GNOME SVN account*, we only care about *your GNOME SVN account and your requested module name*? Sorry, where does it say that? if it doesn't, just mention this (it is a wiki:). See, how was I supposed to know that? I assume that whoever hands out new repositories wrote the NewSVNRepos page and put accurate information there. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-system-tools and liboobs branched for 2.20
Hi!, I've just branched g-s-t and liboobs for 2.20, development for 2.21 will happen in trunk as usual, future plans include: - hal integration - rtnetlink integration (linux only) - optional PolicyKit use - all I couldn't do for 2.20 Regards, Carlos ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/12/07, John Carr [EMAIL PROTECTED] wrote: But wait, if they aren't going to give up on manually written ChangeLogs, won't merge problems still apply? I thought the point of bzr/git was that you could micro-commit and side step the need for changelogs, preventing merge problems? I've been pretty happy with keeping my ChangeLog on a wiki, e.g.: http://code.google.com/p/hotwire-shell/wiki/HotwireChanges While reserving the VCS for low level code comments. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git vs SVN (was: Can we improve things?)
On 9/12/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: [moving thread to d-d-l] On Mon, 2007-09-10 at 23:33 +0200, Olav Vitters wrote: On Mon, Sep 10, 2007 at 03:05:18PM -0500, Federico Mena Quintero wrote: Because it is no longer possible to create new SVN modules easily, as it was when we used CVS. By easily I mean that it you want to create a module, you don't need to ask anyone to do it for you. So ehr, we should have svn.gnome.org/svn/testingground ? (or whatever?) I don't know how Subversion repositories work. Why can't people simply do svn import mynewmodule svn://svn.gnome.org/svn/mynewmodule ? [Just tested it - doesn't work.] [During the days of cvs.gnome.org, /cvs/gnome was group-writable by member of the cvsusers group; that was enough for people to be able to import new modules. Not everyone had a full shell account; they were restricted to cvs only.] http://developer.gnome.org/tools/svn.html - which leads you to http://developer.gnome.org/doc/tutorials/import.html if you want to import your code, but THAT WON'T WORK because it still talks about cvs import. Feel free to fix it and point to NewSVNRepos. Sure, I'll do that. I was just describing the sort of experience that developers get when trying to use our infrastructure. [Straw poll: how many people here *don't* know that developer.gnome.org is a module on SVN? How many people don't know the corresponding module name?] svn in the search box. Great, the first search hit is http://live.gnome.org/NewSVNRepos - which tells you mail an admin with this list of requirements. Download page? Project homepage? Come on, this is my first it barely works release - I don't have all that set up yet! Ehr? Doesn't it tell you that *if you have a GNOME SVN account*, we only care about *your GNOME SVN account and your requested module name*? Sorry, where does it say that? if it doesn't, just mention this (it is a wiki:). See, how was I supposed to know that? I assume that whoever hands out new repositories wrote the NewSVNRepos page and put accurate information there. By the way, we should also add some info that clarifies that if you get svn access it's not restricted to the project you work on, and also that bugzilla product admin rights are not the same as svn rights. I have been solving tickets in the accounts queue and found a good number of them about requesting rights that are actually requests for bugzilla rights or requests for access to svn module X when they already have an account (hence they have rights for everything already). If someone can help rephrase that, maybe we should add it to a subsection of http://live.gnome.org/NewAccounts , something like Account types, can and can't. Greetings! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
