Supporting Gtk+ Maintenance

[Tim Janik]

Hello Foundation Board.

The Gtk+ project is in dire lack of new maintainers, mostly to review
patches, so that bugs can be fixed and new features can be introduced.
We need suggestions for candidates, probably for particular sub-sections
of Gtk+. Ideally, these candidates would be employed to work on Gtk+.

To avoid any misunderstandings, the project is not in lack of more
patches or code contributions, what it lacks is the human resources
to handle the flow of incoming patches and bug reports, and do code
maintenance work.

A more in-depth description of this situation can be found here:
   http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html

In response to that write up, various people have made suggestions to
improve the situation and asked for opportunities or ways to help.
Some of these suggestions involve the Gnome foundation board and Gnome
advisory board, which is why I'm writing you.

A lot of companies are involved in Gnome and Gtk+ at this point, and
probably can be expected to have a vivid self interest in our core
technologies to stay reliable and properly maintained. In order to help
to achieve this, this can be done:

* Companies (especially those on the advisory board) can submit names
   of developers (employees) who can be put on the task of Gtk+
   maintenance.
   Ideally, the developers should already have experience with Gtk+
   project contributions, and they should be team-oriented and
   communicative to be able to develop a good work relationship with
   the existing Gtk+ community.

* The Gtk+ project would like to see those people work full time if
   possible, but regular part time assistance can also help a lot.

* These positions must not be limited to work on constrained feature
   sets only. There are enough limited scope/feature bound contributions
   already. As a consequence, there is a strong need for more general
   involvement and maintenance work like cleanups, regression fixes,
   refactorings and similar things.

So for the foundation board, there are two things that can be done
to improve the current situation:

1) Please present the issue at hand (this email and the email linked
to above) to the advisory board members, to make sure the companies
involved are aware of the situation. And if possible, spread the
word to other involved parties or (non advisory) companies.

2) Please investigate if the hiring/sponsoring of a full time Gtk+
maintainer position by the Gnome foundation is also a possibility.

---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Jeff Waugh]

> So for the foundation board, there are two things that can be done
> to improve the current situation:
> 
> 1) Please present the issue at hand (this email and the email linked
>to above) to the advisory board members, to make sure the companies
>involved are aware of the situation. And if possible, spread the
>word to other involved parties or (non advisory) companies.

Your timing is fantastic -- we're having an Advisory Board meeting tomorrow
morning. I will bring it up then. :-)

> 2) Please investigate if the hiring/sponsoring of a full time Gtk+
>maintainer position by the Gnome foundation is also a possibility.

Current and previous boards have been very cautious about the idea of hiring
developers. We'd prefer to hire people who can support the work of hackers.
That's not to say it's completely off the table, but there's more we can do
with contributing companies beforehand.

Just for the record, I'm taking this issue very seriously. It's one of the
reasons I brought up GTK+ collaboration with the GNOME Foundation (and the
other project mentioned during the GTK+ meeting at GUADEC).

Thanks,

- Jeff

-- 
Open CeBIT 2007: Sydney, Australia  http://www.opencebit.com.au/
 
   "Blessed are the cracked, for they let in the light." - Spike Milligan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Behdad Esfahbod]

On Thu, 2007-03-15 at 09:19 +1100, Jeff Waugh wrote:
> 
> > So for the foundation board, there are two things that can be done
> > to improve the current situation:
> > 
> > 1) Please present the issue at hand (this email and the email linked
> >to above) to the advisory board members, to make sure the
> companies
> >involved are aware of the situation. And if possible, spread the
> >word to other involved parties or (non advisory) companies.
> 
> Your timing is fantastic -- we're having an Advisory Board meeting
> tomorrow morning. I will bring it up then. :-) 

Indeed.  This has been in my agenda for tomorrow's meeting, and I'm
taking notes about it right now.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[मयंक जैन ( makuchaku)]

On 3/15/07, Tim Janik <[EMAIL PROTECTED]> wrote:
> * Companies (especially those on the advisory board) can submit names
>of developers (employees) who can be put on the task of Gtk+
>maintenance.
>Ideally, the developers should already have experience with Gtk+
>project contributions, and they should be team-oriented and
>communicative to be able to develop a good work relationship with
>the existing Gtk+ community.
>
> * The Gtk+ project would like to see those people work full time if
>possible, but regular part time assistance can also help a lot.

