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
