[gimp-web-devel/hugo: 5/16] build advice
- From: Jehan <jehanp src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gimp-web-devel/hugo: 5/16] build advice
- Date: Sat, 6 Aug 2022 14:04:34 +0000 (UTC)
commit 3232bb8c37d3454b9a71516e28c5f6e69705e7c4
Author: robin-swift <robinswiftart gmail com>
Date: Sat Jul 23 22:48:01 2022 +0100
build advice
Makefile | 5 -
README | 84 ++--
content/gimpcon/2003/gimpcon2003-mins-1.md | 487 ++++++++-------------
content/gimpcon/2003/gimpcon2003-mins-2.md | 658 +++++++++++++----------------
4 files changed, 508 insertions(+), 726 deletions(-)
---
diff --git a/README b/README
index 3bafa09..452314a 100644
--- a/README
+++ b/README
@@ -1,55 +1,37 @@
developer.gimp.org
------------------
-This CVS module holds the source for the developer.gimp.org website.
-CVS commits to this module cause the website to be updated immidately.
+This git repository holds the source for the developer.gimp.org website.
+
+Commits to this module cause the website to be updated immediately.
So please do test all your changes locally before you commit them. A
-prerequisite for local tests is that you can build the website. This
-file will try to teach you how to do that...
-
-First of all some background information: The website is build using
-DocBook XML. In particular we are using the WebSite doctype and
-stylesheets. See http://docbook.sourceforge.net/projects/website/ for
-more information on DocBook Website.
-
-In order to create HTML pages from the XML sources, you will need a
-working DocBook XML setup. The default Makefile uses xsltproc as the
-XSLT processor. This is a fairly common tool that you probably have
-installed already; see http://xmlsoft.org/XSLT/xsltproc2.html. In
-addition to the XSLT processor you need to have the DocBook DTDs and
-stylesheets installed. And then, and that's often the problematic
-part, you need an XML catalog (usually /etc/xml/catalog) that refers
-the XSLT processors to the locally installed files. If that catalog is
-missing or incomplete, xsltproc will try to download stylesheets
-on-the-fly. This slows down processing considerably and since some
-stylesheets are not always available online (mainly due to being
-hosted on sourceforge) you should make sure that your catalog file is
-complete.
-
-Assuming your setup is complete, all you need to do is to type 'make'
-in the toplevel directory. The HTML files are created in the source
-tree (but should not be checked into CVS). We also put the XML files
-online. This allows to show people how easy the source for the HTML
-pages looks like and to allow them to provide patches on the XML
-sources w/o checking the whole thing out of CVS.
-
-The structure of the site is defined in the file layout.xml. Here the
-hierarchy and relation of all pages is defined. If you want to add new
-pages, start by adding a new tocentry here. Then, each XML file
-corresponds to a HTML file in the generated site. We name the XML file
-just like the HTML file in order to make our lifes easier. Please
-stick to this rule if possible.
-
-If you want to add images, especially screenshots, please use the PNG
-format (or JPEG if appropriate). Please add binary files such as
-images with the -kb option so that the CVS server knows that the files
-are binary and shouldn't attempt to create diffs.
-
-If you think there's info missing here, feel free to add it or send me
-a mail with your questions. Before you do any commits to this CVS
-module, please get in contact with me or write to the gimp-web
-mailing-list. The only exception to this rule is an obvious build fix.
-You are encouraged to not ask but simply do the fix then.
-
-
- Sven Neumann <sven gimp org>
+prerequisite for local tests is that you can build the website.
+
+## Testing your Changes
+
+Install hugo using the advice on
+[their website](https://gohugo.io/getting-started/installing/).
+Then build with
+
+ $ hugo
+
+To test your site run:
+
+ $ hugo serve
+
+The site will be hosted on your localhost with a port number decided
+at launch, (by default 1313) so open for example:
+[https://localhost:1313](https://localhost:1313) to see your changes.
+
+## Learning Hugo
+
+To learn how to edit the site start by reading any of the markdown
+files while running your local server. It will automatically update
+if you make changes and it should be easy to intuit how it works.
+
+For more advanced editing, read the
+[official docs](https://gohugo.io/getting-started/usage/).
+
+The GIMP Development Team,
+Sven Neumann <sven gimp org>
+
diff --git a/content/gimpcon/2003/gimpcon2003-mins-1.md b/content/gimpcon/2003/gimpcon2003-mins-1.md
index 5d16f64..e9043c2 100644
--- a/content/gimpcon/2003/gimpcon2003-mins-1.md
+++ b/content/gimpcon/2003/gimpcon2003-mins-1.md
@@ -1,307 +1,188 @@
+++
+title = "The First Big Serious Meeting of GIMPCon 2003"
+abbrev = "First Meeting"
+description = "Minutes of the first GIMPCon 2003 Meeting"
author = "The GIMP Development Team"
+++
- <title>The First Big Serious Meeting of GIMPCon 2003</title>
- <titleabbrev>First Meeting</titleabbrev>
- <summary>Minutes of the first GIMPCon 2003 Meeting</summary>
- </head>
-
- <para>
- August 7th 2003, around 8pm
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
- (bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
- Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
- Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
- Williamson (calvin), Roman Joost (romanofski).
- </para>
-
- <para>
- Absent but at camp: Maurits Rijk (Maurits), Branko Collin (bbc).
- </para>
-
- <para>
- Topic discussion, in approximate chronological order:
- <itemizedlist>
- <listitem>
- <link linkend="foundation">The GIMP foundation</link>
- </listitem>
- <listitem>
- <link linkend="manager">Release manager</link>
- </listitem>
- <listitem>
- <link linkend="decisions">Decision making (or lack of
- it)</link>
- </listitem>
- <listitem>
- <link linkend="general">General stuff about CVS,
- Bugzilla</link>
- </listitem>
- <listitem>
- <link linkend="communication">Communication</link>
- </listitem>
- </itemizedlist>
- </para>
-
- <section id="foundation">
- <title>The GIMP Foundation</title>
-
- <para>
- 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 things we don't have at the
- moment - a bank account people could donate to, and a focus on
- <quote>marketing</quote> in the broadest sense of the word.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- This led onto a discussion of whether the foundation would be
- responsible for setting release dates, or whether we would have
- a separate...
- </para>
-
- </section>
-
- <section id="manager">
- <title>Release Manager</title>
-
- <para>
- The general consensus (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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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?
- </para>
-
- <para>
- So we started talking about how to get contentious decisions
- made.
- </para>
-
- </section>
-
- <section id="decisions">
- <title>Decision making (or lack of it)</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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 consensus. However, we tend to be pretty bad at
- reaching consensus 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- </section>
-
- <section id="general">
- <title>General stuff, about Bugzilla and CVS</title>
-
- <para>
- 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 gimp org sufficient? Do
- we need to change bugs gimp org to something else to avoid
- confusion with the old bug reporting address? There were a few
- open points in here.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- We also expressed a desire to have more redundancy in the
- non-technical aspects 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.
- </para>
-
- </section>
-
- <section id="communication">
- <title>Communication</title>
-
- <para>
- It was agreed that we need to communicate better (that's a
- no-brainer, really). For a start, every developer should be
- subscribed to the userlist. 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.
- </para>
-
- <para>
- Basically, we're going to talk a lot more about how the
- developers can interface better with the users.
- </para>
-
- </section>
-
- <section>
- <title>Decisions</title>
-
- <para>
- 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 <quote>5 days and it's dead</quote>
- rule for threads makes sense, so that will be done.
- </para>
-
- </section>
-
- <section>
- <title>Future</title>
-
- <para>
- <orderedlist>
- <listitem>
- Roadmap - rough release schedule, we will have a first draft
- today.
- </listitem>
- <listitem>
- 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.
- </listitem>
- <listitem>
- Communication
- </listitem>
- <listitem>
- Release Manager - what'll he do, who'll he be. This should
- be short once we have discussed communication channels a
- bit.
- </listitem>
- <listitem>
- 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.
- </listitem>
- <listitem>
- GIMP tutorials - jimmac and nomis are going to do some
- presentations for people, which should be good.
- </listitem>
- <listitem>
- 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.
- </listitem>
- </orderedlist>
- </para>
-
- </section>
-
- <para>
- Written by Dave Neary
- </para>
-
-</webpage>
+August 7th 2003, 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: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
+(bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
+Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
+Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
+Williamson (calvin), Roman Joost (romanofski).
+
+Absent but at camp: Maurits Rijk (Maurits), Branko Collin (bbc).
+
+Topic discussion, in approximate chronological order:
+
+* [The GIMP foundation](#the-gimp-foundation)
+* [Release manager](#release-manager)
+* [Decision making (or lack of it)](#decisions)
+* [General stuff about CVS, Bugzilla](#general)
+* [Communication](#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 things we don't have at the
+moment - a bank account people could donate to, and a focus on
+<quote>marketing</quote> 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 consensus (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 consensus. However, we tend to be pretty bad at
+reaching consensus 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 gimp org sufficient? Do
+we need to change bugs gimp org 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 aspects 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 be
+subscribed to the userlist. 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 <quote>5 days and it's dead</quote>
+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.
+
+Written by Dave Neary
+
diff --git a/content/gimpcon/2003/gimpcon2003-mins-2.md b/content/gimpcon/2003/gimpcon2003-mins-2.md
index c20d123..47f55ec 100644
--- a/content/gimpcon/2003/gimpcon2003-mins-2.md
+++ b/content/gimpcon/2003/gimpcon2003-mins-2.md
@@ -1,371 +1,295 @@
+++
+title = "The Second Big Serious Meeting of GIMPCon2003"
+abbrev = "Second Meeting"
+description = "Minutes of the second GIMPCon 2003 Meeting"
author = "The GIMP Development Team"
+++
- <title>The Second Big Serious Meeting of GIMPCon2003</title>
- <titleabbrev>Second Meeting</titleabbrev>
- <summary>Minutes of the second GIMPCon 2003 Meeting</summary>
- </head>
-
- <para>
- August 8th 2003, around 8pm
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
- (bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
- Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
- Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
- Williamson (calvin), Roman Joost (romanofski), Maurits Rijk
- (Maurits), Branko Collin (bbc).
- </para>
-
- <para>
- Topic discussion, in approximate chronological order:
- <itemizedlist>
- <listitem>
- <link linkend="features">Features required for 2.0</link>
- </listitem>
- <listitem>
- <link linkend="documentation">Documentation</link>
- </listitem>
- <listitem>
- <link linkend="web">Web-site</link>
- </listitem>
- <listitem>
- <link linkend="roadmap">Roadmap</link>
- </listitem>
- <listitem>
- <link linkend="bugs">Bugs</link>
- </listitem>
- <listitem>
- <link linkend="tasks">Task List</link>
- </listitem>
- <listitem>
- <link linkend="foundation">GIMP Foundation</link>
- </listitem>
- <listitem>
- <link linkend="manager">Release manager</link>
- </listitem>
- </itemizedlist>
- </para>
-
- <section id="features">
- <title>Features required for 2.0</title>
-
- <para>
- 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.
- </para>
-
- <para>
- The major features or API changes which it was agreed are
- necessary are:
- <orderedlist>
- <listitem>Complete path tool (nomis)</listitem>
- <listitem>Remove libgck (Sven and mitch)</listitem>
- <listitem>Finish the text tool (Sven)</listitem>
- <listitem>Documentation (more on this later)</listitem>
- <listitem>Web-site (again, more on this later)</listitem>
- <listitem>Some libgimp changes which need to be made now so that
- we can havebinary compatibility across a 2.2 release</listitem>
- </orderedlist>
- </para>
-
- </section>
-
- <section id="documentation">
- <title>Documentation</title>
-
- <para>
- 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
- <quote>This help item does not exist yet.If you would like to
- help write it, contact docs gimp org</quote> or some such.
- <footnote>
- <para>
- That email address doesn't exist (yet). People interested in
- helping with the documentation should have a look at the
- <ulink url="http://wiki.gimp.org/gimp/GimpDocs";>Wiki</ulink>.
- </para>
- </footnote>
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- We also need to have the docs browsable online so that if people
- want to browse them they can.
- </para>
-
- </section>
-
- <section id="web">
- <title>Web-site</title>
-
- <para>
- 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 <quote>your website sucks</quote> type
- feedback, but this will only befor 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.
- </para>
-
- <para>
- It was also discussed whether it was a good idea to have a
- separate coordinator for the website.
- </para>
-
- </section>
-
- <section id="roadmap">
- <title>Roadmap</title>
-
- <para>
- 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.
- </para>
-
- <para>
- More specifically, the near-term release schedule that we agreed
- was reasonable is this:
- </para>
-
- <para>
- 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
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- </section>
-
- <section id="bugs">
- <title>Bugs</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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 bugfixing done, but we also
- need to choose what to do and what not to do. We felt this was a
- reasonable compromise.
- </para>
-
- <para>
- 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+.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- This leads us on to...
- </para>
-
- </section>
-
- <section id="tasks">
- <title>Task list</title>
-
- <para>
- 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.
- </para>
-
- <para>
- 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, <quote>Maintaining the TODO
- list</quote> would go in the TODO list).
- </para>
-
- <para>
- 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 <quote>GIMP
- TODO list</quote> we could get that for free.
- </para>
-
- </section>
-
- <section id="foundation">
- <title>GIMP Foundation</title>
-
- <para>
- 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 that 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.
- </para>
-
- <para>
- Other people said they would prefer to assign copyright to an
- organism under the jurisdiction of European law rather than
- under US jurisdiction.
- </para>
-
- <para>
- 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).
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- </section>
-
- <section id="manager">
- <title>Release manager</title>
-
- <para>
- The responsibilities are:
- <itemizedlist>
- <listitem>
- 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
- </listitem>
- <listitem>
- Follow bugzilla closely
- </listitem>
- <listitem>
- Make releases regularly, according to the roadmap (or make
- sure releases get made)
- </listitem>
- <listitem>
- Update the roadmap to reflect reality
- </listitem>
- <listitem>
- Write release notes for the releases (keep NEWS up to date)
- </listitem>
- <listitem>
- 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.
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- Dave Neary (me) agreed to do this. He already regrets it.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- 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.
- </para>
-
- <para>
- Written by Dave Neary
- </para>
-
- </section>
-
-</webpage>
+August 8th 2003, 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: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
+(bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
+Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
+Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
+Williamson (calvin), Roman Joost (romanofski), Maurits Rijk
+(Maurits), Branko Collin (bbc).
+
+Topic discussion, in approximate chronological order:
+
+* <link linkend="features">Features required for 2.0</link>
+* <link linkend="documentation">Documentation</link>
+* <link linkend="web">Web-site</link>
+* <link linkend="roadmap">Roadmap</link>
+* <link linkend="bugs">Bugs</link>
+* <link linkend="tasks">Task List</link>
+* <link linkend="foundation">GIMP Foundation</link>
+* <link linkend="manager">Release manager</link>
+
+## 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:
+
+<orderedlist>
+1. <listitem>Complete path tool (nomis)</listitem>
+2. <listitem>Remove libgck (Sven and mitch)</listitem>
+<listitem>Finish the text tool (Sven)</listitem>
+<listitem>Documentation (more on this later)</listitem>
+<listitem>Web-site (again, more on this later)</listitem>
+<listitem>Some libgimp changes which need to be made now so that
+we can havebinary compatibility across a 2.2 release</listitem>
+</orderedlist>
+</para>
+
+</section>
+
+<section id="documentation">
+<title>Documentation</title>
+
+<para>
+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
+<quote>This help item does not exist yet.If you would like to
+help write it, contact docs gimp org</quote> or some such.
+<footnote>
+<para>
+That email address doesn't exist (yet). People interested in
+helping with the documentation should have a look at the
+<ulink url="http://wiki.gimp.org/gimp/GimpDocs";>Wiki</ulink>.
+</para>
+</footnote>
+
+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.
+</para>
+
+</section>
+
+<section id="web">
+<title>Web-site</title>
+
+<para>
+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 <quote>your website sucks</quote> type
+feedback, but this will only befor 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.
+</para>
+
+</section>
+
+<section id="roadmap">
+<title>Roadmap</title>
+
+<para>
+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.
+</para>
+
+</section>
+
+<section id="bugs">
+<title>Bugs</title>
+
+<para>
+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 bugfixing 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...
+</para>
+
+</section>
+
+<section id="tasks">
+<title>Task list</title>
+
+<para>
+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, <quote>Maintaining the TODO
+list</quote> 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 <quote>GIMP
+TODO list</quote> we could get that for free.
+</para>
+
+</section>
+
+<section id="foundation">
+<title>GIMP Foundation</title>
+
+<para>
+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 that 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.
+</para>
+
+</section>
+
+<section id="manager">
+<title>Release manager</title>
+
+<para>
+The responsibilities are:
+<itemizedlist>
+<listitem>
+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
+</listitem>
+<listitem>
+Follow bugzilla closely
+</listitem>
+<listitem>
+Make releases regularly, according to the roadmap (or make
+sure releases get made)
+</listitem>
+<listitem>
+Update the roadmap to reflect reality
+</listitem>
+<listitem>
+Write release notes for the releases (keep NEWS up to date)
+</listitem>
+<listitem>
+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.
+</listitem>
+</itemizedlist>
+
+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.
+
+Written by Dave Neary
+
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