Code maintainence  is an important part of any project's life cycle &
is often the most dreaded part by developers. Majority of them think
that adding new features is _the_ most exciting part of the project
cycle. However, this phase is good (& very important) for the
developers who are in the process of learning the toolkit's internals
- like me.

I would suggest that when the decision about hiring developers is made
(or discussed), maintainence work should be strongly put forward...
specially since we will decide to branch/develop for the 3.0 branch in
future.

I would be happy to volunteer towards maintainence of GTK+.

Regards,
Makuchaku
http://www.makuchaku.info/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Federico Mena Quintero]

El jue, 15-03-2007 a las 14:20 +0530, मयंक जैन (makuchaku) escribió:

> I would be happy to volunteer towards maintainence of GTK+.

Wow, thanks!

Here's a task for you to get started.  It will take you several days,
but hopefully it will be fun :)

Go to http://bugzilla.gnome.org/browse.cgi?product=gtk%2b and look at
the sidebar on the right, where it says "Patch Status".

Your mission, should you decide to accept it, is to do this:

- Get the latest GTK+ from svn trunk.

- Go through each of the unreviewed patches and classify them
informally:

- obsolete patch which does not apply "as-is" to the sources
  (you can use "patch --dry-run" to test this easily without
  screwing up your source tree)
- big patch which needs detailed testing/review
- small patch which could be tested/reviewed in a few minutes

(you can put this classification in the "Status Whiteboard" field in
each bug.  Alternatively, see below for the "Target Milestone" field.)

- Try to group the patches by functional area; something like "patches
for drag and drop", "patches for geometry management", etc.

- Some patches add new APIs.  We use the "Target Milestone" field in
bugs to indicate whether a bug is to be fixed for a particular GTK+
release, or whether we don't have a release in mind but the bug is an
API addition, a small or big fix, etc.  If you find patches in bugs
which do not have a "Target Milestone" set, please set that field
accordingly.

This will let us use our time more effectively.  Whenever a GTK+
developer has a few minutes, he can look at the list of "little patches"
and test some of them.  When someone has a free afternoon, he can look
at the "big patches", etc.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[मयंक जैन ( makuchaku)]

On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> El jue, 15-03-2007 a las 14:20 +0530, मयंक जैन (makuchaku) escribió:
>
> > I would be happy to volunteer towards maintainence of GTK+.
>
> Wow, thanks!
>
> Here's a task for you to get started.  It will take you several days,
> but hopefully it will be fun :)

Sure... onto it!

Regards,
Makuchaku
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Federico Mena Quintero]

El vie, 16-03-2007 a las 20:44 +0530, मयंक जैन (makuchaku) escribió:
> > Here's a task for you to get started.  It will take you several days,
> > but hopefully it will be fun :)
> 
> Sure... onto it!

That's the spirit! :)

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[मयंक जैन ( makuchaku)]

On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> - Go through each of the unreviewed patches and classify them
> informally:
>
> - obsolete patch which does not apply "as-is" to the sources
>   (you can use "patch --dry-run" to test this easily without
>   screwing up your source tree)
> - big patch which needs detailed testing/review
> - small patch which could be tested/reviewed in a few minutes

I've triaged the first 5 bugs for combobox category.
Now ehn a patch fails, I create a needinfo in the bug. But can this
needinfo be directed to a particular user?

In bugzilla.redhat.com, one can create a needinfo for a particular
user & then it becomes his responsibility to cancel that info. This
assures speedier responses. Is it somehow possible to do the same with
Gnome BZ?

Work is on... :)

Makuchaku
http://www.makuchaku.info/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Behdad Esfahbod]

On Thu, 2007-03-22 at 12:25 -0400, मयंक जैन (makuchaku) wrote:
> On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > - Go through each of the unreviewed patches and classify them
> > informally:
> >
> > - obsolete patch which does not apply "as-is" to the sources
> >   (you can use "patch --dry-run" to test this easily without
> >   screwing up your source tree)
> > - big patch which needs detailed testing/review
> > - small patch which could be tested/reviewed in a few minutes
> 
> I've triaged the first 5 bugs for combobox category.
> Now ehn a patch fails, I create a needinfo in the bug. But can this
> needinfo be directed to a particular user?
> 
> In bugzilla.redhat.com, one can create a needinfo for a particular
> user & then it becomes his responsibility to cancel that info. This
> assures speedier responses. Is it somehow possible to do the same with
> Gnome BZ?
> 
> Work is on... :)

