[gimp-web-devel/pat/bootstrap] content: add the logs of old IRC developer meetings.

[Jehan <jehanp src gnome org>]

commit 86dd96877e5d58ec9e52dc0f9c1cb12c5e1fcf94
Author: Jehan <jehan girinstud io>
Date:   Sun Sep 11 21:04:27 2022 +0200

    content: add the logs of old IRC developer meetings.
    
    Pages which were imported, ported to markdown, from the wiki (!3):
    
    * wiki/Hacking:Dev_Meeting_28_Feb_2011-20200126023332-show.txt
    * wiki/Hacking:Dev_Meeting_14_Mar_2011-20161024020553-show.txt
    * wiki/Hacking:Dev_Meeting_28_Mar_2011-20210417225721-edit.txt
    * wiki/Hacking:Dev_Meeting_19_Apr_2011-20190507091738-show.tx
    
    This page was merged with the conferences/ index page:
    
    * wiki/Hacking:Developer_Meetings-20210515163235-edit.txt

 .../IRC_Meeting/Dev_Meeting_14_Mar_2011.md         | 385 ++++++++++++++++
 .../IRC_Meeting/Dev_Meeting_19_Apr_2011.md         |  32 ++
 .../IRC_Meeting/Dev_Meeting_28_Feb_2011.md         | 509 +++++++++++++++++++++
 .../IRC_Meeting/Dev_Meeting_28_Mar_2011.md         |  72 +++
 content/conferences/_index.md                      |  22 +-
 5 files changed, 1018 insertions(+), 2 deletions(-)
