Re: Plugins at Sourceforge
On Sat, 5 Feb 2000 12:33:38 -0800, "Michael J. Hammel" <[EMAIL PROTECTED]> said: >I'm curious why any new plug-ins should be added to the core *at >all*. Gimp's distribution is fairly large as it is. Isn't it >getting time to limit additional plug-ins to the core distribution to >plug-ins which are considered "vital" in some way? Even some estoric >file plug-ins need not necessarily be included with the core package. >Throwing in the kitchen sink is what's starting to bloat some Linux >distros. I couldn't concur with you more. I'm radical enough to suggest taking all the plugins out of the standard distribution entirely. :) Kelly
Re: Plugins at Sourceforge
Michael J. Hammel spontaneously blurts out: > > I'm curious why any new plug-ins should be added to the core *at all*. > Gimp's distribution is fairly large as it is. Isn't it getting time to > limit additional plug-ins to the core distribution to plug-ins which are > considered "vital" in some way? Even some estoric file plug-ins need not > necessarily be included with the core package. Throwing in the kitchen > sink is what's starting to bloat some Linux distros. > I totally agree! Ideally Gimp should have a connection to some plug-in registry so that needed esoteric (or not so esoteric) plug-ins could be downloaded and installed without restarting gimp. Have the simple plugin's with the distro and then have a series of "power packs" that roughly align with usage domains (i.e. "import powerpack","export powerpack", fine art powerpack", "prepress powerpack", etc). -Dean Johnson Tool Hooligan Cluster Admin Tools & Jessie Project Silicon Graphics Inc.Eagan,MN (651) 683-5880 "I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
Re: Plugins at Sourceforge
Date: Sat, 5 Feb 2000 12:33:38 -0800 From: "Michael J. Hammel" <[EMAIL PROTECTED]> I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Furthermore, look at it from the standpoint of someone trying to package a Linux distribution (especially vis a vis esoteric file formats and other things that depend upon external software). If our jpeg plugin is part of the core (as an example, I don't want to debate jpeg per se), then installing the gimp requires installing jpeg. If we start forcing a unitary build, then eventually we have everything depending upon everything else, and we get into the Windows mess all over again. It *must* be possible to build and install plugins separate from the Gimp tree. Now, that doesn't mean that anything should change *right now*. It's entirely too close to the release, as many people have pointed out, to change something fundamental even if it means an improvement. It seems to me that right now everyone except people working on advanced development should focus on the release. (And yes, however good Print 3.1 becomes, and even if 3.2 is ready before Gimp 1.2 is, Gimp 1.2 will contain Print 3.0. At some point down the road we might want to put Print 3.2 into a Gimp 1.2 refresh or point release, but that's another matter.) -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Shipping which plugins? (was plugins at SourceForge)
Michael J. Hammel said... | |I'm curious why any new plug-ins should be added to the core *at all*. |Gimp's distribution is fairly large as it is. Isn't it getting time to |limit additional plug-ins to the core distribution to plug-ins which are |considered "vital" in some way? Even some estoric file plug-ins need not |necessarily be included with the core package. Throwing in the kitchen |sink is what's starting to bloat some Linux distros. Absolutely. If anything, we should be looking at whether some of them might come out. (Perhaps not for 1.2, since there are books on the way.) Otherwise we end up with something like the USA law, which just grows and gets more complex until nobody really knows it. The core distribution should include all the basic, crucial plugins, and a smattering of interesting/cool ones. Beyond that, we should be looking at how to distribute the rest. - Should we ship packages of somehow related (TBD) plugins? - Should we just use the registry, but with one or more tree views in addition to the monolithic, linear view? - Just stick with the crurent registry? (Good for geeks, too intense for a lot of folks) - Something else? If this has been discussed and is being worked on, and I simply missed it, I apologize. But at any rate, I don't think the answer is shipping the GIMP with every known plugin. Maybe that could be an option, but it should *not* be the default. -Miles
Re: Plugins at Sourceforge
Thus spoke Kelly Lynn Martin > My position is sourceforge should be used at this time only for > plug-ins which are not already in the source tree. Such plug-ins will > not be a part of 1.2 anyway because 1.2 is frozen at this time. When > 1.3 development begins, we can decide what to do with the plug-ins > currently in the distribution. I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Just a thought. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Zach Beane - MINT wrote: > On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: > [snip] > > > > However, since the masses haven't cried out yet, I guess we can try and > > see how it works in practise. > > Count this as a cry out against it. I suggest waiting for a logical pause in > development, such as the release of GIMP 1.2, to begin making these > not-insubstantial changes in source management. Hear hear. Let's get Gimp 1.2 out the door please, before we start mucking with everything's structure? Keep in mind there are lots of users waiting for a `stable' release before they get all the new nifty functionality that 1.2 has to offer. So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN start making changes like this. for 2.0. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As it is now there is the slight danger that the "self-management" >can cause _more_ work for the maintainers. If Sven has to od a >one-line change in every plug-in he would be force to use two >different cvs servers. Well, hopefully this sort of thing shouldn't have to happen; that would occur because of a noncompatible interface change and I'd like to think we can avoid that. (If the interfance needs to be changed, we should offer a "legacy mode" so unadapted plug-ins continue to function.) Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT <[EMAIL PROTECTED]> said: >Count this as a cry out against it. I suggest waiting for a logical >pause in development, such as the release of GIMP 1.2, to begin >making these not-insubstantial changes in source management. My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. Kelly
Re: Plugins at Sourceforge (fwd)
Thus spoke Zach Beane - MINT > On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: > [snip] > > > > However, since the masses haven't cried out yet, I guess we can try and > > see how it works in practise. > > Count this as a cry out against it. I suggest waiting for a logical pause in > development, such as the release of GIMP 1.2, to begin making these > not-insubstantial changes in source management. Make that two cries. Ditto the reasoning. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Plugins at Sourceforge
In ChangeLog : >> Fri Jan 28 01:16:35 CET 2000 Marc Lehmann <[EMAIL PROTECTED]> >> >>* PLUGIN_CVS: updated to give Kevin Turner write access to >>the maze plug-in (therefore, the maze plug-in is no longer >>managable within the gnome cvs server. If you have any >>comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
Re: Plugins at Sourceforge
On 1 Feb, Kelly Lynn Martin wrote: additional plug-ins. Some things, like translations, must be part of the distribution currently. >>>This needs to be fixed. :) >> Do you volunteer? > I don't understand translations at all. :) What a pity... I'm currently trying to dissolve all these problems but while I coding some source I stumbled over a problem with gettext which took me nearly a whole to identify. I would really like someone to give me a helping hand on this to reduce the time and of course I would need someone to wake up Ulrich Drepper because I really need his answer :)) -- Servus, Daniel
Re: Plugins at Sourceforge
On Mon, 31 Jan 2000 08:57:59 +0100 (CET), [EMAIL PROTECTED] said: >>>additional plug-ins. Some things, like translations, must be part >>>of the distribution currently. >>This needs to be fixed. :) > Do you volunteer? I don't understand translations at all. :) Kelly
Re: Plugins at Sourceforge
On 28 Jan, Michael J. Hammel wrote: > Do you mean language locales? I'm not very familiar with working with > multi-language issues, but I have wondered why this isn't handled by > the plug-ins directly. Because it won't work entirely this way... localisation works for everything but the menues which are set up by GIMP at startup time not by the plugins... > GTK supports internationalization, right? Errr, let's say: a little bit > So > shouldn't the plug-ins be responsible for the language issues? Yes, they SHOULD, but it's not possible, at the moment... -- Servus, Daniel
Re: Plugins at Sourceforge
On 28 Jan, Kelly Lynn Martin wrote: >>One possible reason is that it is a pain in the ass to install >>additional plug-ins. Some things, like translations, must be part of >>the distribution currently. > This needs to be fixed. :) Do you volunteer? -- Servus, Daniel
Re: Plugins at Sourceforge
> > This is not at all a distribution issue. Linux is a *multi*-user system, so > > a good answer for it. From my point of view, Gimp is not a multi-user tool > (even if it can run happily on multi-user systems) so should be packaged > for single users. University admins would probably argue otherwise. Whatever, we need a good tool to install other plug-ins later, both for the admin and the single-user case (like CPAN), since the "most interesting plug-ins" (for some user) will not be delivered with the gimp anyway. This will be done, no doubt, after 1.2, and the better it works, the less plug-ins do we have to deliver with the core distribution. We just have to train distribution people to deliver the full plug-ins archive on their cd's (yes, some people still have no internet!), and maybe we could provide a working binary kit. After reading that article about innovative free software and non-innovative gui design, I begin to think that gimp is more prone to be end-user software than, say, gcc ;) (OTOH, I think the gimp GUI is quite innovative: being innovative in GUI design usually lowers the usability index a lot). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 07:14:49PM -0700, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > There are some menus that need adjusting to reduce the number of entries. Some menus (like the file type in the file dialog) still are unusable with some font/screen combination since most of it will be outside the screen. So if the menu is too full, it still should be shown someway (e.g. using wrapping like motif, just a bit better maybe). But that's a gtk+ issue, and I use gtk+-1.2, so maybe that problem is nil already. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Michael J. Hammel wrote: > Thus spoke Marc Lehmann > > This is not at all a distribution issue. Linux is a *multi*-user system, so > > there is not much sense in tailoring the number of installed plug-ins to the > > needs of, say, the admin. > > Playing the devils advocate here, you could also say there is not much > sense in tailoring it for a multi-user system if many of your users are > using it on a single user box. It's a reasonable argument, but there isn't > a good answer for it. From my point of view, Gimp is not a multi-user tool > (even if it can run happily on multi-user systems) so should be packaged > for single users. University admins would probably argue otherwise. Why yes, admins (like me) generally don't like things that are packaged for single users. I suppose I don't care much about whatever packaging changes are made, as long as I can still install the gimp (and plug-ins, and data, and whatever else) in some system-wide location, and as long as users can still put extra bits and pieces in their .gimp directory. Being an admin lets me see a variety of interesting things, such as the guy who ran gimp for the first time, and chose [Ignore] in the gimp installation dialog, and then told me that gimp didn't work right. Why is ignore an option? It doesn't seem to provide anything other than a quick way to make the gimp not work; unless it has some sort of use, it should probably be taken out. later, Andrew Kieschnick
Re: Plugins at Sourceforge
Thus spoke Marc Lehmann > This is not at all a distribution issue. Linux is a *multi*-user system, so > there is not much sense in tailoring the number of installed plug-ins to the > needs of, say, the admin. Playing the devils advocate here, you could also say there is not much sense in tailoring it for a multi-user system if many of your users are using it on a single user box. It's a reasonable argument, but there isn't a good answer for it. From my point of view, Gimp is not a multi-user tool (even if it can run happily on multi-user systems) so should be packaged for single users. University admins would probably argue otherwise. > Most (but of course not all) of the problems are related to the fact that > the menus are too full and can'T be changed, not necessarily that too many > plug-ins are installed (which is mostly a diskspace problem). There are some menus that need adjusting to reduce the number of entries. One thing I noticed today is that there are still menus that don't fit well on my 800x600 laptop. Configurable menus is probably the only good long term solution to this sort of problem, however. Similarly, the Palette options for the Indexed Color Conversion dialog doesn't fit in an 800x600 display using the default fonts. There are so many palettes provided in the distribution that a scrolled list is now a better display option here. -- Michael J. Hammel | The Graphics Muse | Women should put pictures of missing husbands [EMAIL PROTECTED] | on beer cans. http://www.graphics-muse.com
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 19:18:53 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >And yes, I agree with Michael also that 2002 is not a reasonable >target for the next stable release of the Gimp. Target dates are impossible to stick to. I offered 2002 because it took two years to go from 1.0 to 1.2. :) Kelly
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 02:36:36PM -0700, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > They do make it moderately easy during installation, but the default > installations include lots of things many users will never need. But This is not at all a distribution issue. Linux is a *multi*-user system, so there is not much sense in tailoring the number of installed plug-ins to the needs of, say, the admin. Most (but of course not all) of the problems are related to the fact that the menus are too full and can'T be changed, not necessarily that too many plug-ins are installed (which is mostly a diskspace problem). > Do you mean language locales? I'm not very familiar with working with > multi-language issues, but I have wondered why this isn't handled by the > plug-ins directly. Because the plug-ins run in a different process-space from the gimp, but the gimp needs to know translations, and gettetx does not support complex applications like these. > GTK supports internationalization, right? Looking at the current state of gimp, I'd say GTK does not really _support_ i18n :( > Anyway, I could be way off here. No, you aren't ;) What you said is what _should_ be the case, however, existing packages like gtk+ and gettext do not support the gimp model of distributed programs with shared menus. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
From: "Michael J. Hammel" <[EMAIL PROTECTED]> Date: Fri, 28 Jan 2000 14:31:15 -0700 (MST) Cc: [EMAIL PROTECTED] (Gimp Developer List) Thus spoke Kelly Lynn Martin > I agree entirely. It is my considered position that the first thing > we should with 1.3 is remove all, or virtually all, of the plug-ins > from the standard distribution. Moving them to the gimp-plug-in > repository on sourceforge seems practical. All we need to do is Agreed, with a modification: a review of plug-ins should be done so that a set of very useful ones could be left with the core. This would permit a useful, small distribution for *nix distributors to include without having to concern themselves about the added extras on sourceforge. It would also allow the core developers to concentrate on architectural issues and let another group of plug-in developers grow (over time) to handle the extras. I agree. I think that the right question is whether a typical end user would consider something to be core functionality vs. an addon. It doesn't really matter how it's implemented; if an end user expects it as a fundamental part of the application, it's core functionality. That doesn't mean that the development of the core plugins has to be centralized; in our case (presuming that printing is considered core functionality) I don't see any harm in our working on our development series, and releasing stable code to the Gimp core. That's essentially what we're doing right now; I intend 3.0.5 as the version to get into 1.2, unless we have bugs that are deemed high enough priority, but 3.1 is under active development. The more interesting question from our standpoint is what happens when Gimp 1.3 gets underway. My intent is to release versions off the 3.1 development tree (or whatever the latest version that at least passes the paper bag test) into the Gimp development, and then sync up our latest stable release when Gimp 1.4 or 2.0 gets close to release. And yes, I agree with Michael also that 2002 is not a reasonable target for the next stable release of the Gimp. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 23:47:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >Most (but of course not all) of the problems are related to the fact >that the menus are too full and can'T be changed, not necessarily >that too many plug-ins are installed (which is mostly a diskspace >problem). One of the things I would change is allow the user to specify where in the menu system a plug-in goes, when it is installed. The plug-in would provide a default. (Actually, I have a more progressive concept than this, but it's not fully fleshed out.) Kelly
Re: Plugins at Sourceforge
Thus spoke Marc Lehmann > Well, most distros tend to compile every optional feature they cna find > into a program. It's already not too difficult to tailor a distribution, > but nobody does that. They do make it moderately easy during installation, but the default installations include lots of things many users will never need. But that's a discussion for another list, I think. :-) > One possible reason is that it is a pain in the ass to install additional > plug-ins. Some things, like translations, must be part of the distribution > currently. Do you mean language locales? I'm not very familiar with working with multi-language issues, but I have wondered why this isn't handled by the plug-ins directly. GTK supports internationalization, right? So shouldn't the plug-ins be responsible for the language issues? Otherwise it puts a large burden on Gimp to manage something that is already (supposedly) handled at a lower level (the widget kit). Anyway, I could be way off here. Like I said, I don't know that much about internationalization. Or even if that's what you were referring to! :-) -- Michael J. Hammel |We need somebody who can work The Graphics Muse |independently and innovatively in the [EMAIL PROTECTED] |face of unreasonable demands." http://www.graphics-muse.comJob posting at Stanford CS Department
Re: Plugins at Sourceforge
Thus spoke Kelly Lynn Martin > I agree entirely. It is my considered position that the first thing > we should with 1.3 is remove all, or virtually all, of the plug-ins > from the standard distribution. Moving them to the gimp-plug-in > repository on sourceforge seems practical. All we need to do is Agreed, with a modification: a review of plug-ins should be done so that a set of very useful ones could be left with the core. This would permit a useful, small distribution for *nix distributors to include without having to concern themselves about the added extras on sourceforge. It would also allow the core developers to concentrate on architectural issues and let another group of plug-in developers grow (over time) to handle the extras. > develop a good installer tool before 1.4 rolls, which will probably be > sometime in 2002. Oh geez. I hope not. 1.4 by December. Incremental development, I'm hoping this won't stay an all or nothing process. BTW, I've looked at the Loki installer (setup) and think this would be a terrific base for developing an installer for Gimp. It needs some extensions, some of which I discussed in my article on setup on my web site. But it's easy to use and fairly easy to base a platform independent installation package on it. -- Michael J. Hammel |We need somebody who can work The Graphics Muse |independently and innovatively in the [EMAIL PROTECTED] |face of unreasonable demands." http://www.graphics-muse.comJob posting at Stanford CS Department
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 21:40:56 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >One possible reason is that it is a pain in the ass to install >additional plug-ins. Some things, like translations, must be part of >the distribution currently. This needs to be fixed. :) Kelly
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 04:09:55PM -0500, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote: > >One possible reason is that it is a pain in the ass to install > >additional plug-ins. Some things, like translations, must be part of > >the distribution currently. > > This needs to be fixed. :) Wel... we are _about_ to do something, yes.. ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 11:55:20AM -0700, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > I'm curious why any new plug-ins should be added to the core *at all*. > Gimp's distribution is fairly large as it is. Isn't it getting time to One goal of the seperate cvs is to make the choice between "distribute it" and "leave it out" very easy. I imagine that, before some future release, we can just edit a simple configuration file that specifies which plug-ins are part of the distribution and which aren't. That way removing a plug-in from gimp-2.0 would be a matter of commenting out a line somewhere. > necessarily be included with the core package. Throwing in the kitchen > sink is what's starting to bloat some Linux distros. Well, most distros tend to compile every optional feature they cna find into a program. It's already not too difficult to tailor a distribution, but nobody does that. One possible reason is that it is a pain in the ass to install additional plug-ins. Some things, like translations, must be part of the distribution currently. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 11:55:20 -0700 (MST), "Michael J. Hammel" <[EMAIL PROTECTED]> said: >I'm curious why any new plug-ins should be added to the core *at >all*. Gimp's distribution is fairly large as it is. Isn't it >getting time to limit additional plug-ins to the core distribution to >plug-ins which are considered "vital" in some way? Even some estoric >file plug-ins need not necessarily be included with the core package. >Throwing in the kitchen sink is what's starting to bloat some Linux >distros. I agree entirely. It is my considered position that the first thing we should with 1.3 is remove all, or virtually all, of the plug-ins from the standard distribution. Moving them to the gimp-plug-in repository on sourceforge seems practical. All we need to do is develop a good installer tool before 1.4 rolls, which will probably be sometime in 2002. Kelly
Re: Plugins at Sourceforge
Thus spoke Kelly Lynn Martin > My position is sourceforge should be used at this time only for > plug-ins which are not already in the source tree. Such plug-ins will > not be a part of 1.2 anyway because 1.2 is frozen at this time. When > 1.3 development begins, we can decide what to do with the plug-ins > currently in the distribution. I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Just a thought. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: Plugins at Sourceforge (fwd)
Thus spoke Zach Beane - MINT > On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: > [snip] > > > > However, since the masses haven't cried out yet, I guess we can try and > > see how it works in practise. > > Count this as a cry out against it. I suggest waiting for a logical pause in > development, such as the release of GIMP 1.2, to begin making these > not-insubstantial changes in source management. Make that two cries. Ditto the reasoning. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT <[EMAIL PROTECTED]> said: >Count this as a cry out against it. I suggest waiting for a logical >pause in development, such as the release of GIMP 1.2, to begin >making these not-insubstantial changes in source management. My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Zach Beane - MINT wrote: > On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: > [snip] > > > > However, since the masses haven't cried out yet, I guess we can try and > > see how it works in practise. > > Count this as a cry out against it. I suggest waiting for a logical pause in > development, such as the release of GIMP 1.2, to begin making these > not-insubstantial changes in source management. Hear hear. Let's get Gimp 1.2 out the door please, before we start mucking with everything's structure? Keep in mind there are lots of users waiting for a `stable' release before they get all the new nifty functionality that 1.2 has to offer. So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN start making changes like this. for 2.0. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As it is now there is the slight danger that the "self-management" >can cause _more_ work for the maintainers. If Sven has to od a >one-line change in every plug-in he would be force to use two >different cvs servers. Well, hopefully this sort of thing shouldn't have to happen; that would occur because of a noncompatible interface change and I'd like to think we can avoid that. (If the interfance needs to be changed, we should offer a "legacy mode" so unadapted plug-ins continue to function.) Kelly
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: [snip] > > However, since the masses haven't cried out yet, I guess we can try and > see how it works in practise. Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 04:42:57AM -0500, "Garry R. Osgood" <[EMAIL PROTECTED]> wrote: > Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating > where "authoritative source" resides? I'll put the word "sourceforge" into the COMMENT field of any such plug-ins. Does anybody know of a way to merge two cvs files? CVSup reportedly can do that, but it needs the original *,v files and I have no idea what it does in the face of conflicts. As it is now there is the slight danger that the "self-management" can cause _more_ work for the maintainers. If Sven has to od a one-line change in every plug-in he would be force to use two different cvs servers. However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Plugins at Sourceforge
In ChangeLog : >> Fri Jan 28 01:16:35 CET 2000 Marc Lehmann <[EMAIL PROTECTED]> >> >>* PLUGIN_CVS: updated to give Kevin Turner write access to >>the maze plug-in (therefore, the maze plug-in is no longer >>managable within the gnome cvs server. If you have any >>comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
