Hi,
Seems like the attachment got stripped by the mail software, so I'm sending this
again, only this time inline.
As before, these discussions are going to be posted here to give people a chance
to give feedback, even if they can't be here.
Thanks for your time,
Dave.
The First Big Serious Meeting
-----------------------------
7 Aug 03, around 8pm
Discussion was led by Daniel Rogers (dsrogers) but stuff said is for
the most part anonymous. Partly because there shouldn't be any ad
hominem attacks that way, and partly because I didn't take down any
names.
Present:
Dan Rogers, Raphael Quinet, Dave Neary, Sven Neumann, Mitch Natterer,
Hans Brix Anderssen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
Marc Lehmann, Ville Patsi (drc), Oyvind Kolas (pippin), Calvin
Williamson, Roman (romanofski).
Absent but at camp: Maurits Rijk, Branko Collins.
Topic discussion, in approximate chronological order:
-----------------------------------------------------
- The GIMP foundation
- Release manager
- Decision making (or lack of it)
- General stuff about CVS, Bugzilla
- Communication
- The GIMP Foundation
---------------------
The idea of a foundation was proposed. Lots of ideas were thrown about
as to what kind of remit it would have. If created, the foundation would
certainly have 2 thinsg we don't have at the moment - a bank account
people could donate to, and a focus on "marketing" in the broadest
sense of the word.
Some of the issues were whether the foundation would be set up in Europe
or in the US (in the US it might make it easier to get donations from
US companies, but in Europe we're not as litigious, so setting up would
certainly cost less, but then we probably wouldn't have NPO status in
the US), whether it would have any technical aspect (that is, would the
foundation act as a kind of steering committee for the general direction
of the GIMP?), and how, if the issue came up, we might pay someone.
This led onto a discussion of whether the foundation would be
responsible for setting release dates, or whether we would have a
separate...
- Release Manager
-----------------
The general concensus (more on that later) was that a release manager is
a good thing. There do seem to be a few different ideas of what the role
would entail. The general idea would be that the release manager would
be responsible for following CVS and know at what stage a given feature
is at, follow bugzilla making sure that bugs got milestoned for some
release in order of their priority, would annoy people to get commits in
before feature freeze dates or postpone mercilessly features which are
not finished.
It was agreed that a release schedule would be helpful to define the
perimeters of responsibility of the release manager - basically, some
way to set up large milestones to aim for with things to go into those
milestones. This release schedule would be subject to revision, and
would be no more realistic than any other release schedule, but it would
serve as a guide for development. Dan agreed to draw up a first draft of
this, and we'll have something more concrete before the end of the
weekend.
The questions that came up about the release manager were things like
where his authority comes from, how does he decide which bugs are
important and which features can be postponed and so on. In other words,
how do decisions get made. Is the release manager a benevolent dictator,
or does he answer to the larger developer and user community? If so, to
what extent? Is backing out CVS commits OK, for example?
So we started talking about how to get contentious decisions made.
- Decision making (or lack of it)
---------------------------------
Currently, there are two ways to get something done in the gimp. First,
you can write decent code and patches for a while, until you get CVS commit
access, then you write whatever feature you're interested in, and commit
it. If no-one backs it out, then it's in.
Second, you can bring it up on the mailing list, or in bugzilla, or in
IRC (more on communication later), and discuss it until there is a
concensus. However, we tend to be pretty bad at reaching concensus on
anything even slightly contentious. The important questions to be
answered any time a discussion like this comes up are what's going to be
done, and who's going to do it.
It was agreed that beyond a certain point, there is generally very
little technical merit to these types of discussions. It was felt that
about 5 days was enough for everyone with an opinion on a given matter
to make that opinion known, and that after that point, it would be an
idea to have a summary of the salient points and close the discussion.
That means, the people here would stop posting to the discussion. Of
course, if other people want to keep on flaming, they're free to do so,
but people will just ignore the thread.
At this point, the summary should sum up the various points, and finish
with an answer to those two questions - what gets done, and who's doing
it.
We may even have a bake-off system. If there are two competing ideas for
the way something should be done, currently no-one tends to do it.
Ideally, both people would do it and we pick the best one.
This brings up another point, though - in general, what is authority?
And in particular, at what point has someone gained enough standing and
authority to post one of these thread-ending summaries? Some discussion
is going to be had on that over the weekend.
- General stuff, about Bugzilla and CVS
---------------------------------------
We talked about various ways of improving the way we use these tools.
First is whether it makes sense for us to have module owners, and if so,
who should they be? Should we use the system of bug owners to track who
is responsible for a bug at any given time, or is the current scheme of
bugs@xxxxxxxx sufficient? Do we need to change bugs@xxxxxxxx to
something else to avoid confusion with the old bug reporting address?
There were a few open points in here.
Second, we talked about pre-release branches, and whether it would be
worthwhile having a mozilla style release cycle with feature-freezes,
followed by concurrent bug-fixing before unstable releases, freeing up
the branch for bigger stuff that people want to start committing. In
general, it was felt that there was very little to be gained from that,
and the current system of a long-lived devel branch with self-imposed
feature freezes every few weeks was a better way to go.
We also expressed a desire to have more redundancy in the non-technical
aspents of the GIMP, things like the mailing lists and ftp mirror lists
should have more than one person with the ability to change them so that
if there's a problem, and that person has no time to take care of it,
then someone will. Perhaps using a Debian or GNU style ticket system
might help here fro these particular tasks? In any case, everyone in a
given group should know everyone else in the group, and know more or
less that when an issue gets in, it will be handled by at least one
person.
- Communication
---------------
It was agreed that we need to communicate better (that's a no-brainer,
really). For a start, every developer should e subscribed to the user
list. gimp-devel (if it doesn't disappear altogether) would only be used
for technical discussions of implementation details - all the
philosophical level discussions of new features, ui changes, release
mechanisms and so on should be discussed on the user list.
Basically, we're going to talk a lot more about how the developers can
interface better with the users.
- Decisions
-----------
Not too many of these... we will have a release manager, but we need to
define exactly what his/her remit will be. And who it will be. We agreed
that the "5 days and it's dead" rule for threads makes sense, so that
will be done.
- Future
--------
1) Roadmap - rough release schedule, we will have a first draft today.
2) GIMP Foundation - we need to define its responsibilities, set up
election rules, and get this set up. The principle of the foundation is
more or less agreed.
3) Communication
4) Release Manager - what'll he do, who'll he be. This should be short
once we have discussed communication channels a bit.
5) Technie stuff - Sven and mitch are going to talk to us about the
re-organisation of the code, GObjectification of everything, and other
stuff. Daniel and Calvin are going to talk to us about Gegl and how they
feel the GIMP could use it. This will probably be a two-way discussion
about what kind of things we expect gegl to furnish as well.
6) GIMP tutorials - jimmac and nomis are going to do some presentations
for people, which should be good.
7) Plug-in distribution - 3 years ago this was discussion, yosh has been
working on something as a proof-of-concept, it would be nice to address
this and get something in place soon.
So there you go. Hello everyone from camp.
Cheers,
Dave.
--
Dave Neary
Lyon, France
