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 don't follow you on this track. We have come a long way without a strict hierarchy. I enjoy seeing GIMP as unstructured as it is. The only thing that really bugs me is the bad state of our web-site.
What's with the strict? I'm not talking about a strict hierarchy. I'm talking about a series of people who know bits of the code well, who can decide whether something gets done or not (in other words, we'll finally have some decisions), and who knows who's interested in that code. In other words, a release manager.
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!!!
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 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.
What is your plan? Share it with me, because I'm not clear on what you think the plan is.
I would very much welcome to see a better roadmap being published than what we have currently. Again, the problem is the web-site, not some general lack of structure or lack of leadership or lack of a plan.
The website problems come from the lack of leadership and structure. So do the communication problems. There is no place where you can get the answers to the kinds of questions like "who is responsible for the website?", "How can I get a plug-in added to the GIMP?" - all of those things come from a lack of structure.
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 we don't do something like that, we're doomed to continue developing in all directions like headless chickens without ever getting closer to the goal (colorspaces + profiles + bitdepth + DAGs + everything else).
I wonder what makes you think about GIMP development this way. I do understand if it may appear like this to outsiders (again because of the lack of good public relations, i.e. web-site), but _you_ should be aware that there's a plan and that people are working hard to get things done according to this plan.
I don't think that perceptions like this are just outside the organisation. We do not work well as an organisation. That much is clear. I'm not trying to be an agent provocateur here - I'm tryint to make constructive suggestions for how we can improve the organisation (recognise our leaders, don't refuse any avenues of communication which might get people involved in the GIMP, be nice to people, have a plan and stick to it) - these are all constructive suggestions, but they do imply that I want to change the way we do things.
Cheers, Dave.
-- Dave Neary bolsh@xxxxxxxx
