Re: gnomeweb-wml pushes not causing website updates. missing a hook?
Owen Taylor wrote: I think all the updates on gnome.org machines (except for torrent.gnome.org, which I don't have access to, and library.gnome.org which is failing for reasons that don't look git related) should be working fine now. Thanks Owen; I just fixed library.gnome.org. Actually it was slightly git related, as it expected a directory to exist and the svn repos supported empty directories. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom schrieb: On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). A git patch has metadata. That is if you use git format-patch then the commit messages go into the patch and if you use git apply they will be applied along with the patch. Stefan Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Cheers, -Tristan ___ 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: gnomeweb-wml pushes not causing website updates. missing a hook?
Changes to gtk-web still don't seem to propagate to the web server? --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
R: git migration - svn:externals
Hi Owen, I'm not entirely sure (bazaar user here), however I think that git has the notion of submodules: http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html Matteo Messaggio originale Da: j...@jsschmid.de Data: 23-apr-2009 8.06 AM A: Owen Taylorotay...@redhat.com Cc: desktop-devel-listdesktop- devel-l...@gnome.org Ogg: git migration - svn:externals Hi! svn:externals are not migrated at all. That breaks anjuta-extras module (b.g.o #579867) and gtkmm (fixed by duplicating files now). Is there anything we can do to fix it? Duplicating files is a quite weak and ugly solution. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's it. We use git submodules in GStreamer though (we have a 'common' submodule for all other modules), but git submodules are still fairly cumbersome to use and I wouldn't recommend them until the git people make them less painful to use, at least not for projects where the submodule reference needs to be updated frequently. Cheers -Tim ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bumping telepathy-glib to 0.7.27 (Empathy needs that version)
Hi, I just noticed when using jhbuild that empathy needs 0.7.27 of telepathy-glib. OK to bump the version in jhbuild and http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller t@zen.co.uk wrote: On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's it. We use git submodules in GStreamer though (we have a 'common' submodule for all other modules), but git submodules are still fairly cumbersome to use and I wouldn't recommend them until the git people make them less painful to use, at least not for projects where the submodule reference needs to be updated frequently. This whole idea of sub-modules is just brain-dead so I wouldn't count on git developers fixing that instead of concentrating on features of real importance. If you have some code (or even data) that is needed by more than one of your modules/packages, you either put that common stuff in another module/package and make other packages depend on this or you just bite the bullet and don't mind the redundancy. In some cases you just have to wisely use the combination of both. -- 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: R: git migration - svn:externals
On Thu, Apr 23, 2009 at 12:27 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller t@zen.co.uk wrote: On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's it. We use git submodules in GStreamer though (we have a 'common' submodule for all other modules), but git submodules are still fairly cumbersome to use and I wouldn't recommend them until the git people make them less painful to use, at least not for projects where the submodule reference needs to be updated frequently. This whole idea of sub-modules is just brain-dead so I wouldn't count on git developers fixing that instead of concentrating on features of real importance. If you have some code (or even data) that is needed by more than one of your modules/packages, you either put that common stuff in another module/package and make other packages depend on this or you just bite the bullet and don't mind the redundancy. In some cases you just have to wisely use the combination of both. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 Very much +1. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git migration - svn:externals
On Thu, 2009-04-23 at 08:06 +0200, Johannes Schmid wrote: Hi! svn:externals are not migrated at all. That breaks anjuta-extras module (b.g.o #579867) and gtkmm (fixed by duplicating files now). Is there anything we can do to fix it? Duplicating files is a quite weak and ugly solution. http://mail.gnome.org/archives/gnome-infrastructure/2009-March/msg00054.html is some analysis I did earlier. It has a suggestion for gtkmm, which might or might not be better than duplication. The entire anjuta-extras module was created a few weeks ago, so obviously the svn:extras usage there didn't show up in my search. Taking a quick look, my opinion is that Anjuta should just install those files somewhere. I tend to agree with Zeeshan and John that the entire concept of symlinking parts of one version control tree into another version control tree is problematical. In particular: - Its confusing. Depending on the VCS, people will either tend to accidentally commit stuff into the symlinked tree and break other modules, or miss a committing changes altogether. - It breaks tagging, unless the external reference is to a particular version, in which case it needs manual updates. (CVS module references to gnome-common created the tag/branch mess which delayed getting that migrated for almost a week.) And we have powerful tools for intermodule dependencies with jhbuild and pkg-config, and Linux package managers. So, while using git submodules is conceivable, I think it should be an option of last resort. It would also require jhbuild support. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping telepathy-glib to 0.7.27 (Empathy needs that version)
Le jeudi 23 avril 2009 à 12:41 +0200, Jaap A. Haitsma a écrit : Hi, I just noticed when using jhbuild that empathy needs 0.7.27 of telepathy-glib. OK to bump the version in jhbuild and http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies telepathy-glib as good regression tests and its ABI/API is guaranteed to be stable. So I think the external dep should be set has 0.7.x. I always forget to edit that page... IMHO setting an exact version as external dep for GNOME only makes sense when there is an ABI break. Xavier Claessens. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On Thu, 2009-04-23 at 11:45 +0200, Murray Cumming wrote: On Wed, 2009-04-22 at 16:46 +0200, Vincent Untz wrote: Don't use a trailing period either. I find this really odd and rather arbitrary. I think it's something to do with you wanting to use these first lines in bullet-point lists. But there's no real grammar consensus about periods at the end of bullet-point items. I personally can't stand a sentence without a bullet point if it's more than 4 or 5 words. Can we please remove that requirement? It's not a requirement. It's a suggestion. Individual maintainers are free to have different suggestions. So the goal of the overall suggestions is to capture what most maintainers want. FWIW, the no-period form matches exactly what we do for application descriptions in .desktop files, as well as the module descriptions in the new DOAP files. I don't think our Style Guide has anything to say on this matter. We do generally defer to CMS. I could check if CMS says anything if anybody wants to get really persnickety about grammar. Personally, and this is coming from the documentation guy, I think it's pretty massive non-issue. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: http://www.gnome.org/~shaunm/pulse/web/
On Thu, 2009-04-23 at 18:27 +0300, Stefan Kost wrote: hi, what does one get from creating an account for pulse? Also is it going to be switch to check the git repositories? I created a doap file for gtk-doc, but its of course in git :) Second question first: Yes, of course. Pulse already supports Git. The test instance at that URL is not a real deployment. The crawler isn't running on gnome.org, so that page only gets updated when I run the crawler on my machine and upload the database and files. First question: First note that account information is blown away every time I upload a new database. What you get: Currently: Watch people and projects. Activity for those things shows up on your start page. Soon: Claim to be one or more of the accounts Pulse has found. Later: Write notes, edit overview pages for things you maintain, tell Pulse where you are so we can map our contributors, participate in various collaborative features. Et cetera. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping telepathy-glib to 0.7.27 (Empathy needs that version)
On Thu, Apr 23, 2009 at 11:37 AM, Xavier Claessens ... IMHO setting an exact version as external dep for GNOME only makes sense when there is an ABI break. Declaring a dependency on 0.7.x would not be correct if empathy doesn't work with anything older than 0.7.27... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: http://www.gnome.org/~shaunm/pulse/web/
On Thu, 2009-04-23 at 19:05 +0200, Ruben Vermeersch wrote: On Thu, 2009-04-23 at 11:22 -0500, Shaun McCance wrote: Later: Write notes, edit overview pages for things you maintain, tell Pulse where you are so we can map our contributors, participate in various collaborative features. Et cetera. Is stuff like merge request tracking also part of this (in an undefined future), or will that be part of a gitorious alike thing? Maybe. I generally take the practical approach of letting other tools do what they do. Is it worth setting up yet another service just for merge requests? Maybe. Is it worth adding a feature to Pulse that people could get elsewise? Maybe. So, maybe. Depends on what people want and what people are willing to hack on. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: http://www.gnome.org/~shaunm/pulse/web/
On Thu, 2009-04-23 at 13:12 -0500, Shaun McCance wrote: On Thu, 2009-04-23 at 19:05 +0200, Ruben Vermeersch wrote: On Thu, 2009-04-23 at 11:22 -0500, Shaun McCance wrote: Later: Write notes, edit overview pages for things you maintain, tell Pulse where you are so we can map our contributors, participate in various collaborative features. Et cetera. Is stuff like merge request tracking also part of this (in an undefined future), or will that be part of a gitorious alike thing? Maybe. I generally take the practical approach of letting other tools do what they do. Is it worth setting up yet another service just for merge requests? Maybe. Is it worth adding a feature to Pulse that people could get elsewise? Maybe. So, maybe. Depends on what people want and what people are willing to hack on. Unless we add something like gitorious, I'd imagine that merge requests would continue to be handled in bugzilla. A request to merge a branch is very similar to attaching a patch. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Open source and diagramming survey
Dear open source developers, I am Eunyoung Chung, a Masters student working with Dr. Jensen at Oregon State University. We are currently doing a research project in collaboration with Dr. Truong and Ph.D student Koji Yatani at University of Toronto. Our goal is to understand how contributors communicate and collaborate in Open Source Software (OSS) projects, including diagramming practices. We are seeking volunteers for a quick survey on this topic. Any person who is actively working on a OSS project is eligible. The survey takes approximately 10-15 minutes, and the 5 volunteers will be picked to receive a $30 Amazon gift certificate. Your participation is anonymous (unless you consent to have us contact you) Here is the survey address. https://secure.engr.oregonstate.edu/limesurvey/58564/lang-en We really appreciate your help! -- Eunyoung Chung ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On 04/23/2009 08:47 AM, Loïc Minier wrote: On Wed, Apr 22, 2009, Vincent Untz wrote: Frédéric (fredp) is suggesting to also propose a standard scheme to reference bugs that are fixed by a commit (so we can script things if it's needed one day -- that's similar to what Debian does). Something like Closes: #123456 or Fixes: #123456. This should probably live in the longer explanation since the short explanation is limited in size... (Then we can also reference other bug trackers when needed: bnc#12345, rh#12345, lp#12345, etc.) That would be excellent, thanks! However please consider using: GNOME #1234 one issue with the Debian closes: is that it doesn't indicate Debian, which is why Nokia, Ubuntu etc. all use different prefixes to refer to their bugs. Using GNOME #1234 would allow terminals to link to bugzilla.gnome.org directly for instance. I prefer the more verbose GNOME Bug #1234 in that case. And I opened a bug yesterday to allow configuring such matchers on gnome-terminal: http://bugzilla.gnome.org/show_bug.cgi?id=579859 behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
Le jeudi 23 avril 2009, à 15:42 -0400, Behdad Esfahbod a écrit : On 04/23/2009 08:47 AM, Loïc Minier wrote: On Wed, Apr 22, 2009, Vincent Untz wrote: Frédéric (fredp) is suggesting to also propose a standard scheme to reference bugs that are fixed by a commit (so we can script things if it's needed one day -- that's similar to what Debian does). Something like Closes: #123456 or Fixes: #123456. This should probably live in the longer explanation since the short explanation is limited in size... (Then we can also reference other bug trackers when needed: bnc#12345, rh#12345, lp#12345, etc.) That would be excellent, thanks! However please consider using: GNOME #1234 one issue with the Debian closes: is that it doesn't indicate Debian, which is why Nokia, Ubuntu etc. all use different prefixes to refer to their bugs. Using GNOME #1234 would allow terminals to link to bugzilla.gnome.org directly for instance. I prefer the more verbose GNOME Bug #1234 in that case. But I'm lazy. You'll likely get me to write bgo#1234 or gnome#1234, but writing GNOME Bug #1234 or Novell Bug #1234, Red Hat Bug #1234... it just won't work for me (and I would guess other people). 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: git commit messages
On Thu, 2009-04-23 at 21:59 +0200, Vincent Untz wrote: Le jeudi 23 avril 2009, à 15:42 -0400, Behdad Esfahbod a écrit : On 04/23/2009 08:47 AM, Loïc Minier wrote: On Wed, Apr 22, 2009, Vincent Untz wrote: Frédéric (fredp) is suggesting to also propose a standard scheme to reference bugs that are fixed by a commit (so we can script things if it's needed one day -- that's similar to what Debian does). Something like Closes: #123456 or Fixes: #123456. This should probably live in the longer explanation since the short explanation is limited in size... (Then we can also reference other bug trackers when needed: bnc#12345, rh#12345, lp#12345, etc.) That would be excellent, thanks! However please consider using: GNOME #1234 one issue with the Debian closes: is that it doesn't indicate Debian, which is why Nokia, Ubuntu etc. all use different prefixes to refer to their bugs. Using GNOME #1234 would allow terminals to link to bugzilla.gnome.org directly for instance. I prefer the more verbose GNOME Bug #1234 in that case. But I'm lazy. You'll likely get me to write bgo#1234 or gnome#1234, but writing GNOME Bug #1234 or Novell Bug #1234, Red Hat Bug #1234... it just won't work for me (and I would guess other people). I have a certain fondness for http://bugzilla.gnome.org/show_bug.cgi?id=1234 Not that I want to *type* that but I can be ultimately lazy and cut-and-paste it in without fear of mistyping the bug number. - Owen [ Yes, it's not very compact ] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On Thu, 2009-04-23 at 16:23 -0400, Owen Taylor wrote: On Thu, 2009-04-23 at 21:59 +0200, Vincent Untz wrote: Le jeudi 23 avril 2009, à 15:42 -0400, Behdad Esfahbod a écrit : On 04/23/2009 08:47 AM, Loïc Minier wrote: On Wed, Apr 22, 2009, Vincent Untz wrote: Frédéric (fredp) is suggesting to also propose a standard scheme to reference bugs that are fixed by a commit (so we can script things if it's needed one day -- that's similar to what Debian does). Something like Closes: #123456 or Fixes: #123456. This should probably live in the longer explanation since the short explanation is limited in size... (Then we can also reference other bug trackers when needed: bnc#12345, rh#12345, lp#12345, etc.) That would be excellent, thanks! However please consider using: GNOME #1234 one issue with the Debian closes: is that it doesn't indicate Debian, which is why Nokia, Ubuntu etc. all use different prefixes to refer to their bugs. Using GNOME #1234 would allow terminals to link to bugzilla.gnome.org directly for instance. I prefer the more verbose GNOME Bug #1234 in that case. But I'm lazy. You'll likely get me to write bgo#1234 or gnome#1234, but writing GNOME Bug #1234 or Novell Bug #1234, Red Hat Bug #1234... it just won't work for me (and I would guess other people). I have a certain fondness for http://bugzilla.gnome.org/show_bug.cgi?id=1234 Not that I want to *type* that but I can be ultimately lazy and cut-and-paste it in without fear of mistyping the bug number. - Owen [ Yes, it's not very compact ] But it's certainly the easiest to parse for any crazy kids out there who like building project trackers. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomeweb-wml pushes not causing website updates. missing a hook?
On Thu, 23 Apr 2009, Owen Taylor wrote: On Thu, 2009-04-23 at 10:10 +0300, Tor Lillqvist wrote: Changes to gtk-web still don't seem to propagate to the web server? Not in my control, cc'ing Tim, he should be able to give the status there. I've not checked the actual gtk-web module (the beast module conversion at least seems to have major problems), but updates to the website from git should be working now. I'm currently polling git ls-remote git://git.gnome.org/gtk-web refs/heads/master (suggested by Owen) every few minutes to check for updates. - Owen --- ciaoTJ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: intltool move
Le dimanche 19 avril 2009, à 15:25 -0400, Rodney Dawes a écrit : The intltool product on bugzilla.gnome.org is now closed for new reports, and the SVN module was moved over to svn-archive before the gnome.org transition to git. The latest intltool code is already in a bzr branch on Launchpad (lp:intltool) and, all new bugs should be reported at http://bugs.launchpad.net/intltool/ from now on. There are still a few open bugs in bugzilla, which Danilo or myself will deal with as appropriate, by fixing, moving, or closing as wontfix. Going to https://bugs.launchpad.net/intltool/+filebug, I get: intltool does not use Launchpad as its bug tracker. 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
Reminder: Travel assistance applications to attend to GUADEC
Dear hackers, The Travel Committee is receiving applications for travel sponsorship requests for the next GUADEC which will be held in Gran Canaria, Spain. The deadline is April 27, 2009, 19:00 UTC. Do no wait until the very last minute. Read carefully the instructions and the process' explanation at http://live.gnome.org/Travel Kind regards, -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
