Re: [Gimp-developer] Third big serious meeting from GIMPcon
Raphaël Quinet [EMAIL PROTECTED] writes: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time. The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution. - current debian unstable = 2.2.2 (2.2.2-3) - current mandrake cooker = 2.2.2 (2.2.2-6mdk) - current rh rawhide = 2.2.2 (gtk2-2.2.2-2.1) mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december. so this issue may not be a real one. you're left to few classes of users: - those who use only distro packages: they will wait until a binary package is availlable - those who know how ot build programs: they're supposed to know how to build dependancies and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. this is a valid point for: - users of very old distributions - non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) This is not only about users of very old distributions. The world is not only Linux and Windows, and the Linux world is not only made of binary distributions. agreed. Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.) factoring features around all tools is nice even if it's bring more dependancies. sure it's Even if we could create the binary packages, I don't think that we should distribute them from the GIMP web site. This means that we would get support questions for these binaries. We already get some distribution-specific bug reports from time to time, but we can usually divert them to a more appropriate place. Supporting the binaries is not something that most developers would enjoy doing. So it is better if someone else can take care of building and distributing binaries for us. This can be a Linux distributor or some individual who puts the binaries on his web site (like it is currently done for the Windows version). so since, most oses are in one of the following states: - already provides gimp-1.3.x somewhere (debian unstable, mandrake contribs) - is ready for gimp-1.3.x regarding dependancies (redhat) - some site provide prebuild binaires (windows) and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org. We would be glad to link to these sites from the GIMP web site, but it is better to avoid hosting any binaries on www.gimp.org. though, this web site could then figure some url to get binaries for most people (either distros packages or tarballs from third parties) [maybe it exists already, i didn't check it out] As far as I am concerned (I spend several hours per week on Bugzilla), I don't think that answering Bugzilla by mail would really save time. For every third or fourth bug to which I respond, I do a Bugzilla query to find related bugs. Since I use the web interface for queries, I don't think that I would save much time by using e-mail for the other bugs. well, ones can use its bugzilla mail box for such queries :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Hi, On Sun, 2003-08-24 at 14:23, Thierry Vignaud wrote: and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Sven Neumann [EMAIL PROTECTED] writes: and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer. sure, when woraounding old bugs became too much development time consuming, it's better to just bump the requires. what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Hi, On Sun, 2003-08-24 at 16:00, Thierry Vignaud wrote: what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too Not only are the odds high, they don't have any other chance. On the other hand, by the time that gimp-2.0 will be ready, we will most likely see gtk+-2.4 being released. But I'd rather avoid a dependency on that version of possible. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Thierry Vignaud wrote: Raphaël Quinet [EMAIL PROTECTED] writes: The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution. - current debian unstable = 2.2.2 (2.2.2-3) - current mandrake cooker = 2.2.2 (2.2.2-6mdk) - current rh rawhide = 2.2.2 (gtk2-2.2.2-2.1) mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december. so this issue may not be a real one. It's real in so far as most linux users aren't using RedHat 9.x, Debian unstable or Mandrake 9.x - I am using Debian testing here, for example, to which I moved relatively recently from RedHat 6.2, which is still the distro available in work, where we have a binary package dependency (a database product) that isn't available in the version we use for later distros. On that work machine, building a 1.2 GIMP from scratch can be done in a day (that is, from glib up, through libjpeg, libpng and friends). Building a 1.3 CVS GIMP takes considerably longer than that. you're left to few classes of users: - those who use only distro packages: they will wait until a binary package is availlable One of the reasons that we haven't had as much testing as we'd like yet on 1.3. - those who know how ot build programs: they're supposed to know how to build dependancies and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros. This is an immense simplification. There are people who want to use the new GIMP, but have had problems building some part of it. You're forgetting that the target audience of the GIMP is a user interested in graphics, not a developer. this is a valid point for: - users of very old distributions Even recent distros - GNOME 2 has only been around for a little over a year. - non developer users (that is most end users) And most people we're interested in. - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) Setting up a build environment in windows is something of a nightmare. Windows users are also our biggest user base, I reckon. And they also find lots of bugs in the GIMP because it's used in ways that Linux doesn't even think of doing. Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.) factoring features around all tools is nice even if it's bring more dependancies. Sure - it's The Unix Way to use smaller packages to do specific jobs. The point is that each smaller package which isn't already available on the system raises the barrier for entry for GIMP building. and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org. I'm not sure I follow the reasoning... The point is that to get more people using, testing, contributing to and developping for the newer version of the GIMP, freely available binary packages lower the barrier. Of course we don't want to build the packages, but if volunteers do packages for a given distro, we should have one place where we link to the externally maintained binaries. It would be pretty simple to do, and would, I think, prove a great benefit to people eager to see what we've been up to for the last 3 years. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Dave Neary [EMAIL PROTECTED] writes: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time. there's no problem in providing both gtk+-1.2.x and gtk+-2.x in a distro. Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. this is a valid point for: - users of very old distributions - non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy) Do we need binary distributions? There was a discussion about binary distributions. This may help people to try some versions of the GIMP (especially the development versions) without having to compile everything. However, maintaining binaries is a lot of work, even if we only maintain binaries supplied by others. In addition, this would bring some additional responsabilities that we do not want to have. For these reasons, it was decided that www.gimp.org would not host any binaries but would link to the pages of those who are providing binaries for various platforms. yes development and packaging (well binary tarball is some kind of packaging) are two different tasks. you can either: - leave it to distributions (after all gimp-1.3 is already provided in mandrake contribs and in debian unstable) - leave it to a nightly build system (see mozilla) - leave it to another specialized team (aka you need one people that sometimes build windows binaries and someone who sometimes build static gimp for linux) Is Bugzilla too hard to use for new users? -- It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known). This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes. even if bug reporting by mail may not look suitable, being able to anwser bugzilla by mail is a must. it saves quite a lot of time and is often see as more easy to use by developers (at least here at mdk). there're several extensions that do this (see freshmeat.net or soft/bugs module in mandrake cvs). ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
On 9 Aug 2003 at 18:35, Leonard Rosenthol wrote: At 8:36 PM +0200 8/9/03, Dave Neary wrote: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. This problem may be solved as time passes, because more and more distributions will include the required libraries. I think the related reason here is that many open source projects get their contributors from non-Linux platforms, esp. Windows. And building GIMP/Windows is even more of a nightmare than building GIMP on Linux. Well, building GIMP/Windows so that GIMP can be run isn't that complicated - building it right so it can be make installed is. Building with Cygwin seems to be rather easy once you've got recent versions of all required libraries and tools. Building with MinGW is a bit more complicated - the packages of libiconv and libintl that are linked from http://www.gimp.org/~tml/gimp/win32/downloads.html don't include import libriaries to be used with libtool. All my tries to create them with pexports and dlltool didn't produce working libs. Maybe one of the GIMPGTK/Win32 gods can enlighten a mere mortal on the modifications that need to be done to build GIMP with MinGW? Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Alan Horkan wrote: I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all. I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward. I like the 'benevolent dictator' model for OpenSource management - it works well in so many projects - ranging from tiny three man projects right up to the Linux kernel itself. It's really hard to come to a firm decision in a timely manner in an environment where everyone's voice counts equally...doubly so if things get ugly. The art is to find a dictator who actually *is* benevolent. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
At 8:36 PM +0200 8/9/03, Dave Neary wrote: Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. This problem may be solved as time passes, because more and more distributions will include the required libraries. I think the related reason here is that many open source projects get their contributors from non-Linux platforms, esp. Windows. And building GIMP/Windows is even more of a nightmare than building GIMP on Linux. Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions Whether they're included in the latest major distributions is quite irrelevant unless a developer (or indeed, user) is USING the latest major distributions. I imagine (okay, know) that unix-heads can be pretty shy of re-installing their operating system world just to get a small handful of the latest versions of OMG L33T DEPS!!! apps working properly. As you say, as time approaches infinity the issue tends to zero. Meanwhile... --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Third big serious meeting from GIMPcon
At 1:37 PM +0200 8/10/03, Michael Schumacher wrote: Well, building GIMP/Windows so that GIMP can be run isn't that complicated - It is for folks using Visual Studio - which (all free software stuff aside) is the standard for development on Windows. If you want people developing on GIMP/Windows (which would also mean GIMP in general), you need VC projects. Sure, building from CygWin and MinGW are nice - but that's not how folks work in the real world... LDR -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