Thanks for all the work!

Setting bugs with outdated patches to needinfo may be a bit problematic
as the bugsquad team has a tendency to close needinfo bugs after some
time...  Also they won't show in some default search queries..  Just
removing the patch keyword, or marking the patch as needs-work may be
better, but that's just my idea.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[मयंक जैन ( makuchaku)]

On 3/23/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> Setting bugs with outdated patches to needinfo may be a bit problematic
> as the bugsquad team has a tendency to close needinfo bugs after some
> time...  Also they won't show in some default search queries..  Just
> removing the patch keyword, or marking the patch as needs-work may be
> better, but that's just my idea.

Obviously the objective it to get this anomoly to the patch
submitter's attention. But as Behdad you just said.. then whats the
best way to go about it?

One option I see is to re-assign the bug to this patch submitter &
once he resubmits a working patch, re-assign it to the gtk-bugs list.

Would that be good enough?

:)
Makuchaku
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Behdad Esfahbod]

On Fri, 2007-03-23 at 15:42 +0530, मयंक जैन (makuchaku) wrote:
> On 3/23/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> > Setting bugs with outdated patches to needinfo may be a bit problematic
> > as the bugsquad team has a tendency to close needinfo bugs after some
> > time...  Also they won't show in some default search queries..  Just
> > removing the patch keyword, or marking the patch as needs-work may be
> > better, but that's just my idea.
> 
> Obviously the objective it to get this anomoly to the patch
> submitter's attention. But as Behdad you just said.. then whats the
> best way to go about it?
> 
> One option I see is to re-assign the bug to this patch submitter &
> once he resubmits a working patch, re-assign it to the gtk-bugs list.
> 
> Would that be good enough?

The submitters gets mail about all changes to the bug (by default).  So
no real need to do anything specific.  Just marking as needs-work and a
two line comment about the patch status should be enough.  Assigning to
him may work better as he will see it in his bug page, but note that
other people can update an outdated patch too, and many times do.


> :)
> Makuchaku
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[मयंक जैन ( makuchaku)]

On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> Your mission, should you decide to accept it, is to do this:
>
> - Get the latest GTK+ from svn trunk.
>
> - Go through each of the unreviewed patches and classify them
> informally:
>
> - obsolete patch which does not apply "as-is" to the sources
>   (you can use "patch --dry-run" to test this easily without
>   screwing up your source tree)
> - big patch which needs detailed testing/review
> - small patch which could be tested/reviewed in a few minutes
>

29 patches were categorized. More to go...

Is there a way to check programatically (scripts/patch-command/etc)
that if a patch is applicable to be applied with p0 or p1?

If so, then this process of categorizing patches can be automated i suppose.

...any comments, suggestions :)

--
Makuchaku
http://www.makuchaku.info/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Behdad Esfahbod]

On Tue, 2007-03-27 at 11:27 -0400, मयंक जैन (makuchaku) wrote:
> On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > Your mission, should you decide to accept it, is to do this:
> >
> > - Get the latest GTK+ from svn trunk.
> >
> > - Go through each of the unreviewed patches and classify them
> > informally:
> >
> > - obsolete patch which does not apply "as-is" to the sources
> >   (you can use "patch --dry-run" to test this easily without
> >   screwing up your source tree)
> > - big patch which needs detailed testing/review
> > - small patch which could be tested/reviewed in a few minutes
> >
> 
> 29 patches were categorized. More to go...
> 
> Is there a way to check programatically (scripts/patch-command/etc)
> that if a patch is applicable to be applied with p0 or p1?

patch --dry-run

$ cat gnome-patch
#!/bin/bash

if test $# '!=' 1; then
echo usage: $0 attachmentid
exit 2
fi

ID=$1
FILE="attachment.cgi?id=$ID"
OUT="attachment-$ID.patch"
wget "http://bugzilla.gnome.org/$FILE"; -O "$OUT" &&
patch --dry-run -p0 < "$OUT" &&
patch -p0 < "$OUT" &&
echo "Patch $OUT applied cleanly."


