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
> >>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!
Gimp-developer mailing list