Minutes meeting Oct 26

[Olav Vitters <olav bkor dhs org>]

See attached for full IRC log in UTC +1.

Attending:
 * lucasr
 * bkor
 * andre
 * murrayc
 * guenther

Regrets:
 * vuntz

+ release team membership changes
 - nobody was willing to leave
 - fredp was acceptable, some discussion regarding 9 man team being too
   big
   @vuntz to talk to fredp

+ looking back at the 2.24 cycle:
 - if vuntz is not around, the release is in trouble
  - bkor and mclasen mentioned too short timeframe between deadline and
    release
 - gdm decision process was bad
   @ by lucars: in future, if situation is not clear enough for too
                long, say no to the (rewritten) module

+ setting in stone the 2.25 schedule
 - andre already mailed it

+ new module proposals
 - external dep: libproxy 
   doesn't do the actual proxy handling, only finding out which proxy to
   use
 - gnome-user-share
 - likely: notification daemon, NM
 - ask to apply: (?)
    - conduit
      @andre will ask
    - webkit-gtk
      Epiphany isn't sure if webkit port will be ready in time.
      Yelp+devhelp are likely ok.
      Evolution is a lot of work, focus now is on de-bonofication. HTML
      widget is used than just Composer.
      @bkor to ask to concrete thoughts, from all modules

+ tasks for 2.25/2.26
  bkor proposed to get some doable non-forceful tasks that are promoted
  for a specific release
  - degnomeification (removal of libgnome*)
  - if glade-3 with gtkbuilder, glade->gtkbuilder
    Some doubt if glade-3 is ready in time. Also, glade convertion tool
    (used by some modules) fails for Nautilus.
  @mclasen to work on other good task proposals for 2.26

+ rewrites during 2.25/2.26
 - existing rewrites should be finished before starting new ones
 - mclasen mentioned that gconf might be rewitten (dconf?)
   --> likely to occur for 2.28
   @bkor to  ask desrt + codethink for plans/roadmap
 - 'webkit' --> see new module proposals
 - hal -> DeviceKit
   --> likely to occur for 2.28


+ release assignments
 - bkor declined from all
 @mclasen: 2.25.2, 2.25.4
 @lucasr: 2.24.3, 2.25.5, likely: 2.25.91

+ GNOME 3.0 discussion
 - two existing plans:
   - UI shell
   - revamped file management (federico)
 - board meeting mentioned that we need to make 3.0 more concrete from a
   release management perspective
    1. a roadmapping strategy
    2. a development process
 - GNOME 3 moduleset
   - once gshell materializes
   - should have rules like: no bonobo or libgnome or libgnomeui, etc
 - need to be clear that focus is on user experience, not the way it
   looks
 - consultation period:
    - lucasr proposed mailing 
    - no idea what happened during UI hackfest
      @vuntz, write down plans please
    - suggested message something like: 
      "we want to define the major goals for the next 2 years, we are
       willing to implement fresh/inovative ideas that improves GNOME's
       user experience. two major ideas came out from the ui hackfest, a
       new desktop shell and file management revamping, we believe those
       are exciting ideas as an initial effort to define our 3.0
       release.
       when suggesting something, try to keep in mind that: they should
       be "feasible", ideally based on existing development efforts,
       improve the user experience, etc"
     - ask targeted audience, not a free for all (e.g. only maintainers)
     - hackfest people should explain their ideas
     - we gather feasible ones and promote
   @lucasr: to write suggested message, send to r-t. Message shouldn't
            conflict with hackfest ui
   @mclasen: chat with owen about the 'hackfest team' perspective
 - need new meeting with vuntz participating
 - no updated gtk3 schedule

+ AOB:
 - not really part of meeting, but leio mentioned frustration from
   distribution POV regarding rewrites
    - gvfs being unstable during 2.22
    - gvfs && gnome-vfs mix
    - gnome-session not saving the session
    - loss of functionality after rewrite
 - also from leio: external dependencies being optional
    - explained that external deps are ok to be mandatory
    - leio gave example of vinagre depending on avahi for feature which
      not everyone wants
    - outcome: compile time things add to maintainers burden

-- 
Regards,
Olav

