On Fri, 2007-11-30 at 11:07 -0800, Bastian, Waldo wrote: > So what should the foundation be doing to address this issue in your > opinion?
I think the foundation could setup (orchestrate) meetings (or interops or however you want to call them) with the different teams. Gather the right people and put them together from time to times. For example funding the participant's travelling expenses and making decisions about which meetings are high priority and which are low priority (and therefore wont get a budget for this). Maybe out of those face-to-face / round-table meetings could a group of maintainers step forward to discuss things on a regular basis? Whether or not we'll call that 'technical leadership' is just branding of course. Basically do what GUADEC is, but far more often and on a micro scale. With ess people who'll be a lot more focused on a specific goal: for example "improving network manager's API" or "making a better VFS API" or "in three weeks we want a Unit Test library in GLib, several app developers are using different things already, let's discuss IRL" I, for example, don't think mailing lists and IRC are always the right medium for discussion and consensus making. At least not anymore. We get much more decided during and after GUADEC. I don't think the foundation should pick up the role of technical leadership itself. I do think it should play a more active role in supporting the existing "leadership" in cooperating more closely. As Behad said, it's the maintainers themselves who know their technology best. I think that putting smart heads together usually leads to better software. > On Fri, 2007-11-30 at 11:52 -0500, Behdad Esfahbod wrote: > > > Anyway, my short answer to most of your mail is that every team / > group > > is only mandated to do whatever the actual people doing the work like > to > > do. No one knows better than me as the Pango maintainer that what > Pango > > needs most. > > And that's fine and the right way, indeed. > > Then the problem starts: integration of the different components, > decisions about how this integration will take place, helping future > customers with picking the right components, ... > > For example D-Bus APIs for desktop services > > A good example (yet it's just an example) are the differences between > Network Manager's D-Bus API and many competing network management and > detection mechanisms. > > A reason for that might be that Network Manager right now doesn't tell > me about the latency nor the cost of the (mobile) connection. With some > discussion at the level of GNOME Mobile, it would probably have come to > the surface that things like these are needed for mobiles. > > Multiple platform providers are each using their own API for the purpose > of this. Access has something, Maemo has Conic, the desktop has Network > Manager. This is 'not' good and more complicated for app. developers. > > I know most people will now think: "yes but THEY should have ...." (fill > in the dots). The reality is different. And sometimes it's good to also > open your eyes for the actual situation. > > > I can make a very long list of examples (and I can point to code, if > necessary). I already promised not to make such long philosophic E-mails > anymore. > > -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ foundation-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/foundation-list
