gmane.comp.gnome.desktop

Re: new module proposal: notification-daemon+libnotify

Christian Hammond — 2008-12-04T23:13:50

_______________________________________________ desktop-devel-list mailing list desktop-devel-list< at >gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: DVCS

Patryk Zawadzki — 2008-12-04T22:36:33

Should you need any help (now or in the future), I'm a webdev for living. My main interest is Python/Django but I've spent 9 years working with PHP. Feel free to yell if in need (my company donates some of my office time to GNOME hacking anyway).

Re: DVCS

Zeeshan Ali (Khattak — 2008-12-04T22:29:45

Cool! I thought the whole thing got forgotten. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124

Re: DVCS

Zeeshan Ali (Khattak — 2008-12-04T22:19:26

Hi! On Tue, Nov 18, 2008 at 1:04 AM, Vincent Untz gnome.org> wrote: So you already on it or you are waiting for someone to get you th list of svn accounts? If latter is the case, It's pretty easily doable using git but unfortunately the dates in the git repos created through git-svn aren't correct (or it seems to be the case). I am no expert in svn but reading the output of `svn help log` i don't see it be done easily using svn. :(

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Max Kanat-Alexander — 2008-12-04T21:28:49

Hey folks. I'm Max, from the Bugzilla Project. I also have a company called Everything Solved, and we'd be the ones doing the upgrade work if it happens. The fact of who *I* am (Everything Solved) is not confidential at the moment. Only the funder's identity is confidential until we decide whether or not we're actually going ahead. Anyhow, I've read through the thread and here's my feedback: All the attachment status stuff will still be there. The fact that they *show up* in the attachment table will probably even be there. They haven't ever been *changeable* from show_bug.cgi, as far as I could see in the code. Instead of the patch emblem, would they rather just have a "patches" column in the buglist output that shows the names of patches and the current attachment status on them? We wrote some code for bugzilla.mozilla.org that does something similar, it wouldn't be hard to bring it over. (It would still be a Phase 2 item.) It looks like this on bugzilla.mozilla.org: http://tinyurl.com/5naa43

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Cosimo Cecchi — 2008-12-04T20:22:20

Right, but I don't think there's an intermediate solution between resolving the crash trace symbols locally with a debugger and saving a minidump and let an external process gather the symbols afterwards. In the former case, you can either get incomplete information (if you lack debug some symbols locally) or a good trace, while in the latter (please correct me if I'm wrong) you either get a perfect trace or the minidump is completely useless. I suppose distributors themselves are interested in fixing crashers (I'd go as far as saying the casual user would rather blame the distribution instead of upstream if something crashes!) and, at least the bigger ones, usually have people paid to take care to some degree of them, so I wouldn't worry too much about this. P.S: sorry if this is off-topic. Cheers, Cosimo

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Luis Villa — 2008-12-04T19:21:24

You don't need full symbols for crash information to be useful. It certainly helps, but we shouldn't let the perfect be the enemy of the good there. The crash information is (well, should be) the most important bug-related information GNOME has. Relying on the judgment of others to handle them should only be a last resort used if we're absolutely incapable of handling it ourselves. Luis

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Cosimo Cecchi — 2008-12-04T19:17:37

I haven't tried that kind of programs, but I think that any solution for reviewing patches has to be tightly tied to bugzilla itself (and I personally quite like the current solution, though I understand it's not very handy for big changes with many diffs), as that seems an easy way to me to attract users to jump in and contribute a patch. Technically, bug-buddy is already capable of creating minidumps and push them to a crash.gnome.org server, and this would be great indeed, but AFAICT it requires a lot of coordination between us and distributions to provide: - a way for distributors to automatically push debug information to a centralized server for every package/update. - an unified way to get the version of a package, as distributors often ship two or more updates for the same upstream version. To be honest, I like more the way Ubuntu handles this, i.e. has its own crash server and pushes upstream only the good/unique traces. Cheers, Cosimo

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Cosimo Cecchi — 2008-12-04T19:04:44

Well, then we should make sure that at least the most necessary features are there since the beginning, or will be missing for the least time possible (i.e. not more than 2-3 weeks). If, once decided which are the priorities, that's granted, you have a big +1 from me. Cheers, Cosimo

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Matthias Clasen — 2008-12-04T18:42:45

Patch review status and patch emblems and their interaction with product pages are essential for my ability to manage GLib and GTK+. Getting those back as soon as possible would be important. And while we are at it, maybe patch emblems can be improved to show the patch review status ? That would be awesome.

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Germán Póo-Caamaño — 2008-12-04T18:36:37

_______________________________________________ desktop-devel-list mailing list desktop-devel-list< at >gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Olav Vitters — 2008-12-04T18:18:05

Yeah, but I need to know: * what priority should the missing stuff get (to determine order of work) * what is critical (e.g. affects GNOME release if missing for more than at most 4 weeks) Missing functionality ok, causing 2.26 to suck is not.

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Vincent Untz — 2008-12-04T17:59:42

Le jeudi 04 décembre 2008, à 12:56 -0500, Colin Walters a écrit : We had crash.gnome.org (seems to not be working anymore?). The issue with it is that nobody did the last few steps to make it really work with our current infrastructure. Vincent

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Colin Walters — 2008-12-04T17:56:28

Maybe time to investigate Review Board or the like? Suggest we move crashes out of Bugzilla and into a separate database (like Socorro). Bugzilla should only be for hand-written input from technical people.

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Olav Vitters — 2008-12-04T17:46:33

Development should be done in the open. The only thing is that it should be done as cleanly as possible and I don't want any new features compared to current bgo. Stuff that isn't part of the upgrade is changing the layout to match GNOME. I said I'd (someone;) do that instead IIRC.

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Vincent Untz — 2008-12-04T17:42:36

Le jeudi 04 décembre 2008, à 17:00 +0100, Olav Vitters a écrit : The current situation is a dead-end, so I'm all for moving, even if we lose some stuff. We'll eventually reimplement stuff that is important to us, and hopefully, we'll be able to do it in a more upstream-friendly way so that we can push stuff upstream and have upstream accept the stuff. Would be bad to go in the same dead-end again ;-) (it's a bit like when we ask our downstream to do their changes upstream; we should do the same) Vincent

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Andre Klapper — 2008-12-04T17:19:46

