Re: Use of maintainer mode in GNOME modules
On Fri, 2011-09-16 at 08:15 -0400, Ryan Lortie wrote: > hi Murray, > > On Fri, 2011-09-16 at 10:05 +0200, Murray Cumming wrote: > > No packager has mentioned any problem with gtkmm and friends. > > This is not about reducing problems for packagers. It's about reducing > problems for those who try to build your module via jhbuild. If you > jhbuild a maintainer-mode-disabled module, then later on someone does a > commit that introduces a new file (and updates the Makefile.am to add > it) then on next build, the build is broken. There is no problem with gtkmm and friends in jhbuild. In this case, there is no problem because our autogen.sh turns on maintainer mode. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
hi Murray, On Fri, 2011-09-16 at 10:05 +0200, Murray Cumming wrote: > No packager has mentioned any problem with gtkmm and friends. This is not about reducing problems for packagers. It's about reducing problems for those who try to build your module via jhbuild. If you jhbuild a maintainer-mode-disabled module, then later on someone does a commit that introduces a new file (and updates the Makefile.am to add it) then on next build, the build is broken. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Thu, 2011-09-15 at 09:50 -0400, Ryan Lortie wrote: > We're currently suffering because > gnome-common also ties maintainer mode to the enabling of deprecation > checks and we're not sure we want these to be enabled by default for > casual tarball downloaders. [snip] This is not a problem experienced by gtkmm and friends. Our modules never enable warnings or deprecations in the tarball builds. We have our own separate --enable-warnings option for that: http://www.murrayc.com/blog/permalink/2011/01/18/avoiding-use-of-deprecated-api/ We don't use gnome-common. We tried to add something similar to gnome-common, though I don't personally find it flexible enough: http://amigadave.blogspot.com/2011/03/compiler-warnings-and-deprecations-with.html No packager has mentioned any problem with gtkmm and friends. On the contrary, they are glad that we have this "maintainer mode" that reduces the work of a packager, and that they can turn it off if necessary. We get bug reports when it doesn't work. So please don't break our modules. We will revert it if you do. We welcome corrections that don't break things. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
hi, On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote: > Because maintainer mode existing is really annoying when you are a > packager, and tying arbitrary unrelated changes to an option that is > documented as only changing the make rules is just wrong. > > --enable-maintainer-mode enable make rules and dependencies not useful > (and sometimes confusing) to the casual installer > > Options should do one clearly defined thing. What if a packager needs > maintainer mode off but wants the GTK+ integration? I really agree with this point. We're currently suffering because gnome-common also ties maintainer mode to the enabling of deprecation checks and we're not sure we want these to be enabled by default for casual tarball downloaders. My suggestion to anyone affected by any issues tied to side effects of maintainer mode is to either create a new flag to control these effects directly or, if unable to do so now, to temporarily revert the '([enable])' patch until such a time as it is practical. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Thu, 2011-09-15 at 10:52 +0200, Dodji Seketeli wrote: > > the above help string might then just suggest that I would rather define > > my own --enable-maintainer-mode when I want to cover more things under > > it. > > If you do so, please don't call it --enable-maintainer-mode. I agree > with Ross here. This is an option with confusing enough semantics, so > please don't overload it more than it ought to. Hi, yup, I will not. I realized I wrote a nonsense after I read Javier's post with --enable-strict bug. That makes much more sense, than what I was "proposing" here with the --enable-maintainer-mode overload. Still, after this change, users may change their habit of not passing --enable-maintainer-mode to use --disable-maintainer-mode on affected projects, which would be, at least for me, quite surprising change. But maybe I'm just not an average user after all ;) Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Milan Crha a écrit: > On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote: >> --enable-maintainer-mode enable make rules and dependencies not useful >> (and sometimes confusing) to the casual installer [...] > > the above help string might then just suggest that I would rather define > my own --enable-maintainer-mode when I want to cover more things under > it. If you do so, please don't call it --enable-maintainer-mode. I agree with Ross here. This is an option with confusing enough semantics, so please don't overload it more than it ought to. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Wed, 2011-09-14 at 12:53 +0100, Javier Jardón wrote: > ... > if test x$enable_strict != xno; then > CPPFLAGS="$CPPFLAGS -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED > -DGDK_DISABLE_DEPRECATED" > fi > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=658608 Hi, OK, that fixes one part of the problem. What about concerns mentioned by Murray and Tristan, their use case seems to be valid to me. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote: > On 14 September 2011 11:43, Milan Crha wrote: > > why is that? I can imagine couple useful things being tight to the > > maintainer mode, also those aforementioned deprecated stuff being in use > > only for maintainers, not for regular users, like is done here [1]. > > Other users in this thread gave also reasonable examples of a usage of > > the maintainer mode, not only for a makefile generation. > > Because maintainer mode existing is really annoying when you are a > packager, and tying arbitrary unrelated changes to an option that is > documented as only changing the make rules is just wrong. > > --enable-maintainer-mode enable make rules and dependencies not useful > (and sometimes confusing) to the casual installer Hi, the above help string might then just suggest that I would rather define my own --enable-maintainer-mode when I want to cover more things under it. > Options should do one clearly defined thing. What if a packager needs > maintainer mode off but wants the GTK+ integration? If you mean for the eds, then it's intentionally available for maintainers only. And to be honest, it's for bug-buddy, to be registered on the factory and catch any background crashes. Eds is still able to run without gtk environment, it's "only larger" on a lib dependency. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On 14 September 2011 11:43, Milan Crha wrote: > On Wed, 2011-09-14 at 10:56 +0100, Ross Burton wrote: >> >> "maintainer mode" shouldn't mean anything else apart from changing how >> the makefiles generate, and certainly shouldn't change what code is >> being compiled. > > Hi, > why is that? I can imagine couple useful things being tight to the > maintainer mode, also those aforementioned deprecated stuff being in use > only for maintainers, not for regular users, like is done here [1]. > Other users in this thread gave also reasonable examples of a usage of > the maintainer mode, not only for a makefile generation. > Bye, > Milan > > [1] http://git.gnome.org/browse/bug-buddy/tree/configure.in#n101 What you are doing there is pretty disconnected from what AM_MAINTAINER_MODE does. They share a nebulous concept of a "maintainer mode", but they're doing very different things. As Rob said, "maintainer mode" shouldn't mean anything else apart from changing how the makefiles generate, and certainly shouldn't change what code is being compiled. We are working in a new macro [1] to fix this use case. As a temporary solution you can use this in your configure.ac: dnl --- dnl - Use strict options (default enabled for devs, disabled in releases) dnl --- dnl if .git directory is present, considering we are working in the repository test -d "$(srcdir)/.git"; then default_strict=yes else default_strict=no fi AC_ARG_ENABLE([strict], [AS_HELP_STRING([--enable-strict], [Enable strict compilation options])], [enable_strict=$enableval], [enable_strict=$default_strict]) if test x$enable_strict != xno; then CPPFLAGS="$CPPFLAGS -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED" fi [1] https://bugzilla.gnome.org/show_bug.cgi?id=658608 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On 14 September 2011 11:43, Milan Crha wrote: > why is that? I can imagine couple useful things being tight to the > maintainer mode, also those aforementioned deprecated stuff being in use > only for maintainers, not for regular users, like is done here [1]. > Other users in this thread gave also reasonable examples of a usage of > the maintainer mode, not only for a makefile generation. Because maintainer mode existing is really annoying when you are a packager, and tying arbitrary unrelated changes to an option that is documented as only changing the make rules is just wrong. --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer Options should do one clearly defined thing. What if a packager needs maintainer mode off but wants the GTK+ integration? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Wed, 2011-09-14 at 10:56 +0100, Ross Burton wrote: > On 14 September 2011 08:19, Milan Crha wrote: > > By the way, your change has a side-effect where DBus factories of > > evolution-data-server (e-addressbook-factory and e-calendar-factory > > processes) depend on gtk+ by default, because I did a change couple > > weeks ago to do that *when compiled with the maintainer mode*, which is > > the default after your change. > > "maintainer mode" shouldn't mean anything else apart from changing how > the makefiles generate, and certainly shouldn't change what code is > being compiled. Hi, why is that? I can imagine couple useful things being tight to the maintainer mode, also those aforementioned deprecated stuff being in use only for maintainers, not for regular users, like is done here [1]. Other users in this thread gave also reasonable examples of a usage of the maintainer mode, not only for a makefile generation. Bye, Milan [1] http://git.gnome.org/browse/bug-buddy/tree/configure.in#n101 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On 14 September 2011 08:19, Milan Crha wrote: > By the way, your change has a side-effect where DBus factories of > evolution-data-server (e-addressbook-factory and e-calendar-factory > processes) depend on gtk+ by default, because I did a change couple > weeks ago to do that *when compiled with the maintainer mode*, which is > the default after your change. "maintainer mode" shouldn't mean anything else apart from changing how the makefiles generate, and certainly shouldn't change what code is being compiled. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Mon, 2011-09-12 at 08:23 +0200, Milan Crha wrote: > On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote: > > So if Its not already fixed in your module, we are going to proced to > > fix all the GNOME modules that appear > > in "orange" and convert it to "yellow", ie > > > > AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) Hi again, still no answer for this? You know, break things quickly and then do not answer follow-up issues/concerns isn't much kind of you, somehow. By the way, your change has a side-effect where DBus factories of evolution-data-server (e-addressbook-factory and e-calendar-factory processes) depend on gtk+ by default, because I did a change couple weeks ago to do that *when compiled with the maintainer mode*, which is the default after your change. I still believe that this is not the right change being done, neither properly discussed, and definitely not the best time to do, just before the hard code freeze. Can you revert the mess and choose a correct fix for your initial issue, please? My main concern is that you changed the default behavior for projects, and that using --disable-maintainer-mode is not the usual way of using it. Users use to ask to do more, than to do less, especially with the maintainer mode, which adds special processing and dependencies for maintainers, not for users. As a possible gnome goal, would it make any sense to remove the AM_MAINTAINER_MODE macro from all projects and replace it with their own implementation of this --enable-maintainer-mode configure argument? Though I'm still not certain whether not using AM_MAINTAINER_MODE at all or using AM_MAINTAINER_MODE/AM_MAINTAINER_MODE([disable]) is equivalent. I didn't get it from the gno.org doc [1]. Bye and I'm looking forward for your replies in this thread, Milan [1] http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
2011/9/12 Murray Cumming : > On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote: >> Hi all, >> >> As you can read in the Ryan blog post [1], the use of the >> AM_MAINTAINER_MODE macro is only correct when used in this way: >> >> AM_MAINTAINER_MODE([enable]) >> >> As ryan said in the blog post, fredp made a report page for packages >> using AM_MAINTAINER_MODE. >> >> green -> no “AM_MAINTAINER_MODE” at all (good) >> yellow -> “AM_MAINTAINER_MODE([enable])” (fine) >> orange -> means that your package is currently broken and needs to be fixed. >> >> So if Its not already fixed in your module, we are going to proced to >> fix all the GNOME modules that appear >> in "orange" and convert it to "yellow", ie >> >> AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) >> >> Thanks for you collaboration. >> >> [1] http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/ >> [2] http://people.gnome.org/~fpeters/reports/maintainer-mode.html > > We don't really want this change in the gtkmm (and friends) modules. > Chaning AM_MAINTAINER_MODE to AM_MAINTAINER_MODE([enable]) will change > the default behaviour in tarball builds. > > We currently ship generated C++ files and HTML documentation files in > our tarballs. Distro packagers generally don't want to regenerate those > files because a) It's unnecessary and b) It requires extra build tools. Hi guys, After reading the blog post and this thread yesterday I did not think much of it... but can we clarify this point ? If I have AM_MAINTAINER_MODE([enable]) then what happens by default ? a.) docs and user manual are not included in the tarball ? b.) docs are built and distributed in the tarball but typing 'make' causes them to be rebuilt ? Actually I accepted a patch to "modernize" Glade's configure script (which adds the '([enable])' bit to AM_MAINTAINER_MODE) and it's possible that I have just not noticed the pain which I've caused anyone downloading our tarballs (since I obviously happen to always have all the tools I need to build GNOME from git). We've always been very clear about this, to build from a git checkout you need "a whole lot of gnome stuff", but when you build from the tarball you really only need a basic gnu toolchain and the GTK+ development files and dependencies. If users are forced to have unnecessary tools on their system to download and test Glade tarballs, this is definitely a problem for us and we will probably be inclined to revert to just AM_MAINTAINER_MODE. But, perhaps this is just a misunderstanding, does this change really push complications onto the innocent downloaders of our tarballs ? Best regards, -Tristan > > We don't want distro packagers to regenerate the files because there is > a risk that the output will not be the same if they have slightly > different versions of the dependencies, including newer versions. It can > even risk breaking ABI. Distro packagers don't want that either. > > If, for some reason, distro packagers do want to turn this off, they > already can with the configure option. > > So, for *mm modules, it doesn't seem to be a change that would actually > help anybody in the real world, though it risks causing real problems. > > > Theoretically we might not be doing things in the right way, but then it > would be up to someone to fix things properly instead of just breaking > our modules. > > > We have seen you make this change at least once without asking the > maintainer: > http://git.gnome.org/browse/gdlmm/commit/?id=3272c0aa3008654e54b6fd68af8c324db3ee72f8 > even though this has not apparently been approved yet as a gnome-wide > goal. > > -- > murr...@murrayc.com > www.murrayc.com > www.openismus.com > > ___ > 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: Use of maintainer mode in GNOME modules
On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote: > Hi all, > > As you can read in the Ryan blog post [1], the use of the > AM_MAINTAINER_MODE macro is only correct when used in this way: > > AM_MAINTAINER_MODE([enable]) > > As ryan said in the blog post, fredp made a report page for packages > using AM_MAINTAINER_MODE. > > green -> no “AM_MAINTAINER_MODE” at all (good) > yellow -> “AM_MAINTAINER_MODE([enable])” (fine) > orange -> means that your package is currently broken and needs to be fixed. > > So if Its not already fixed in your module, we are going to proced to > fix all the GNOME modules that appear > in "orange" and convert it to "yellow", ie > > AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) > > Thanks for you collaboration. > > [1] http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/ > [2] http://people.gnome.org/~fpeters/reports/maintainer-mode.html We don't really want this change in the gtkmm (and friends) modules. Chaning AM_MAINTAINER_MODE to AM_MAINTAINER_MODE([enable]) will change the default behaviour in tarball builds. We currently ship generated C++ files and HTML documentation files in our tarballs. Distro packagers generally don't want to regenerate those files because a) It's unnecessary and b) It requires extra build tools. We don't want distro packagers to regenerate the files because there is a risk that the output will not be the same if they have slightly different versions of the dependencies, including newer versions. It can even risk breaking ABI. Distro packagers don't want that either. If, for some reason, distro packagers do want to turn this off, they already can with the configure option. So, for *mm modules, it doesn't seem to be a change that would actually help anybody in the real world, though it risks causing real problems. Theoretically we might not be doing things in the right way, but then it would be up to someone to fix things properly instead of just breaking our modules. We have seen you make this change at least once without asking the maintainer: http://git.gnome.org/browse/gdlmm/commit/?id=3272c0aa3008654e54b6fd68af8c324db3ee72f8 even though this has not apparently been approved yet as a gnome-wide goal. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote: > So if Its not already fixed in your module, we are going to proced to > fix all the GNOME modules that appear > in "orange" and convert it to "yellow", ie > > AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) Hi, you didn't give much time for a discussion on this, and just made the change. However, if I got it right, your proposed change is also changing default behavior, thus people whom didn't pass --enable-maintainer-mode into ./configure does have it enabled now. Am I right? It's not a problem if you have nothing tight to it (nothing else than what is written in the desrt's blog), but what with projects which adds more things to it, only used for module maintainers, like disabling deprecated API, which really should be done for maintainers only, because you never know against which version of glib/gtk/... your module will be compiled (when your module "supports" also older APIs of them)? Was this change done for jhbuild users only/mainly? Why not change the jhbuild itself then? It is using development versions, thus it makes sense to enable maintainer mode there - I think. By the way, was the Makefile generation added to maintainer mode some time recently? I noticed build issues after update for jhbuild users only in couple last weeks, and it used to work fine for years, as far as I can tell. And if this was added for speedup of compilation, wouldn't it be better to fix libtool, to avoid relinking on "make install" phase when there is done a linkage against module-added .la files? (It relinks against $(libdir) in "make install", but during "make" it links against $(topbuildir)/sub/folder/library.la, though for some cases it is able to pick .la files from $(libdir) during "make" phase too, if they are there - can be caused by a way of usage.) Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
On 9 September 2011 14:16, Vincent Untz wrote: > Le vendredi 09 septembre 2011, à 13:49 +0100, Javier Jardón a écrit : > >> Also, that bug is unrelated with the use of AM_MAINTAINER_MODE > > Sorry, you're wrong :-) well, partially ;) > gnome-session is orange in the report and doesn't use > AM_MAINTAINER_MODE. And that's because it uses the > GNOME_MAINTAINER_MODE_DEFINES macro, which has: > AC_REQUIRE([AM_MAINTAINER_MODE]) What GNOME_MAINTAINER_MODE_DEFINES does is pretty disconnected from what AM_MAINTAINER_MODE does. They share a nebulous concept of a "maintainer mode", but they're doing very different things. So there is to problems here: - Incorrect use of AM_MAINTAINER_MODE - Fix GNOME_MAINTAINER_MODE_DEFINES This mail is only about fix the first one. -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Le vendredi 09 septembre 2011, à 13:49 +0100, Javier Jardón a écrit : > On 9 September 2011 13:24, Vincent Untz wrote: > > Le vendredi 09 septembre 2011, à 13:09 +0100, Javier Jardón a écrit : > >> Hi all, > >> > >> As you can read in the Ryan blog post [1], the use of the > >> AM_MAINTAINER_MODE macro is only correct when used in this way: > >> > >> AM_MAINTAINER_MODE([enable]) > >> > >> As ryan said in the blog post, fredp made a report page for packages > >> using AM_MAINTAINER_MODE. > >> > >> green -> no “AM_MAINTAINER_MODE” at all (good) > >> yellow -> “AM_MAINTAINER_MODE([enable])” (fine) > >> orange -> means that your package is currently broken and needs to be > >> fixed. > >> > >> So if Its not already fixed in your module, we are going to proced to > >> fix all the GNOME modules that appear > >> in "orange" and convert it to "yellow", ie > >> > >> AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) > >> > >> Thanks for you collaboration. > > > > I'd prefer to get https://bugzilla.gnome.org/show_bug.cgi?id=658608 > > fixed, instead of adding back AM_MAINTAINER_MODE in my modules. > > We are not going to modify the modules that are not using > AM_MAINTAINER_MODE at all (green). > We are only going to change the modules that are using > AM_MAINTAINER_MODE (orange) to > AM_MAINTAINER_MODE([enable]) > > Also, that bug is unrelated with the use of AM_MAINTAINER_MODE Sorry, you're wrong :-) gnome-session is orange in the report and doesn't use AM_MAINTAINER_MODE. And that's because it uses the GNOME_MAINTAINER_MODE_DEFINES macro, which has: AC_REQUIRE([AM_MAINTAINER_MODE]) This is what Ryan wanted to fix in the bug above :-) 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: Use of maintainer mode in GNOME modules
On 9 September 2011 13:24, Vincent Untz wrote: > Le vendredi 09 septembre 2011, à 13:09 +0100, Javier Jardón a écrit : >> Hi all, >> >> As you can read in the Ryan blog post [1], the use of the >> AM_MAINTAINER_MODE macro is only correct when used in this way: >> >> AM_MAINTAINER_MODE([enable]) >> >> As ryan said in the blog post, fredp made a report page for packages >> using AM_MAINTAINER_MODE. >> >> green -> no “AM_MAINTAINER_MODE” at all (good) >> yellow -> “AM_MAINTAINER_MODE([enable])” (fine) >> orange -> means that your package is currently broken and needs to be fixed. >> >> So if Its not already fixed in your module, we are going to proced to >> fix all the GNOME modules that appear >> in "orange" and convert it to "yellow", ie >> >> AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) >> >> Thanks for you collaboration. > > I'd prefer to get https://bugzilla.gnome.org/show_bug.cgi?id=658608 > fixed, instead of adding back AM_MAINTAINER_MODE in my modules. We are not going to modify the modules that are not using AM_MAINTAINER_MODE at all (green). We are only going to change the modules that are using AM_MAINTAINER_MODE (orange) to AM_MAINTAINER_MODE([enable]) Also, that bug is unrelated with the use of AM_MAINTAINER_MODE Regards, -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
Le vendredi 09 septembre 2011, à 13:09 +0100, Javier Jardón a écrit : > Hi all, > > As you can read in the Ryan blog post [1], the use of the > AM_MAINTAINER_MODE macro is only correct when used in this way: > > AM_MAINTAINER_MODE([enable]) > > As ryan said in the blog post, fredp made a report page for packages > using AM_MAINTAINER_MODE. > > green -> no “AM_MAINTAINER_MODE” at all (good) > yellow -> “AM_MAINTAINER_MODE([enable])” (fine) > orange -> means that your package is currently broken and needs to be fixed. > > So if Its not already fixed in your module, we are going to proced to > fix all the GNOME modules that appear > in "orange" and convert it to "yellow", ie > > AM_MAINTAINER_MODE -> AM_MAINTAINER_MODE([enable]) > > Thanks for you collaboration. I'd prefer to get https://bugzilla.gnome.org/show_bug.cgi?id=658608 fixed, instead of adding back AM_MAINTAINER_MODE in my modules. Cheers, 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