Oct 26 00:06:24 *	J5 has quit (Ping timeout: 600 seconds)
Oct 26 01:03:55 *	J5 (~quinticen c-76-24-17-105 hsd1 ma comcast net) has joined #release-team
Oct 26 01:16:44 *	J5 has quit (Ex-Chat)
Oct 26 01:33:02 *	kmaraas has quit (Ping timeout: 600 seconds)
Oct 26 10:15:16 *	kmaraas (~kmaraas 98 80-202-74 nextgentel com) has joined #release-team
Oct 26 18:40:00 *	mclasen (~mclasen c-24-62-230-73 hsd1 ma comcast net) has joined #release-team
Oct 26 18:43:41 *	mclasen is back now
Oct 26 18:43:47 <mclasen>	how long till we meet ?
Oct 26 19:32:16 <lucasr>	mclasen, in 1h30 I guess
Oct 26 19:32:30 <mclasen>	ok
Oct 26 20:24:36 *	guenther (~guenther IP-213157027052 dialin heagmedianet de) has joined #release-team
Oct 26 20:24:42 *	monkey|bot gives channel operator status to guenther
Oct 26 20:35:35 *	andre_ (~andre g224236068 adsl alicedsl de) has joined #release-team
Oct 26 20:35:35 *	bugbot gives channel operator status to andre_
Oct 26 20:35:37 *	monkey|bot gives channel operator status to andre_
Oct 26 20:36:16 *	andre_ gives channel operator status to kmaraas lucasr mclasen
Oct 26 21:02:07 <lucasr>	hey
Oct 26 21:02:10 <lucasr>	meeting now?
Oct 26 21:04:29 <lucasr>	andre_, bkor, fcrozat|gone, kmaraas, mclasen, vuntz, guenther, ping
Oct 26 21:04:48 <lucasr>	andre_, bkor, fcrozat|gone, kmaraas, mclasen, vuntz, guenther, meeting?
Oct 26 21:04:53 *	mclasen is here
Oct 26 21:04:58 <guenther>	I'm here, waiting for some food to heat up. ;)
Oct 26 21:05:11 <bkor>	there
Oct 26 21:05:25 <andre_>	yupp, just came back too
Oct 26 21:05:28 <lucasr>	ok
Oct 26 21:05:31 <lucasr>	agenda is:
Oct 26 21:05:33 <lucasr>	 + release team membership changes
Oct 26 21:05:33 <lucasr>	  - people willing to leave?
Oct 26 21:05:33 <lucasr>	  - new people (fredp is a good candidate)
Oct 26 21:05:33 <lucasr>	 + looking back at the 2.24 cycle:
Oct 26 21:05:33 <lucasr>	  - what went wrong?
Oct 26 21:05:34 <lucasr>	  - what went right?
Oct 26 21:05:36 <lucasr>	  - if people have things in mind that we should improve, etc.
Oct 26 21:05:38 <lucasr>	 + setting in stone the 2.25 schedule
Oct 26 21:05:40 <lucasr>	  - hopefully, this can be done before the meeting :-)
Oct 26 21:05:42 <lucasr>	 + new module proposals
Oct 26 21:05:44 <lucasr>	  - we should probably send a mail in the next few days, but we might
Oct 26 21:05:46 <lucasr>	    want to really announce the schedule first (for the deadline)
Oct 26 21:05:48 <lucasr>	 + release assignments
Oct 26 21:05:50 <lucasr>	 + GNOME 3.0 discussion
Oct 26 21:05:52 <lucasr>	vuntz is not coming, right?
Oct 26 21:06:00 <andre_>	no, he's family guy
Oct 26 21:06:05 <lucasr>	hehe
Oct 26 21:06:09 <andre_>	> + setting in stone the 2.25 schedule
Oct 26 21:06:10 <andre_>	already done
Oct 26 21:06:14 <lucasr>	ok
Oct 26 21:06:44 <lucasr>	about membership, I guess we should only decide about vuntz's suggestion for fredp
Oct 26 21:07:19 <lucasr>	andre_, fcrozat|gone and kmaraas already gave their +1
Oct 26 21:07:27 *	mclasen has no objections
Oct 26 21:07:33 <lucasr>	neither do I
Oct 26 21:07:41 <guenther>	Is there anything that holds us back from getting in a 9th guy to the team?
Oct 26 21:07:55 <lucasr>	guenther, what do you mean?
Oct 26 21:07:57 <lucasr>	any rule?
Oct 26 21:08:08 <bkor>	I don't feel too useful in r-t atm
Oct 26 21:08:10 <guenther>	something like that -- not that I would know any
Oct 26 21:08:33 <guenther>	I guess people pondering to leave will just state that anyway. ;)
Oct 26 21:08:43 <guenther>	FWIW, no objections either
Oct 26 21:09:16 <lucasr>	bkor, you mean you want to leave?
Oct 26 21:09:47 <lucasr>	bkor, or that you're just considering this possibility?
Oct 26 21:10:11 <bkor>	lucasr: I said something totally different
Oct 26 21:10:22 <bkor>	I don't feel useful, so I want to feel useful
Oct 26 21:10:30 <lucasr>	haha, ok
Oct 26 21:10:37 <lucasr>	I'm really sorry for that
Oct 26 21:10:53 <bkor>	however, the release deadline is for me *way* too short
Oct 26 21:11:14 <bkor>	I basically have Tue evening, plus finish Wed evening
Oct 26 21:11:18 <bkor>	that doesn't work
Oct 26 21:11:55 <lucasr>	bkor, but making releases is one of our tasks
Oct 26 21:11:56 <lucasr>	not all
Oct 26 21:12:01 <lucasr>	ok, abour fredp in release team topic, I'll just put in the notes that the team agrees to have him in
Oct 26 21:12:34 <bkor>	but if vuntz is not around our releases are really impacted
Oct 26 21:12:49 <mclasen>	bkor: I agree, it is hard/impossible for me too 
Oct 26 21:12:49 <lucasr>	yeah, that's true
Oct 26 21:13:06 <lucasr>	I'll probably have more time now (after my move)
Oct 26 21:13:32 <lucasr>	I implicitly understand that no one if considering to leave r-t for now
Oct 26 21:13:43 <lucasr>	ok, next: "looking back at the 2.24 cycle"
Oct 26 21:14:03 <lucasr>	imo, one of the bad points is what bkor just commented
Oct 26 21:14:18 <lucasr>	release are too centralized in vuntz hands right now
Oct 26 21:14:45 <lucasr>	another bad one was the decision making process about new gdm
Oct 26 21:14:55 <lucasr>	we took too long to decide
Oct 26 21:15:04 <lucasr>	basically we decided on the last minute
Oct 26 21:15:29 <guenther>	yeah, agreed
Oct 26 21:15:48 <guenther>	It also can cause harm, if things are left in such an uncertain state.
Oct 26 21:15:56 <lucasr>	yep
Oct 26 21:17:11 <lucasr>	we should be more objetive on future cycles
Oct 26 21:17:29 <lucasr>	when dealing with rewriten modules
Oct 26 21:17:45 <lucasr>	and/or new modules in general
Oct 26 21:18:20 <lucasr>	anything else? anyone?
Oct 26 21:18:57 <lucasr>	about the releases, how's everyone in terms of available time for that?
Oct 26 21:19:03 *	mclasen thinks that a lot of the contention wrt to rewritten modules stems from the general lack of direction
Oct 26 21:19:15 <lucasr>	mclasen and bkor already said the schedule it's not good for them
Oct 26 21:19:54 <lucasr>	mclasen, and the fact we have this implicit behavior of not "breaking" things
Oct 26 21:20:21 <bkor>	for gdm we should've made the decision earlier IMO
Oct 26 21:20:31 <bkor>	not everything resolved? -->2.20
Oct 26 21:20:39 <lucasr>	I wrote about this some time ago... http://blogs.gnome.org/lucasr/2008/06/15/notes-on-the-future-of-gnome-problems-and-questions/
Oct 26 21:21:36 <mclasen>	bkor: everything is never resolved -> perfect statis
Oct 26 21:21:39 <mclasen>	err, stasis
Oct 26 21:22:17 <lucasr>	mclasen, imo, there were some communication problems as well
Oct 26 21:22:54 <bkor>	we didn't get an answer for a long time
Oct 26 21:23:11 <bkor>	it resulted in delaying our decision
Oct 26 21:23:32 <bkor>	which impacted translators, which weren't too happy
Oct 26 21:24:29 <bkor>	we shouldn't have left that at the last moment
Oct 26 21:24:34 <lucasr>	I think if this happens again (we keep waiting for an answer or the situation is not clear for too long), we should just say no to the module
Oct 26 21:24:52 <lucasr>	after a certain deadline we define
Oct 26 21:25:26 <lucasr>	anything else?
Oct 26 21:26:11 *	behdad (~behdad CPE001217b19226-CM0012c9c84bc4 cpe net cable rogers com) has joined #release-team
Oct 26 21:27:22 <lucasr>	ok
Oct 26 21:27:37 <lucasr>	next: "setting in stone the 2.25 schedule"
Oct 26 21:27:42 <lucasr>	andre_, done, right?
Oct 26 21:27:46 <andre_>	yupp
Oct 26 21:28:05 <mclasen>	do you have a link at hand ?
Oct 26 21:28:58 <guenther>	http://live.gnome.org/TwoPointTwentyfive
Oct 26 21:29:39 <lucasr>	next: "new module proposals"
Oct 26 21:30:07 <lucasr>	andre_ has sent the mail already
Oct 26 21:30:22 <mclasen>	so far only two
Oct 26 21:31:24 <lucasr>	mclasen, yep, gnome-user-share and...?
Oct 26 21:31:49 <mclasen>	but I have asked colin and dan to look into proposing the notification daemon and NM in some form
Oct 26 21:31:55 <mclasen>	the other one is libproxy
Oct 26 21:32:02 <lucasr>	ah, yes, libproxy as external dependency
Oct 26 21:32:47 <lucasr>	ok
Oct 26 21:33:01 <lucasr>	anything being rewrite in this cycle?
Oct 26 21:33:04 <andre_>	maybe we should explicitly ask conduit to reapply, if they want
Oct 26 21:33:35 <mclasen>	lucasr: we should probably finish off the rewrites that are currently underway before starting any new ones...
Oct 26 21:33:36 <lucasr>	andre_, yeah
Oct 26 21:33:44 <guenther>	which implies they have addressed the criticism...
Oct 26 21:33:49 <bkor>	webkit, or is that an implicit ok?
Oct 26 21:34:02 <mclasen>	but in general, gconf is on the list of rewrite candidates...
Oct 26 21:34:14 <lucasr>	mclasen, yeah, that's the point I want to make, we should be careful with too many rewrites
Oct 26 21:34:21 <mclasen>	right, webkit should probably be brought up again, too
Oct 26 21:34:23 <bkor>	will that be ready in time (you mean dconf right)?
Oct 26 21:34:40 <mclasen>	I don't know, up to desrt (and codethink ?)
Oct 26 21:34:50 <lucasr>	let's see
Oct 26 21:35:04 <lucasr>	my impression is that this will end up being proposed for 2.28
Oct 26 21:35:14 <lucasr>	just an impression though
Oct 26 21:35:20 <bkor>	I assume (guess) the same
Oct 26 21:35:35 <bkor>	maybe ask for explicit tasks for a release?
Oct 26 21:35:37 <mclasen>	what we have in the making is the hal -> DeviceKit transition, but thats a 2.28 topic at this point, too
Oct 26 21:35:56 <lucasr>	and for something like dconf, the ideal process would be to have it "pre-proposed" on 2.26
Oct 26 21:36:14 <lucasr>	so that developers are aware of it before it's officially proposed
Oct 26 21:36:20 <bkor>	nothing forceful, more a 'we really like if X was done' (like libgnome* removal)
Oct 26 21:36:37 <lucasr>	bkor, I think that's doable
Oct 26 21:36:42 <mclasen>	bkor: its a good idea
Oct 26 21:36:55 <mclasen>	degnomification seems to be an idea whose time has come...
Oct 26 21:37:09 <lucasr>	ok, actions I saw here are:
Oct 26 21:37:31 <lucasr>	- someone to talk to conduit guys to know if they want to propose for 2.26
Oct 26 21:37:49 <lucasr>	- someone to make a call for tasks
Oct 26 21:38:03 <lucasr>	maybe we should suggest one big task
Oct 26 21:38:15 <lucasr>	the degnomification seems to be the best candidate at this point
Oct 26 21:38:34 <mclasen>	if glade-3 gets gtkbuilder support in time, tackling glade -> gtkbuilder would be nice, too
Oct 26 21:38:36 <lucasr>	proposing more than one task may make developer lose focus
Oct 26 21:39:03 <lucasr>	andre_, can you talk to conduit guys?
Oct 26 21:39:32 <andre_>	yupp
Oct 26 21:39:53 <lucasr>	bkor, mclasen, can one of you work on the task proposals?
Oct 26 21:40:10 <mclasen>	sure
Oct 26 21:40:16 <lucasr>	cool
Oct 26 21:40:24 *	bkor is fine too
Oct 26 21:40:34 <bkor>	other actions:
Oct 26 21:40:52 <lucasr>	bkor, mclasen, glade->gtkbuilder and degnomification are good suggestions
Oct 26 21:40:52 <bkor>	- talk to dconf, get a roadmap/readiness?
Oct 26 21:41:00 <lucasr>	bkor, yeah
Oct 26 21:41:11 <lucasr>	bkor, I can do that
Oct 26 21:41:32 <bkor>	ok, then also need to talk to epiphany guys regarding webkit-gtk
Oct 26 21:41:40 <lucasr>	anyone?
Oct 26 21:41:45 <bkor>	IMO if they say it is ready, then it is in
Oct 26 21:41:48 <guenther>	Hey, I got the impression bkor /wants/ to do it. ;)
Oct 26 21:42:01 <lucasr>	hehe
Oct 26 21:42:09 <lucasr>	bkor, you do it then?
Oct 26 21:42:22 <mclasen>	webkit conversion is more than just epiphany though, right ?
Oct 26 21:42:22 <bkor>	lucasr: dconf + epiphany/webkit
Oct 26 21:42:32 <lucasr>	bkor, ok
Oct 26 21:42:41 <guenther>	mclasen: yes
Oct 26 21:42:42 <bkor>	mclasen: yes, but from what I understood during GUADEC, that yelp etc is ready
Oct 26 21:42:47 <guenther>	epiphany and yelp
Oct 26 21:42:53 <guenther>	plus Evo as bonus
Oct 26 21:42:55 <bkor>	mclasen: hmm, maybe proper investigation
Oct 26 21:42:55 <mclasen>	devhelp too
Oct 26 21:42:57 <lucasr>	needs testing though
Oct 26 21:43:18 <mclasen>	getting some insight into the evo roadmap would be good, too
Oct 26 21:43:28 <bkor>	so maybe as 'task': ensure webkit will kick out firefox?
Oct 26 21:43:40 <lucasr>	this is why it's quite important to have the webkit support official asap (if that makes sense)
Oct 26 21:44:05 <mclasen>	I know mbarnes has been working on de-bonoboization and webkittification, then there's the dbus work, etc
Oct 26 21:44:16 <bkor>	so talk to the relevant apps now, and then if ready put webkit in jhbuild?
Oct 26 21:45:12 <lucasr>	makes sense to me
Oct 26 21:45:36 <mclasen>	I can try to corner mbarnes and find some evo roadmap information
Oct 26 21:46:01 <lucasr>	it seems there's a lot of work to be done in ephy
Oct 26 21:46:37 <lucasr>	there was this plan to make a hackfest around that but it ended up not happening
Oct 26 21:47:02 <lucasr>	let's see, the board would be happy to sponsor something like this
Oct 26 21:47:33 <lucasr>	ok, anything else?
Oct 26 21:47:35 <andre_>	mbarnes will work on evo/webkit once debonobozation is done
Oct 26 21:47:41 <andre_>	see http://bugzilla.gnome.org/show_bug.cgi?id=540362
Oct 26 21:47:42 <bugbot>	Bug 540362: enhancement, Normal, ---, evolution-mail-maintainers ximian com, NEW, Use webkit for composer
Oct 26 21:48:35 <bkor>	http://live.gnome.org/Epiphany/Meetings/20081020 <-- webkit in epiphany
Oct 26 21:48:39 <guenther>	heh, that Summary is incomplete
Oct 26 21:48:56 <bkor>	webkit in 2.26 will be not impossible, but difficult
Oct 26 21:49:00 <guenther>	There's more HTML rendering in Evo than the Composer only.
Oct 26 21:49:53 <andre_>	sure, and some gtkhtml elements not available in webkit
Oct 26 21:50:57 <lucasr>	ok, next: "release assignments"
Oct 26 21:52:07 <lucasr>	I'll probably be very unresponsive during november 
Oct 26 21:52:21 <lucasr>	because I'm moving to London next week
Oct 26 21:52:40 <lucasr>	and I'll be settling down
Oct 26 21:52:57 <bkor>	oh right, when is the party?
Oct 26 21:53:12 <lucasr>	hehe next saturday!
Oct 26 21:53:18 <bkor>	anyway, I must decline for all, I now the time is too short
Oct 26 21:53:33 *	mclasen can do one of the december releases
Oct 26 21:54:22 <lucasr>	mclasen, is 2.25.2 ok for you?
Oct 26 21:54:30 <mclasen>	sure
Oct 26 21:54:33 <lucasr>	ok
Oct 26 21:54:36 <lucasr>	anyone else?
Oct 26 21:55:08 <lucasr>	I can do 2.24.3 and 2.25.5
Oct 26 21:55:18 <mclasen>	I can probably do one in january too
Oct 26 21:55:40 <lucasr>	2.25.4? :-)
Oct 26 21:55:46 <mclasen>	perfect fit
Oct 26 21:56:03 <lucasr>	ok
Oct 26 21:56:16 <lucasr>	I can probably do 2.25.91 as well
Oct 26 21:56:46 <lucasr>	so far:
Oct 26 21:57:00 <lucasr>	mclasen -> 2.25.2 and 2.25.4
Oct 26 21:57:18 <mclasen>	we should probably leave the rest to vuntz, or he'll get withdrawal symptoms...
Oct 26 21:57:22 <lucasr>	me -> 2.24.3, 2.25.5 and 2.25.91
Oct 26 21:57:29 <lucasr>	hehe
Oct 26 21:58:27 <lucasr>	for the others, feel free to assign for releases later
Oct 26 21:58:44 <guenther>	Maybe fredp wants to join a release with one of you.
Oct 26 21:58:57 <lucasr>	guenther, good idea
Oct 26 21:59:18 <guenther>	I'd say just ask him, and let him decide which one(s).
Oct 26 21:59:42 <lucasr>	I'm implicitly considering that vuntz will talk to fredp about r-t
Oct 26 22:00:00 <lucasr>	so, I'll leave this to vuntz
Oct 26 22:00:06 <guenther>	*nod* likely
Oct 26 22:00:25 <lucasr>	next: "gnome 3.0"
Oct 26 22:00:44 <lucasr>	that's the nicest topic :-P
Oct 26 22:01:16 <bkor>	oh btw, I also like Luca Ferretti, less active lately though
Oct 26 22:01:37 <lucasr>	I prefered to wait for this meeting before sending the roadmap call
Oct 26 22:01:51 <lucasr>	because I wanted to know what we want to do about 3.0 first
Oct 26 22:02:12 <bkor>	there was a UI hackfest, but not sure about plans
Oct 26 22:02:20 <lucasr>	at this point, we have some more concrete stuff for the future
Oct 26 22:02:46 <bkor>	seems like a lot of work and our deadline is not so far away
Oct 26 22:02:47 <lucasr>	we talked about this during the last board meeting
Oct 26 22:03:09 <lucasr>	the consensus was that we need to make 3.0 more official from a release management perspective
Oct 26 22:03:16 <lucasr>	more official = more concrete
Oct 26 22:03:35 <lucasr>	in practice, as I see it, this would initially involve:
Oct 26 22:03:36 <bkor>	we need to set goals yes
Oct 26 22:03:52 <lucasr>	1. a roadmapping strategy
Oct 26 22:04:07 <mclasen>	I guess once gshell materializes, we can start to put together a gnome3 jhbuild moduleset
Oct 26 22:04:18 <lucasr>	2. a development process
Oct 26 22:04:28 <lucasr>	mclasen, true
Oct 26 22:04:54 <mclasen>	not sure how far off that is, but I can talk to owen
Oct 26 22:05:13 <bkor>	also saw some stupid feedback that the UI stuff was 'exactly like' plasma
Oct 26 22:05:15 <lucasr>	have you read http://blogs.gnome.org/bolsh/2008/10/22/call-to-release-team-open-shop-on-gnome-30-planning/
Oct 26 22:05:17 <lucasr>	?
Oct 26 22:05:26 <bkor>	plasma IMO is just applet stuff
Oct 26 22:05:47 <bkor>	but I haven't used KDE4, nor really understood the intention of plasma from the blogs
Oct 26 22:06:13 <lucasr>	being similar to kde 4 on the ui level is a big problem per se
Oct 26 22:06:32 <lucasr>	is *not* a big problem I meant
Oct 26 22:06:34 <lucasr>	hehe
Oct 26 22:06:38 <bkor>	I don't mean that
Oct 26 22:06:57 <bkor>	what from I read, the hackfest was about experience
Oct 26 22:07:06 <bkor>	not about new applets and so on
Oct 26 22:07:15 <lucasr>	ah, ok
Oct 26 22:07:25 <bkor>	so need to be clear that we focus on that
Oct 26 22:07:35 <lucasr>	iiuc, applets was one of the topics
Oct 26 22:07:47 <bkor>	iiuc?
Oct 26 22:08:00 <lucasr>	I like bolsh's idea for a consultation period
Oct 26 22:08:19 <lucasr>	bkor, If I Understood Correctly
Oct 26 22:08:42 <lucasr>	what do you think?
Oct 26 22:08:59 <lucasr>	it's basically what I've been doing with the roadmap calls
Oct 26 22:09:17 <lucasr>	but we'd have a more focused section about 3.0
Oct 26 22:09:20 <bkor>	good idea
Oct 26 22:09:58 <lucasr>	defining major and feasible topics for 3.0 is good first step imo
Oct 26 22:10:07 <bkor>	but we shouldn't forget: 1) I don't like open for all crap  2) I dislike brainstorm  3) it is not too far off (nothing too radical)
Oct 26 22:10:41 <lucasr>	we already have 2 good candidates: new shell (window management and task launching) and revamped file management
Oct 26 22:10:58 <lucasr>	window management = task switching
Oct 26 22:11:27 <lucasr>	the new shell goal involves topics which are handled by several modules
Oct 26 22:11:33 <bkor>	I'd like something simple enough to implement, so we know it is possible (not easily 6+ month delay), but not to 'UI minor' to avoid that nothing was done
Oct 26 22:11:39 <lucasr>	and makes a big different from user perspective
Oct 26 22:11:46 <mclasen>	I don't necessarily think that the release team needs to do the 'defining' work on this
Oct 26 22:12:04 <mclasen>	after the ui hackfest, things seem to be off the ground to some extent
Oct 26 22:12:19 <lucasr>	mclasen, you're right
Oct 26 22:12:20 <bkor>	mclasen: IMO we just define the ideas that are with maintainers
Oct 26 22:12:51 <bkor>	so maintainers think stuff up, and we check if doable, then promote
Oct 26 22:12:56 <lucasr>	mclasen, but imo the "message" is important too 
Oct 26 22:13:05 <mclasen>	there's a certain role for making sure that the central ideas are clearly communicated, to give some focus
Oct 26 22:13:38 <lucasr>	mclasen, for example, if make it a "official" module set and call it 3.0 this may bring some momentum to the new code
Oct 26 22:13:45 *	behdad has quit (Leaving.)
Oct 26 22:13:55 <mclasen>	yes, that too
Oct 26 22:14:33 <lucasr>	so, how do you think this "consultation period" should happen?
Oct 26 22:14:35 *	bkor believes in the first paragraph on http://live.gnome.org/ReleasePlanning, but promoting is a big part
Oct 26 22:16:09 <bkor>	silence :)
Oct 26 22:16:39 <lucasr>	hehe
Oct 26 22:16:45 <bkor>	my proposal: define things that are happening/proposed now
Oct 26 22:17:31 <bkor>	that determine from devs if that would be solvable before/for 3.0
Oct 26 22:17:42 <bkor>	but that wouldn't get any new ideas in..
Oct 26 22:17:51 *	mclasen was distracted by sunday afternoon activities
Oct 26 22:18:21 <bkor>	maybe everyone should just do a proposal for consulation method
Oct 26 22:18:46 <bkor>	andre_: quit the drugs and continue pls :)
Oct 26 22:20:01 <bkor>	hmm, fcrozat|gone ?
Oct 26 22:20:17 <lucasr>	imo, the message should be something like "we want to define the major goals for the next 2 years, we are willing to implement fresh/inovative ideas that improves GNOME's user experience. two major ideas came out from the ui hackfest, a new desktop shell and file management revamping, we believe those are exciting ideas as an initial effort to define our 3.0 release"
Oct 26 22:20:40 <lucasr>	"what are yours?"
Oct 26 22:21:22 <bkor>	include a 'but they must be doable within 2 years'
Oct 26 22:21:31 <bkor>	or something more politically correct
Oct 26 22:21:51 *	andre_ reads the backlog
Oct 26 22:21:59 <lucasr>	"when suggesting something, try to keep in mind that: they should be "feasible", ideally based on existing development efforts, improve the user experience, etc"
Oct 26 22:22:23 <lucasr>	my point here is that, for gnome *desktop*, the focus should be on user experience
Oct 26 22:22:26 *	bkor doesn't like innovative, but personal thing.. I saw the 'innovative' responses after that was the new popular word where I work.. same old stuff, and worse
Oct 26 22:22:43 *	lucasr nods
Oct 26 22:23:18 <lucasr>	my point is more to make it clear that we're willing to "break" the current ui, if that brings improvements to our users
Oct 26 22:24:16 <bkor>	yes
Oct 26 22:24:25 <lucasr>	on the other hand, I don't like the "think from scratch" aproach where you just ignore the current good aspects of our ui and design something *completely* different
Oct 26 22:24:44 <bkor>	but that wouldn't be possible in 2 years
Oct 26 22:24:45 <lucasr>	there should be some balance
Oct 26 22:24:58 <bkor>	maybe just state something like that
Oct 26 22:25:20 <lucasr>	what do others think?
Oct 26 22:25:25 <bkor>	mention we still have to do a GNOME 4.0 ;)
Oct 26 22:25:30 <lucasr>	hehe
Oct 26 22:25:31 <mclasen>	lucasr: thats not happening anyway (blank slate)
Oct 26 22:26:06 *	mclasen thinks it is up to the hackfest participants to open up the discussion about their ideas
Oct 26 22:26:14 <bkor>	I guess if you ask the right people, that is not going to be proposed anyway
Oct 26 22:26:15 <mclasen>	to some extent that has been happening
Oct 26 22:26:35 <bkor>	mclasen: did you participate?
Oct 26 22:26:41 <mclasen>	no
Oct 26 22:27:48 <bkor>	asking is intended so we don't just focus on who was at the hackfast
Oct 26 22:27:50 <bkor>	fest
Oct 26 22:27:59 <lucasr>	bkor, exactly
Oct 26 22:28:18 <bkor>	we shouldn't conflict though, but I think vuntz is good enough to avoid that
Oct 26 22:28:39 <bkor>	we just ask him if ok
Oct 26 22:28:55 <lucasr>	ok
Oct 26 22:29:32 <lucasr>	I'll try to come up with a call for 3.0 topics text and send to r-t mailing list for comments
Oct 26 22:29:57 <lucasr>	about the release management part of all this
Oct 26 22:30:09 <mclasen>	sounds good
Oct 26 22:30:29 *	mclasen will chat with owen about the 'hackfest team' perspective
Oct 26 22:30:35 <lucasr>	do we agree that as soon as the new shell has a more concrete form (aka code), we should create a moduleset for that?
Oct 26 22:30:43 <bkor>	yeah
Oct 26 22:30:52 <lucasr>	mclasen, that would be nice, thanks
Oct 26 22:31:52 <lucasr>	bkor, with the new moduleset, we should probably have a set of rules to have modules in the "3.0" mode
Oct 26 22:31:54 <mclasen>	do we have more to discuss ? 
Oct 26 22:31:59 *	mclasen needs to drop out soon
Oct 26 22:32:30 <lucasr>	for example, it shouldn't depend on bonobo or libgnome or libgnomeui, etc
Oct 26 22:32:33 <bkor>	more a board like thing:
Oct 26 22:32:46 <bkor>	http://www.markshuttleworth.com/archives/223 <-- lucasr, so GNOME gets a few dedicated persons for 3.0 ?
Oct 26 22:33:18 <bkor>	lucasr: we're fucked if shell isn't done (panel will always depend on bonobo)
Oct 26 22:33:27 <bkor>	but I agree
Oct 26 22:33:54 <lucasr>	bkor, we're working on getting adboard members to help on 3.0 discussion and efforts
Oct 26 22:34:21 <bkor>	lucasr: every time I see adboard I think they're only good for promoting GNOME
Oct 26 22:34:32 <bkor>	and that I don't like ads
Oct 26 22:34:51 <lucasr>	bkor, adboard members = company that hire people who indirectly or directly work on gnome
Oct 26 22:34:59 <lucasr>	companies
Oct 26 22:35:06 <bkor>	lucasr: I know, advisory board
Oct 26 22:35:13 <lucasr>	bkor, so, yes, we're talking about resourcing too
Oct 26 22:35:14 <bkor>	I always think advertisement board
Oct 26 22:35:29 <lucasr>	hehe
Oct 26 22:35:57 <lucasr>	anything else?
Oct 26 22:36:23 <bkor>	people ok with another GNOME 3.0 meeting, but now with vuntz?
Oct 26 22:36:43 <bkor>	not what was discussed now
Oct 26 22:36:51 <bkor>	but IMO vuntz has a good plan in his head
Oct 26 22:36:58 <bkor>	but we need to know it all
Oct 26 22:37:17 <mclasen>	fine with me
Oct 26 22:37:23 <lucasr>	me too
Oct 26 22:37:37 <andre_>	me too
Oct 26 22:37:38 <guenther>	yup, picking vuntz's brain isn't a bad idea
Oct 26 22:38:26 <lucasr>	vuntz said he's going to send his ideas to mailing list
Oct 26 22:38:42 <guenther>	heh, he said that, right...
Oct 26 22:38:44 <bkor>	hehe, 
Oct 26 22:38:47 <bkor>	since UDS
Oct 26 22:39:00 <lucasr>	maybe he's preparing this really long mail since uds
Oct 26 22:39:03 <lucasr>	like a book
Oct 26 22:39:07 <lucasr>	hehe
Oct 26 22:39:51 <lucasr>	there's this whole gtk 3.0 discussion which we need to know about too
Oct 26 22:39:55 <lucasr>	in terms of schedule
Oct 26 22:39:55 <bkor>	it is pretty funny, talking about 3.0 at UDS, then stupid decadence thread, then GAUDEC with announce, and now gshell, UI talk at pgo
Oct 26 22:40:51 <bkor>	just how a 'feeling' can influence development
Oct 26 22:40:58 <lucasr>	hehe
Oct 26 22:41:46 <lucasr>	mclasen, is there any concrete plan for gtk 3.0 in terms of schedule?
Oct 26 22:44:16 <bkor>	I guess he left
Oct 26 22:44:20 <lucasr>	yeah
Oct 26 22:44:27 <bkor>	end of meeting?
Oct 26 22:44:30 <lucasr>	yep
Oct 26 22:45:10 <lucasr>	gotta go
Oct 26 22:45:13 <lucasr>	night all!
Oct 26 22:45:21 <guenther>	night
Oct 26 22:45:29 <bkor>	OO.org: "Most surprising is the fact that over 80% of downloads were from Windows users."...
Oct 26 22:45:40 <bkor>	I hope the rest is Mac
Oct 26 22:45:44 <leio-dl>	I'd have some comments if the meeting is over
Oct 26 22:45:50 <mclasen>	lucasr: sorry, I was gone for a bit; no update on gtk3 at this point
Oct 26 22:45:55 <bkor>	.. who gets it for Linux, packaged is way easier
Oct 26 22:46:19 <lucasr>	mclasen, ok
Oct 26 22:46:20 <guenther>	bkor: reminds me of FF...
Oct 26 22:46:41 <bkor>	guenther: /., so understandable that comment is idiotic
Oct 26 22:46:47 <guenther>	At one point FF devs thought there is no point in enhancing Linux related stuff...
Oct 26 22:46:50 <lucasr>	mclasen, just asking because we probably want to sync gnome 3.0 with gtk 3.0 at some point
Oct 26 22:46:58 <lucasr>	leio, shoot
Oct 26 22:46:59 <guenther>	because there are just a very few Linux downloads
Oct 26 22:47:05 <mclasen>	yeah, I'll get back to gtk when F10 is out
Oct 26 22:47:05 <guenther>	off of *their* site
Oct 26 22:47:21 <guenther>	They didn't understand that most Linux users get it from their distro.
Oct 26 22:47:37 <leio-dl>	regarding the module rewrites, the situation is quite sad from our distributions point of view indeed. 2.x.0 is incresingly less usable
Oct 26 22:47:48 leio leio-dl 
Oct 26 22:47:56 <bkor>	leio-dl: gdm, or others?
Oct 26 22:48:37 <lucasr>	leio-dl, usable in the sense of stability or features or both?
Oct 26 22:49:00 <leio-dl>	gvfs (stability), then gnome-session now (features), gdm we just stay away from completely (features)
Oct 26 22:49:30 <leio-dl>	impacts shipping delays quite a bit
Oct 26 22:50:08 <bkor>	gvfs during 2.22?
Oct 26 22:50:11 <leio-dl>	I'm all for rewrites, but when they are worse for a notable amount of users, should they ship yet?
Oct 26 22:50:44 <leio-dl>	when it was first introduced, yes. Home directories getting nuked in release candidate wasn't exactly confidence boosting, etc
Oct 26 22:50:49 *	behdad (~behdad CPE001217b19226-CM0012c9c84bc4 cpe net cable rogers com) has joined #release-team
Oct 26 22:51:21 <lucasr>	leio-dl, I think it's natural to have some regressions when you rewrite complex stuff like gnome-session, gdm or gvfs
Oct 26 22:51:39 <lucasr>	leio-dl, and it's pretty hard to get things right when you don't have enough users or testers
Oct 26 22:51:49 <leio-dl>	the disrespect of things wasn't a good experience either, with half of the things using gvfs, half gnome-vfs and interfacing between apps using different things not all that peachy
Oct 26 22:52:03 <lucasr>	leio-dl, but I agree those changes (gvfs, session and gdm) had their problems
Oct 26 22:52:07 <leio-dl>	I'm all for rewrites, but we can't ship it if it looses features our users rely on
Oct 26 22:53:32 <bkor>	I agree, but not sure about the solution
Oct 26 22:53:45 <leio-dl>	mostly a problem with packages that are really at the core. If it happens to an application that doesn't interface with other things so much, we can just stay behind, in case of something like session, it's lots of testing to make sure the old one actually works fine, etc
Oct 26 22:53:50 <bkor>	some things can't be done in just 6 months, so 2.22 regarding gvfs wasn't good
Oct 26 22:54:38 <lucasr>	leio-dl, at least in the gnome-session case, there was this serious problem that the code base was so cryptic that no one was really maintaining that code
Oct 26 22:54:48 <bkor>	but I don't think it could've have been done any other way, otherwise a lot of modules wouldn't have a release in 2.22, so distro's would've ended up with a 2.20
Oct 26 22:54:52 <lucasr>	leio-dl, so, the code is stable but in a bad way :-)
Oct 26 22:54:56 <mclasen>	it is not as if session-saving was working before, application-wise...
Oct 26 22:55:53 <leio-dl>	they can't exactly start working better if the infrastructure doesn't allow it anymore. There were some prominent applications where it worked quite OK, epiphany for instance - there's no other way to keep the tabs that were there before if you don't use session saving or just blatantly killall epiphany
Oct 26 22:57:21 <leio-dl>	the biggest use case is getting what you had running when you logged out start up again, so you don't need to go and start all these things again on login - no, adding autostart entries is not a solution there - it's an intrinsic part of session handling. Now what does it do for session, just launch predefined stuff on startup?
Oct 26 22:58:05 <mclasen>	leio-dl: if you just want stuff running, how are autostart entries not sufficient ?
Oct 26 22:58:10 <leio-dl>	anyhow, we are trying to keep at 2.22 then until it's finally implemented or someone out of us somehow manages to find the time, start magically understanding the code, and implement it ourselves; not likely :(
Oct 26 22:58:38 <lucasr>	leio-dl, the problem here is that xsmp is a dead end, it's time to move on. we should definitely keep basic support for it (because there are tons of apps relying on it) but I wouldn't encourage developers to spend a long time trying to make session saving work perfectly with xsmp at this point
Oct 26 22:58:39 <leio-dl>	I want things running that were running when I logged out, not go to some extra effort in tweaking stuff in the session dialog
Oct 26 22:59:06 <bkor>	can the new gnome-session still save the session?
Oct 26 22:59:21 <bkor>	meaning: let the apps come back in the same state as before logging out?
Oct 26 22:59:25 <leio-dl>	no
Oct 26 22:59:36 <mclasen>	lucasr: there tons of xsmp-requiring apps haven't shown up here...
Oct 26 22:59:39 <bkor>	I don't mean XSMP btw, anything..
Oct 26 23:00:23 <leio-dl>	current gnome-session happily tells you this in verbose logs:
Oct 26 23:00:25 <leio-dl>	** (gnome-session-properties:27389): DEBUG: Session saving is not implemented yet
Oct 26 23:00:30 <mclasen>	leio-dl: of course, you are not meant to manually add them. Someone just needs to find the time to implement session saving
Oct 26 23:00:38 <lucasr>	mclasen, yeah, I guess in practice just a few apps implement proper xsmp-based session saving
Oct 26 23:01:06 <mclasen>	ironically, firefox grew xsmp support just as we are kicking it out...
Oct 26 23:01:19 <lucasr>	hehe
Oct 26 23:01:51 <leio-dl>	yes, and until someone does, we can't ship it and we have all kinds of potential and real module together working issues with differing versions. Anyhow, the point is to avoid such situations in the future. gnome-session already has happened
Oct 26 23:02:16 <leio-dl>	and I think this is in alignment with what lucasr was telling
Oct 26 23:02:21 <lucasr>	leio-dl, ok, message taken :-)
Oct 26 23:03:16 <leio-dl>	regarding gvfs, trying to squeeze both the library and some users in at the same cycle maybe the problem - maybe provide the supporting library for one release, and switch applications over in the next one if most aren't ready for the same or there are bugs
Oct 26 23:03:47 *	mclasen fails to see how that solves anything
Oct 26 23:03:56 <lucasr>	I really have to go
Oct 26 23:03:57 <mclasen>	no point in shipping a library if nothing uses it
Oct 26 23:04:00 <lucasr>	night all
Oct 26 23:04:04 <mclasen>	and no bugs get found that way either
Oct 26 23:04:41 <mclasen>	its not as if gvfs was conceived, written and deployed in a single cycle
Oct 26 23:05:31 *	guenther recalls some lifely discussion at GUADEC in Barcelona about gvfs
Oct 26 23:09:38 <leio-dl>	I don't have any bright ideas for a solution either, it's just unfortunate when we end up with half of the things using one framework, the other half another framework and they don't quite work together when that's necessary for a good experience. Not to mention gvfs still has feature regressions compared to gnome-vfs (hello ADS networks, fortunately uncommon for us)
Oct 26 23:11:09 <leio-dl>	anyhow, next about gtkbuilder - one potentially possible thing to do is, if glade doesn't grow gtkbuilder support on time, is to use gtkbuilder in code, but keep the glade files and run them through gtk-builder-convert at build time. Seems to work for non-complex glade files
Oct 26 23:11:33 <leio-dl>	seems to work fine for a few modules in 2.24
Oct 26 23:12:35 <bkor>	yeah, but that is nice to promote
Oct 26 23:12:46 <leio-dl>	exactly, my next note is about such conversion in general
Oct 26 23:12:48 <bkor>	also some seem to dislike glade 3
Oct 26 23:12:59 <bkor>	ehr not nice 
Oct 26 23:14:08 <leio-dl>	that it tends to be that a few people do most of the conversion work across many modules, if they get some push and motivation to do that, maybe more modules could be covered - would help for not using different frameworks as well if they get converted quickly
Oct 26 23:14:37 <leio-dl>	though they seem to be pretty motivated anyhow, just not enough hands?
Oct 26 23:14:55 <bkor>	we pushed like mad for gvfs, was just not enough people
Oct 26 23:17:08 <guenther>	The conversion tool isn't perfect yet. It fails for some features in Nautilus, for example.
Oct 26 23:17:43 <andre_>	there's always a few modules that are obviously unmaintained. i've been pinging some maintainers for month now to get a gvfs/gio patch committed
Oct 26 23:17:52 <andre_>	s/month/months
Oct 26 23:18:04 <leio-dl>	yeah, it maybe can't be used for all projects, but in case of glade/gtkbuilder there at least aren't any issues with interaction between the two being necessary if half use one and another half the other
Oct 26 23:18:36 <leio-dl>	and obviously the conversion tool could be improved
Oct 26 23:19:05 <guenther>	oh, I was just commenting on the "use the conversion tool" proposal ;)
Oct 26 23:19:26 <leio-dl>	nod, I told in my initial sentence "non-complex" glade files :)
Oct 26 23:20:55 <leio-dl>	everyone of course knows this, but I have a note here that getting evolution to use webkit instead of gtkhtml isn't necessary for getting rid of xulrunner/firefox dependencies
Oct 26 23:21:40 <guenther>	yup, everyone knows that :)
Oct 26 23:21:54 <guenther>	Hence my comments about "Evo as a bonus".
Oct 26 23:21:58 <bkor>	andre_: can we get another good dev to look at those patches? I know there aren't always perfect, so needs a review from a good person
Oct 26 23:22:25 <guenther>	It's not depending on Firefox for rendering. That would eliminate a second HTML renderer quite nicely.
Oct 26 23:22:41 <bkor>	andre_: but other than that.. if someone isn't available for months, then infrastructure work should go forward (not RFE stuff and so on)
Oct 26 23:23:45 <leio-dl>	so, good to see many of the open "issues" being discussed and I'm done with my useless meeting notes
Oct 26 23:24:12 <leio-dl>	on an unrelated note I have a request to encourage external deps to remain optional when sensible
Oct 26 23:24:37 <bkor>	such as
Oct 26 23:24:38 <bkor>	?
Oct 26 23:24:53 <leio-dl>	such as avahi for instance
Oct 26 23:24:54 <bkor>	external is not optional, that is the point
Oct 26 23:25:07 <bkor>	as soon as we approve it, it is ok
Oct 26 23:25:29 <bkor>	devs can add new deps as long as it isn't mandatory
Oct 26 23:25:32 <leio-dl>	right, and that is a slight problem for us
Oct 26 23:25:49 <bkor>	so you're saying: no new external deps
Oct 26 23:26:02 <leio-dl>	no
Oct 26 23:26:30 <bkor>	why don't you speak up during the proposals btw?
Oct 26 23:27:17 <leio-dl>	I haven't managed to get to subscribe to additional mailing lists and being able to keep up with all I already have, sorry :(
Oct 26 23:28:14 <bkor>	yeah, but that is basically the point that people can object
Oct 26 23:28:15 <leio-dl>	avahi can be a mandatory dep for some things, just for some things, where it adds an additional non-core feature, it's good to have it optional, however if it's a blessed dep it can default to enabling that feature with the external dep
Oct 26 23:28:56 <guenther>	leio-dl: Your input is much appreciated, not "useless" as you put it.
Oct 26 23:29:04 <bkor>	I don't think I understand
Oct 26 23:29:18 <bkor>	if it is required by one GNOME module, why would it be a problem for another?
Oct 26 23:29:21 <leio-dl>	my problem is maintainers now telling us "sorry, it's a blessed external dep, we won't make it optional", while in reality it's quite easy to do so
Oct 26 23:29:33 <guenther>	That's the reason why this channel is public -- and in particular the meeting.
Oct 26 23:29:37 <bkor>	because it complicates the code
Oct 26 23:29:57 <bkor>	can you give a few examples?
Oct 26 23:30:24 <leio-dl>	vinagre hard depending on it now, for example
Oct 26 23:30:44 <guenther>	err... That's the reason for being a blessed ext dep.
Oct 26 23:30:53 <guenther>	You may depend on it.
Oct 26 23:31:25 <leio-dl>	people would love to use it, but they are in their own LAN, they have their own dhcp, they don't need any zeroconf, they don't want to have avahi installed - we can accommodate where upstream allows due to our nature of the distribution
Oct 26 23:31:26 <leio-dl>	now we can't
Oct 26 23:31:29 <bkor>	but why is it a problem? avahi is used already low in the stack?
Oct 26 23:31:46 <bkor>	you mean because of people compiling?
Oct 26 23:31:59 <leio-dl>	what complicates matters is that KDE seems to use mDNSresponder, and they don't like to live together with avahi - we have dependency chains and blockers that simply can't be resolved right now
Oct 26 23:32:45 <guenther>	How does SuSE do it, for example?
Oct 26 23:33:28 <leio-dl>	because of people having the ability to choose what features are enabled, we very easily expose --enable/--disable flags to users
Oct 26 23:33:37 <mclasen>	from my perspective, 'optional' is a disease
Oct 26 23:33:51 <mclasen>	that prevents proper integration and smooth user experience
Oct 26 23:34:32 <leio-dl>	yeah, there might very well be a solution to resolve the mDNSresponder/avahi thing, been busy with other stuff till now to go into depth on this one
Oct 26 23:35:51 <leio-dl>	I disagree on the notion that it prevents proper integration and smooth user experience
Oct 26 23:36:43 <bkor>	anyway, anything is optional until it is blessed as an external dependency
Oct 26 23:37:54 <leio-dl>	there's currently two states here:
Oct 26 23:38:24 <leio-dl>	* you can optionally depends on anything, but until it's not an external dependency you may not enable that by default (as I understand it)
Oct 26 23:38:58 <leio-dl>	* you can have a mandatory depend on what is in the external dependency list
Oct 26 23:39:34 <bkor>	no, you can enable by default
Oct 26 23:39:39 <bkor>	if it is found
Oct 26 23:40:00 <bkor>	just not give an error if not found
Oct 26 23:40:08 <leio-dl>	so what I'm after is simply optional dependency encouraged, but enabled by default to get proper integration and smooth user experience out of the box, but allow disabling it by users who know what they are doing
Oct 26 23:40:09 <leio-dl>	hmm, ok..
Oct 26 23:41:03 *	leio-dl looks up where the discussion on external deps happen to monitor closer from now on
Oct 26 23:41:04 <guenther>	"autodect" for a dep is the really bad thing
Oct 26 23:41:10 <mclasen>	leio-dl: it doesn't work, in general. if something is optional, you can hardly use it as integral part of your application design
Oct 26 23:41:17 <guenther>	*unless* it is an *optional* feature
Oct 26 23:41:30 <guenther>	Autodetect for a blessed dep is just bad.
Oct 26 23:42:14 <leio-dl>	autodetect is something we must at all costs avoid in our distribution, so for any configure flags that auto-enable if stuff is found, we need to pass either --enable or --disable, often based on user overridable choice
Oct 26 23:42:52 <leio-dl>	mclasen: except in the example I'm bringing it is not an integral part of the application design. I'm quite cool for it to be used where it is, but would like to encourage keeping it optional where it isn't
Oct 26 23:43:25 <leio-dl>	the applications are useful outside a full GNOME system context as well
Oct 26 23:44:19 <bkor>	but isn't this just a compilation thing?
Oct 26 23:44:42 <leio-dl>	what do you mean under "just a compilation thing"?
Oct 26 23:44:45 <bkor>	oh.. I actually have avahi running, thought I didn't
Oct 26 23:45:27 <bkor>	people don't want/need avahi
Oct 26 23:45:37 <leio-dl>	it's correct you don't need to have the service running
Oct 26 23:45:40 <bkor>	is fine, but you don't need to have avahi running.. although atm I have it
Oct 26 23:49:49 <leio-dl>	from our users perspective the question then is - then why have it link against a set of libraries that adds up to 400KB, but I know this doesn't fly as a reason here really ;p
Oct 26 23:52:16 <mclasen>	you have very peculiar users...
Oct 26 23:53:30 <leio-dl>	and you use a distribution that simply can't support this kind of stuff due to its nature anyway
Oct 26 23:57:06 <leio-dl>	we can, and we'd like to where it's sensible. Just as an example gnome-user-share - it could be quite integral there, and the blessed external dep would help a lot there and it makes a lot more sense to have it mandatory there. Just things could be taken a bit more separately and not mean that if it's blessed everything should use it as a mandatory dep
Oct 26 23:57:40 <leio-dl>	in the vinagre example, I will simply write a patch that makes it optional again in a maintainable manner, and see what happens from there
Oct 27 01:14:14 *	behdad has quit (Ping timeout: 600 seconds)
Oct 27 01:52:24 *	leio-dl has quit (Leaving)
Oct 27 01:59:51 *	leio-dl (~leio 103 124 191 90 dyn estpak ee) has joined #release-team
Oct 27 02:13:02 *	kmaraas has quit (Ping timeout: 600 seconds)
Oct 27 03:25:00 *	guenther has quit (Leaving)
Oct 27 04:11:58 *	behdad (~behdad CPE001217b19226-CM0012c9c84bc4 cpe net cable rogers com) has joined #release-team
Oct 27 06:41:26 *	mclasen has quit (Ping timeout: 600 seconds)
Oct 27 09:30:33 *	fcrozat|gone is now known as fcrozat
Oct 27 09:44:38 *	behdad has quit (Ping timeout: 600 seconds)
Oct 27 12:41:50 *	kenvandine has quit (Remote closed the connection)
Oct 27 12:52:52 *	fcrozat is now known as fcrozat|lunch
Oct 27 13:53:34 *	fcrozat|lunch is now known as fcrozat
Oct 27 14:27:47 *	mclasen (~mclasen lan-nat-pool-bos redhat com) has joined #release-team
Oct 27 14:27:49 *	monkey|bot gives channel operator status to mclasen
Oct 27 14:33:11 *	kenvandine (~ken 66 192 95 199) has joined #release-team
Oct 27 14:54:23 *	mraudsepp (~leio artec-gw artecdesign ee) has joined #release-team