As long as stock answers and simple-dup-finder functionality get a high priority so they will be provided again asap, this all sounds totally fine to me. Looking forward to get most of GNOME's beautiful modifications upstreamed. andre

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Frederic Peters — 2008-12-04T17:14:04

Olav Vitters cited: Are the features I find important in my usage of our Bugzilla. Do you know what kind of collaboration work will be possible ? For example I reproduced most of the show_bug.cgi UI re-ordering (that mattered to me) for a private Bugzilla; changes that are kept to templates are hopefully within my reach. Frederic

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Behdad Esfahbod — 2008-12-04T17:03:35

Sounds crazy, but, has anyone every considered using a dedicated search engine instead of MySQL's fulltext search? I'm thinking about Lucene. I have used it for one of my projects for years and have been really happy about it. Recently I switched over from Java Lucene to PHP Lucene which is supported and included in the Zend Framework and have become much happier. If there's interest, I can work on a prototype. All I'd need is a dump of the database. behdad

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Luis Villa — 2008-12-04T16:57:12

Oh, I'm fully aware that getting our current full set of patches upstream would be hard; they were a nightmare years ago, and our feature set and the pace of upstream's development and refactoring work have only accelerated since then. I meant more for new features we might develop after moving to 3.2- what steps will we take to make sure that we don't end up yet again with a gigantic mess of unmaintainable and/or non-upstreamable patches? Ewww. I had assumed that they moved primarily to Hg when the rest of mozilla did. Perhaps this is a good time to lobby them to move to a DVCS. Right. Again, the problems 2.20->3.2 are unsolvable and the result of lots of (ugly) history, much of it my fault. I'm not asking for miracles there. (Miracles would be nice! ;) The question is how do we avoid it in the future- hopefully part of the plan is 'do the next upgrade from 3.2->3.4 instead of 3.2->4.20' :) but I imagine other steps could possibly be taken as well. Luis

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

Olav Vitters — 2008-12-04T16:54:54

Normally you first click 'Edit' or 'Details' in the table with the patches to change the status. On GNOME bugzilla you can do that from show_bug.cgi which IMO is 10x better UI. I understood it as: * initially: change status in e.g. http://bugzilla.gnome.org/attachment.cgi?id=36779&action=edit * eventually: show_bug.cgi (great) or attachment.cgi (sucks) I'll try and verify, but it wouldn't be acceptable to have a Bz without a patch status.