GNOME.org
 

Re: Gtk+ Volunteer tasks

Hi,

Very happy to see something is happening on that side :-)
I personally dislike GTK a bit ... but keeping in mind its improntance
for Linux in general I am really happy that things are ongoing to make
contributions easier.
I am also happy that at least the statement has been accepted that GTK
has some weaks (as any other software) and that they need to be
adressed somehow ... to be honest I even wondered to read this ;)

My idea would be to make backbuffer-handling more flexible:
- If several x-windows are repainted do not acquire a backbuffer for
every sub-window, instead acquire one (for the largest repainted are)
and share it.
- Modularize backbuffer-handling in general, to allow the distributor
to select wether backbuffers should be kept, re-allocated after every
repaint or destroyed after some time of inactivity.

Well if there's interrest on that I could try to work on it in summer,
if not ... no problem.

lg Clemens

2007/4/13, Tim Janik <timj gtk org>:

Hi All.

The "State of the Gtk+ Maintenance" email outlined several tasks that
can be accomplished by non-senior Gtk+ developers:
   http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html
Since that email was sent out, many people have asked for concrete advice
on how they can help the Gtk+ project.

Unfortunately, we do not currently have any formal setup or even semi-
structured process to utilize such voluntary offers. So, one suggestion
that was raised was to start a voluntary task list, where people can
sign up for individual tasks to help Gtk+ project maintenance and
development.
I found this particular suggestion to be a very good idea and would like
to suggest that we:

1) Create a openly-editable wiki page with a Gtk+ project task list; note
    that this is different from the "Gtk+ Love Bug List" started by Xan:
      http://live.gnome.org/GtkLove
    because it's about non-bug tasks that can help the project.
    I've started construction of this at:
      http://live.gnome.org/GtkTasks

2) The tasks should be signed up for by individual volunteers (or maybe
    multiple volunteers as needed) who want to work on particular items
    quasi regularly. People should also remove their entries if they have
    to step back from tasks at some point, so others know which tasks are
    up for grabs.

3) The actual task list is subject to change as we identify needs of the
    project. Below i've collected initial ideas that seem suitable for Gtk+
    at this point and that borrow positions from other projects.

4) Embrace new contributors by making it easy for them to gain commit
    rights for non critical sections (gtk-web, doc) and for code changes
    as long as there's still some core developer review (e.g. by IRC
    requests + pastebin patch sighting).

Here comes the tentative initial task list, I'm open for any
comments/critics to improve or adapt this:

Permanennt Tasks:
   +----------------------------------------------+--------------------------+
   | Gtk+ Project Task Description                | Person in charge [*]     |
   +==============================================+==========================+
   | Bug testing & triaging; [1]                  |                          |
   +----------------------------------------------+--------------------------+
   | Patch testing & committing; [2]              |                          |
   +----------------------------------------------+--------------------------+
   | Patch/bug monitoring & filing; [3]           |                          |
   +----------------------------------------------+--------------------------+
   | Website (*content*) maintainer; [4]          |                          |
   +----------------------------------------------+--------------------------+
   | FAQ maintainer; [5]                          |                          |
   +----------------------------------------------+--------------------------+
   | Spam handling on mailing lists               | moderator gnome org      |
   +----------------------------------------------+--------------------------+

Transient Tasks:
   +----------------------------------------------+--------------------------+
   | Gtk+ Project Task Description                | Person in charge [*]     |
   +==============================================+==========================+
   | Canvas evaluation moderator; [6]             |                          |
   +----------------------------------------------+--------------------------+

Resources:
   Website:     http://www.gtk.org/
   IRC Channel: #gtk+ on GimpNet
   FAQ:         http://www.gtk.org/faq/
   Tutorial:    http://www.gtk.org/tutorial/
   API docs:    http://developer.gnome.org/doc/API/
   Lists:       http://mail.gnome.org/archives/gtk-devel-list/
                http://mail.gnome.org/archives/gtk-app-devel-list/
                http://mail.gnome.org/archives/gtk-list/
   GLib Bugs:   http://bugzilla.gnome.org/buglist.cgi?query=product:glib
   Gtk+ Bugs:   http://bugzilla.gnome.org/buglist.cgi?query=product:gtk%2B

[*] Please sign up for a task by adding your real name and a working email
     address. Multiple people may sign up for a task, they should communicate
     with each other to avoid duplication of effort however.

[1] Bugs regularly need to be sorted out and patches filed therein need
     to be tested and possibly adapted. A detailed description is given here:
       http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html
       (Re: Supporting Gtk+ Maintenance)

[2] Patch snippets that get pasted/submitted via email/irc/etc. and that
     core developers can approve off head still need to be actually applied,
     compiled, tested with our test suite, be committed and potentially back-
     merged onto other branches.
     Someone signing up for this should have reasonable C knowledge, hang
     out on #gtk+ and be frequently reachable via email. Ideally people
     signing up for this already have SVN commit access, if not, see: [x]

[3] Sometimes bugs are being described on mailing lists or IRC without any
     record being taken on them in Bugzilla. It'd help to have someone who
     is responsible to wade through all emails on gtk-devel-list (and if
     possible other Gtk+ mailing lists and #gtk+) to make sure no bug
     description or patch snippet is lost by asking people to file bugs in
     Bugzilla and by filing things himself if necessary. It'd be nice for
     multiple people to sign up here, to split the mailing list loads.
     An SVN project related Google talk shortly describes this position in
     the SVN project:
       http://video.google.com/videoplay?docid=-4216011961522818645
       (How Open Source Projects Survive Poisonous People)

[4] The Gtk+ website http://www.gtk.org/ is kept in the gtk-web SVN module
     and needs regular updates and fixes. At some points even redesigns may
     be in order. This task requires monitoring gtk-devel-list for possible
     new website content and some self interest in cleaning up the current
     site. (about SVN access: [x])

[5] Many questions are regularly being asked and answered on the Gtk+ mailing
     lists and on the IRC channels. Frequently asked questions with answers
     should be collected and need to be integrated into the Gtk+ FAQ,
     tutorial or sometimes even the reference documentation:
       http://www.gtk.org/faq/          http://www.gtk.org/tutorial/
     (about SVN access: [x])

[6] Someone needs to lead/nurture the effort to collect Gtk canvas
     requirements from the community and in a second stage evaluate existing
     canvas projects for Gtk+ project inclusion feasibility as described in
     topic (4) during FOSDEM:
       http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00001.html
       (Minutes of the GTK+ meeting at FOSDEM)

[x] In order to get started with a task that requires commit privileges,
     such as gtk-web module editing, do the following:
     - sign up for the task, possibly communicate with other volunteers;
     - submit small patches in diff -up format via email to
       gtk-devel-list gnome org or another contributor who already has
       commit rights;
     - after some initial mutual familiarization phase, you can apply for
       an SVN account if you have the backing of some core developer:
         http://developer.gnome.org/doc/policies/accounts/requesting.html

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]