Hi again,
Sorry I forgot to send the mail from yesterday to the users list - I will
correct that in a moment.
So here is my notes from the second big meeting we had last night, which covers
the upcoming release schedule, things which are considered blockers to 2.0
pre-releases, and how we plan to get 2.0 out the door.
As usual, feedback is welcome.
Happy GIMPing,
Dave.
The Second Big Serious Meeting
-----------------------------
8 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 (bolsh), 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 Joss (romanofski), Maurits Rijk, Branko
Collins (bbc).
Topic discussion, in approximate chronological order:
-----------------------------------------------------
- Features required for 2.0
- Documentation and web
- Roadmap
- Near-term release schedule
- Bugs
- GIMP Foundation
- Release manager
- Features required for 2.0
---------------------------
There was quite a lot of talk on what was required for a 2.0 release.
It was agreed that a pre-release should have feature complete versions
of everything going into 2.0, for obvious reasons. These can be somewhat
buggy, but they should at least support what is supported in the 1.2
equivalents.
The major features or API changes which it was agreed are necessary are:
1) Complete path tool (nomis)
2) Remove libgck (Sven & mitch)
3) Finish the text tool (Sven)
4) Documentation (more on this later)
5) Web-site (again, more on this later)
6) Some libgimp changes which need to be made now so that we can have
binary compatibility across a 2.2 release
- Documentation
---------------
We felt that with pre-releases, the documentation will become more
complete. There should, however, be an effort to actively get people
writing docs. The main requirement, then, for 2.0 pre-releases will be
to have a working help framework, so that when people hit F1 for help,
they at least get a message saying "This help item does not exist yet.
If you would like to help write it, contact [EMAIL PROTECTED]" or some such.
If documentation is going to be released as a separate package, as now
seems likely, then we will need to define the interface between the core
and the help pages reasonably quickly. The general idea is to more or
less hard-code tagnames for a particular help topic, and get the core
and help using the same tags, and agreeing on how they be communicated.
This will presumably require a considerable amount of communication
with the help team.
We also need to have the docs browsable online so that if people want to
browse them they can.
- Web-site
----------
The new site should switch over to www.gimp.org soon. There will
obviously be quite a bit of pain involved as content gets added and we
get lots of "your website sucks" type feedback, but this will only be
for the short term. We should switch to mmaybe as the main site before
2.0pre1. It was suggested to do it even earlier than that, in the region
of 2 to 3 weeks time.
It was also discussed whether it was a good idea to have a separate
coordinator for the website.
- Roadmap
---------
As an approximate set of ideals, it was agreed that we want this:
2.0pre1 very soon, 2.0 soon, 2.2 next year, and gegl integration the end
of next Summer.
More specifically, the near-term release schedule that we agreed was
reasonable is this:
1 or 2 developer releases(one now, more or less, and another one in
another 2 weeks).
6 weeks time (end of September 2003): First pre-release of 2.0,
including the features mentioned above, and any other minor features
that people code in the meantime (hint, hint).
Roughly 3 months later: 2.0
It was more or less agreed that 3 to 4 weeks was a nice turnaround time
for pre-releases, so that would imply between 4 and 6 (inclusive)
pre-releases before 2.0.
The reason for not having a pre-release straight away was mentioned
above: to be feature complete, some features need a little more than 2
weeks work, and people have real lives. So 6 weeks was felt to be a
reasonable amount of time to have the path tool and the help browser in
place.
- Bugs
------
The developer release will also be a prelude to a bug week. We would
like people (that's you, in particular) to actively work on bugzilla
clean-up for 2.0 - bugs need to be prioritized, unconfirmed bugs need
confirming and milestoning (and if you're feeling really helpful,
fixing). The idea would more or less be that the 2.0 milestone will be
locked down for anything other than serious bugs after this bug week, so
if there are bugs that are annoying you a lot, this is your chance to
get them considered and worked on for the 2.0 releases.
Just to spell that out - at the end of the bug week, any bugs reported
against the gimp in CVS will be milestoned for 2.0.x, or even 2.2,
unless they are considered blockers for the release. If we want to get a
2.0 release soon, we need to get lots of testing done, and lots of bug
fixing done, but we also need to choose what to do and what not to do.
We felt this was a reasonable compromise.
It was also re-discussed whether it would make sense to have module
owners. The conclusion was that for certain components, it makes sense
to have a smaller group of people getting the bug reports and having
responsibility for them. This would be done via mail aliases for the
group of people guiding the component, in a similar way to that which is
used for (say) gtktreeview in gtk+.
The module owner group wouldn't have to be technical, and we should be
actively recruiting people to do this kind of work and leave more time
for programmers to program.
This leads us on to...
- Task list
-----------
There are lots of non-technical jobs that need doing around the gimp -
docs, website, bugzilla triage, internationalisation, etc. Often it is
quite difficult to know what needs doing, and who to contact about
getting it done. We need a list of bite-sized tasks that people can do,
including the kinds of tasks that only take a few hours a week to do,
but are ongoing tasks.
We used to have a TODO, and we could use that system again, if someone
were maintaining it. That could come under the remit of the release
manager to some extent, but since the mainenance of the TODO list is
mostly a non-technical task, anyone could do it (in fact, as an example
of a task, "Maintaining the TODO list" would go in the TODO list).
We might do this through Bugzilla using a keyword to allow getting at
the list easily, which would imply getting more people looking at
bugzilla regularly. Then again, if there were a link to a bugzilla query
on the webpage marked "GIMP TODO list" we could get that for free.
- GIMP Foundation
------------------
Basically, we're agreed this is a good idea to have some kind of public
face people and companies can contribute to. There is no problem with
having 2 foundations, one in Europe and one in the US. It was more or
less agreed taht assigning copyright to the foundation isn't going to
happen soon (for a start, so many plug-in authors have gone their merry
way and are almost unfindable) This may hapen in the future, but most
people felt that it would not be something they'd be happy doing
personally.
Other people said they would prefer to assign copyright to an organism
under the jurisdiction of European law rather than under US
jurisdiction.
So, to sum up, there's no reason not to have one of these. Daniel Rogers
has agreed to do the necessary paperwork and set up the foundation and
the bank account for donations in the US. Pretty quickly after
getting that up and going, we will need to get a board of directors and
a set of by-laws. We know lots of people who can help with this (in
particular, the GNOME foundation and the FSF).
If someone wants to set up an equivalent in Europe, we're all ears.
Currently no-one has said they'll do it, so it's an open point. To
start, the foundation will only be a board an a bank account - in the
future, we could expand its responsibilities to promotional work, a
single point where people could go to get speakers, a group that does
press releases and so on. It was agreed that at least in the short term
it is undesirable to have the foundation have actual control of source
code, just in case the foundation then gets sued.
In brief, it's being set up with a very narrow remit, with the
possibility to expand later if it is felt that there is a need.
- Release manager
-----------------
The responsibilities are:
- Follow CVS so that he can write release notes, and knows at any given
time who is working on what, and at what stage it is.
- Follow bugzilla closely
- Make releases regularly, according to the roadmap (or make sure
releases get made)
- Update the roadmap to reflect reality
- Write release notes for the releases (keep NEWS up to date)
- Generally annoy people sending mails to the mailing lists and sending
content to the website to explain the state of play and get people to
work on stuff.
Dave Neary (me) agreed to do this. He already regrets it.
That's it folks - today, Sven and mitch are going to talk to us about
the major changes in the codebase and the general utility stuff which
exists now which has been written from scratch, Calvin and Daniel are
going to talk about gegl and how we can use it, and work towards having
a gegl that we can use in a year. I'm going to lead a discussion on
communication in the gimp, and how to maybe make it easier for people to
contribute, and jimmac is going to demonstrate what a power user really
is.
Goodbye from everyone at camp. As usual, comments are welcome on all
this stuff. While on a philosophical level, we are agreed on the
direction things should take, all the details are open to discussion, if
there's any reason to change them.
Cheers,
Dave.
--
Dave Neary
Lyon, France
_______________________________________________
Gimp-user mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
