Hi, Dave Neary <dneary@xxxxxxx> 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 future. Technical decisions need to be made when the time has come to go into the technical details. 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. > 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. 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). > I recently (based on a proposal of Dan Rogers) came up with a > medium-term planb for integrating gegl into the GIMP, which included > functionality lists, rough dates, and so on, which brought me to the > end of 2005. That's just a piece of paper without much value. You don't know if Mitch sits down next weekend and has half of your estimated hacking down before the sun rises Monday morning. There are way too many variables in such a calculation. Sure it's a plan because it has "Plan" written on top of it. However it would be a lot better if it had "Proposal" written on top of it and would be subject of discussion here. And I don't think such a discussion needs to end in a decision. 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. 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. > What is your plan? Share it with me, because I'm not clear on what > you think the plan is. I am sticking to the plan that we made together last year. And the plan was to get 2.0 done, then start to think about what we want to have in 2.2. We also decided that we want 2.2 early, that we want to attack our goals one by one without giving up stability. As soon as 2.0 is out, I would like to prepare a list of things that could go into 2.2. Having 2.0 out should also give everyone time to look at GEGL and think about how it can fit our needs, what it is lacking and how we could start using it. > And I'll say it again - we do not have a lack of leadership. You are > the leader. This is clear to everyone. What we have is a lack of a > leader who says he's the leader. If you want me to say something definite, here are my words: Calm down, help us doing 2.0 or help us doing the web-site for 2.0. If you want a plan for the time thereafter, then come back later when these goals are finished and discuss it with us. And now let's get back to some serious hacking, damned! Sven
