Re: Offtopic: Git workflow with external repository and git.gnome.org
Hi, to add to what Germán said, the key point is that one local repository can have several branches, and each of this branches can have a different upstream repository. So you would clone bugzilla's git repo. Then, in a different branch (say, gnome-integration) you would apply your patches, then you set a new git repository on git.gnome.org and push the gnome-integration branch into it, and that's more or less it. That would get you two branches (one for vanilla bugzilla , one for gnome bugzilla) that are attached to two different remote repositories. Hope it helps On Tue, Apr 15, 2014 at 7:51 PM, Germán Poo-Caamaño wrote: > On Tue, 2014-04-15 at 17:29 +0200, Olav Vitters wrote: > > [...] > > Is there any recommended workflow people are using in the following > > situation: > > - be able to commit changes in a self hosted Bugzilla repository > > - use that self hosted Bugzilla repository for own installation (easy) > > - be able to merge changes from git.mozilla.org > > - be able to move from 4.2 branch to 4.4 branch, etc > > - be able to see the difference between local and "pristine upstream" > > - how to set all of this up initially? > > Any recommended workflow to follow? > > > > I'm pretty much an idiot with git. I've found various guides, just > > wondering what people use in practice. > > Hi Olav, > > I think it depends on how many changes are you going to apply on top of > them. FWIW, in a similar use case I've used a workflow based on > http://nvie.com/posts/a-successful-git-branching-model/ > > Though, instead of master I've used a branch named 'stable'. > > If you had 2 branches, stable and development. I would "merge" first in > development, fix anything needed to be fixed, run all tests, once happy, > merge development in stable. > > You might want to consider rebase instead of a regular merge. So, you > will always see clearly what is on top of upstream (I mean visually, > with a tool like gitg). > > In this case, I am assuming you would apply changes for 4.4, like 4.4.1, > 4.4.2, and so on. > > I have not written the commands because in the link you will find many > examples with diagrams. I would go for something simpler, but you will > get the idea. Nevertheless, I can get into the details if you need to. > > -- > Germán Poo-Caamaño > http://calcifer.org/ > > ___ > 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
Re: Preserved Window Placement
Hi, On Fri, Oct 26, 2012 at 4:07 PM, Havoc Pennington wrote: > On Wed, Oct 24, 2012 at 2:27 PM, Federico Mena Quintero < > feder...@gnome.org> wrote: > >> >> Disclaimer/introduction: In the past I've said that saving window >> geometries is the job of the window manager and shouldn't be done by >> applications. THIS IS WRONG. I retract myself. Applications should be >> responsible for saving their own window geometries. > > > > YES. Federico has it right. Apps: implement it please. ;-) > > Fwiw, one app implementing this is Evince, where each window has a unique URI associated (the file being viewed) and the app state is then saved using Gvfs metadata. Of course, here we have the chance of the easy association between windows and URIs, so the big problems described in this thread don't appear ;) Greets, José ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v6)
Hi, On Tue, Oct 18, 2011 at 1:51 PM, Olav Vitters wrote: > On Tue, Oct 18, 2011 at 05:15:37PM +0100, Sergey Udaltsov wrote: >> Provocative question: is there any way that some unbiased survey would >> change the emphasis of development from gnome-shell to the fallback mode? >> And increase the configurability and so on.. Or - the current strategy is >> unchangeable (unfalsifiable), regardless? > > See the release notes of 3.2. Feedback is used. > > Note: I care about feedback, not about surveys. That is just one > of many ways to get feedback. I think that has been discussed to death > already. > > Regarding fallback: > At the moment, it seems almost noone is using fallback mode. As such, I > don't think the current efforts made into fallback more will continue > for too long. Usage seems to be minimal. But not a lot of distributions > have GNOME 3 yet, so it is also a bit early to tell. > -- The latest version of Ubuntu (11.10 I guess) allows you to choose between Unity, Gnome Shell and Gnome Classic, which is, up to what I have seen (i dont use ubuntu but a friend of mine does) Gnome 3 with fallback mode on, so we might get some more people using it. Regards, José > Regards, > Olav > ___ > 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: GNOME user survey 2011 (v2)
On Mon, Aug 1, 2011 at 11:35 AM, Felipe Contreras < felipe.contre...@gmail.com> wrote: > Hi, > > After going through all the feedback, here's the second version of the > proposed survey. > > There is a proposal to delay the survey until 3.2 is released, to try > to avoid some of the initial negative feedback of 3.0, I guess. If > this is delayed for 3.2, perhaps there could be a small piece of > software that pops up a notification for this, and perhaps some > notifications in the future. > > What do you think? > > > > === 06. Does GNOME do what you want? === > (single choice) > > I would probably rephrase this to "Can you accomplish all you want with GNOME?" and add a text for the user to explain why? besides the single choice options. > === 09. How often do you use terminal/console? == > > * What is that? > * When I have no other option > * I can't leave without them > I asume you mean "I can't live without them" Greetings ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Feature Request
Hi, Please see comments inline. 2011/5/8 Erick Pérez : > On 08/05/2011, Jasper St. Pierre wrote: >> 2011/5/8 Erick Pérez >> >>> > Why not at the time of the menu? >>> Cause it will be to slow, way to slow. Making choices based on the >>> data you think we should send to the service will be slow, any >>> decision at all will take to long for a responsive UX to act. >>> >> >> What makes you think that? Profile it and then make decisions. Don't degrade >> the experience a user has because it could possibly be "too slow". > Fair, enough, anyway what's make think like my programming experience. > >> >>> > I'd rather see "No definitions" inline in the menu than having a new >>> popup window tell me the new thing. >>> No one is talking about new popup windows. That's a pretty rushed >>> thought for something is still an idea, and, it's up to the app >>> developer how they will handle the data and the interaction with the >>> service, so It's kinda naive to assume you will have popup windows >>> informing you of the results of anything. >>> >> >> If the app developer already has to implement a UI for a dictionary result, >> then why don't they just call gnome-dictionary directly? > > No one says that. You just assumed it that way. > >> > You said that you didn't want a daemon started, so we can't use D-Bus in >>> that case, unless we use D-Bus autostart, but I don't see the value in >>> that >>> either. >>> You miss-understood me, when I said I didn't want a daemon, I was >>> talking about a daemon of each application registered. In the first >>> email I said that D-Bus should provide the infrastructure for the >>> service/module >>> >> >> A D-Bus daemon needs to be running for you to be able to call it. D-Bus can >> start the daemon for you if it isn't started or it crashes, but the daemon >> needs to keep running. > > You keep miss-understanding, when I talk about daemon, I meant, I > didn't want a dictionary daemon, and a daemon for every app publishing > actions/services, course it has to be a daemon for the apps to query > it, and to answer back > >> Now the hard part: >>> > The only tangible idea I can extract out of this is querying a service >>> with something akin to a mimetype, and getting a list of programs that can >>> handle it. I query the service with SEMANTIC_WORD, and I get >>> "/usr/bin/gnome-dictionary-lookup-word %s" back. >>> That's more or less the whole point of it. With SEMANTIC_WORD would >>> return gnome-dictionary, and some others too, and even more than not >>> regular gnome-dictionary, but gnome-dictionary called in a way that >>> the app show just a small overlay with the definition, and nothing >>> else >>> >> >> If they have to implement a UI for every result that could be possibly >> returned, they can only implement a certain number of actions... so the >> middleman aggregator that you're suggesting is useless. Every time you add a >> UI, you add support for the tool. > I don't see how this is an answer to what I said before > >> >>> > ... and I still can't see how you would build jumplists out of this >>> Ohh, that so easy, the jump list are composed of two main things, >>> recent files opened with that app, and sub-actions other than the main >>> purpose of the app. Well the for recent files part there's already >>> zeitgeist for that, but for a list of sub-actions of every app that >>> allow it, then you can query the service I'm proposing. Because you >>> should already know by now that querying the service about a specific >>> action is not the only way of interacting with it. >>> >> >> We already have a way to find the programs that have the ability to open a >> file. It's been around for a long time now, too, and even works with KDE: >> >> http://portland.freedesktop.org/xdg-utils-1.0/xdg-mime.html >> >> This is what nautilus talks to with its "Open With" dialog, for instance. > Yeah, already know that, but xdg-open still handles just files based > on a mime-type. I'm thinking more generally. > >>> There might be an inch of value in that idea, but I don't see it. >>> > I don't see the value in this service >>> Hopefully, you're not the main man behind Gnome. >> >> I'm not. I don't even know who the main man is, or even if there is one. >> >>> Gnome Desktop >>> actually needs integration/communication between applications, to >>> start looking as whole, like is already doing with the system settings >>> trying to provide a niche for a bunch of somewhat different settings, >>> and the way to provide that is centralizing communications and >>> interactions, acting as a middle man between desktop apps. >>> >> >> Of course gnome desktop would be better if it had integration. It would be >> excellent if everything "just worked", but like any other timely, shipped >> system, there are warts. GNOME 3.0 certainly isn't as "integrated" as we >> would have liked it to be, but we have a schedule, we have time constraints, >> and we have manpower constraints. If we had infinite t
Re: 3.2: gjs/seed
Hi, On Thu, Apr 21, 2011 at 1:12 AM, Colin Walters wrote: > Hi, > > So speaking as someone who was motivated to make writing GNOME apps > easier, I'm not very happy with how things turned out with the mix of > gjs/seed/python/introspection/gtk3. > > In this mail I just want to focus on the gjs/seed situation. Before > 3.0 we chose to use gjs for gnome-shell for a variety of reasons: > > 1) gjs existed > 2) seed didn't > 3) Litl contributed a number of engineers to gjs > 4) While I know some GNOME contributors here don't like Mozilla, in > the big picture their mission and culture is *MUCH* more aligned with > ours than Apple, at least > 5) The Spidermonkey-specific JavaScript extensions like "const" and > "let" were useful and cool > 6) Many GNOME consumers actually ship Firefox and not Epiphany, and so > we were technically aligned on that end (yes, this is the "GNOME is a > bucket of parts" mindset, which I would really like to fix, but that's > a separate issue) > > But let me cut to the chase and say that I think we'd at least > consider realigning on seed for 3.2 for gnome-shell (and by extension, > mark gjs as deprecated at least in GNOME). > > There are, however, nontrivial issues. First is that actually in good > news on the gjs front, a standalone Spidermonkey release was just made > recently, and I have a patch ready to use it in gjs: > https://bugzilla.gnome.org/show_bug.cgi?id=646369 > In contrast though, /usr/bin/seed appears to actually link to WebKit, > which would be a painful dependency to have for gnome-shell, since > it'd be insane to try using it inside the compositor process. This > may (hopefully) be fixable. > > Even tougher would be unwinding the Spidermonkey let/const and > generator usage inside gnome-shell, but we dug the hole, we can dig it > out. > > That covers reasons 1,2 and 5. As far as reason 3), they're not as > active anymore (probably gjs basically works for them), and for 6) I > think we need to change this anyways. This leaves reason 4) which I > admit is just a feeling. > > So - seed/gjs contributors - what do you think? >From my personal (developer using seed) point of view, I think the important point is to have one blessed javascript-gi glue. I am using Seed to add Javascript support to Evince, so it would be good to know that Seed is going to be revamped or deprecated so I can use gjs instead. > > One thing I'm not totally happy with is the organic growth in API in > both seed and gjs. seed for example added an "os" module with e.g. > "fork" which I think is totally wrong; it's just broken to fork() a > GNOME app, since it conflicts with threads, etc. If we're going to do > some unification, we should also prune a lot of cruft. If there are > bits missing from GNOME (like GIO is really missing both Console and > Process classes), we need to add them. > > == Dynamic Languages in GNOME == > > One thing that's worth addressing though (again) is the question "do > we need both Python and JavaScript?". The uptake of both seed and gjs > has been relatively low; lower than Python at least for scripting > GNOME apps. However, I think at least one the core reason for working > on JavaScript remains that *we define the platform*. Python comes > with a vast API, a lot of it really old and crufty, but even more > importantly, large parts of it are *wrong* to use in GNOME. > > For example, we don't want people to use Python's mostly-POSIX-like > wrappers for IO, we want people to use GIO, so it doesn't block the > mainloop. We don't want people to use Python's "webbrowser" module, > its "multiprocessing" module (which totally breaks things like X and > DBus since it uses a bare fork()), etc. I understand your point, but I don't think this implies that we don't (at least for me) python. What we really need IMO is good documentation on how to write good Python Gnome Apps, by pointing out the recommendations, like, use GIO instead of python IO, etc. The dev is free to mix code in weird ways, no? > > On the other side of the coin though, I think we largely failed to > make JavaScript a compelling way to write apps. The language is only > a part of the question, and it's really not a large one. We need to > focus more on a build/deploy story, and less on /usr/bin/gjs. By > "build" I mean we really shouldn't be leaving it up to app authors to > figure out how to use Automake with gjs/seed and to do > "imports.gi.Gtk". Deploy is another story. > > The other reasons: > * ecosystem: The industry adoption is reflected in all the work that > goes into JIT compilers, as well as people simply learning the > language > * Better engine internals - the global interpreter lock in cPython > really hurts it as far as a future in a multicore world > > (No, unlike what you've read in some parts of the internets, a reason > to add JavaScript wasn't to attract "web developers" explicitly; but > they are part of the industry) > _
