Mirroring GNOME on github
Hi, I spoke about this with a few people at GUADEC, but I would like to continue the discussion here. Can we please mirror the GNOME repositories on github.org (https://github.com/GNOME)? Advantages * Many many people already have forks of GNOME components there, if GNOME was the parent of these clones then we could easily the differences * Github has a working code search * Nice web UI including visual image diffs, branch diff browser, commit browser, etc * Allows maintainers see who is working on their project via notification of forks and watchers * Code search is approximately ∞ than google code search (RIP) * In my experience cloning from github is faster than cloning from gnome.org * Improved visibility, perception of openness, other marketing intangibles. Disadvantages * Maintainers might see this is mandating them change their workflow. I emphasize that github should be only a mirror, interaction and merging should occur first on git.gnome.org * Github UI is not FOSS * Work required to keep mirror up to date Regarding the last point, Alberto Ruiz already has some scripts that are manually run to update the mirror. A simple approach would be to put these on the gnome servers and run them in the post commit hook. However, Github already maintains mirrors for others (https://github.com/mirrors). I would not be surprised if they could do a similar thing for us if we ask. Regards, John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Hey John! I would prefer to have a gitorious instance setup on the GNOME servers as has been previously discussed. Basically someone would need to do the job. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Hello Johannes, a mirror in github will not stop anyone from doing a mirror in gitorious as well. But as it turns out, there is a huge community of developers in github (way bigger than gitorious') that we can outreach if we have an official mirror there. 2012/8/7 Johannes Schmid j...@jsschmid.de Hey John! I would prefer to have a gitorious instance setup on the GNOME servers as has been previously discussed. Basically someone would need to do the job. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, Aug 7, 2012 at 12:09 PM, John Stowers john.stowers.li...@gmail.com wrote: Hi, I spoke about this with a few people at GUADEC, but I would like to continue the discussion here. Can we please mirror the GNOME repositories on github.org (https://github.com/GNOME)? Advantages * Many many people already have forks of GNOME components there, if GNOME was the parent of these clones then we could easily the differences * Github has a working code search * Nice web UI including visual image diffs, branch diff browser, commit browser, etc * Allows maintainers see who is working on their project via notification of forks and watchers * Code search is approximately ∞ than google code search (RIP) * In my experience cloning from github is faster than cloning from gnome.org * Improved visibility, perception of openness, other marketing intangibles. Disadvantages * Maintainers might see this is mandating them change their workflow. I emphasize that github should be only a mirror, interaction and merging should occur first on git.gnome.org This is a killer. There would just be forks of random GitHub repositories with patches, and people submitting pull requests, that are as effective as /dev/null. Slashdot writes that we're mirroring on GNOME, and the designers are the cabal again. if we want to mirror on GitHub, we need to have an active presence there. I don't know what that would mean. I'd really like if it we would switch to GitHub wholesale; it would be great for PR and everything. But it won't happen, because: * Github UI is not FOSS And that's that. To me, having the entirety of GitHub contributing to GNOME would be so much more than a sacrifice of freedom. But that's not my decision to make. * Work required to keep mirror up to date Regarding the last point, Alberto Ruiz already has some scripts that are manually run to update the mirror. A simple approach would be to put these on the gnome servers and run them in the post commit hook. However, Github already maintains mirrors for others (https://github.com/mirrors). I would not be surprised if they could do a similar thing for us if we ask. Regards, John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Disadvantages * Maintainers might see this is mandating them change their workflow. I emphasize that github should be only a mirror, interaction and merging should occur first on git.gnome.org This is a killer. There would just be forks of random GitHub repositories with patches, and people submitting pull requests, that are as effective as /dev/null. Slashdot writes that we're mirroring on GNOME, and the designers are the cabal again. if we want to mirror on GitHub, we need to have an active presence there. I don't know what that would mean. I don't see how your second paragraph follows from your first (and the cabal bit is just confusing). I believe that the most important consideration is whether github will attract more contributors to the project, and if so, whether the benefit of such will be worth working with a non-free UI. Would it be fair to say you acknowledge that it will attract more contributors (random[1] forks and patches) but on balance think it will not be worth the non-free UI? I'd quite like to have pull requests that I can ignore (or format into a patch to merge)... John [1] s/random/GNOME/ (that is the point remember. we currently have random forks there) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, Aug 7, 2012 at 1:30 PM, John Stowers john.stowers.li...@gmail.com wrote: Disadvantages * Maintainers might see this is mandating them change their workflow. I emphasize that github should be only a mirror, interaction and merging should occur first on git.gnome.org This is a killer. There would just be forks of random GitHub repositories with patches, and people submitting pull requests, that are as effective as /dev/null. Slashdot writes that we're mirroring on GNOME, and the designers are the cabal again. if we want to mirror on GitHub, we need to have an active presence there. I don't know what that would mean. I don't see how your second paragraph follows from your first (and the cabal bit is just confusing). I'm just saying that we need maintainers to manually look at GitHub every once in a while for pull requests, and file a bug upstream or merge into the repo or something. Maintainers are already overworked, so I doubt they're going to do that. The other alternative is telling everyone that files a pull request this is not the appropriate mechanism for contributing back upstream, even politely, is a turn-off. Are they going to make the effort to register at Bugzilla and learn how to use git-bz? I don't think so. I believe that the most important consideration is whether github will attract more contributors to the project, and if so, whether the benefit of such will be worth working with a non-free UI. Would it be fair to say you acknowledge that it will attract more contributors (random[1] forks and patches) but on balance think it will not be worth the non-free UI? But will the contributors forks and patches be respected? If we don't make an effort to upstream contributions from GitHub (which is manual effort), their time is wasted, and all we've done is put up a trap for potential contributors to fall into, where what they should have done was to file a bug and patch upstream. It also means that we're maintaining two separate infrastructures -- one on git.gnome.org, and one on GitHub. Fragmentation is never good. I'd quite like to have pull requests that I can ignore (or format into a patch to merge)... John [1] s/random/GNOME/ (that is the point remember. we currently have random forks there) -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
2012/8/7 Jasper St. Pierre jstpie...@mecheye.net: The other alternative is telling everyone that files a pull request this is not the appropriate mechanism for contributing back upstream, even politely, is a turn-off. Are they going to make the effort to register at Bugzilla and learn how to use git-bz? I don't think so. Or you could make GitHub the preferred way to contact devs of some modules and keep the GNOME git as an auto-sync'd mirror. The question is whether the freedom is more important than productivity of course. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
I'm just saying that we need maintainers to manually look at GitHub every once in a while for pull requests, and file a bug upstream or merge into the repo or something. Maintainers are already overworked, so I doubt they're going to do that. See at end. The other alternative is telling everyone that files a pull request this is not the appropriate mechanism for contributing back upstream, This is Linus's position. I don't see it as a problem (although I would replace 'appropriate' with 'preferred'). even politely, is a turn-off. Are they going to make the effort to register at Bugzilla and learn how to use git-bz? I don't think so. Probably not - that is my premise; they are using github because they don't like/know the bz+git-bz workflow. Would such a hypothetical contributor have bothered giving me the laborious opportunity to reject his contribution if I had asked him to go through bz first anyway? If a contributor already has a github account, and a local git branch, I can't honestly say that the most efficient way for him to contact me is to install git-bz, magic it, set up a bz account, and magic the diff into bugzilla. The magic is technically cool, I love git-bz, but we are too inside the bubble to see that this is fcrazy for a moderate newcomer (hello GSOC/GWOP)! But will the contributors forks and patches be respected? If we don't make an effort to upstream contributions from GitHub (which is manual effort), their time is wasted, and all we've done is put up a trap for potential contributors to fall into, where what they should have done was to file a bug and patch upstream. I guess I replied above to this. It also means that we're maintaining two separate infrastructures -- one on git.gnome.org, and one on GitHub. Fragmentation is never good. Well Alberto can chime in here, but this should be automatic. We have the metadata to route the branch/pull request mails to maintainers via the doap files anyway. We already have fragmentation on github, but because we are not a canonical upstream there we cannot see the fragmentation via the github network view. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, Aug 7, 2012 at 1:51 PM, John Stowers john.stow...@gmail.com wrote: Would such a hypothetical contributor have bothered giving me the laborious opportunity to reject his contribution if I had asked him to go through bz first anyway? If a contributor already has a github account, and a local git branch, I can't honestly say that the most efficient way for him to contact me is to install git-bz, magic it, set up a bz account, and magic the diff into bugzilla. The magic is technically cool, I love git-bz, but we are too inside the bubble to see that this is fcrazy for a moderate newcomer (hello GSOC/GWOP)! One of the modules that I develop (gnome-shell) has very strict code review policies. If we want a paper trail of reviews, the typical thing to do is to link to a Bugzilla bug in the commit message, which has patch review comments. How does that fit into our GitHub flow? Do I review a pull request, and link to it in the commit message? Again, that means that our workflow now depends on GitHub. John -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
One of the modules that I develop (gnome-shell) has very strict code review policies. If we want a paper trail of reviews, the typical thing to do is to link to a Bugzilla bug in the commit message, which has patch review comments. How does that fit into our GitHub flow? Do I review a pull request, and link to it in the commit message? Again, that means that our workflow now depends on GitHub. Maintainers are free to reject contributions if they are improperly made for the project. Having a github mirror does not take away their ability to do that (c.f. the Kernel model and forks on github). Similarly, not all projects have the code review policies of gnome-shell; I fear by thinking this is the case was we will cut of our nose to spite our face, as they say. Github is already a wild west of GNOME technology forks, and I believe having an official presence there would allow us to take advantage of those forks and to reduce fragmentation. Beyond making things less messy than they are now, Github has its own advantages too, as I mentioned (code search across all projects, etc). Anyway, I think that is my case made now. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, Aug 7, 2012 at 2:29 PM, John Stowers john.stowers.li...@gmail.com wrote: Maintainers are free to reject contributions if they are improperly made for the project. Having a github mirror does not take away their ability to do that (c.f. the Kernel model and forks on github). Similarly, not all projects have the code review policies of gnome-shell; I fear by thinking this is the case was we will cut of our nose to spite our face, as they say. Github is already a wild west of GNOME technology forks, and I believe having an official presence there would allow us to take advantage of those forks and to reduce fragmentation. Beyond making things less messy than they are now, Github has its own advantages too, as I mentioned (code search across all projects, etc). I love GitHub, and I agree with its advantages, but I think that if we don't make a coordinated effort to respect the GitHub community, it's a big issue for us. As I said, in the best case scenario we move infrastructure to GitHub entirely, and embrace it. But giving already-overloaded maintainers more places to check for code contributions is not really the best strategy, here. Anyway, I'd be fine if we made an official mirror. I'd certainly accept pull requests for the modules that I own. I just want to be cautious here about our strategy here, though. It only takes one guy with an ignored pull request and a Slashdot account to promote the myth of the GNOME cabal. Anyway, I think that is my case made now. John -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, 2012-08-07 at 14:38 -0300, Jasper St. Pierre wrote: On Tue, Aug 7, 2012 at 2:29 PM, John Stowers john.stowers.li...@gmail.com wrote: Maintainers are free to reject contributions if they are improperly made for the project. Having a github mirror does not take away their ability to do that (c.f. the Kernel model and forks on github). Similarly, not all projects have the code review policies of gnome-shell; I fear by thinking this is the case was we will cut of our nose to spite our face, as they say. Github is already a wild west of GNOME technology forks, and I believe having an official presence there would allow us to take advantage of those forks and to reduce fragmentation. Beyond making things less messy than they are now, Github has its own advantages too, as I mentioned (code search across all projects, etc). I love GitHub, and I agree with its advantages, but I think that if we don't make a coordinated effort to respect the GitHub community, it's a big issue for us. As I said, in the best case scenario we move infrastructure to GitHub entirely, and embrace it. But giving already-overloaded maintainers more places to check for code contributions is not really the best strategy, here. GitHub does have an API [1]. It should be possible to periodically check for pull requests on GitHub and automatically file corresponding bugs. I'm not volunteering, just saying it should be possible. Anyway, I'd be fine if we made an official mirror. I'd certainly accept pull requests for the modules that I own. I just want to be cautious here about our strategy here, though. It only takes one guy with an ignored pull request and a Slashdot account to promote the myth of the GNOME cabal. To be fair, the same applies to Bugzilla. It only takes one guy with an ignored bug report and a Slashdot account to promote the myth of the GNOME cabal. -Evan [1] http://developer.github.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Patryk Zawadzki pat...@pld-linux.org a écrit: The question is whether the freedom is more important than productivity of course. I'd rather keep the Freedom, and encourage people to work on improving the productivity in the realm of that freedom we fought so hard to get. I mean, we could imagine asking the board to help us support a Please Host a GNOME initiative, inviting people to donate to support gitorious or, if their infrastructure doesn't have a good enough availability track record, help to build up gitorious instances on our own servers. Of course, doing something like that would be less convenient than just going to github, but that is the high road that I figure the great GNOME community I care about would take. Until now, we have striven to make the right choices, not necessarily the easy ones. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
On Tue, Aug 7, 2012 at 5:12 PM, Dodji Seketeli do...@seketeli.org wrote: Patryk Zawadzki pat...@pld-linux.org a écrit: The question is whether the freedom is more important than productivity of course. I'd rather keep the Freedom, and encourage people to work on improving the productivity in the realm of that freedom we fought so hard to get. I mean, we could imagine asking the board to help us support a Please Host a GNOME initiative, inviting people to donate to support gitorious or, if their infrastructure doesn't have a good enough availability track record, help to build up gitorious instances on our own servers. Of course, doing something like that would be less convenient than just going to github, but that is the high road that I figure the great GNOME community I care about would take. Until now, we have striven to make the right choices, not necessarily the easy ones. I don't care about gitorious. Even if we went out and bought a GitHub Enterprise copy, and had github.gnome.org, that wouldn't solve any of the complaints that John Stowers was talking about. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
Just my opinion, as someone who follows gnome development and has a github account. I would highly welcome this too. And I definitely prefer Github to gitorious. On 07/08/12 17:40, Alberto Ruiz wrote: Hello Johannes, a mirror in github will not stop anyone from doing a mirror in gitorious as well. But as it turns out, there is a huge community of developers in github (way bigger than gitorious') that we can outreach if we have an official mirror there. 2012/8/7 Johannes Schmid j...@jsschmid.de mailto:j...@jsschmid.de Hey John! I would prefer to have a gitorious instance setup on the GNOME servers as has been previously discussed. Basically someone would need to do the job. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org mailto:desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Boston Summit 2012
Hi, At GUADEC, it was announced that the Boston Summit 2012 is on! More information is available here: https://live.gnome.org/Boston2012 Please do fill in the attendance list so we can somewhat accurately gauge required refreshment quantity, etc. There's a lot of topics to discuss, and I hope we can continue some of the momentum from the awesome GUADEC that just finished! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mirroring GNOME on github
- Mensaje original - De: Dodji Seketeli do...@seketeli.org Para: desktop-devel-list desktop-devel-list@gnome.org CC: Enviado: Martes 7 de agosto de 2012 22:12 Asunto: Re: Mirroring GNOME on github Patryk Zawadzki pat...@pld-linux.org a écrit: The question is whether the freedom is more important than productivity of course. I'd rather keep the Freedom, and encourage people to work on improving the productivity in the realm of that freedom we fought so hard to get. I mean, we could imagine asking the board to help us support a Please Host a GNOME initiative, inviting people to donate to support gitorious or, if their infrastructure doesn't have a good enough availability track record, help to build up gitorious instances on our own servers. Of course, doing something like that would be less convenient than just going to github, but that is the high road that I figure the great GNOME community I care about would take. Until now, we have striven to make the right choices, not necessarily the easy ones. I agree with Dodji that we should keep freedom values and not use privative software in our workflow. Of course, I think individuals can use it if they please, but I don't think is a good idea embrace github as a project. Cheers, -- Juanjo Marin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Saving App State
I wanted to start a discussion about how GNOME and friends use saved state. Currently, applications tend to stuff bits of saved state (like window position, which tabs are open, etc.) in gsettings, because it is convenient. But that puts the state in ~/.config instead of ~/.cache and I believe is discouraged for other reasons(?). Regardless, gsettings is a nice API for storing the same kind of data that state-saving would use. Is a similar API for state on any roadmaps? If we were able to funnel all state-saving through the same API and into the same store, we could potentially do some neat things with it like syncing the state between devices. And along with a single API, we could provide some guidelines (like maybe instead of having every app save its x,y position, just let the shell save that state). This isn't necessarily a call for full session saving again. But at least letting what applications are already doing, do it in a recommended way. (Though regarding session saving, apparently Mac OS Lion recently added Resume which is basically desktop-wide saved state.) -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
A few missing 3.5.5 releases
There are a number of modules which haven't had a 3.5.5 release yet, and should probably get one: gnome-control-center gnome-settings-daemon gnome-bluetooth gnome-icon-theme gnome-icon-theme-symbolic A few others have had migrations (gtkapplication, gsettings, gdbus) completed, and could probably celebrate that with a release as well: sushi gnome-search-tool Let me know if you need release team assistance in doing releases. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libxml2 commit 65c7d3b2e6506283eecd19a23dcf0122fbcdac33
Hi,
On Mon, Aug 6, 2012 at 3:05 AM, Daniel Veillard veill...@redhat.com wrote:
mistake done circa 98-99 IIRC and a bit late to fix ... The problem are
that those buffers were using int instead of size_t for various size
leading to a variety of troubles including security ones. How to fix
that while keeping everything pblic API and ABI compatible ?
One idea (if you're sure consumers are just reading the public
structure and not allocating/writing to it):
struct xmlExtendedBuffer {
xmlBuffer compatBuffer;
size_t realSize;
}
Then when allocating e.g., an output buffer:
outputBuffer-buffer = extendedBuffer-compatBuffer;
and any time you need to get at the extended buffer do:
extendedBuffer = (xmExtendedBufferPtr) outputBuffer-buffer;
Any time you need to adjust the size of the buffer, adjust
extendedBuffer-realSize, and then do
extendedBuffer-compatBuffer.size = (int) extendedBuffer-realSize;
Though, sizeof(size_t) == sizeof(int) on 32-bit arches so i'm a little
unsure how swapping one for the other could fix overflow problems.
--Ray
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
