[Gimp-developer] Project structure
Hi all, I sent this yesterday to gimp-devel but I used the scam.xcf.berkeley.org server, which seems to be still having problems. Re-sending it. I'm also eaving gegldev in the CC, just to keep a common thread for cross-posts. === The major problem that this project has at the moment is its lack of structure. There are no bosses, no maintainers, no active developers (this is a point where I agree with Robin Rowe). I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Maintainer: Sven Neumann Module owners: Vectors: Simon Budig Core: Sven or Mitch perl bindings: Seth Burgess Python bindings: ? PDB/libgimp: ? Plug-ins: ? (stick with plugin-maintainers?) GAP: Wolfgang Hofer Help: Roman Joost GEGL nodes: Calvin Williamson GEGL data: Dan Rogers I've deliberately left out some obvious modules (web, because it seems that this is now dead, for example). What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review. It puts names and faces on the organisation for magazines, articles, interviews, presentations. It also obliges people who already have a certain amount of authority and responsibility in the project to assume that responsibility, rather than shirking it by saying that everyone's voice has the same weight. This is clearly not true. I don't expect any of the names to be particularly controversial. This is a request for comments, though - so comment away. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Dave Neary [EMAIL PROTECTED] writes: What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review. I think our policy is to encourage people to use bugzilla and the mailing-lists, and not to contact developers directly. I for one do generally not accepct any private GIMP-related mails. This doesn't mean that I ignore them but in most cases I ask people to use the public channels. I believe that this policy is a good thing. If we ask people to contact developers directly, we rely on these developers being responsive at all times (which they cannot be, they might be busy or on vacation). We would encourage off-list discussions and those bear the risk that imporant ideas are lost because the right people don't hear about them. It also means that these discussions are not archived and generally not accessible by the rest of the crew. It puts names and faces on the organisation for magazines, articles, interviews, presentations. Is that desirable? Wouldn't it be nicer if we could show the world that GIMP is a collaborative effort? I agree that we need to communicate better and that in particular the web-site should be improved. But I would rather like to emphasize the team aspect than to put names on the official GIMP site. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Foundation
On 8 Mar 2004, at 23:09, Kelly Martin wrote: Sven Neumann wrote: If sueing copyright violators is the main goal, I'd rather let the Free Software Foundation do this job. It is probably in a lot better position when it should ever come to a law-suit. The FSF can't sue someone unless it owns at least some part of the code in question. The FSF's solution to this has been to seek assignment of copyright. Do you want to assign the GIMP copyrights to the FSF? Sven cannot assign _all_ GIMP copyrights to the FSF, since he does not own them. He can, however, assign _his_ copyrights to the FSF (as can anybody else, for that matter). (This is undoubtedly what you meant, I am just stressing it to clarify.) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review. I think our policy is to encourage people to use bugzilla and the mailing-lists, and not to contact developers directly. Do you mean is, or should be? I agree that that is the current policy, but disagree that things should be like that. Mailing lists and bugzilla are for the most parts an excessively high barrier to entry for people not already in the community. The quantity of mail we're talking about is not huge either - just because a name is on a website somewhere does not mean that all of a sudden they're going to get slashdotted by 1 mails a day. ... in most cases I ask people to use the public channels. I believe that this policy is a good thing. I believe we should be much more flexible about how we use those public channels, too... for example, someone recently reported a bug on a mailing list. The bug was confirmed on the mailing list, and the fix was trivial. In spite of that he was asked to create the bug on bugzilla so that it would be fixed in the next release, which probably meant taking 5 more minutes than he had already taken to create a bugzilla account. That was, imho, unnecessary. Similarly, someone complained about the interface to another feature in bugzilla, claiming that there was no way to do task X, and that this was a bug. He was asked to contact the user list if he didn't know how to do task X. Again, this was IMHO excessive - especially given that the feature in question is pretty well hidden, and currently undocumented. In the same way, private e-mails are often a lot less intimidating than mailing to a public list which is often not very welcoming (there are countless examples of people understandably not knowing about stuff getting told off for not doing their homework on the lists). For example, the person who is currently the most active contributor to gimp-help-2 has never sent a mail to the list, because he's not particularly technical, and he doesn't feel comfortable mailing the list. Private e-mail is a much nicer way to get involved, particularly if you manage to talk to someone who listens to you and encourages you. I sent my first patches to Daniel Egger, because his name appeared pretty often in the changelog at the time. Daniel was very nice, pointed out where I could improve my patches, committed them for me, and at a certain point pointed me towards the lists and towards mitch when the patches got a bit bigger. In short, Daniel made it easier for me to contribute. If I send a patch to the list, it's actually sending it to no-one. Same thing with a bugzilla report. No-one is responsible, no-one says I can't help you with this - but person X might. There is no way to know whether a patch will get applied, acknowledged or whatever. Plus, I need to sign up for a list where I might get another 100 mails a month to add on top of the 2 or 300 I already get if I'm a free software developer. I'm not saying that we should actively encourage people to send mail directly to developers, I'm saying that we shouldn't actively *discourage* avenues of communication. If someone contacts me personally with a question (which happens more and more frequently), I reply to the question as best I can. I'm reasonably pleasant, polite and friendly. If I can't help them personally, I might add someone better placed to help as a CC. Or I might reccommend that they ask the list. But if I can help, I do. Sure, there might be some gem of wisdom lost to the mail archives, but the chances are that the GIMP has made a new friend, someone who'll go away and say that the GIMP guys are really nice and approachable. If instead I say I can answer your question, but first you have to sign up to a mailing list and ask your question there, they're more likely to go away thinking that the GIMP guys are kind of uptight, maybe they'd consider that rude, perhaps they might even go away saying that the GIMP developers are arseholes. Bear in mind that this has very little to do with the fact that you're being polite or impolite. They're asking for help, and you're insisting that they conform to an artificial structure which makes them go out of their way to get help. If we ask people to contact developers directly, we rely on these developers being responsive at all times (which they cannot be, they might be busy or on vacation). We wouldn't be asking people to contact developers directly. We'd be not asking them not to. And no-one expects an individual to be any more responsive to personal mail than normal. It's not a duty call, there is no-one holding a gun to anyone's head. You're simply opening up the possibility of another, friendlier way of getting involved in the GIMP.
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: It is a very common policy for a lot of projects that all bugs must be reported in Bugzilla. Some projects even go so far that you must not commit anything w/o refering to a bug-report. I don't think we need to go that far but I think that it is important that bugs are entered in Bugzilla. If someone reports a bug and the bug is confirmed on the mailing list, it's a 30 second job to enter it into Bugzilla if you know bugzilla and have an account. I think that it would be nice for us to accept bug reports via that channel, and then create the bug in bugzilla when it's been confirmed (for example). So far every bug reporter who was asked to use Bugzilla has managed to create a bugzilla account and has entered his/her bug there. A couple of times I have had to nurse people through a bugzilla account creation and how to create a bug. Bugzilla's interface sucks (at least the version we use), so I imagine that lots of other potential contributers don't bother getting over that barrier. If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten. Not if we put them in bugzilla. If I send a patch to the list, it's actually sending it to no-one. Same thing with a bugzilla report. No-one is responsible, That is simply not true. If you file a bug-report against GIMP, you usually get a respone in less than a day. The problem is entered into a database for later reference and a bunch of people immidiately get to know about it and can comment on it. While some people spend a lot of time on bugzilla, and every report gets commented on, it's hardly a formalised process for getting code into CVS. I stand by the point that when you send mail to a mailing list or attach an attachment to a bug in bugzilla, no-one is responsible for it. I haven't yet seen anyone who didn't subscribe to the lists and asked there. What you get is another happy user of the mailing list that might soon start to answer questions of other users or become otherwise involved. I've seen quite a few people who haven't gone on to the lists. I think that you're being idealistic to think that everyone you direct towards the lists will sign up and join in. Usually there is a certain amount of benefit you have to get back to first sign up to the lists. Once you're signed up, sure, you might end up an active contributor. Bear in mind that this has very little to do with the fact that you're being polite or impolite. They're asking for help, and you're insisting that they conform to an artificial structure which makes them go out of their way to get help. Do you have an example to keep up this argument? From my experience it is void. There have been several occasions when people on the user list, or on IRC, or on the devel list, have said that they resented having to sign up to bugzilla to report a bug. There have been several occasions similarly that people have been a bit annoyed on IRC at being asked/told to sign up to mailing lists. That's probably the worst thing that could happen. I can live with the idea of people discussing development in private emails but patches hiding in private inboxes instead of being attached to Bugzilla is what can kill an open source project. The patches shouldn't rest there, but they should arrive at the person best able to handle them. If needs be, they should be attached to a bugzilla report afterwards. Again, I'm not saying that we insist that things happen this way, just saying that we shouldn't forbid people from getting into the project via a kind of mentor relationship. But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. Also, we have tried every so often to keep a list of module owners. All you get is a list of names that is outdated before you finished to put it on online. Have a look at PLUGIN_MAINTAINERS. Do you really want to publish this? The responsibilities and interest of GIMP developers are changing, new people coming, other people retiring. Any attempt to track is futile. It's hard to keep track of things like the owner of the gif plug-in, say - sure. But there needs to be some hierarchy. There needs to be someone in charge to co-ordinate things. That someone should know at any given moment who's best able to handle a particular problem, or who's the best person to bounce ideas off about some functionality or other. Only because the German football team does it, we don't have to do it that way, do we? No, but we should. If every team in existence has a leader, it's because that's a decent way to get the team working well together. I
Re: [Gimp-developer] Project structure
Hi, Dave Neary [EMAIL PROTECTED] writes: If someone reports a bug and the bug is confirmed on the mailing list, it's a 30 second job to enter it into Bugzilla if you know bugzilla and have an account. I think that it would be nice for us to accept bug reports via that channel, and then create the bug in bugzilla when it's been confirmed (for example). Now this turns into something we can easily aggree on. Simply because that's how it is handled already. So we will continue to encourage people to use Bugzilla and if they don't do it themselves, we put the bug into Bugzilla for them. This is good since over the last year we put a lot of work into establishing a reasonably well-working way of handling bug-reports. We cut our response-time to bug-reports down to a few hours and we cut the number of bugs down to about a third of what we had a year ago. This is definitely a success and I don't see a reason to change anything about that. A couple of times I have had to nurse people through a bugzilla account creation and how to create a bug. Bugzilla's interface sucks (at least the version we use), so I imagine that lots of other potential contributers don't bother getting over that barrier. Face it, if someone is not even willing to create a bugzilla account, he/she is hardly a potential contributor. So please continue to put other people's bug-reports into bugzilla (although this is a bad thing in general since it makes it impossible to get in contact with the bug reporter and ask for more details). Preferably though, nurse people through creating a bugzilla account. That is a very much appreciated effort and noone said you shouldn't do that. If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten. Not if we put them in bugzilla. See my comment above. It is important to have the bug reporter create the bug-report herself. Of course if you can reproduce the problem, it is less of an issue but in general it is important. While some people spend a lot of time on bugzilla, and every report gets commented on, it's hardly a formalised process for getting code into CVS. I stand by the point that when you send mail to a mailing list or attach an attachment to a bug in bugzilla, no-one is responsible for it. I don't see why it should be that way. What's wrong about using bugzilla for patches? It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. Believe me or not, but I think getting patches into The GIMP has never been easier than today. That doesn't mean that it could not be improved but IMO bugzilla is the way to go. The patches shouldn't rest there, but they should arrive at the person best able to handle them. If needs be, they should be attached to a bugzilla report afterwards. Again, I'm not saying that we insist that things happen this way, just saying that we shouldn't forbid people from getting into the project via a kind of mentor relationship. I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. there's no plan. We need a plan. There is no plan? I think we have a very decent plan. What is it? I published a set of dates, and a set of funtionalities, for 2.2 recently, and it was out of the question that we use dates (even though we ended up using rough dates anyway), and the list of functionality doesn't exactly constitute a plan. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant
Re: [Gimp-developer] Pushing the 2.0 release
Hi Sven, Sven Neumann wrote: think we can get GIMP into shape for 2.0rc1 until sunday. Since this will involve quite some hacking, we should IMO do a 2.0rc1 tarball but the idea is that unless there are major problems with this tarball, 2.0.0 should be released a few days later. This sounds great. Thanks. PPS: I would also appreciate if people would not spend their time with discussions that are not related to the 2.0 release. These can probably wait until 2.0 is out of the door. I'll work on the press pack this weekend. As to the other discussions, I guess that we can talk more about the project's organisation after 2.0. 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] Pushing the 2.0 release
On Tue, Mar 09, 2004 at 07:46:16PM +0100, David Neary wrote: Hi Sven, Sven Neumann wrote: think we can get GIMP into shape for 2.0rc1 until sunday. Since this will involve quite some hacking, we should IMO do a 2.0rc1 tarball but the idea is that unless there are major problems with this tarball, 2.0.0 should be released a few days later. This sounds great. Thanks. Ditto. PPS: I would also appreciate if people would not spend their time with discussions that are not related to the 2.0 release. These can probably wait until 2.0 is out of the door. I'll work on the press pack this weekend. As to the other discussions, I guess that we can talk more about the project's organisation after 2.0. Just to avoid duplicate efforts, I guess we should try to tell who is doing an announce and where. I can do the announce on linuxfr (french linux related news site), if nobody object. Who will do on slashdot, and other major news sites? Regards, DindinX -- [EMAIL PROTECTED] Why is the third hand on the watch called a second hand? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Printing with gimp 2.0 German
Hi The print output from gimp2.0pre4 german is also buggy like in the previous versions. If i like to print with gimp with LANG=en is all ok. If i use [EMAIL PROTECTED] it does not work. With the same printer preferences Cups with turboprint printername - Stylus640, printer - PostScript Level 2, command - lp -s -dStylus670, pppd-file - /usr/share/cups/model/turboprint/Epson_StylusColor670.ppd it works with english language. But if i change to german i get no preview. The developers from turboprint mean its a bug in the translation of floatingpoint numbers if using german. It translates the decimal point to a decimal comma. Knows anybody something about this? Thanks Frank ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re : [Gimp-developer] Printing with gimp 2.0 German
Le 09.03.2004 20:39, Frank Noack a écrit : Hi The print output from gimp2.0pre4 german is also buggy like in the previous versions. If i like to print with gimp with LANG=en is all ok. If i use [EMAIL PROTECTED] it does not work. With the same printer preferences Cups with turboprint printername - Stylus640, printer - PostScript Level 2, command - lp -s -dStylus670, pppd-file - /usr/share/cups/model/turboprint/Epson_StylusColor670.ppd it works with english language. But if i change to german i get no preview. The developers from turboprint mean its a bug in the translation of floatingpoint numbers if using german. It translates the decimal point to a decimal comma. Knows anybody something about this? Thanks Frank The locale that fixes the decimal is LC_NUMERIC. The value for this for fr_FR ou de_DE is the comma. I suppose the bug is in Turboprint which is not aware of the locale. A call to setlocale() should be done in this program ... A quick fix is to use LC_NUMERIC=C in your environement. Doing so you will get everywhere a dot instead of a comma as a decimal separator which is IMHO harmless. -- Regards - Jean-Luc pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Printing with gimp 2.0 German
Am Tuesday 09 March 2004 20:39 schrieb Frank Noack: But if i change to german i get no preview. I dont get only now preview, i cant also print. The job hangs and blocks all other printing jobs. Frank ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I don't see why it should be that way. What's wrong about using bugzilla for patches? Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that. It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. I'm not advocating going back to an upload directory... I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). The encouraging needs to be done the right way. Something along the lines of thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me is good. Something like Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there is bad. I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules. I'll maintain this if I know who to send it to for the website. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... I take it you've never heard about the underpants gnomes. Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005. The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time. That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do. We should have this discussion over the next couple of weeks, as soon as 2.0 is out. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details. We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time. And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features. Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits down, evaluates them and starts to hack on CMS integration for GIMP. Of course we could decide today that it needs to be lcms. But what would that yield? By the time that someone wants
Re: [Gimp-developer] Project structure
I would be willing to maintain the module maintainers list as well as any other lists relating to who to contact about this or that. On Tue, 2004-03-09 at 14:23, David Neary wrote: Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I don't see why it should be that way. What's wrong about using bugzilla for patches? Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that. It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. I'm not advocating going back to an upload directory... I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). The encouraging needs to be done the right way. Something along the lines of thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me is good. Something like Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there is bad. I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules. I'll maintain this if I know who to send it to for the website. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... I take it you've never heard about the underpants gnomes. Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005. The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time. That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do. We should have this discussion over the next couple of weeks, as soon as 2.0 is out. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details. We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time. And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features. Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits
Re: [Gimp-developer] Project structure
On Tue, Mar 09, 2004 at 09:29:02AM +0100, Dave Neary wrote: I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Help: Roman Joost If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Gimp-developer] Pushing the 2.0 release
David, Please forward me the press release as well. I work for TweakTown.com, a hardware/software review site that's pretty big, and I would like to make a big mention of the GIMP 2.0 release. I will also be writing an article about it and am currently redesigning the site with the GIMP2.0pre series. ;) Thom Also, my apologies to everyone about not shortening the previous message.
[Gimp-developer] Bugs on milestone 2.0
Hi, I've made a list of all bugs on milestone 2.0 (there were 26 of these at the time of this writing) and added some comments. I'd like you to review this list with me and take ownership of bugs if you think you can fix them. It would also help to have the bugs better prioritized in Bugzilla. Blockers should be marked as such. Bugs not marked as blockers will be moved to the 2.0.1 milestone if they don't get fixed before sunday. Some of the bugs listed can IMO be moved to 2.0.1 or even 2.2 immidiately. I've added comments if I think that's the case. If you disagree with any of these comments, please object now. Do we have a volunteer with some free time and bugzilla permissions who wants to help me with the bug maintainance? 130985 Tools Text tool broken with respect to Undo I consider this a blocker but I think I can fix it this week. There are probably some optimizations that should be done on the undo stack but these can wait till after 2.0. 133719 User Interface crashes on paste This doesn't look like a crash but rather like an endless resizing loop. This should be fixable by always allocating the space for the alpha channel in the channels list. Since this problem only shows up with a rather uncommon, very condensed docks setup, I don't consider this a blocker. But it might be an easy fix. 136636 Tools Selection mode modifier affects selection at mouse release Looks like a GTK+/GDK problem to me. It doesn't crash GIMP but it makes some actions with selections impossible on Windows. Should not be considered a blocker but it needs to be addressed soon. 136219 Tools crash with shapeburst gradients (adaptive supersampling / ma This one has a PATCH attached that fixes it but Pedro would prefer a better fix. Will be fixed before 2.0, one way or the other. 131965 General Deletion of layer with brightness-contract active This is data loss but on the undo stack only. This is critical but it shouldn't block the release. We don't seem to have much clue what is going wrong here. 120021 General GIMP Crashes when undoing editing of a blured text layer This should get fixed when text undo is redone, see #130985. Better to keep it a separate bug report to make sure this particular use case is being tested. This is a blocker. 136623 General text layer paint problems Blocker, since it's a crash. Seems to be caused by some code I added recently. If I don't get this fixed, I will revert said change. 136645 General Text and Texture Could be the same bug as above (#136623) or it is similar one. Reverting the change mentioned above should fix it as well. 93806 Script-Fu Script-Fu args parsing needs to be made sane This can IMO be moved to 2.0.1 immidiately. 124176 General assertion `gimage-group_count 0' failed when performing undo Pobably hard to fix since there isn't even a descrption on how to reproduce. We shouldn't block the release with this. 120490 Tools Scale tool produces wrong output (misses parts of image) Looks like some rounding bug. Data loss but not a crasher so I don't think it should be seen as a blocker. 115774 General Tablet pointer becames core pointer Noone knows what's causing this one and Simon found that it might be fixed with latest versions of all libraries involved. Tablet support is important but shouldn't block 2.0. 76228 Tools brush scaling algorithm fails for large brushes Doesn't seem to annoy anyone badly enough to fix it, so it can as well be bumped to 2.2. Would probably be a local change that can be easily backmerged to the 2.0 branch. 128594 Tools Rotating layer more wide than 16000 pixels causes problem on Doesn't look like a blocker to me. 118356 Tools Switching font units should maintain same text height I would better fix this. Shouldn't be too hard if some uglyness is allowed. 136489 Script-Fu gimp-edit-copy fails on transparent area This is strictly speaking an API change but it seems we better do it since the current API is just plain broken, 128833 User Interface Tool dialogs block image (crop tool) Smells like another user preference. For anyone comfortable with GimpConfig, this is an easy change to GimpToolDialog, GimpGuiConfig and a line or two in gui/preferences_dialog.c. 123888 Plugins PSD images gets wrong modulo Can IMO be moved to 2.0.1 at once. 112859 User Interface transform tools' preview should take linked-group in conside Not critical but it would
[Gimp-developer] choosing fonts
Hi all, I find that when you have more than ten fonts and try to choose a good one, it takes lots of time because you have to click in everyoneblah..blah If you could make a feature so one can youse the arrows on the keyboard and see how a font looks, down arrow and check out the next font instead of having to click so many times. Also adding letter spacing feature wouldn't be too bad. Thanks for all your efforts, Gezim __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Foundation
Hello, First of all I'd like to thank Daniel for putting a lot of work into investigating what needs to be done in order to launch The GIMP Foundation. On Mon, 2004-03-08 at 15:58, Daniel Rogers wrote: THINGS TO BE DECIDED [snip] 1. Will TGF have members? I am talking about members with voting privledges, like I described above. (my vote is yes, btw) Yes, if we decide to form TGF I believe we should allow the foundation to have members. 2. Should the membership be paid? (my vote is yes, for like $50 a year or some toher small amount. It helps for tax purposes). How does paid membership help for tax purposes? What exactly will the benefit of paid membership be? 3. Should the membership have additional rights? Such as...? Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] The GIMP Foundation
Hi all, Sven Neumann wrote: Also, so far the FSF has done a great job at funding our developer conferences. So we should really have good reasons to form our own foundation since I don't expect the FSF to grant any more fundings as soon as The GIMP Foundation has been created. This is not a vote against the TGF; it's just something to keep in mind... I don't see why this should be the case, unless we have a sufficient revenu stream to fund ourselves. In any case, to have any revenu at all we need an organisation and a bank account, since a private individual accepting donations for a non-existent organisation isn't very professional or reassuring, never mind the fact that it opens up, as Dan said, channels of liability for the individual involved. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Foundation
Nathan Carl Summers wrote: Is this required to be in person, or is conference call/irc/email/etc sufficient? Furthermore, is it possible for board members to be reimbursed for expenses? I can see this being a major obstacle for non-us residents otherwise. Kelly already answered the first part, but yes. If TGF has money, it's board members can be reimbursed for the expenses of attending a meeting (including phone bills, even), without destroying it's non-profit status. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
