Hi, Sven Neumann wrote: > Dave Neary <dneary@xxxxxxx> 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 to start hacking on this, a better CMS might be > available. Or that someone who is willing to hack on it feels more > comfortable with the API of a different CMS. Do you want me to point > to the plan and say "Hey, it got to be lcms because we said so half a > year ago!"? No thanks, I am not going to do that. Nope, not at all. But gegl has been on the roadmap for 4 years now. gegl will have the API we want it to have. But we need to say what we need that API to be, and figure out how we'll use it. Of course, in the meantime perhaps someone will liberate a brilliant gegl-like image processing framework, and we can use that instead (that will probably not happen, though). You're not setting things in stone by saying what you're going to do. > > There has been lots of discussion, but no decisions, on what gegl > > needs to be ready, how that will happen and when, nor has there been > > any decision (again, lots of discussion) on how gegl will actually be > > integrated into the GIMP, what implications that has for the > > interface, at what points we have interim milestones where we can > > settle things down and have a release, etc. > > I don't see how we could possibly make such a decision today. I also > don't see how such a decision would be helpful. This is very technical > stuff. Most of the developers that would have to do such a decision > haven't made themselves comfortable with GEGL yet. We have always said > that we will start to go into these details when GIMP 2.0 is out. That's reasonable. We will talk about all of those things next week or so. > Why > do you question the whole project now that we are only some days from > this goal? Really, I don't get your point (or rather, I don't > understand your timing). The timing was due to other events which caused a build-up of stress - the recent discussion of 2.2 features and dates, the fact that 2.0 keeps getting delayed, the Mark Shuttleworth offer, and the ensuing discussions, which showed up some of the weaker points of the organisation, and general stress in life outside the GIMP. The timing might be off, but I believe that most of my points have merit. I think hand-holding is the way to get more people involved in the GIMP. I think we shoudl say who is responsible for what (at least partially), and I think we should plan ahead for gegl integration now (+/- a couple of weeks) to allow the gegl developers to work towards that goal. > And I don't think such a discussion needs to end in a decision. We disagree. > Whoever writes the code decides about the implementation details. You > don't need a leader or module owner for that. You need serious hackers > that have fun doing some serious hacking. Sure, but you need hackers, and somewhere along the line, most people have a tendency to ask "does anybody mind if I try to do this?" All you're doing by having a guy in charge is having someone who can say "you should contact X, he started on that earlier and would love the help", or "No, fire ahead - that would be cool". > If you put up team leaders > and module owners all over the place, people will not any longer want > to hack in this environment. People do that all day long in their > daytime jobs already. Again, we disagree. We're not talking about imposing a hierarchy, but theer has to be some structure. Anyway - as you say, we'll talk about all this stuff in 10 days or so after 2.0. Cheers, Dave. -- David Neary, Lyon, France E-Mail: bolsh@xxxxxxxx