> If so, then this process of categorizing patches can be automated i suppose.
> 
> ...any comments, suggestions :)
> 
> --
> Makuchaku
> http://www.makuchaku.info/blog
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Loïc Minier]

On Tue, Mar 27, 2007, Behdad Esfahbod wrote:
> > Is there a way to check programatically (scripts/patch-command/etc)
> > that if a patch is applicable to be applied with p0 or p1?
> patch --dry-run

 [ And the preferred order to try patch level is probably "1 0 2"; at
 least that's what Debian tools do since bugs such as
 .  The logic is in the cdbs package:
 /usr/share/cdbs/1/rules/simple-patchsys.mk ]

-- 
Loïc Minier
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Matthias Clasen]

On 3/15/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:

> Your mission, should you decide to accept it, is to do this:
>
> - Get the latest GTK+ from svn trunk.
>
> - Go through each of the unreviewed patches and classify them
> informally:
>
> - obsolete patch which does not apply "as-is" to the sources
>   (you can use "patch --dry-run" to test this easily without
>   screwing up your source tree)
> - big patch which needs detailed testing/review
> - small patch which could be tested/reviewed in a few minutes
>

I see that somebody took up this task now. While I appreciate the effort,
I don't think that a mere applies/doesn't apply  small/big classification of
patches helps _that_ much with the patch review.

I have started a small patch review checklist in
http://live.gnome.org/GtkTasks#P1
that should help people who want to bring patches in good shape.

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Supporting Gtk+ Maintenance

[Philip Withnall]

Yeah, that was me. I've since stopped, and I'm talking with Tor
Lindqvist about how I could be more useful. He's suggesting I go through
the list of unloved patches and review them, which sounds fair enough.

Philip

On Sun, 2007-05-27 at 12:39 -0400, Matthias Clasen wrote:
> On 3/15/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> 
> > Your mission, should you decide to accept it, is to do this:
> >
> > - Get the latest GTK+ from svn trunk.
> >
> > - Go through each of the unreviewed patches and classify them
> > informally:
> >
> > - obsolete patch which does not apply "as-is" to the sources
> >   (you can use "patch --dry-run" to test this easily without
> >   screwing up your source tree)
> > - big patch which needs detailed testing/review
> > - small patch which could be tested/reviewed in a few minutes
> >
> 
> I see that somebody took up this task now. While I appreciate the effort,
> I don't think that a mere applies/doesn't apply  small/big classification of
> patches helps _that_ much with the patch review.
> 
> I have started a small patch review checklist in
> http://live.gnome.org/GtkTasks#P1
> that should help people who want to bring patches in good shape.
> 
> Matthias
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Supporting Gtk+ Maintenance

[Vincent Untz]

Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit :
> On 3/14/07, Tim Janik wrote:
> >
> > Hello Foundation Board.
> 
> Hello GTK+ team.
> 
> > The Gtk+ project is in dire lack of new maintainers, mostly to review (...)
> 
> Thanks for this report, and actually thanks for the first report you
> sent back in Christmas. On thaty time the board was in transition, but
> we already took your points and since then this has been one of the
> main points in our agenda.
> 
> This is why GTK+ was one of the 2 main issues presented to the
> advisory board members this week, together with Documentation. There
> are lots of aspects to fix and improve in the GNOME project, but the
> board has decided to put these two on top of the agenda.
> 
> A practical conclusion of the discussion this week was that we need a
> space for discussion where the GTK+ team, the board, the advisory
> board companies and probably any other key GTK+ contributor /
> stakeholder / user can share this discussion. An official channel
> where we can hold a discussion from these different perspectives in
> order to solve the main issues and push GTK+ to the bright horizon it
> deserves. This channel might be online+offline, something like a
> combination of a specific mailing list + meetings in relevant
> conferences + ...
> 
> The GTK+ core team has the initiative proposing the space and the
> bootstrapping process of collaboration. Let's use this list to decide
> the new channel.

I'm wondering if gtk-devel-list is the place where the discussion about
collaboration should be happening: I don't know if having a mix of
technical discussions and collaboration discussions is good or not.
Having a separate mailing list might help, but it might also be a stupid
idea :-)

What does the GTK+ team think?

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Supporting Gtk+ Maintenance

[Murray Cumming]