---
diff --git a/content/conferences/IRC_Meeting/Dev_Meeting_14_Mar_2011.md 
b/content/conferences/IRC_Meeting/Dev_Meeting_14_Mar_2011.md
new file mode 100644
index 0000000..5359c8b
--- /dev/null
+++ b/content/conferences/IRC_Meeting/Dev_Meeting_14_Mar_2011.md
@@ -0,0 +1,385 @@
+---
+title: "IRC developer meeting — 2011 March 14"
+author: "The GIMP Development Team"
+date: 2011-03-14
+lastmod: 2016-10-24
+---
+
+Meeting page for the Developer Meeting which will take place in the GIMP IRC on March 14th 2011, 10:00 PM 
CET (GMT+1)
+
+**Time for Next Meeting(?):** March 28 2011, 10:00 PM CET (GMT+1).
+
+## Agenda
+
+### Reviewing last meeting's decision
+
+Follow up what was done and what wasn't, from the decisions of last meeting. See [Dev Meeting 28 Feb 
2011](../dev_meeting_28_feb_2011/).
+
+### Serious discussion of GIMP's programming language
+
+There have been many questions about whether we should switch some of GIMP's code to some language other 
than C+GObject, where the development would be more rapid. On the list of suggested languages we saw 
JavaScript, Python, Vala and some more.
+
+There is a consensus(?) that core code was and will continue to be in C, mainly for performance reasons but 
not only. But now that we are starting to get some logic out to GEGL, would it make sense to change at least 
the language of the UI to something other than C?
+
+Some people vetoed this, others vetoed remaining in C - so let's discuss it!
+
+### 2.8 - Get it out!
+
+We are [54 
bugs](https://bugzilla.gnome.org/buglist.cgi?query_format=advanced&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=NEEDINFO⌖_milestone=2.6⌖_milestone=2.8&amp;product=GIMP)
 away from releasing GIMP 2.8. Lets browse hrough that list and see who can fix what, and if there are any 
ways in which some devs can help others to balance the load (for example, mitch is working too much!)
+
+### Roadmap Review
+
+Enselic made a wonderful roadmap for gimp (*link dead*)! I think we should all review this together, to make 
plans clear for everyone. For example, some stuff that were proposed for the upcoming google summer of code, 
are targeted for versions of gimp which aren't exactly "near".
+
+### Anything else?
+
+Tell LightningIsMyName and he'll add it :)
+
+## Decided Actions
+
+See chat log - nothing organized this time...
+
+## Meeting Log
+
+```html
+## Topic: GIMP developer meeting, 22:00 CET (GMT+1) March 14th 2011 | Agenda: 
http://gimp-wiki.who.ee/index.php?title=Hacking:Dev_Meeting_14_Mar_2011 | THIS MEETING IS BEING LOGGED!
+
+<lightningismyname> Topic 1 on the agenda
+ Reviewing last meeting's decision
+ http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011#Decided_Actions
+ old-decision 1: schumaml - any progress on wgo? I had none
+<schumaml> neo hasn't replied to my mail
+<lightningismyname> so we are stuck on this...
+<schumaml> I asked him to tell me what' left to do to get automatic updates
+<lightningismyname> ...
+ old-decision 2: Alexia and mitch take care of redirecting wiki.gimp.org
+ Both aren't attending, so it's kind of hopeless to ask for progress
+ seems as if it's not working, so let's move on
+<schumaml> it's not redirecting for me
+<lightningismyname> old-decision 3: Enselic makes a draft of a GIMP roadmap and sends to gimp-developer
+<enselic> done, next
+<schumaml> http://gimp-wiki.who.ee/index.php/GIMP_Roadmap
+<lightningismyname> Enselic, anything you'd like to add to your mail? Or should we wait for the in depth 
discussion, which is scheduled later for this meeting?
+<enselic> yes let's be done with the old stuff first
+<lightningismyname> old-decision 4: everybody subscribe to bug mail and TRIAGE BUGS
+ Is any of the devs here not submitted to bugmail?
+<enselic> I haven't noticed a significant increase in bug triaging
+ it's not that important... it's more important that people write code
+<schumaml> we should set goals and guidelines
+<lightningismyname> 2.8 and future are planned for the rest of this meeting :)
+<schumaml> LightningIsMyName: for bug triaging
+<pippin> Enselic: regarding the roadmap, low:priority High-end CMYK support...
+<lightningismyname> schumaml, for example? what sort of goals?
+<pippin> Enselic: I think taking the separate- plug-in given on the mailinglist and making it part of GIMPs 
default install is a sensible thing to do
+<enselic> pippin: let's wait with this discussion
+<schumaml> LightningIsMyName: what to do with new bugs, unconfirmed bugs, long-time nedinfo
+<enselic> common sense is enough to get started, if someone does the wrong thing, more experienced bug 
triagers will correct it
+ don't be scared
+<lightningismyname> :) I think this should be tightly related to the roadmap
+<enselic> just start slowly so that people have a chance to correct you if you do something wrong
+ next item on the old-action list please
+<schumaml> bug don't necessarily involved the roadmap
+ but yes, next
+<lightningismyname> old-decision 5: mitch, make a development release soo
+<enselic> epic fail, next ;)
+<lightningismyname> mitch itsn't here, and 2.8 is topic 2 of the agenda
+ old-decision 6: LightningIsMyName takes care of next meeting
+ done, next :)
+ old-decision 7: setting pages on the wiki to discuss changes in different topics
+ now, here we have something more serious
+<enselic> can someone elaborate on the topic? I don't understand it
+<lightningismyname> for example, the last PDB change annoyed some people, and broke many things
+ mainly scripts/plugins
+<schumaml> what change?
+<lightningismyname> these things should be discussed more in depth and not be solo work
+ schumaml, all the context related ones
+ Enselic, what's the status of the dev site?
+<enselic> the work should have been performed on a feature branch, that's the problem
+* LightningIsMyName objects new branches - we have too many of these
+<kevin> I don't think the PDB changes broke anything but they made most scripts pop up some deprecation 
warnings.
+<enselic> LightningIsMyName: if you mean tasktaste.com, it's not for production use yet
+<enselic> let's revisist this topic after we're done with the old-action list
+<lightningismyname> agreed
+<enselic> next on that list please
+<lightningismyname> old-decision 8: LightningIsMyName gets a list of projects on the wiki by tomorrow, 
developers review the ideas by email or by commenting on the wiki. Saturday (March 5th, 2011) is hard dead 
line for finalizing the project list!
+ done with gsoc ideas :)
+ old-decision 9: all devs PM/Email LightningIsMyName username and email
+ any dev here without a user on the wiki?
+<schumaml> yes
+<enselic> ... that wants one
+<lightningismyname> schumaml, as the topic states - PMing me is the way to get a user
+ closed topic 1 - review old decisions
+ topic 2: Serious discussion of GIMP's programming language
+ I think this title talks for itself, but I'm afraid we have a serious lack of devs here
+<enselic> I noticed that the AdaptableGIMP guys used Vala for quite some substantial parts of their added 
code, and I think Vala is the language we should choose as a higher-level GIMP language
+<lightningismyname> I was also thinking in that direction. Is vala stable?
+<enselic> I haven't had time to thoroughly test it yet unfortunately
+<pippin> is the vala language spec frozen yet?
+<schumaml> do we drop scheme and python for vala then?
+<enselic> enough to get some vala code into GIMP
+<lightningismyname> my main concern with vala is horror stories I heard on #gimp about programs that break 
because of vala changes
+<kevin> what are you referring to as "GIMP's programming language"?
+<enselic> no, Vala doesn't fit our gimprc files for example
+ ketas-av Kevin
+<lightningismyname> Kevin, ui programming and other non core
+<enselic> for "settings files", my long-term pick is JavaScript, mu short-term pick is to stick with Scheme
+<pippin> vala has the advantage of possible integrating directly with existing C gobject code
+<lightningismyname> how hard would it be to introduce a vala dependancy for building gimp from git?
+<enselic> my plan is to rewrite GimpTag in Vala
+<lightningismyname> (vala code can generate C code for tars)
+<akk> Are there vala plug-in bindings already? Maybe try translating some plug-ins into vala and see how it 
goes before totally committing to it?
+<kevin> Perhaps you should define the problem before we trying to pick a single(?) language for the GUI and 
non-core stuff.
+<pippin> plug-ins != core
+<schumaml> IMO Vala will be "yet another obscure language those gimp guys chose" to the general public
+<enselic> schumaml: it's very C#-ish
+ or Java-ish if you prefer. It's not an alien syntax
+<lightningismyname> ok, let's make a list: gui, image-processing core, plug-ins
+<akk> Would you really want to use a language in the core that wasn't supported for plug-ins?
+<lightningismyname> gui first
+<enselic> before we decide on a language, we need some hands on experience
+ that is, we need patches that introduces Vala to the GIMP core
+ we need experimental patches for other languages too preferably
+<lightningismyname> is there an auto* expert here?
+ (autotools)
+<enselic> I'm fairly comfortable with autotools
+<schumaml> what do we want to achieve by this?
+ ketas-av Kevin
+<enselic> schumaml: increased productivity
+<schumaml> by whom?
+<enselic> manually initializing vtables is a waste of time
+<lightningismyname> Kevin, what would it take to introduce vala as a git optional dependancy
+<kevin> As I said, I think we need to define the problem first.
+<enselic> writing GOBject C boilerplate code is a waste of time
+* LightningIsMyName more than just agrees
+<schumaml> so the problem is "no C!!!"
+<lightningismyname> no, the problem is "no  gobject!"
+<enselic> no, the problem is "stop using the wrong tool for the job"
+<schumaml> I guess mayn people agree on that
+<akk> The problem is "glib C bindings are a pain"
+<kevin> It shouldn't take much to add vala but I don't know anything about Vala and only heard pippin talk 
about it.
+<enselic> http://live.gnome.org/Vala
+<pippin> from a more argumentative perspective, learning to read and understand GObject with C is hard; 
potential contributors flee before they are able to decode what code does...
+<enselic> if we add Vala, it must not be optional. If it is optinal, we won't know if it's good enough
+<kevin> If the problem is "how to create dialog boxes in an easier and more portable method than coding in 
C", the solution doesn't really depend on picking a single language.
+<schumaml> is Vala supported on all of our platforms, within the standard autotools chain?
+<lightningismyname> I think that in general, having 30% of gobject files on glue code is a waste of 
resources?
+<enselic> schumaml: Vala generates C code
+<pippin> schumaml: vala is just a pre-processor that generates C+gobject code passed to the c compiler
+<enselic> schumaml: answer: yes
+<schumaml> I'd really hate to hit a "oh, hehe, nobody uses autools on windows" pitfall
+<lightningismyname> We need someone to fix the tutorial on native windows build. I can do it with enselic's 
nightlys, but direct git is a pain
+<kevin> For many situations a dialog can be designed with GUI tools such as Glade.
+<enselic> don't see it as my nightlys, it's GIMP's nightlys
+ ketas-av Kevin
+<kevin> or one of its variants to get a gtk builder file.
+<enselic> guys, this is not about a higher level language for the GUI parts, it's for the whole core
+<schumaml> btw, where are the vala builds for windows and os x?
+<enselic> Few, if none, of the GIMP core objects needs to be in C
+* LightningIsMyName did a mistake and started talking about gui
+<enselic> if any*
+<pippin> I think the PDB in GIMP and its myriad set of bindings is a problem in this regard.. what we are 
talking about is not yet another language with bindings to the PDB either...
+<kevin> Enselic: That is why I thought we should clearly define the problem of needing to pick some language 
first. :-)
+<enselic> Kevin: again, the problem is that one is not productive in C
+<kevin> Productive doing what?
+<enselic> getting your computer to do what you want
+ ketas-av Kevin
+<lightningismyname> Kevin,  30% glue code for gobject
+<kevin> Works fine for me.
+<enselic> getting the GIMP core do what you want*
+<lightningismyname> and in small files, up to 60%
+<pippin> if gegl ops didnt use chanting, they would be ~50 lines longer
+ with a lot of repetition
+<schumaml> IMO any language would be good, if we decide to make it the default for scripts and plug-ins too 
and drop anything else from the default installs
+<lightningismyname> the good part of vala, is that it can integrate with things we have - so the transition 
could be gradual
+<kevin> I don't run in to gObject in scripts and plug-ins. I've only seen it in GEGL.
+<enselic> it seems like we agree that Vala probably is the best choice to fix the problem of too much 
GObject C boilter plate in the core, the next step is writing some actual Vala code
+<lightningismyname> so, not hearing any real suggestions for other core languages - I'm closing this topic 
as:
+ 1. All devs take a look at vala, and try to mess with it
+<kevin> The next thing is finding someone who has heard of Vala and knows something about it.
+<lightningismyname> 2. Someone tries some actual patch
+ ketas-av Kevin
+ Kevin, I played a bit with vala
+ so, any other additions on this subject? Any other languages?
+<kevin> I'm already trying to get more of a handle on C# for another project I'm working on and I also am 
looking more at Python. I don't need to deal with another (obscure?) language right now.
+<akk> Stupid question: would this be in the 2.8 timeframe, or 3.0, or what?
+<pippin> javascript can work quite nicely, using the same/similar api meta data binding generation that vala 
relies on
+<enselic> vala is low-prio
+ compared to high-prio things on our roadmap
+<lightningismyname> so tagging vala as a "hack if you want" on the roadmap?
+* pippin is playing with the idea of resurrecting a proper example GEGL ui front-end, and would be trying to 
avoid doing that in C
+<enselic> I don't think we should keep it on the roadmap, the roadmap should be high-level enough for users 
to digest
+ things there should matter for users
+<lightningismyname> I think there should be a "dev roadmap"
+<kevin> pippin: Python and wxWindows? :
+<enselic> LightningIsMyName: we don't need to put this on any roadmap imo
+<pippin> Kevin: I wouldnt exclude python,. but wxwindows is out of the quesiton
+<enselic> this meeting log is good enough
+<lightningismyname> ok :) so let's move on
+ topic 3: 2.8 - Get it out!
+ Enselic did a very serious clean of bugs for 2.8
+<enselic> first of all, things on the 2.6 milestone don't block a 2.8 release
+<lightningismyname> Enselic, what were the things you filtered off?
+ (other than 2.6 specific bugs)
+<enselic> I didn't touch any bugs on the 2.6 milestone, only on the 2.8, 2.10 and 3.0 milestones
+<kevin> isn't it a bit premature to change milestones on bugs set for 2.10 and 3.0?
+<enselic> we have a roadmap
+<lightningismyname> I'm going to ask a possibly "non popular" question - if we get 2.8 out, can we tell 2.6 
only bugs (that don't appear on 2,8) to go to hell?
+<enselic> our priorities are set, so I don't see how it was premature
+<lightningismyname> Enselic, roadmap is the next topic on the list - I think there is place to discuss it
+<enselic> LightningIsMyName: one we have released 2.8, I plan to go through the 2.6 bugs and remove them if 
they are not important
+ LightningIsMyName: ok
+<enselic> once we have*
+<lightningismyname> Is it acceptable to "discard" such bugs in open source?
+<enselic> with "remove" I meant "remove from milestone"
+ we fix what's important and what matters, we don't have resources to fix more things than that
+<schumaml> why would you do that. isn't it enough to resolve them as wontfix?
+<enselic> a bug is still a bug and should be in our bugtracker
+<schumaml> it is
+<lightningismyname> As a part of this topic, I also mentioned helping other devs.
+ Are there any devs here blocked by others, other than gui specs?
+<enselic> again, we're not blocked by gui specs...
+ afaik
+<lightningismyname> gui specs should have recieved "blocked"
+ speaking of gui, guiguru - do we/us/you have gimp interns?
+<enselic> are we done with "2.8, get it out"?
+<lightningismyname> not yet
+ Enselic, you said you'll work on swm, right?
+<enselic> I will, yes
+<lightningismyname> Is there any load of the work that other devs can take off from that project?
+ something which does not require deep hacking of the display?
+<enselic> not really no
+<lightningismyname> so yeah, we are done :P
+ topic 3: Roadmap Review
+ http://gimp-wiki.who.ee/index.php/GIMP_Roadmap
+ all devs and *users* please take a look
+<enselic> um "*users*"? ;)
+<pippin> ... I think taking the separate- plug-in given on the mailinglist and making it part of GIMPs 
default install is a sensible thing to do ...
+<lightningismyname> Enselic, roadmap is also about community :)
+<enselic> pippin: yes, but for 2.10, we must not add more features to 2.8
+<enselic> LightningIsMyName: fair enough
+<pippin> I am referring to the statement on the roadmap that CMYK is low priority
+<lightningismyname> quick question - why do we have 2.10?
+<enselic> well, existing patches have high priority
+<kevin> core developers *really* want JavaScript support?
+<enselic> LightningIsMyName: in particular because mitch wants to adjust the libgimp API before 3.0
+ ketas-av Kevin
+<lightningismyname> Kevin, not me
+<kevin> mitch has already stated more changes to the api are in the works.
+<lightningismyname> Has mitch discussed these api changes anywhere?
+ I haven't seen anything specific before it happened :P
+<kevin> I don't remember much of the discussion of the changes that have been made already.
+<enselic> not that I know of, but what he has done so far has been sensible
+<kevin> I'm not 100% certain about the sensible part.
+<lightningismyname> hehe
+<enselic> Kevin: what changes would you consider controversial?
+<kevin> Moving parameters out of the procedure call and making this context set of api calls seems odd and 
might have broken some scripts. It remains to be seen how that is going to work out.
+ ketas-av Kevin
+<enselic> Kevin: so you like functions with 10 parameters?
+<lightningismyname> Kevin, that actually makes sense - allow adding more parameters in the future
+<kevin> I am not sure if the default context values will be the same as the values previously used by 
scripts.
+<lightningismyname> Enselic, win32 api calls can have 20 :P
+ ketas-av Kevin
+ Kevin, has a point there - I'm also worried about that
+ I think we should add something like (gimp-context-reset "2.8")
+<enselic> why are you not sure?
+<kevin> I'm still not happy about the gimp-flip that used to be simple but now takes about a half dozen 
parameters to do a simple flip in either H or V directions.
+<enselic> isn't it as simple as, instead of   f(a, b, c); it's now f(b); f(c); f(a); ?
+<kevin> I have two other things I need to get done then I'll get back to reviewing pending patches for 
Script-Fu scripts. After the changes are commited, it will mean having to get someone(s) to test all 100 
scripts to make sure the move to context didn't break something.
+<lightningismyname> I think this is something we can use all the non programming users that wanted to help 
for
+<enselic> Kevin: that situation is a good argument for making sure new code gets regression tests written too
+<lightningismyname> I don't think we can write such tests for script-fu
+<kevin> gimp-flip used to take drawable and a direction. Now its replaced by 
gimp-drawable-transform-flip-simple which requires 5 parameters
+<enselic> LightningIsMyName: of course we can, it's software we're crafting
+<enselic> :)
+<lightningismyname> How do we write regression tests for scripts with random output?
+<enselic> Kevin: so write a simple wrapper function that you use in your scripts?
+<enselic> LightningIsMyName: seeding+
+<enselic> ?
+<kevin> A change that can affect parameters used in operations make it hard to write regression tests that 
would ensure scripts will still do what they used to do.
+<lightningismyname> I think that adding (gimp-context-reset "2.8") for a different versions is an asap 
requirement for allowing such wrapper functions
+ back to the roadmap, shall we?
+<enselic> yes please
+<kevin> Every script will need to push and pop context but IIRC, the script gets a copy of the existing 
context which may or may not have all the context settings as the default so a script may not work the same 
as before.
+<kevin> Move JavaScript to low priority?
+* guiguru was afk
+<lightningismyname> Enselic, how can "Automatic layer boundary management" be scheduled for 3.2, and also 
proposed as a gsoc this year?
+<guiguru> LightningIsMyName: interviewing 2 interns this week
+<lightningismyname> guiguru, great!
+<enselic> LightningIsMyName: the roadmap is not set in stone
+ LightningIsMyName: if code is ready, we merge it in
+<lightningismyname> so let's discuss it(=roadmap).
+ I'll begin with 2.10
+ doing a release just for bugfixes and libgimp changes?
+* guiguru signs off
+<enselic> LightningIsMyName: and the CMYK plug-in, and new layer modes
+<kevin> Its the last chance to get in any remaining API changes before 3.0
+<enselic> LightningIsMyName: and other things that will drop in
+<enselic> I'm willing to move JavaScript off the milestone btw
+<lightningismyname> The move to 3.0 includes integrating gegl as the core of everything, right?
+<enselic> I've moved JS off the roadmap now
+<enselic> LightningIsMyName: we will store image data in GeglBuffers, yes
+<kevin>  Enselic: ok. You could have moved it to low priority as its also currently a GSoC idea
+<lightningismyname> I was urged by many photographers whom I know, to ask this to be done earlier. Not that 
I can do anything about it, but I'm raising this here
+ GIMP 3.4 - "Auto-anchoring of floating selection"
+ can someone explain me why do we need floating selections? it's more of a trouble than anything else
+<kevin> what happened to 3.2?
+ ketas-av Kevin
+<lightningismyname> Kevin, no objection on 3,2 goals, I think :)
+<kevin> :-)
+<lightningismyname> Why can't pasting be above the current layer or at the top (different shortcuts) and we 
simply get rid of floating selections?
+ I'll lie if I say that I used these more than once in a month, and I use gimp daily as a user
+<mikachu> then how would you move what you pasted, if it's not a new layer?
+<kevin> How do other programs handle pasting? How would you be able to move a pasted thing in to position?
+<akk> I don't even use them that often, and I spend a lot of time trying to explain them to users who don't 
understand them.
+<lightningismyname> Mikachu, paste a new layer would paste above the current layer. then simply move
+ merge would be easy
+<kevin> What about automerge of the paste to current layer when tool changes from the move tool?
+ ketas-av Kevin
+<lightningismyname> Kevin - other ops may be needed on pastes - not sure that's the right criteria. but we 
can work something out
+<akk> The tool won't normally be the move tool to begin with.
+<schumaml> should we default to non-destructive solutions if possible?
+<pippin> ,. this is ux/guiguru territory, but we do know we want to get rid of the floating selection
+<akk> You might want to paste then scale, paste then levels/curves/brightness, ...
+<kevin> Paste something, move tool is selected, you move it then after changing tool, it merges. It would be 
predictable behaviour. Just have to decide which steps push Undo's
+<lightningismyname> I think getting rid of floating selection is easier than continuing to support it when 
moving to 3
+<akk> What if you don't want it to merge?
+ I always want pastes to be a new layer.
+* Enselic signs off
+<kevin> Paste as new layer.
+<lightningismyname> bye Enselic ;)
+<pippin> paste as new layer is a possible valid option
+<lightningismyname> The only problem is pasting on a channel, everything else doesn't need this
+<schumaml> but we're discussing 'move to new layer'
+<kevin> I usually want to paste to current layer and move the paste before anchoring. I don't tend to do 
other ops on a floating layer.
+<akk> I very often do ops on something I've just pasted
+ but I can't, until I make it a real layer -- can't do anything useful while it's floating
+<mikachu> i hate when you select something and do copy visible and paste, then try to new the layer, and it 
won't let you because you were accidentally in a layer mask
+<akk> can't even see it, a lot of the time.
+<lightningismyname> vote: Does anyone have a reason to use floating selections? (+1/0/-1)
+ (+=keep floating layers(
+<kevin> Only to allow me to move the paste to the right spot before anchoring.
+<lightningismyname> Kevin, a on canvas option for merging down a pasted layer, would fix that?
+<akk> If floating layers were eliminated, the Anchor button in the Layers dialog could do Merge down (which 
would be really handy anyway).
+<lightningismyname> suggested policy: after paste, while selection == pasted segment, show merge down
+<kevin> So a paste would always create a new layer above current selected layer but below any other higher 
layers? That might work but then that changes workflow to merge new pasted layer to active layer. Just need a 
simple way to merge the two.
+<lightningismyname> Kevin: how do you merge them right now?
+<kevin> paste, move, anchor.
+ simple
+<lightningismyname> anchor with keyboard or gui? both can be kept
+ Ctrl+H will merge down, and button will be replaced
+<kevin> Either. I usually use the gui as I don't always remember keyboard shortcuts
+<mikachu> merge down isn't the same as anchor, in case the layer isn't visible
+<lightningismyname> Ctrl+H: if after paste (and) selection = paste area (and) visible, merge down.
+<pippin> anchor would go away, and I guess all things achiveable in the other way would still be 
achievable.. but..
+ next topic?
+<kevin> How would merge down know which layers are to be merged if multiple layers exist&gt;
+<lightningismyname> "Layer effects" on 3.6 - can't we do that with filter layers?
+<akk> If paste made a new layer above the current one, it wouldn't have to know anything special.
+<pippin> IMO - filter effects and layer effects are two sides of the same thing
+<kevin> bbiab
+<akk> I thought they were both basically "make a UI for treating gegl ops as layers"
+<lightningismyname> practically, right
+<lightningismyname> seeing the lack of will of people to talk (and the desire to sleep for most of us), I 
suggest locking the meeting as discussed everything as much as we can with the current dev's attendancy
+ any topic that someone wants to raise before?
+<lightningismyname> I am hereby declaring this gimp developer meeting, LOCKED. Next meeting, March 28th - 
same time, same place
+```
diff --git a/content/conferences/IRC_Meeting/Dev_Meeting_19_Apr_2011.md 
b/content/conferences/IRC_Meeting/Dev_Meeting_19_Apr_2011.md
new file mode 100644
index 0000000..1a4e54a
--- /dev/null
+++ b/content/conferences/IRC_Meeting/Dev_Meeting_19_Apr_2011.md
@@ -0,0 +1,32 @@
+---
+title: "IRC developer meeting — 2011 April 19"
+author: "The GIMP Development Team"
+date: 2011-04-19
+lastmod: 2019-05-07
+---
+
+Meeting page for the Developer Meeting which will take place in the GIMP IRC on April 19th 2011, 20:00 UTC 
(For time zone conversions, see 
[here](http://www.timeanddate.com/worldclock/fixedtime.html?msg=GIMP+Developer+Meeting+%234&amp;iso=20110419T20)).
 '''Developers who mentor at GSoC, and all other admins involved in GSoC, must arrive 20 minutes earlier''' 
to a final meeting and "clicking some buttons" ;)
+
+## Agenda
+
+### GSoC final meeting - GSoC Mentors Only!
+
+As Alexia_Death stated, developers will meet 20 minutes before the official meeting in order to finish the 
process of handling GSoC student applications.
+
+### GIMP 2.8
+
+Congrats for the new GIMP 2.7.2 release :)
+
+Now this obviously leads to the discussion of what next? What can we do to speed up 2.8? Some devs asked how 
can they help on Single-Window-Mode (SWM) and there were also some more questions. The more devs attending 
this meeting, the more complete will be the image of what we have left to do.
+
+### Anything else?
+
+Reply on the mailing list or email LightningIsMyName, and it will be added. (Developers, feel free to add 
topics and/or edit existing ones)
+
+## Decided Actions
+
+To be filled once the meeting ends
+
+## Meeting Log
+
+Will try to record and upload once the meeting is done
diff --git a/content/conferences/IRC_Meeting/Dev_Meeting_28_Feb_2011.md 
b/content/conferences/IRC_Meeting/Dev_Meeting_28_Feb_2011.md
new file mode 100644
index 0000000..a9579dd
--- /dev/null
+++ b/content/conferences/IRC_Meeting/Dev_Meeting_28_Feb_2011.md
@@ -0,0 +1,509 @@
+---
+title: "IRC developer meeting — 2011 February 28"
+author: "The GIMP Development Team"
+date: 2011-02-28
+lastmod: 2020-01-26
+---
+
+Meeting page for the Developer Meeting which took place in the GIMP IRC on February 28th 2011, 10:00 PM CET 
(GMT+1)
+
+**Time for Next Meeting:** March 14 2011, 10:00 PM CET (GMT+1).
+
+## Agenda
+
+### GSoC 2011 - ORG Application deadline is in 11 days!
+
+We need to discuss the list of ideas that were raised on the mailing list. See 
[http://old.nabble.com/Google-Summer-of-Code-2011---Project-Ideas-Suggestions-to30911798.html](http://old.nabble.com/Google-Summer-of-Code-2011---Project-Ideas-Suggestions-to30911798.html)
+for GEGL, see [http://gegl.org/contribute.html](http://gegl.org/contribute.html)
+
+
+### Bug fixing priorities
+
+We won't get 2.8 or 3.0 out unless we start  doing concentrated bug fixes. We should set a priority list and 
try to stick with it, even if working on other stuff is more fun.
+
+
+### Future development?
+
+Some serious PDB changes are going on now, potentially many of these will be relevant for 3.0. This is worth 
a discussion, but not necessaraly today.
+
+
+### Make an official wiki working again (i.e. make wiki.gimp.org pointing at it)!
+
+Can be done by making [http://gimp-wiki.who.ee/](http://gimp-wiki.who.ee/) the official wiki - we need it to 
apply for GSoC, write roadmaps, etc. With all respect for bugzilla, discussions should be done in some more 
apropriate page.
+
+
+### Make a roadmap on the official wiki
+
+Self explanatory.
+
+
+### Try and decide on clear release policy for beta builds
+
+I personally would like to see more recent beta releases, and the last one was 7 months ago!
+
+
+### Schedule meetings?
+
+Depending on the success of this one, we should possibly start doing this regularly. This was tried in the 
past, and we'll try to do this again.
+
+
+### Anything else?
+
+Tell LightningIsMyName and he'll add it :)
+
+Random thought: Add an option to support gegl plugins with a gui nicely, for 2.8, so that users will start 
developing plugins for 3.0 in GEGL?
+
+
+## Decided Actions
+
+* schumaml and LightningIsMyName fix wgo?
+* Alexia and mitch take care of redirecting wiki.gimp.org
+* Enselic makes a draft of a GIMP roadmap and sends to gimp-developer
+* everybody subscribe to bug mail and TRIAGE BUGS
+* mitch, make a development release soo
+* LightningIsMyName takes care of next meeting
+* setting pages on the wiki to discuss changes in different topics
+* LightningIsMyName gets a list of projects on the wiki by tomorrow, developers review the ideas by email or 
by commenting on the wiki. Saturday (March 5th, 2011) is hard dead line for finalizing the project list!
+* all devs PM/Email LightningIsMyName username and email
+
+## Meeting Log
+
+```html
+## Topic: GIMP developer meeting, 22:00 CET (GMT+1) February 28th 2011 | Agenda: 
http://gimp-wiki.who.ee/index.php/Hacking:Dev_Meeting_28_Feb_2011 | THIS MEETING IS BEING LOGGED!
+
+<lightningismyname> Let's start :) Please take a look at the Agenda, as pointed by the topic, and read it
+<lightningismyname> The most burning issue for todays meeting, is potentially GSoC this year
+ We have 10 days to apply, and we still don't have an organized ideas list or a mentors list
+ Do we want to participate?
+<xsdg> I would suggest that the bigger issue is one of overall organization, and that the GSoC issues and 
the release issues are a consequence of that
+<lightningismyname> xsdg, you are probably right, but I don't know if we have time to fix all these before 
the application deadline
+<xsdg> As far as GSoC itself, if mentors want to step forward, great.  I have neither the knowledge nor the 
time.  I'm not sure there's anything non-mentors can really do about it
+ we could potentially lower the bar for mentoring, but that's probably not such a great idea.  It'd probably 
be more valuable (if mentors don't step forward) to deal with the higher-level issues and think about it 
again next year
+<lightningismyname> mitch, I know you offered to mentor "since you do it anyway". Now, is it serious and you 
have time, or was that just a cynical comment?
+<mitch> i meant it, but i'm not going to mentor a particular student
+ i will help when i'm on irc
+ mitch gives channel operator status to Mikachu
+<mitch> we should hear schumaml on that issue, he's been doing gsoc orga all the years
+<lightningismyname> schumaml - your opinion?
+<schumaml> I won't force anyone to become a mentor
+<mitch> so my estimate is that if nobody steps up and organizes things, gsoc this year will not happen
+<schumaml> if some of the previous mentors want to do it again, then I'll take care of the orga again
+<mitch> Alexia wanted to mentor again afail
+<lightningismyname> schumaml, does GSoC require specific mentors for each project, or can we have general 
mentors?
+<mitch> specific mentors
+<schumaml> each student is assigned one mentor
+<schumaml> and this mentor is responsible for all administrative stuff concerning that one student
+ e.g. evaluations
+<lightningismyname> Taking a look at the list of projects, does anyone have something which is urgent and 
GSoC could probably help more than regular development?
+<lightningismyname> I.e. is there something a student can take care of which is critical?
+<schumaml> should we decide not to apply as an org, then mentors could approach gnome ans ask to mentor gimp 
or gegl-related tasks
+<mitch> not really, otherwise it wouldn't be critical :)
+<guiguru_> (switching machine)
+<lightningismyname> Let's jump for a second - what's on the top of the todo list?
+ Except for fixing bugs
+<mitch> generally getting 2.8 out
+<lightningismyname> I can't see a clear roadmap anywhere, and that prevents me from knowing what to work on
+<schumaml> I'd like to have an auto-updating main website again
+<mitch> schumaml: you just volunteered
+<enselic> we should switch to a wiki so it's not a big project to keep the website up to date
+<lightningismyname> I volunteer to try and do website fixes if needed, the question is what do we want from 
auto-updating website?
+<mitch> a wiki for the main site?
+<lightningismyname> It was discussed previously today to point wiki.gimp.org at alexia's wiki. Any 
objections?
+<enselic> most parts of the main site
+<mitch> i don't think so, both for reasons of load and security, as pointed out on the list
+<enselic> not news for example
+<mitch> LightningIsMyName: not from me
+<schumaml> I think Alexia got a point about not introducing dynamic systems to www.gimp.org
+<enselic> we could have non-free-for-all registration
+<mitch> Enselic: giving out accounts is a prerequisite
+<lightningismyname> The registration to alexia's wiki is aprooved only by me and her, to avoid spam
+<mitch> no self registration
+<schumaml> we discussed that earlier today - as long as there is any script involved, the site is exploitable
+<enselic> LightningIsMyName: could I get an account?
+<lightningismyname> Each dev who creates an account (see the topic) and email me, will get an editing 
permission on the wiki
+<schumaml> and believe me, www.gimp.org would be a priority one target
+<lightningismyname> who has the control over the domain names?
+<mitch> snorfle
+<lightningismyname> snorfle?
+<mitch> shawn admunson(?)
+* Kevin waves hello
+<mitch> so let's focus in wgo for a moment
+ schumaml: since you see it as priority, what about mailing sven about an account, and simply fixing it? 
sven doesn't have the time
+<schumaml> I don't know what is missing, all I know is that commits to gimp-web aren't pulled and shown 
within minutes
+ I don't know if I can fix it, but I'
+<kevin> Sounds like you need Jenkins for the wgo
+<schumaml> ll try to do this
+<mitch> i don't know either, but sven can point you to a starting point
+<lightningismyname> I volunteer to try and help on that, if I'll have an account on gimp.org
+<mitch> fine with me
+<mitch> so action #1: schumaml and LightningIsMyName fix wgo?
+<lightningismyname> fine with me
+<schumaml> yes
+<kevin> If there is a script to build the wgo pages from a repo it just needs to be run by a cron job as a 
simple way to fix the problem.
+<lightningismyname> question 2: who can request re-direction of wiki.gimp.org to alexia's wiki?
+<mitch> i think the problem was commit hooks or something that would send a mail from the old svn server to 
foo and then bar would happen
+<kevin> mitch: That would be the better way instead of a cron job
+<mitch> Kevin: that's how it worked before
+* LightningIsMyName points back at redirecting wiki.gimp.org
+<mitch> LightningIsMyName: ideally, that wiki would be moved to the machine gimp.org runs on
+<schumaml> I think we can add a daily cron job as a fallback at least
+<kevin> who currently owns/maintains the DNS entries for g.o?
+<mitch> it's really big enough
+ Kevin: as said, snorfle
+<lightningismyname> didn't we just say we don't want that for security reasons?
+<mitch> LightningIsMyName: it could run in a chroot, or a vm, as sven said
+<lightningismyname> so we'll need someone who can mess with servers more than I know to do that
+<schumaml> I guess we need emergency response plans anyway?
+<lightningismyname> unless we have someone who volunteers to do that, that's ain't practical
+<mitch> but for the time being, a redirect would be better than the current situation
+<lightningismyname> agree
+<enselic> +1
+<schumaml> i.e. what to do if somethings seems fishy with any gimp.org?
+<enselic> mitch: can you talk to snorfle about that?
+<kevin> I have no problem working on servers
+ snorfle?
+<enselic> Kevin: gimp.org DNS admin
+<xsdg> Kevin: snorfle is a person
+<pippin> Shawn Amundson?
+<mitch> Enselic: sure, if alexia provides me with details, i'll take care of that
+<mitch> action #2: Alexia and mitch take care of redirecting wiki.gimp.org
+ pippin: precisely
+<lightningismyname> mitch, the link is at the topic, alexia is back, just joined #gimp
+<kevin> yes, I see Shawn. Snorfle has some interesting meanings in the Urban dictionary
+<enselic> Ok, next topic "Make a roadmap on the official wiki"
+<lightningismyname> Big topic
+<enselic> I can take care of that
+ I just need an account
+<lightningismyname> we first of all need 2.8 goals asap
+ Enselic, create one now, I'll give your permissions
+<enselic> that's easy, look at 
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&amp;bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED⌖_milestone=2.8
 and work on what's important ;)
+<mitch> LightningIsMyName: that would basically be "fix all milestome bugs" and "clean up open ends"
+<mitch> it's not *that* much to do actually
+<lightningismyname> guiguru, are you here? Some bugs there are dependant on you
+<guiguru> I guess so
+<enselic> LightningIsMyName: how do I register?
+<lightningismyname> guiguru: what are the chances we can start seeing specs soon?
+ Enselic, one sec
+<enselic> LightningIsMyName: specs are not blocking us, we'll do our best if we don't get specs
+<enselic> we can't wait forever
+ but we can fix things afterwards forever
+<lightningismyname> Enselic, http://gimp-wiki.who.ee/index.php?title=Special:UserLogin&amp;type=signup
+<guiguru> LightningIsMyName: high
+<mitch> and spec &lt;-&gt; impl is always a loop, so just get started
+<kevin> Apart from SF deprecation issues, there are two minor enhancements it would be nice to have in there 
before 2.8 (getenv and create a directory procedures)
+<enselic> LightningIsMyName: priv msg
+<xsdg> Enselic: are the priorities on that list accurate?
+<enselic> xsdg: no
+<xsdg> Enselic: how hard would it be for them to become accurate?
+ that would be a big help, I think
+<mitch> bugzilla priorities are noise only for the most part
+<xsdg> (I've certainly looked at that list and not known what to focus on)
+<enselic> xsdg: you can pick any of them
+<mitch> xsdg: just pick *any* bug that seems doable
+<xsdg> are they all 2.8 blockers?
+<mitch> even non-milestone bugs, as long as the patch fixes something :)
+<enselic> no, some of them we will ship without
+<xsdg> Enselic: it would be useful to know the difference between the two classes, then
+<enselic> I'm going to clean that list up once I get my site up and running
+<kevin> xsdg: The higher priority ones would be ones with 2.8 as their target milestone
+<xsdg> Kevin: all of the things on that list are milestone 2.8
+* LightningIsMyName points at "Random thought: Add an option to support gegl plugins with a gui nicely, for 
2.8, so that users will start developing plugins for 3.0 in GEGL?"
+<kevin> I'm not sure which list you are looking at
+<lightningismyname> is this practical?
+<kevin> Oh, that list.
+<mitch> and really, evetybody can help by simply subscribing to bugmail and at least *triaging* new bugs
+<enselic> action #3, Enselic makes a draft of a GIMP roadmap and sends to gimp-developer
+<mitch> come on guys, it's not that hard
+<enselic> next item on the agenda: "Try and decide on clear release policy for beta builds"
+<kevin> Sure. Just mark them all as RESOLVED, WONTFIX  ;-)
+<xsdg> mitch, Enselic: if our first goal is to get 2.8 out the door, we need to focus on the things which 
will allow us to accomplish that
+<mitch> how did that agenda point come up?
+<pippin> LightningIsMyName: that is part of the random non-roadmap which is http://gegl.org/contribute.html
+<enselic> I don't know, but I think we should have nightly binary builds so we don't need to worry about that
+<mitch> oh "beta build" is what we call a devel release now
+<xsdg> mitch: regarding subscribing to bugmail, would be good for there to be a way for people to learn 
about that
+<enselic> we have nightly tarball builds, it's not that hard to make binary builds from that
+<mitch> i can make one easily within the next 2 weeks or so
+ now that gegl is out
+<lightningismyname> I can have nightly builds of gtk+babl+gegl, but I need some FTP to host them
+ +gimp
+<mitch> Enselic: imho that can exist and is good, but advertizing it too much will feed the trolls
+<enselic> LightningIsMyName: host them here ftp://gimptest.flamingtext.com/pub/nightly-tarballs/
+<schumaml> how will we deal with nightly builds in bugzilla?
+<enselic> mitch: "feed the trolls"?
+ how?
+<lightningismyname> Enselic, need to check with ftcameron. I'll email him to see it's OK
+<mitch> a lot of "testing" from the clueless, and even more useless bugs
+<enselic> LightningIsMyName: you don't need to, I am admin on that machine
+<xsdg> schumaml: I think, possibly as a separate action item somewhere, we need to spend a bit more time 
making bugzilla more useful
+<schumaml> bug reported against 2.7.x-git20110316
+<mitch> schumaml: precisely
+<enselic> mitch: or more useful bugs
+<xsdg> schumaml: that would likely include updating the templates, making sure the defaults are useful, and 
not letting people edit the ones they tend to enter incorrectly
+<mitch> Enselic: nobody is even triaging new bugs around here
+ so action 3: everybody subscribe to bug mail and TRIAGE BUGS
+<michaelgr> If I may interject, nightly builds might also attract developers, if you advertise it.
+<enselic> it's not that important, is it?
+<xsdg> mitch: are there any guidelines for triaging bugs?
+ Enselic: "it" -&gt; ???
+<mitch> xsdg: look at them, understand them, judge them
+ Enselic: triaging bugs?
+<xsdg> mitch: what does that mean?
+<enselic> unimportant bugs that is
+<kevin> xsdg: Read them, does it make sense, can the problem be reproduced, does it need more input from 
reporter
+<schumaml> xsdg: it's not that hard, most are either reproducable or needinfo
+<lightningismyname> I have a document on making useful bug reports, is it possible to link to it in the 
submission form
+ ?
+<mikachu> Enselic: deciding which are important == triaging :)
+<enselic> I ignore == I think it's not important
+<schumaml> or duplicates
+ lots of duplicates
+<mitch> xsdg: check for duplicates, ask questions and set to NEEDINFO, close useless crap right away
+<xsdg> mitch, Kevin, schumaml: that's more than I knew 10 minutes ago.  As obvious as this may seem, these 
instructions need to go somewhere.
+<kevin> Right. also checking if bug has already been reported.
+<xsdg> it doesn't help if they only exist in your heads
+<schumaml> xsdg: gnome has bug triaging guidelines
+<jonnor> gnome should have general documentation for triaging available
+<kevin> If a patch has been supplied, does it look right, does it apply to the current (git master) source 
tree.
+<mitch> xsdg: get a wiki account and start a page :)
+<enselic> anyway.... action #4: mitch, make a development release soon
+<mitch> Enselic: fine with me
+<xsdg> mitch: I'm currently at work; not going to happen
+<enselic> mitch:
+ mitch: thanks
+ next item on the agenda "Schedule meetings?"
+<lightningismyname> Enselic, sure! I want to learn to make a release, I'm going to be increasingly active 
this year
+<mitch> LightningIsMyName: there is a release-howto in devel-docs
+<lightningismyname> The agenda isn't exactly ordered
+<kevin> LightningIsMyName: make distcheck is a start
+<lightningismyname> I think there are some other things which should be discussed
+<enselic> make distcheck is run each night...
+<schumaml> meetings? yes. late, like 10pm. interval?
+<lightningismyname> the question is if we want to get techinical today or some other time?
+<mitch> Enselic: action #5: enselic to finally return ;)
+<lightningismyname> I think that a bi-weekly meeting cycle would be productive
+<enselic> I'm afraid my girlfriend has infected my mind, I see a future of less GIMP activity :/
+<mitch> LightningIsMyName: you are more than welcome to push that
+<enselic> but it's a good kind of infection
+<lightningismyname> mitch - I am trying :)
+<enselic> I like being infected
+<mitch> Enselic: turn her into a hacker
+<schumaml> mitch: haeckse
+<enselic> meeting: not that often, every 2 months?
+<kevin> Definitely a good type of infection to have
+<lightningismyname> Also, I'm going to add another topic which I saw in comments of some users
+ They said we should sort of advertise gimp, by promoting the new features officially instead of just 
developer blogs
+<schumaml> two months is too long, imo
+<kevin> if you want regular meetings someone will have to set an agenda for the meetiings
+* pippin would like to have the meetings in #gimp instead of here
+<mitch> LightningIsMyName: if wgo was working, much of that would happen
+<lightningismyname> show more activity on the main website, possibly with features videos, to attract devs
+<mitch> pippin: i disagree
+<xsdg> Let's all pause; I think everyone's talking about a different thing
+ What are we discussing right now?
+<enselic> pippin just want the pleasure of telling people to shut up
+<mitch> heh
+<enselic> right now the topic is "Schedule meetings?"
+<lightningismyname> Boys, calm down ;) we were talking about scheduling meetings
+<mitch> LightningIsMyName: you seem to do a pretty good job, just go ahead with regular meetings
+<enselic> mitch: +1
+* pippin already has &gt;30 tabs in his irc client, would prefer not to have more
+<mikachu> you can close this one soon
+<kevin> 30??
+<lightningismyname> We need to get some technical meetings, and not just one like these
+* LightningIsMyName reminds people to stay on topic
+<lightningismyname> some people objected the recent PDB refactors
+ and there are some more changes that need to be dicussed
+<schumaml> technical meetings can be done by groups of interested people
+<mitch> LightningIsMyName: this is a good start already, we can'T get technical with hald our infrastructure 
down
+<enselic> action #6: LightningIsMyName takes care of next meeting
+<pippin> I like how the blenders devs hijack their regular channel, use /topic to force people staying on 
topic stating which part of the agenda they are on, etc. :)
+<mitch> half*
+ pippin: offtopic
+<kevin> :-)
+<pippin> mitch: it is on topic on the topic of scheduling meetings
+<lightningismyname> action #7: setting pages to discuss changes in different topics
+<enselic> next item on agenda: "Anything else? "
+<prokoudine_> LightningIsMyName, promoting features officially is not a problem
+<lightningismyname> prokoudine_, you volunteer?
+<prokoudine_> LightningIsMyName, I write news for gimp.org anyway
+<lightningismyname> good to know - the news are anonymous :)
+<mitch> LightningIsMyName: will you put the log and the collected actions up in the wiki?
+<lightningismyname> yes. btw, we still haven't finished one topic
+<kevin> Are you only going to promote new features after they are complete?
+<mitch> i know :)
+<lightningismyname> We didn't decide a thing about GSoC
+<lightningismyname> do we apply this year for something?
+ I agree to be a student, and there will be probably many other applications
+ there will be student interest, so it's a shame to miss the coding work
+<prokoudine_> LightningIsMyName, and will you mentor yourself? :)
+* pippin does not want to have direct responsibility of any student, wbut will aid in helping any strudent 
working on gegl or gegl related projects
+<schumaml> Alexia would mentor, I guess
+ Kevin ketas-wi
+<lightningismyname> ketas-wi, you are Alexia, right?
+<mitch> LightningIsMyName: i would mentor you :) but not some random fool
+<schumaml> I've asked Akkana as well, she could do a beginner task provided that it will end up in gimp if 
finished
+<prokoudine_> LightningIsMyName, he is not
+<gwidion> btw, sorry for last years gsoc.
+<kevin> I took myself off the mentor list but I could sign up again if there was something I might be able 
to help with. Last couple of years there hasn't been.
+<prokoudine_> gwidion, just finish the project, will you? :)
+<gwidion> my student would do even less things than what i 'd  ask her
+<mitch> LightningIsMyName: which would be self-mentring, but google's formalities followed, and i'd be 
around for any questions of course
+<lightningismyname> is there any project which we want to feed me/some-other-jobless-student for the summer?
+<kevin> Rewrite gimp-perl  :-)
+<pippin> LightningIsMyName: see http://gegl.org/contribute.html
+<mitch> fix pygimp
+<jonnor> If Enselic does not expect to find more time for gimp dev soon, having someone else work on 
single-window mode is pretty critical for 2.8
+<lightningismyname> jonnor, you are very right about that
+<jonnor> it is afaik, the one big thing blocking it
+<ankh> time-critical things have not been good for gsoc projects in the past
+<mitch> jonnor: i'm afraid that particular job will stick with me anyway
+<ankh> jonnor: that and more-than-8-bits
+<jonnor> Ankh: that is not for 2.8?
+<schumaml> can we release 2.8 with gtk+ 2.x at all?
+<mitch> Ankh: that's not a gcos project
+<lightningismyname> Anything potentially 3.0 targeted, that will not need re-writing later?
+<xsdg> Question: do we have a time goal for shipping 2.8?  I would say "december 31, 2011 at the very latest"
+<mitch> gsoc
+<ankh> mitch: agreed
+<kevin> mitch: Anything that can be taken off your plate and pushed to someone else to free up your time for 
SWM?
+<mitch> so, i have a general issue now that 3.0 came up
+<ankh> neither swm nor ?8bit is gsoc I fear
+<mitch> i figured that we will likely *never* get proper xinput back with gtk 2.x
+ so might i suggest something:
+<schumaml> and tablet support is broken on windows, too
+<mitch> 2.x -&gt; 3.x migration:
+<kevin> I'm also curious why ruler widgets were removed from gtk
+<gwidion> prokoudine_: My intentio is to "finish" the other Gsoc - jsut gimp python which was never 
integrated into trunk.
+<mitch> - deprecate as much as humanly possible in the 2.x api and replace it by stuff that is 3.x-able
+<enselic> xsdg: we don't know, but will know within a few months
+<mitch> - after 2.8 is out, have a short devel cycle
+<prokoudine_> gwidion, that's what I was referring to -- python project
+<carol> not /src/gimp/gkt+ like gap and ffmpeg? moving targets and all....
+<mitch> - gfet 3.0 out
+<lightningismyname> schumaml, does a ORG need to supply a list of projects in his application? If so, does 
google choose between these, or the ORG?
+<pippin> LightningIsMyName: the _student_ has to propose his own project, potentially inspired by the orgs 
list
+<xsdg> Enselic: I would suggest that we set a hard deadline sometime, and commit to shipping by that date.  
Otherwise we end up having this discussion next March
+<enselic> xsdg: that's not going to work
+<schumaml> mitch: so 3.0 would be just the gtk+ change?
+<kevin> Part of the release date issue is having a defined set of things to work on and getting those things 
done.
+<mitch> schumaml: plus really nicely working tablet hotplug and stuff
+ schumaml: and it's a big change
+<lightningismyname> schumaml, would you take care of our GSoC application this year? I'll organize a list of 
projects, and I'll put it on for review by the devs? Link will be on the mailing list tomorrow
+<schumaml> s/just //
+<lightningismyname> btw, all devs that want a wiki account, PM me a username and an email
+<xsdg> Enselic: Suppose that GIMP hadn't advanced March of next year.  Should we not release the stuff 
that's already done by that point?
+<xsdg> Enselic: what's in git already has value over the latest thing that's been released
+ (that is, excluding dev releeases)
+<xsdg> Enselic: do we want people to sit on 2.6 forever?
+<kevin> oh, well.
+ I still have 2.6 on my machine.
+<schumaml> xsdg: if they need tablet support, then probably yes
+<enselic> xsdg: the harm is done, people expect swm, we will get a lot of badwill if we ship without
+<mitch> xsdg: then just get started doing some hacks, roadmaps and hard dates don't help much on their own
+<gwidion> shure
+<xsdg> Enselic: is that worth people sitting on 2.6 for another year?
+<lightningismyname> I want to see 2.8 out soon, it's pretty stable at least for my everyday workflow. Better 
release and stop blocking ourselves, than blocking ourselves and the users
+ So it will a bit incomplete - legitimate for an end of cycle product
+<xsdg> mitch: I've been on a project that died because they couldn't release (geeqie).  I'm hoping it 
doesn't happen to gimp
+<pippin> Enselic: you just have to take a week off from work and emma, and hide in a rødmalt stuga...
+<prokoudine_> Enselic, what is exactly blocking simple swm?
+<kevin> One user reported working in SWM mode and felt it was working ok.
+<schumaml> LightningIsMyName: yes, please collect a list of projects
+<prokoudine_> Enselic, without image parade, I mean
+<enselic> see milestoned bugs...
+<lightningismyname> prokoudine_, it's not session managed
+<schumaml> LightningIsMyName: google uses this to judge whether an org is ready for gsoc
+<prokoudine_> LightningIsMyName, any estimations time-wise?
+<mitch> prokoudine_: what is the problem about image parade? i could hack that in one week
+<prokoudine_> mitch, no spec?
+<kevin> image parade?
+<mitch> prokoudine_: not a problem, i have a mind
+<prokoudine_> mitch, then go for it? :)
+<xsdg> mitch: this is why we need priorities
+<kevin> mitch is supposed to be working on SWM  ;-)
+<prokoudine_> that will leave us only broken tablets
+<mitch> prokoudine_: if you noticed, i'm already the main committer and my time is limited ;)
+<prokoudine_> mitch, I have :) I track it
+* pippin thinks mitch should focus on killing off 8bit :P
+<mitch> and other swm things are far worse
+<lightningismyname> action #8: LightningIsMyName gets a list of projects on the wiki by tomorrow, developers 
review the ideas by email or by commenting on the wiki. Saturday is hard dead line for finalizing the project 
list
+<schumaml> do we have any unassigned action items?
+<mitch> pippin: irrelevant for 2.8
+<enselic> mitch: btw, at some point you need to stop rebasing the gtk3 branch and merge master to it instead
+ regularly
+<pippin> "gimp developer(s) continue to ignore higher bitdepths" ;)
+<mitch> Enselic: clearly not
+* LightningIsMyName points at action #8
+<mikachu> i don't think that's a meeting topic
+<xsdg> schumaml: I would suggest that we have people initially prioritize things on the 2.8 milestone
+<mitch> i want a sane history
+<enselic> mitch: how are more than you supposed to be able to work on it then?
+<gwidion> pippin: "which sounds better than gimp developers continue not releasing"
+<xsdg> schumaml: I'm willing to help with that, but I don't feel I know enough to pass judgment on _all_ of 
those bugs
+<gwidion> unfortunatelly
+<mitch> Enselic: i don't see anyone even trying ot
+ it
+<lightningismyname> any devs will be willing to review the idea list with me?
+<enselic> mitch: no one can until you stop rebasing :)
+<mitch> Enselic: and it's close to done anyway
+<pippin> 60min since meeting start, where in the agenda are we by now?
+<xsdg> that said, I need to run. back in a bit
+<lightningismyname> pippin, sort of finished :P
+<enselic> mitch: do we share the same definition of "done"?
+ done to me means it's ready to be merged to git master and released
+<mitch> Enselic: done as in "works better than master" &lt;- good enough? :)
+<enselic> if there are no known regressions, than it's good enough
+ then*
+<mitch> there are missing plugins still
+ but Mikachu is very helpful there
+<mikachu> is neo still working on gfig?
+<mitch> Mikachu: damn good question
+* Enselic -&gt; bed
+<lightningismyname> Summarizing the list of actions:
+ action #1: schumaml and LightningIsMyName fix wgo?
+ action #2: Alexia and mitch take care of redirecting wiki.gimp.org
+ action #3, Enselic makes a draft of a GIMP roadmap and sends to gimp-developer
+<ankh> neither swm nor ?8bit is gsoc I fear
+ *8
+ `
+<lightningismyname> action 4: everybody subscribe to bug mail and TRIAGE BUGS
+  anyway.... action #4: mitch, make a development release soo
+ action #6: LightningIsMyName takes care of next meeting
+ action #7: setting pages to discuss changes in different topics
+ action #8: LightningIsMyName gets a list of projects on the wiki by
+  action #8: LightningIsMyName gets a list of projects on the wiki by tomorrow, developers review the ideas 
by email or by commenting on the wiki. Saturday is hard dead line for finalizing the project list
+<mitch> very nice
+<mikachu> you missed five
+<prokoudine_> LightningIsMyName, what happened to 5?
+<mikachu> LightningIsMyName: if i can help with some git thing wrt updating the web site, just ask
+<lightningismyname> action #9: all devs PM me username and password
+ sorry, an email
+ not a password
+ MikeM Mikachu
+ Mikachu, thanks :)
+<kevin> prokoudine_: It was the second #4?
+<mitch> LightningIsMyName: thanks for taking care of meeting stuff!
+<lightningismyname> mitch, no problem :) I just hope next time we get actual stuff done in addition to 
talking :)
+ schumaml, and everyone, I'll email the project list page to the dev-mail-list, people should review the 
list!
+<kevin> Is there an overall tracking bug for SWM stuff?
+<bat`o> is cage tool in 2.8 or not a topic that's worth to discuss ?
+<lightningismyname> There will be a wiki page for each important milestone, and I'll bug devs to fill the 
pages on their stuff
+<mitch> Bat`O: of course it will be in 2.8
+<bat`o> \o/
+<xsdg> kevin, I don't really think so
+<mitch> Bat`O: what about showing your changes done since it was merged?
+* Bat`O need to get back to work
+<xsdg> kevin, maybe just "do SWM", but certainly nothing beyond that
+<bat`o> mitch: you mean, merge my branch to master ?
+<lightningismyname> Anyone has any objection to lock the official meeting?
+<mitch> Bat`O: no, getting it past my evil review
+<kevin> I see 5 reports re: SWM
+<bat`o> i'm not against
+ but there is still a bad bug i need to kill
+<xsdg> kevin, I could be wrong :o)
+<mitch> i want one patch to try to apply
+<xsdg> It'd be awesome if I were
+<mitch> one patch where i can clearly see the changes, not some evil git diff against a non-rebased branch
+<kevin> xsdg: I think you might be right that there isn't a tracking bug.
+```
diff --git a/content/conferences/IRC_Meeting/Dev_Meeting_28_Mar_2011.md 
b/content/conferences/IRC_Meeting/Dev_Meeting_28_Mar_2011.md
new file mode 100644
index 0000000..fdf21f3
--- /dev/null
+++ b/content/conferences/IRC_Meeting/Dev_Meeting_28_Mar_2011.md
@@ -0,0 +1,72 @@
+---
+title: "IRC developer meeting — 2011 March 28"
+author: "The GIMP Development Team"
+date: 2011-03-28
+lastmod: 2021-04-17
+---
+
+Meeting page for the Developer Meeting which will take place in the GIMP IRC on March 28th 2011, 10:00 PM 
CET (For time zone conversions, see 
[here](http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=28&year=2011&hour=22&min=0&sec=0&p1=48))
+
+**Time for Next Meeting(?):** April 14 2011, 10:00 PM CET
+
+## Agenda
+
+### GSoC Student Applications
+
+Official GSoC applications should start coming in on march 28 19:00 utc - that's 2 hours before the meeting 
should begin. Also, we already have student applications on the mailing list. Some suggestions were made on 
putting minimal student requirements (not sure how practical this is) and some suggested creating some quick 
start guides for new developers. Do we want to do anything to get students started?
+BTW, since this is the developer wiki, such content should be placed here!
+
+Rating of students should be done after April 8 (student application deadline) and finish on April 22, so 
this can be done on the next meeting.
+
+For obvious reason, the writer of these lines (who applies for GSoC himself) will not participate in that 
part of the discussion.
+
+### Optional topic: Re-Discussing GIMP's programming language
+
+Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala 
into gimp, claiming that it will scare off developers (more than the "simple" C GObject code). '''Please see 
the topic thread on the mailing list!'''
+
+We should seperate this for:
+
+* GUI - Maybe try to use GtkBuilder and friends in more places, instead of a new language?
+* Core
+
+Also, we should discuss the reason for such act (GObject glue code is "annoying", or something else?)
+
+### Default JPEG Quality
+
+As someone suggested on irc a week ago, we should probably raise the default quality for jpeg images in 
gimp. Disk space and bandwidth are bigger today than before, and the current default quality is rather noisy.
+Hopefully just a yes/no vote, nothing more than that (unless there are some other plugins which have quality 
parameters).
+
+### bringing UI crew to LGM
+
+UI team gets build as we speak, can they come to LGM. would be good.
+
+### Resource management for 2.8
+
+Where are we with new brushes, patterns, etc.?
+
+### Anything else?
+
+Tell LightningIsMyName and he'll add it :)
+
+## Decided Actions
+
+* GSoC Student Applications
+  * Core developers sign up as mentors (for GSoC)
+  * schumaml: Write mail about application is open, and required skills, and required code example
+* Re-Discussing GIMP's programming language
+  * For core (non-UI), continue using GObject, use code generators (such as 
[turbine](http://git.gnome.org/browse/turbine/)) and do copy/paste/replace for existing GObject classes (for 
the rare case where the generator won't be enough).
+  * For UI, porting widgets to GtkBuilder is an option (and then we'll use Glade and UI xml files), but any 
action on the UI is postponed until we get 3.0 out!
+* Default JPEG Quality (quickie, not a real topic)
+  * Change to 95 2x1, and add a hack to save defaults (using something like the PNG plugin does, or 
something more elegant). Note that a decent system to save plugin defaults, along with other api changes, is 
not something that will happen for 2.8.
+* bringing UI crew to LGM
+  * Will be discussed with mitch and schumaml on the financial aspect (using gimp funds) when the team is 
fully assembled (parts of it are already assembled - hurray for guiguru and congrats for the new team 
memebers!)
+* Resource management for 2.8
+  * One member of the new UI team (lead by guiguru) will take care of that
+
+## Meeting Log
+
+No propper meeting logs, since the discussion included lots of off-topic stuff, and many of that should be 
filtered...
+Important off-topic points from the meeting, in addition to the decided actions above:
+
+* Seems as if most GIMP team can't attend LGM this year, but there may be a GIMP village in the [Chaos 
Communication Camp](http://events.ccc.de/2010/08/10/chaos-communication-camp-2011/) as most developers want 
to attend it
+* UI team members will start hanging on IRC once the team is assembled. Many developers suggested help in 
setting them up with build environments and every other thing they need. This will happen soon, so be nice to 
the new guys ;)
diff --git a/content/conferences/_index.md b/content/conferences/_index.md
index 97f1b73..f78ebd4 100644
--- a/content/conferences/_index.md
+++ b/content/conferences/_index.md
@@ -15,8 +15,8 @@ over the World have gathered at multiple occasions.
 
 Called historically as "GIMP Developers Conference", abbreviated
 GIMPCon, this event continued at the [Libre Graphics
-Meeting](https://libregraphicsmeeting.org/) for years, where we also
-exchanged with developers of other graphics FLOSS.
+Meeting](https://libregraphicsmeeting.org/) for years, starting in 2006,
+where we also exchanged with developers of other graphics FLOSS.
 These are where we get together and discuss the future development, hack
 on GIMP, meet GIMP users…
 
@@ -72,3 +72,21 @@ members. Some of these events are:
   ([announcement](https://www.gimp.org/news/2018/01/09/libre-graphics-meeting-scale-2018/))
 * GUADEC 2016, August 12-14, with Aryeom and Jehan presenting [ZeMarmot
   project](https://2016.guadec.org/schedule/index.html#42-zemarmot__open_animation_film_produced_with_foss)
+
+Finally some developers meeting happened online. A first attempt started
+with bi-weekly IRC meetings in 2011 (arranged by LightningIsMyName, once
+in every two weeks, on Monday at 10:00 PM, Central Europe Timezone
+(usually, CET = GMT+1), with a mail sent to the mailing list before each
+meeting to discuss the agenda, and after every meeting with a link to
+the meeting page). This process ended but the logs are still available
+for logging history:
+
+* [2011 April 19](irc_meeting/dev_meeting_19_apr_2011/)
+* [2011 March 28](irc_meeting/dev_meeting_28_mar_2011/)
+* [2011 March 14](irc_meeting/dev_meeting_14_mar_2011/)
+* [First IRC developer meeting! — 2011 February 28](irc_meeting/dev_meeting_28_feb_2011/)
+
+Nowadays more informal meetings are organized on video-conference tools
+such as Jitsi and more recently Big Blue Button, organized by Aryeom and
+Jehan. A few such meetings happened already in 2020, 2021 and 2022. So far
+these events are not logged.