Re: GNOME Panel maintainers
The classical GNOME mode has a lot of users and fans. Please GNOME leadership be open minded and let the community members who wants to enhance it do their work. GNOME Flashback's successes are GNOME's successes. When people join the bazaar, you don't build a cathedral in a bazaar. On Mon, Sep 8, 2014 at 11:48 AM, Alberts Muktupāvels alberts.muktupav...@gmail.com wrote: Hi, On Mon, Sep 8, 2014 at 4:10 PM, Emmanuele Bassi eba...@gmail.com wrote: hi; On 8 September 2014 12:33, Alberts Muktupāvels alberts.muktupav...@gmail.com wrote: I need some help and/or suggestion on how to take over gnome-panel maintaining. that's not how it works. I strongly suggest you discuss it with him, calmly, and productively, in order to amicably solve this issue. Does not look that it is possible otherwise I would not write this mail. if nothing happens, you can create a clone of the gnome-panel repository somewhere else, and convince others that your work is the actual upstream. I'd strongly advise against this solution. I don't think it would be good solution. Philipp does not want that I am taking over maintainership of gnome-panel. Problem is that he is not maintaining it and does not want that I do it... after reading the various threads it seems that he has concerns on the quality of your contributions; have you tried improving them so that his concerns will not be relevant any more? it also seems that he rolled back your commits and instead moved them to topic branches for ease of review and development. He is only one who find problems with my contributions. Rolled back for what? First master was tested by separate users/distribution maintainers and it was reported that it works - works better than last release. At that time it was 3.8.0. Rolling back he lost at least one commit which is not available in topic branches nor in master. For ease of review? There is no one else who is going to review it. Was not it easier to look at code and if he finds something bad ask me to fix it rather than rolling back, creating new branches? For example he accepted GtkTable to GtkGrid changes in .ui files by other dev, but did not accept my commit that do some thing in code. I don't see any reason for this. Can you name any? He is author of 16 commits. And at least half is not related to any fixes, just updating news, version bump, adding himself to maintainers. release management is a huge part of what maintainer means, alongside code review, and integration of third party contributions. I agree on this. But to make new release you need something new/improved/fixed... Is not that maintainers job too? He is just asking and mostly waiting until someone else will write patches, will review them. As I said he is not doing anything. Almost all work in last release is my work. So if I would not do anything how could he make new release? GNOME Panel is part of unofficial GNOME Flashback session (metacity, gnome-panel, gnome-applets). I am already maintaining gnome-applets, metacity. Also I have created new module that is very important part of Flashback session. Flashback is not really sanctioned by GNOME in any way, so the GNOME community can at most suggest ways of solving this issue amicably. It is not official part of GNOME, but still GNOME. Currently we speak about gnome-panel and there was time when gnome-panel was part of official GNOME session. What about maintainers that used to maintain gnome-panel while it was official part? Can not they help? Also I asked who approved him as maintainer. Till now he has not responded. Also I did not find any public discussions about it. So there is possibility that he simply took over maintaining. Mailing list subscribers is on my side. development and maintainership are not popularity contests. Of course. It was not meant that way. I tried to say that basically Philipp is not happy with my work, but everyone else on mailing-list is not happy with his work. For example there was user who reported bug about broken EDS in clock applet. He just responded that it is working asking to do more testing, he even wrote that he tested. He was wrong. I found problem, I fixed it, I sent patches to mailing list. Did he even look at them? No. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2014 民國103年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+3/Win32 : looking for help
My wife uses GIMP on windows, if you want a random sample. Yes, saves all the money that would go to Adobe. On Fri, Jun 6, 2014 at 3:24 PM, C. Thomas Stover c...@thomasstover.com wrote: On Fri, 06 Jun 2014 23:37:37 +0200, Alberto Ruiz wrote: Do you have any idea how many people save hunderds of dollars by having GIMP and Inkscape available on Windows? No, that's why I asked. GIMP and Inkscape are great. I use them both. Though do many people use them on windows? This is a serious question. C. Thomas Stover ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2014 民國103年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
buildiing pango error with jhbuild
I am trying to build GNOME 3.10 (the release) using jhbuild, on a Fedora 19 machine (which comes with GNOME 3.8) I checkout out jhbuild, follow the steps and can build using this command up to pango: jhbuild -m http://download.gnome.org/teams/releng/3.10.1/gnome-apps-3.10.1.modulesbuild -afc pango then while building pango I got these errors: make[4]: Entering directory `/media/drive2/software/gnome3/checkout/pango-1.36.0/pango/mini-fribidi' CC fribidi.lo CC fribidi_char_type.lo CC fribidi_types.lo libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[4]: *** [fribidi_char_type.lo] Error 63 make[4]: *** Waiting for unfinished jobs make[4]: *** [fribidi_types.lo] Error 63 libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[4]: *** [fribidi.lo] Error 63 I cannot find information on the net on how to fix this Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. Any clues for fixing this? thanks -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2013 民國102年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2013 民國102年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
buildiing pango error with jhbuild
I am trying to build GNOME 3.10 (the release) using jhbuild, on a Fedora 19 machine (which comes with GNOME 3.8) I checkout out jhbuild, follow the steps and can build using this command up to pango: jhbuild -m http://download.gnome.org/teams/releng/3.10.1/gnome-apps-3.10.1.modulesbuild -afc pango then while building pango I got these errors: make[4]: Entering directory `/media/drive2/software/gnome3/checkout/pango-1.36.0/pango/mini-fribidi' CC fribidi.lo CC fribidi_char_type.lo CC fribidi_types.lo libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[4]: *** [fribidi_char_type.lo] Error 63 make[4]: *** Waiting for unfinished jobs make[4]: *** [fribidi_types.lo] Error 63 libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[4]: *** [fribidi.lo] Error 63 I cannot find information on the net on how to fix this Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. Any clues for fixing this? thanks -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2013 民國102年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2013 民國102年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 -- Andy Tai, a...@atai.org Year 2010 民國99年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Opening the 3.12 cycle
what would this mean for systems not using systemd? On Mon, Sep 23, 2013 at 5:33 AM, Matthias Clasen matthias.cla...@gmail.comwrote: Hi, with 3.10 getting wrapped up today, it is time to look ahead at the next cycle and start making plans for what we want to achieve. We've set up the usual page on the wiki to collect the plans: https://wiki.gnome.org/ThreePointEleven/Features - Systemd for the user session -- Andy Tai, a...@atai.org Year 2010 民國99年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
GNOME is a free software project where all the decision making process should be transparent. Mailing lists, for example, are transparent. The tool you recommend will go against the spirit of openness and community. On Sun, Apr 14, 2013 at 1:36 AM, אנטולי קרסנר tomback...@gmail.com wrote: Hello, I found a tool for collaborative decision making and brainstorming called loomio: https://www.loomio.org/ It's open for private beta, and I think Gnome, as a community project, can really benefit from using it. Currently the communication between people in the project is done in several channels not connected to each other: mailing list, GnomeLive wiki and IRC channels. All three of them treat all text as just plain text, meaning the computer doesn't provide us tools for specific content such as brainstorming, ideas, plans, schedules, etc. Loomio doesn't provide all of these things, but it's a great tool for a community to use for managing ideas and decisions. What do you think? Anatoly ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2013 民國102年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 7:17 AM, Lennart Poettering mzta...@0pointer.dewrote: I second that. Speaking as a member of the Debian GNOME team, having the independent parts be compilable on their own would definitely help us: - While Debian has a systemd package and we hope to have systemd as a supported alternative for wheezy, sysvinit is still the default. Having GNOME depend on systemd would definitely complicate things for us. - Debian's has non-Linux ports. Having the non-arch specific parts in a separate package would mean we can more easily make the GNOME packages depend on them. No, that's not going to happen. systemd is strictly Linux-only. I have What is not going to happen? systemd is Linux only, or GNOME is systemd only? Look, systemd is wonderful; it works great. But GNOME is a desktop environment, and making it tied to an init system does not make sense. no plans porting it to other kernels, and I will not merge any such patches. One of the reasons systemd is small and easy to read is that we don't waste time and resources on abstractions and use the power the Linux platform supports. For example our main loops are pure epoll(), and I have no plans at all supporting anything else with a metric ton of #ifdefs. If the other kernels matter, then the folks working on them should share our interfaces (such as the hostnamed bus iface), not our code. Your interface is the POSIX standard? You don't care about other Unix like systems with other init implementations; you would screw Debian, Ubuntu, BSDs, Solaris, etc. But this is not and cannot be the attitude for a wide community. You have no logical argument to force a desktop environment to support a very narrow viewpoint of yours. What I am willing to support is builds of systemd that consist only of the tiny mechanism daemons, and leave the core of it outside. That way folks can install these mechanisms and stick with their old init systems for a while. Lennart -- Lennart Poettering - Red Hat, Inc. -- Andy Tai, a...@atai.org, Skype: licheng.tai Year 2011 民國100年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
So long as GNOME provides the same experience when these technologies are not present... On Tue, Aug 18, 2009 at 4:22 PM, Seif Lotfys...@lotfy.com wrote: 2009/8/19 Matthias Clasen matthias.cla...@gmail.com On Tue, Aug 18, 2009 at 6:49 PM, Seif Lotfys...@lotfy.com wrote: Problem with thinking of these tecnologies as what wil lit give the user is a wrong approach IMHO. 'Designing' the next desktop by picking the cool-sounding technologies to base it on first and leaving the user experience as something to be worked out later is a disaster in the making. We can not do things this way. I never said pick the cool sounding, If the appliaiton providing good user experience uses a technology to do that then this technology should be considered! We need applications that make use of these technologies first then we can decide which tehcnology is better! Basically the better application will push the technology behind it! -- Andy Tai, a...@atai.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
You should purchase a separate license from the Mutter authors... On Wed, Jul 8, 2009 at 12:23 PM, Joone Hurjo...@kldp.org wrote: Hello All, Mutter(Metacity+Clutter) is very impressive technology. However, Mutter seems hard to be used on embedded devices. Because Metacity uses GPL license and most of HW accelerated OpenGL/ES library use a proprietary license. Is there any way of using Mutter with proprietary OpenGL/ES library on embedded devices? Thanks, Joone ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Andy Tai, a...@atai.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Will the 3d shell work well on OpenMoko? On Tue, Mar 31, 2009 at 11:10 AM, Owen Taylor otay...@redhat.com wrote: And the same applies to virtualized desktops, but more so. Don't put the effort into avoiding 3D. Put the effort into making 3D work. - Owen -- Andy Tai, a...@atai.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
On 7/19/06, David Nielsen [EMAIL PROTECTED] wrote: As if the question of Mono's inclusion doesn't already fragment GNOME, those who are opposed to it because it's MS technology or similar, IMHO, silly reasons (read: not based on technological merit) won't let it in. Then there are people like me who have been waiting for the right moment for Mono to get included so that one day I might rely on Mono for any development I do - I'm frankly getting to the point where if Mono doesn't get included, I'll simply stop using GNOME. I'm getting tired of this debate, I think Mono is great and I think continuing to push a C based platform is a mistake.. We are handed great technology to move GNOME forward, do we want that or are we willing to bet that C is a viable option for Topaz. If you think that not including Mono is a way to keep users you are mistaken, there are plenty out there who will not switch over or leave GNOME if we don't take this step. What is this? Some type of threat? To date GNOME does not have Mono and GNOME is doing great. The majority of users do not use Mono and do not want to depend on Mono. If you have your way, more people will lose their way. Who have heard any users today who refuse to switch to GNOME unless Mono is adapted? (What do these people use today? KDE?) When Mono works comfortably on a machine with 32 MBytes of RAM, than maybe it makes sense to talk about basing some parts of GNOME on Mono. -- Andy Tai, [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDFL - why is it bad? Debian could do better! (was: Re: Debian and the GFDL problem)
Same for your attacks on the GFDL... they have nothing to do on a GNOME mailing list. Please bring this on another place or in private mail.On 1/8/06, Josselin Mouette [EMAIL PROTECTED] wrote: As for your anti-Debian crusade and false statements, they have nothingto do on a GNOME mailing list. Please bring this on another place or in private mail.Regards,-- .''`. Josselin Mouette/\./\ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