On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote:
> Le lundi 26 mars 2007, à 14:12, Quim Gil a écrit :
> > On 3/14/07, Tim Janik wrote:
> > >
> > > Hello Foundation Board.
> > 
> > Hello GTK+ team.
> > 
> > > The Gtk+ project is in dire lack of new maintainers, mostly to review 
> > > (...)
> > 
> > Thanks for this report, and actually thanks for the first report you
> > sent back in Christmas. On thaty time the board was in transition, but
> > we already took your points and since then this has been one of the
> > main points in our agenda.
> > 
> > This is why GTK+ was one of the 2 main issues presented to the
> > advisory board members this week, together with Documentation. There
> > are lots of aspects to fix and improve in the GNOME project, but the
> > board has decided to put these two on top of the agenda.
> > 
> > A practical conclusion of the discussion this week was that we need a
> > space for discussion where the GTK+ team, the board, the advisory
> > board companies and probably any other key GTK+ contributor /
> > stakeholder / user can share this discussion. An official channel
> > where we can hold a discussion from these different perspectives in
> > order to solve the main issues and push GTK+ to the bright horizon it
> > deserves. This channel might be online+offline, something like a
> > combination of a specific mailing list + meetings in relevant
> > conferences + ...
> > 
> > The GTK+ core team has the initiative proposing the space and the
> > bootstrapping process of collaboration. Let's use this list to decide
> > the new channel.
> 
> I'm wondering if gtk-devel-list is the place where the discussion about
> collaboration should be happening: I don't know if having a mix of
> technical discussions and collaboration discussions is good or not.
> Having a separate mailing list might help, but it might also be a stupid
> idea :-)
> 
> What does the GTK+ team think?

If it's going to be a public discussion then it should be on
gtk-devel-list. It would be silly to create a new mailing list just to
discuss this one subject. If it's meant to be a private discussion then
a CC list will probably do it, with the advisory and board lists in it.

You might also want to arrange an extra conference call with the
advisory board if that's more to their liking. But that will probably
take 2 or 3 months to arrange.

I'm disappointed that this has been turned into a discussion about
discussing.


-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Supporting Gtk+ Maintenance

[Vincent Untz]

Hi Murray,

Le jeudi 29 mars 2007, à 23:27, Murray Cumming a écrit :
> On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote:
> > I'm wondering if gtk-devel-list is the place where the discussion about
> > collaboration should be happening: I don't know if having a mix of
> > technical discussions and collaboration discussions is good or not.
> > Having a separate mailing list might help, but it might also be a stupid
> > idea :-)
> > 
> > What does the GTK+ team think?
> 
> If it's going to be a public discussion then it should be on
> gtk-devel-list. It would be silly to create a new mailing list just to
> discuss this one subject. If it's meant to be a private discussion then
> a CC list will probably do it, with the advisory and board lists in it.

My point is: this is up to the GTK+ team to decide. I personnally don't
think there'll be anything private.

> You might also want to arrange an extra conference call with the
> advisory board if that's more to their liking. But that will probably
> take 2 or 3 months to arrange.

This is definitely something we'll do if people feel it's necessary.

> I'm disappointed that this has been turned into a discussion about
> discussing.

We're only trying to know how the GTK+ team wants to work. This is only
a first step :-)

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Supporting Gtk+ Maintenance

[Tim Janik]

On Thu, 29 Mar 2007, Vincent Untz wrote:


Hi Murray,

Le jeudi 29 mars 2007, à 23:27, Murray Cumming a écrit :

On Thu, 2007-03-29 at 21:25 +0200, Vincent Untz wrote:

I'm wondering if gtk-devel-list is the place where the discussion about
collaboration should be happening: I don't know if having a mix of
technical discussions and collaboration discussions is good or not.
Having a separate mailing list might help, but it might also be a stupid
idea :-)

What does the GTK+ team think?


If it's going to be a public discussion then it should be on
gtk-devel-list. It would be silly to create a new mailing list just to
discuss this one subject. If it's meant to be a private discussion then
a CC list will probably do it, with the advisory and board lists in it.


My point is: this is up to the GTK+ team to decide. I personnally don't
think there'll be anything private.


i fully agree with Murray here, so far all collaboration efforts have been
discussed on gtk-devel-list and i think we can continue to do so, e.g.:
  http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00058.html
  (Gtk+ Volunteer tasks)


Vincent


---
ciaoTJ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list