Re: Getting to Topaz (Was Re: getting on a longer release cycled)
On 9/11/06, Havoc Pennington [EMAIL PROTECTED] wrote: Maxim Udushlivy wrote: I remember somebody compared Gnome with a car. But the desktop is an environment, so it is not a car, it is a parking. The same goes about a hammer: desktop environment is a collection of tools. Different tasks require different collections. The items that you mentioned may fit very well into one desktop ideology (e.g. simplicity) as several profiles. It is possible to make a parallel with Eclipse IDE which has profiles (they call them perspectives). There are profiles for Java source code editing, SVN browsing, debugging, etc. Every profile has its own layout and a set of opened sub-windows (hammers). All profiles are Eclipse-style. Desktops have so-called workspaces (never used them), may be they could be extended into task-oriented profiles?! [SNIP lots of about GNOME:s focus] Still, the broadest, most general-purpose description of IBM Workplace is still tightly focused on corporate office workers with IT staff (GNOME has not narrowed down to that) and the broadest, most general-purpose description of the Eclipse IDE is that it's for developers (GNOME has not narrowed down to that either). I think you are 100% right and that it is important for GNOME to narrow its focus. For example, if GNOME limited its focus to computers with 256 MB of RAM, then there wouldn't need to be huge debates of the advantages and disadvantages of Mono. It would be a no-brainer to include it because with that much memory, a virtual machine hurts no one. On the other hand, if it was decided that GNOME targets computers with less than 64 MB of RAM, then it would be a no-brainer to exclude it (along with Python and all other memory hungry stuff). IMHO, it would be better for GNOME to target the high-end machines because the low-end market is already occupied by XFCE. And it is not just the memory requirements for GNOME that needs to be decided. I agree that choosing a specific target niche would be very useful. Problem is, how are you going to do it? GNOME doesn't have a BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the target niche is? Many of the most successful free software projects (Linux and Python for example) have a BFDL, that person has a clear vision about how they want their product to be. Everyone else has just to accept that vision or leave the project. GNOME is different in that regard, different developers have different visions and when they clash, big debates erupt on this mailing list. Debates that really doesn't solve the problems and doesn't find a common ground... It appears to me that GNOME is in many ways in a similar situation as Debian/Ubuntu (see: http://www.markshuttleworth.com/archives/56 and http://mjg59.livejournal.com/66647.html). GNOME itself isn't very focused but has provided others with components on which they can build a more coherent system (http://www.novell.com/products/desktop/). I wonder if that clearly superior Novell-Windows Start menu look-a-like will ever be included in GNOME? -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
BJörn Lindqvist wrote: I think you are 100% right and that it is important for GNOME to narrow its focus. For example, if GNOME limited its focus to computers with 256 MB of RAM, then... I was proposing to narrow Gnome by ideology (implementation style), Havok - by desktop tasks (implementation scope), you - by hardware requirements (implementation details). What is more viable? And it is not just the memory requirements for GNOME that needs to be decided. I agree that choosing a specific target niche would be very useful. Problem is, how are you going to do it? GNOME doesn't have a BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the target niche is? Many of the most successful free software projects (Linux and Python for example) have a BFDL, that person has a clear vision about how they want their product to be. Everyone else has just to accept that vision or leave the project. GNOME is different in that regard, different developers have different visions and when they clash, big debates erupt on this mailing list. Debates that really doesn't solve the problems and doesn't find a common ground... There is an interesting observation on how laws are being developed in the USA: they are formulations of common practices. I.e. those laws do not try to change behavior of people, instead they enforce something that already exists and works. That's why I propose with a pure conscience a position of Gnome Moderator (who is not a Dictator but an anti-crisis manager). It is very common for an on-line community to have a moderator. With a moderator endless debates would be impossible since there will be a man to whom you could prove that your practices (of vision of practices of others) are efficient and deserves to become a law. Currently people just express their opinions without any effect - a boiling water inside a teapot that could otherwise become a steam engine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
So clearly we need to choose a number relatively prime to 12 if this is desirable. With 9 months there's only 4 possible months for release. If you did, say, 7 months, then you'd never repeat a month until you'd hit 'em all :-) -Rob On Fri, 2006-09-08 at 10:43 -0400, Pat Suwalski wrote: Elijah Newren wrote: I used to be firmly in favor of the 6-month cycle, but I found Andrew's argument quite convincing and it has turned me into more of a fence sitter for now. It isn't yet clear to me that a change would be a definite improvement, let alone enough of a benefit to merit the change in the process, but that may well change. I think this is why an alternating 6 and 12 month cycle would be nice. A 9 month cycle would be even more interesting, because the dates would not always fall at the same times. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Maxim Udushlivy wrote: BJörn Lindqvist wrote: I think you are 100% right and that it is important for GNOME to narrow its focus. For example, if GNOME limited its focus to computers with 256 MB of RAM, then... I was proposing to narrow Gnome by ideology (implementation style), Havok - by desktop tasks (implementation scope), you - by hardware requirements (implementation details). What is more viable? Additional point: - narrowing by scope tells people *what* things to do: the freedom is sacrificed (impossible for Gnome?) - narrowing by style tells people *how* to do things: people are educated (if the style is good) And it is not just the memory requirements for GNOME that needs to be decided. I agree that choosing a specific target niche would be very useful. Problem is, how are you going to do it? GNOME doesn't have a BFDL (http://en.wikipedia.org/wiki/BFDL) so WHO would decide what the target niche is? Many of the most successful free software projects (Linux and Python for example) have a BFDL, that person has a clear vision about how they want their product to be. Everyone else has just to accept that vision or leave the project. GNOME is different in that regard, different developers have different visions and when they clash, big debates erupt on this mailing list. Debates that really doesn't solve the problems and doesn't find a common ground... There is an interesting observation on how laws are being developed in the USA: they are formulations of common practices. I.e. those laws do not try to change behavior of people, instead they enforce something that already exists and works. That's why I propose with a pure conscience a position of Gnome Moderator (who is not a Dictator but an anti-crisis manager). It is very common for an on-line community to have a moderator. With a moderator endless debates would be impossible since there will be a man to whom you could prove that your practices (of vision of practices of others) Typo: ...(*or* vision of practices of others)... are efficient and deserves to become a law. Currently people just express their opinions without any effect - a boiling water inside a teapot that could otherwise become a steam engine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
On 9/11/06, Maxim Udushlivy [EMAIL PROTECTED] wrote: I was once lurking around planet.gnome.org and there was an interesting accident. One guy said about Israel that it is evil and another (Jeff Waugh?) was trying to moderate him. I blogged about the Israel issue and Jeff did not try to moderate me. He blogged saying maybe I went too far in my blog entry, though he blogged after my apology blog entry. Jeff, as far as I can tell, does not want to moderate Planet Gnome as Planet GNOME is a window into the world, work and lives of GNOME hackers and contributors. Zaheer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Gnome Sheriff must be elected by some formal procedure (better by democratic voting). His main responsibility - moderate mailing lists from bullshit, destroy crazy ideas before they infect people, protect project ideology, etc. A democracy arises because allowing everyone a say in running the country is not feasible. We already have structures where everybody can voice opinion, and if you think you can do something better you are free to patch/fork anyone elses code (as a programming domain example). Lets not limit ourselves to the non-digital world for the sake of an organisation diagram. Ed Mack ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
On 9/12/06, Ed Mack [EMAIL PROTECTED] wrote: A democracy arises because allowing everyone a say in running the country is not feasible. We already have structures where everybody can voice opinion, and if you think you can do something better you are free to patch/fork anyone elses code (as a programming domain example). Technically, a democracy is everyone having a say in running the country, you're thinking of a republic. I do agree that we don't need a Sheriff or any such thing. People need to stop asking for permission to do things and just start doing them. If someone doesn't like the work you're doing they then have to a) help you fix it, b) make something that works better, or c) live with it. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Shaun McCance wrote: On Tue, 2006-09-12 at 00:33 +0400, Maxim Udushlivy wrote: Havoc Pennington wrote: I think the best shot at this would be to gather a small group that agrees on some audience they want to try and do stuff for, and just start doing it; I'm not sure how the overall GNOME boat can be turned up front, it's probably not possible. The small group would have to be prepared for potentially large divergence from the existing gnome-panel/nautilus/etc. desktop codebase - they would need to be open to doing very different things either instead or in addition, if that made sense to provide the benefits to the audience. ...gather a small group - this reminds the infamous lack-of-leadership Gnome problem (at least from the outsider perspective) I was once lurking around planet.gnome.org and there was an interesting accident. One guy said about Israel that it is evil and another (Jeff Waugh?) was trying to moderate him. I'm going off-topic for the list, but I don't want any misinformation to spread. I don't remember who it was that wanted political opinion silenced on the planet, but it absolutely was not Jeff. The whole idea of the blog aggregator (and it was pretty much all his idea) is to let people see the personal lives of the people who make Gnome work. -- Shaun May be was trying sounds a bit negative, but I completely support Jeff reply regardless of who asked him to do that. Many people read planet.gnome; it's a public place, not a private home page. There is a good saying: where the freedom of another person starts, mine ends. Political propaganda limits freedom of the mind (there is a choice to completely ignore planet.gnome of course). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Zaheer Merali wrote: On 9/11/06, Maxim Udushlivy [EMAIL PROTECTED] wrote: I was once lurking around planet.gnome.org and there was an interesting accident. One guy said about Israel that it is evil and another (Jeff Waugh?) was trying to moderate him. I blogged about the Israel issue and Jeff did not try to moderate me. He blogged saying maybe I went too far in my blog entry, though he blogged after my apology blog entry. Jeff, as far as I can tell, does not want to moderate Planet Gnome as Planet GNOME is a window into the world, work and lives of GNOME hackers and contributors. Zaheer Zaheer, I do not think that you said something horrible and unbearable. I used that event as an example of possible useful moderation that could be done on the project level in other areas. Whether to moderate planet.gnome or not is not my business, although I think since it is a public place there should be a couple of obvious rules. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Ed Mack wrote: Gnome Sheriff must be elected by some formal procedure (better by democratic voting). His main responsibility - moderate mailing lists from bullshit, destroy crazy ideas before they infect people, protect project ideology, etc. A democracy arises because allowing everyone a say in running the country is not feasible. We already have structures where everybody can voice opinion, and if you think you can do something better you are free to patch/fork anyone elses code (as a programming domain example). There are opinions that those structures do not influence much. I do not think I can do better, I just see that Gnome appears to be lost a bit and I was trying to suggest a new position that may fix a leadership problem, a Gnome Moderator (or Sheriff if you are not against humor). It seems to me that Jeff Waugh is doing something similar to moderation - then why not to create an official position, give more rights (as well as responsibilities) to it and elect a man for a period? Lets not limit ourselves to the non-digital world for the sake of an organisation diagram. Developers are not digital. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Travis Watkins wrote: On 9/12/06, Ed Mack [EMAIL PROTECTED] wrote: A democracy arises because allowing everyone a say in running the country is not feasible. We already have structures where everybody can voice opinion, and if you think you can do something better you are free to patch/fork anyone elses code (as a programming domain example). Technically, a democracy is everyone having a say in running the country, you're thinking of a republic. I do agree that we don't need a Sheriff or any such thing. People need to stop asking for permission to do things and just start doing them. If someone doesn't like the work you're doing they then have to a) help you fix it, b) make something that works better, or c) live with it. Ahem... Afraid of a sheriff? Why? (-; There is no freedom without rules. Without rules there is anarchy, chaos, nonexistence. Our visible universe is built around strict physical laws, such as gravity. Only due to those laws we could enjoy freedom: to walk, to run, to speak, to drink, to kiss (and not only to kiss!), to eat, to read, etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Hi, Travis Reitter wrote: 1. Pick a short list of major concepts to put into Topaz. We don't need perfect consensus at this stage, but it'd be nice to start forming some agreement. Concepts (superfeatures across the platform/desktop) would be along the lines of People as a first-class object, Integrating Web apps and desktop apps, User tasks instead of individual apps, Pervasive integration of Creative-Commons artwork, music, etc., and so on. The concepts thing is just not really right. It's architecture astronaut stuff. If you want to redefine GNOME it should look like a benefit to an audience. Something like: - provide the best way to use the web for today's teenagers or - get seniors who find Windows overwhelming in touch with their families or (more realistically) - provide the best environment for software developers to work in or - provide the ideal console for UNIX-like server operating systems or - provide a functional equivalent to Windows for schools and non-US governments that see the democratic value in open source Or whatever. But it's about people and things you might offer them they don't already have. Unfortunately a lot of people have the IMNSHO insane theory that the above sort of stuff is too specific for something general purpose which is sort of like saying a hammer is too specific so our product should be a tool. 2. Have everyone create mock-ups and prototypes of their ideas for these concepts. This is a great idea, though. And in fact I think you'll find it leads you away from the architecture concepts mode of thinking and toward something more real. It also tends to show that you can't prototype a tool but you can prototype a hammer. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Hi! On Mon, 2006-09-11 at 02:02 -0400, Havoc Pennington wrote: Hi, Travis Reitter wrote: 1. Pick a short list of major concepts to put into Topaz. We don't need perfect consensus at this stage, but it'd be nice to start forming some agreement. Concepts (superfeatures across the platform/desktop) would be along the lines of People as a first-class object, Integrating Web apps and desktop apps, User tasks instead of individual apps, Pervasive integration of Creative-Commons artwork, music, etc., and so on. The concepts thing is just not really right. It's architecture astronaut stuff. If you want to redefine GNOME it should look like a benefit to an audience. Something like: - provide the best way to use the web for today's teenagers or - get seniors who find Windows overwhelming in touch with their families or (more realistically) - provide the best environment for software developers to work in or - provide the ideal console for UNIX-like server operating systems or - provide a functional equivalent to Windows for schools and non-US governments that see the democratic value in open source Or whatever. But it's about people and things you might offer them they don't already have. That's a really good point. I'm new to development on large, real-world projects, so if any of my ideas sound naive, don't be too shocked. :) So, adjusting 1. to Unique, focused, user-centric benefits (instead of the too-vague concepts/major features that sound cool), how do you (and everyone else) think the plan sounds now? Unfortunately a lot of people have the IMNSHO insane theory that the above sort of stuff is too specific for something general purpose which is sort of like saying a hammer is too specific so our product should be a tool. The Big Question, then, is whether Gnome could support many significantly different user profiles (like all the ones listed above, and many others) _really well_, and not just wandering into the mediocre middle. Is it possible? 2. Have everyone create mock-ups and prototypes of their ideas for these concepts. This is a great idea, though. And in fact I think you'll find it leads you away from the architecture concepts mode of thinking and toward something more real. It also tends to show that you can't prototype a tool but you can prototype a hammer. Thanks. My main goal with this approach is to hopefully (with enough people involved) encourage some rapid prototyping of flexible solutions to fairly far-reaching goals, without anyone getting too heavy-handed at the beginning. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Maxim Udushlivy wrote: I remember somebody compared Gnome with a car. But the desktop is an environment, so it is not a car, it is a parking. The same goes about a hammer: desktop environment is a collection of tools. Different tasks require different collections. The items that you mentioned may fit very well into one desktop ideology (e.g. simplicity) as several profiles. It is possible to make a parallel with Eclipse IDE which has profiles (they call them perspectives). There are profiles for Java source code editing, SVN browsing, debugging, etc. Every profile has its own layout and a set of opened sub-windows (hammers). All profiles are Eclipse-style. Desktops have so-called workspaces (never used them), may be they could be extended into task-oriented profiles?! The Eclipse platform is a great example really, let's contrast it with GNOME. First, there's an Eclipse rich client platform which is roughly on the level of gtk/dbus/gconf/gnome-vfs type stuff, i.e. it's libraries. On top of that there are at least two large projects. One is the Eclipse IDE, which is already narrowed in scope to software developers; it can make some UI decisions intended for that audience in a global way. Inside the Eclipse IDE, there are task or audience oriented perspectives and plugins for different kinds of software developers. Another large project is IBM Workplace, which is (in some sense) a desktop. However, it's a desktop very specifically for corporate office workers. And IBM does not leave it at that, they tune the desktop for very specific vertical markets. So here's an example that Google turned up (everyone will have to look past all the corporate buzzword speak): http://publib.boulder.ibm.com/tividd/software/saleskits/H219009P42370K84/KEY_36.html click on tech specs on the right, and look at slide 2 in the powerpoint deck. Slide 1 is the title slide. So the first slide with content is labeled value proposition and that slide has a table. The first two rows in the table are: For: Chief Operating Officer, Chief Information Officer, Procurement Team Who needs: Enhanced collaboration across the organization and with OEMs, Streamlined service and parts operations, and more efficient buying and procurement processes Made clear just before that in the slide is that this is specifically for the automotive industry. Now, I don't think this is the _best_ example: - it's all a bit too market segment instead of ethnography/persona - the Eclipse UI does feel a little clunky imo, like it's wedging everything into a Grand Unified Platform whether it wants to fit or not Still, the broadest, most general-purpose description of IBM Workplace is still tightly focused on corporate office workers with IT staff (GNOME has not narrowed down to that) and the broadest, most general-purpose description of the Eclipse IDE is that it's for developers (GNOME has not narrowed down to that either). Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Havoc Pennington wrote: Maxim Udushlivy wrote: I remember somebody compared Gnome with a car. But the desktop is an environment, so it is not a car, it is a parking. The same goes about a hammer: desktop environment is a collection of tools. Different tasks require different collections. The items that you mentioned may fit very well into one desktop ideology (e.g. simplicity) as several profiles. It is possible to make a parallel with Eclipse IDE which has profiles (they call them perspectives). There are profiles for Java source code editing, SVN browsing, debugging, etc. Every profile has its own layout and a set of opened sub-windows (hammers). All profiles are Eclipse-style. Desktops have so-called workspaces (never used them), may be they could be extended into task-oriented profiles?! The Eclipse platform is a great example really, let's contrast it with GNOME. First, there's an Eclipse rich client platform which is roughly on the level of gtk/dbus/gconf/gnome-vfs type stuff, i.e. it's libraries. On top of that there are at least two large projects. One is the Eclipse IDE, which is already narrowed in scope to software developers; it can make some UI decisions intended for that audience in a global way. Inside the Eclipse IDE, there are task or audience oriented perspectives and plugins for different kinds of software developers. Another large project is IBM Workplace, which is (in some sense) a desktop. However, it's a desktop very specifically for corporate office workers. And IBM does not leave it at that, they tune the desktop for very specific vertical markets. So here's an example that Google turned up (everyone will have to look past all the corporate buzzword speak): http://publib.boulder.ibm.com/tividd/software/saleskits/H219009P42370K84/KEY_36.html click on tech specs on the right, and look at slide 2 in the powerpoint deck. Slide 1 is the title slide. So the first slide with content is labeled value proposition and that slide has a table. The first two rows in the table are: For: Chief Operating Officer, Chief Information Officer, Procurement Team Who needs: Enhanced collaboration across the organization and with OEMs, Streamlined service and parts operations, and more efficient buying and procurement processes Made clear just before that in the slide is that this is specifically for the automotive industry. Now, I don't think this is the _best_ example: - it's all a bit too market segment instead of ethnography/persona - the Eclipse UI does feel a little clunky imo, like it's wedging everything into a Grand Unified Platform whether it wants to fit or not Still, the broadest, most general-purpose description of IBM Workplace is still tightly focused on corporate office workers with IT staff (GNOME has not narrowed down to that) and the broadest, most general-purpose description of the Eclipse IDE is that it's for developers (GNOME has not narrowed down to that either). Havoc I used Eclipse IDE just as an example of perspective (profile) switching. Like Eclipse, Gnome may have different perspectives: one for developers, another for internet browsing and email, third for office-related tasks, etc. These perspectives form *one* desktop by means of several workspaces, one workspace for each perspective. I wanted to say that there is no need to narrow Gnome to only one audience/task/perspective. Of course Gnome must target certain category of users, but that should not be done by limiting the whole Gnome to a some subset of all possible desktop tasks. Desktop is a general-purpose environment and Gnome should find its users by promoting certain ideology (for example UI simplicity, extended functionality and minimal configuration effort). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
Travis: One thing I'd like to remind people is that typically when a product bumps the major version number, this involves some evolution in the underlying interfaces. I know some of these sorts of issues are being addressed by Project Ridley (e.g. GtkPrint), but it would probably be good to consider how we want our Desktop interface stability story to look after Topaz. Some suggestions... 1) How could we better navigate people who want to integrate with the desktop towards interfaces that the GNOME community recommends? Are all GNOME Platform interfaces recommended or just a subset? Are some interfaces recommended over others? 2) Should additional interfaces be included in the Platform that are not already? Should libcairo or GStreamer be made part of the Platform? Are there others that would make sense to support in a more Stable fashion? 3) Are all interfaces exposed in the latest GNOME Sysadmin Guide supported in a stable fashion, for example (such as /usr/share/gnome/default.session)? 3) What further items in Project Ridley should be done before Topaz? Should libgnome, libgnomeui, libgnomecanvas be deprecated? Should GNOME after Topaz have a different Platform that doesn't include deprecated libraries? Should we deprecated esound in favor of GStreamer? I noticed libgnomeprintui was deprecated, should libgnomeprint be deprecated also (or has it been already and I didn't notice?) 4) How does the GNOME community want FreeDesktop interfaces to be exposed? It seems the Portland project is controversial. Do we recommend users use Portland interfaces or other interfaces to integrate with /usr/share/applications, the MIME database, icon integration, etc. This doesn't seem clear to me. Also libcairo is a FreeDesktop library interface, and it isn't really clear how this will be managed. Since it is not a part of the platform, I assume an ABI incompatible libcairo-2.0 could come out and a new version of GTK+ could use it (as long as those libcairo interfaces exposed in GTK+ didn't break). Might be nice if we clarified how we anticipate stability will be managed with FreeDesktop library interfaces like libcairo. Should end-users consider using libcairo in a Stable fashion or no? Also could consider the same sort of questions about d-bus. Should libart_gpl be deprecated in favor of libcairo? 5) How could we better manage the file-system footprint. I notice over 3/4 of the directories in /usr/share are installed by GNOME. Could the clutter be better organized? It would probably be a good thing if we thought about questions like these so that we would have a better desktop integration story to coincide with whatever functionality/usabiity improvements we intend to deliver with Topaz. Just my 2 cents... Brian This kicked off a few ideas for me: Topaz basically seems to be so massive a change that some extremely enthusiastic people are flinging high-level concepts at the wiki (without developing them - I'm responsible for one of these [which I've since removed]), while others (who seem to tend to be more experienced developers) are so caught up on feasibility concerns that they're just focusing on short-term, tangible goals. So I think the big blocker is that those who are experienced enough to dive in realize how complex a re-design would be, and just give up on it. We need to make Topaz development less scary. Here's my plan: 1. Pick a short list of major concepts to put into Topaz. We don't need perfect consensus at this stage, but it'd be nice to start forming some agreement. Concepts (superfeatures across the platform/desktop) would be along the lines of People as a first-class object, Integrating Web apps and desktop apps, User tasks instead of individual apps, Pervasive integration of Creative-Commons artwork, music, etc., and so on. It's important that these be global concepts, and not just An app to do 'X' or necessarily A library that does 'Y' - I think our current development process already handles these cases fairly well. Topaz should be about superfeatures that require concerted, simultaneous effort from many different projects (which is what we currently _don't_ do well). 2. Have everyone create mock-ups and prototypes of their ideas for these concepts. Overlap should be encouraged (ie, multiple meta-implementations of one concept, multiple meta-implementations of each concept for each project). 3. Use a process similar to the proposals for inclusion to select a short list of these major concepts and meta-implementations to focus on for Topaz's first development cycle. These concepts and meta-implementations would be chosen based on their feasibility and perceived usefulness. 4. Start implementing. It seems like the development cycle(s) could work in one of two ways: A. Gradually; Select a few
Re: Getting to Topaz (Was Re: getting on a longer release cycled)
On Tue, 2006-09-12 at 00:33 +0400, Maxim Udushlivy wrote: Havoc Pennington wrote: I think the best shot at this would be to gather a small group that agrees on some audience they want to try and do stuff for, and just start doing it; I'm not sure how the overall GNOME boat can be turned up front, it's probably not possible. The small group would have to be prepared for potentially large divergence from the existing gnome-panel/nautilus/etc. desktop codebase - they would need to be open to doing very different things either instead or in addition, if that made sense to provide the benefits to the audience. ...gather a small group - this reminds the infamous lack-of-leadership Gnome problem (at least from the outsider perspective) I was once lurking around planet.gnome.org and there was an interesting accident. One guy said about Israel that it is evil and another (Jeff Waugh?) was trying to moderate him. I'm going off-topic for the list, but I don't want any misinformation to spread. I don't remember who it was that wanted political opinion silenced on the planet, but it absolutely was not Jeff. The whole idea of the blog aggregator (and it was pretty much all his idea) is to let people see the personal lives of the people who make Gnome work. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Getting to Topaz (Was Re: getting on a longer release cycled)
This kicked off a few ideas for me: Topaz basically seems to be so massive a change that some extremely enthusiastic people are flinging high-level concepts at the wiki (without developing them - I'm responsible for one of these [which I've since removed]), while others (who seem to tend to be more experienced developers) are so caught up on feasibility concerns that they're just focusing on short-term, tangible goals. So I think the big blocker is that those who are experienced enough to dive in realize how complex a re-design would be, and just give up on it. We need to make Topaz development less scary. Here's my plan: 1. Pick a short list of major concepts to put into Topaz. We don't need perfect consensus at this stage, but it'd be nice to start forming some agreement. Concepts (superfeatures across the platform/desktop) would be along the lines of People as a first-class object, Integrating Web apps and desktop apps, User tasks instead of individual apps, Pervasive integration of Creative-Commons artwork, music, etc., and so on. It's important that these be global concepts, and not just An app to do 'X' or necessarily A library that does 'Y' - I think our current development process already handles these cases fairly well. Topaz should be about superfeatures that require concerted, simultaneous effort from many different projects (which is what we currently _don't_ do well). 2. Have everyone create mock-ups and prototypes of their ideas for these concepts. Overlap should be encouraged (ie, multiple meta-implementations of one concept, multiple meta-implementations of each concept for each project). 3. Use a process similar to the proposals for inclusion to select a short list of these major concepts and meta-implementations to focus on for Topaz's first development cycle. These concepts and meta-implementations would be chosen based on their feasibility and perceived usefulness. 4. Start implementing. It seems like the development cycle(s) could work in one of two ways: A. Gradually; Select a few concepts to integrate _well_ in each 6-month cycle. Develop in our current lineage, without a parallel branch. Phase Topaz in without causing significant breakage and panic. B. In Parallel; Branch for Topaz, and mainly focus on implementing the short list of concepts in one go (possibly a 12-month initial cycle, then back to 6 month cycles after that). Continue 2.x releases every 6 months in parallel, though only working on bug fixes, documentation, etc. Basically like the current releases, but with slightly fewer features (and hopefully much less developer involvement necessary). The whole point of this plan is to move forward without getting ahead of ourselves and rigidly defining ourselves into a corner. What does everyone else think? -Travis On Thu, 2006-09-07 at 23:55 +0100, Jono Bacon wrote: Hi all, I think the focus in this thread is a little imbalanced. I think we really, really need to focus on actually decided on what Topaz is going to be. I feel that the lack of direction in the project to say this is what will be in Topaz is actually starting to harm us - it is making us look like we can't make decisions. Much of the problem is that huge infrastructure changes cannot be easily hacked on by a single person to gain enough momentum to become Topaz. Sure, I have my idea of how Topaz should work, and I have blogged about how the GNOME desktop should be contextual to a project, and I also fleshed out ideas of interface with MacSlow at GUADEC. But, I think need to sit down, and make hard decisions about what is happening with Topaz. There are distinctive connections and threads of similarity between what people seem to want to achieve, and this seems to large fall into the domain of people as top-level objects and such. But, I think we need to get a core bunch of us together to sit down, thrash out some ideas and actually start scoping out what GNOME 3.0 should look like. I have a huge interest in usability, and Jokosher is a product of an application domain re-thought around usability - I think we need to decide on this before we start a flamewar about release scheduling. Jono ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 13:56 -0400, Pat Suwalski wrote: Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. I think 12 months is too much time. And if we need to do a major release, we can, for instance, branch now for gnome-2-18, do there only minor bugfixes and small feature additions for the upcoming 2-20 and, at the same time, dedicate the 12 months (2-18 + 2-20) to work on HEAD for the major release. That is, there is nothing in the schedule preventing us from working on a major release for 1/1.5 years while at the same time keeping up with the 6-month release cycle. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
2006/9/8, Rodrigo Moya [EMAIL PROTECTED]: On Thu, 2006-09-07 at 19:51 +0100, Jamie McCracken wrote: Hubert Figuiere wrote: Hi, I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. There have been a large pimping of project Topaz, and I strongly believe that this is the kind of goal that would need a longer development cycle for a big leap forward towards world domination. Why not thinking for after 2.18 starting on a 12 to 18 month release cycle. We must have a FIRM date (eventually flexible), but more importantly a FIRM features goal (eventually adapted to not become a Death March). What do people think? I think its worth experimenting with a longer release cycle but I would start at 9 months and see if that improves things before considering a 12 month or 18 month cycle. I dont know how topaz will transpire but I feel it should be written in a native high level language like D or Vala as its likely to be a rewrite of much of the existing code and could be doable in 9 months with a more productive language. if we rewrite much of the existing code, I think we would need much more than 9 months :-) And if anyone is serious about rewriting said amounts of code in high level languages, I would imagine they are welcome to do so outside the release cycle. In fact, (in my personal opinion) any rewrite has no businnes to be in ANY release until it a) exists as a drop-in replacement (where possible) b) has been moderately tested and approved by the active community c) doesn't mean that half of the now-working stuff suddenly won't work As always, there is little point on carrying on lengthy conversations about fabled rewrites of this and that to the [insert favour here] language. Just go and write it, let's see how it'll work out! -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Le jeudi 07 septembre 2006, à 19:32, Don Scorgie a écrit : Hi, On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? For one thing: the documentation gets squeezed. We (the doc team) have, basically, 3 month to document all the changes, update all the docs and add any new documentation needed. The doc team is currently running at skeleton staff and is working right up until the tarball submission deadline. This knocks on and means that the doc translations (if present) are invariably a release behind. I don't get this. If we move to a longer release cycle, then it will be longer to add more features/changes. And you'll still have 3 months to document even more changes... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi Andrew, Quoting Andrew Cowie [EMAIL PROTECTED]: We regularly have people showing up who are asking us questions about gtk 2.6 and using a version that is *FOUR* cycles old. We can't support that as we've long since moved on from there (shit, the people who wrote that code aren't even involved anymore), with the result that ISV developers are left out in the cold, and there's no momentum or support for new developers. Let me see if I can play out this scenario with (say) a 9 month cycle. GNOME 2.2X comes out January 2008. It hits the first distros March 2008, and you get it installed around May. So then you update your bindings to GNOME 2.2X, which are done for GNOME 2.2(X+1), which releases in October 2008. And application developers get that installed sometime around March the year after, when it's released in their distros. So, following your logic, ISDs will be building on GNOME 2.2X APIs in this scheme 18 months after they're done. Isn't this just the same situation again? Cheers, Dave. -- Dave Neary Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Fri, 2006-09-08 at 14:44 +1000, Andrew Cowie wrote: The people I work with on java-gnome won't be able to hack on GNOME 2.16 specific bindings until we have GNOME 2.16 desktops on our systems. My systems are otherwise production (in the sense that I use them to do business so I can't afford to have them hideously broken With jhbuild or similar, there's no need to install experimental stuff system-wide. Just a create a development sandbox and use it to write the bindings. -- Bye, -Torsten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 12:59 -0400, Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. Not sure whether the situations are similar, but I don't think this went well for Ubuntu. In hind sight, I don't believe there was much of a benefit of stretching the dapper release cycle by 6 weeks. We got 6 more weeks of bug fixing, sure, but we also got 6 more weeks of bug development. The fact is that whatever your release cycle length, things always fall in the same places. What would work better would be if features were actively developed for the 2.20 release at the same time as things were being developed for the 2.18 release, so that the release schedule remains the same but the development focus can be different. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Fri, 2006-09-08 at 10:17 +0200, Rodrigo Moya wrote: On Thu, 2006-09-07 at 13:56 -0400, Pat Suwalski wrote: Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. I think 12 months is too much time. And if we need to do a major release, we can, for instance, branch now for gnome-2-18, do there only minor bugfixes and small feature additions for the upcoming 2-20 and, at the same time, dedicate the 12 months (2-18 + 2-20) to work on HEAD for the major release. That is, there is nothing in the schedule preventing us from working on a major release for 1/1.5 years while at the same time keeping up with the 6-month release cycle. This is pretty much always given as the reason why longer cycles aren't needed. And what it completely fails to address is the issue of non-programmer contributors. As a programmer, I can absolutely get myself ten straight months of unbridled hacking time by skipping a release. In fact, I've done it once before with Yelp. But the documentation team still only gets six weeks. Not only that, they now have six weeks to document everything you were able to change in ten months. Programmers are the only people who can take advantage of this. Nobody else can. The documentation team can't just sit out a release cycle and force the programmers to keep their modules static while we do so. We need more expert reviews (accessibility, user interface, strings), more testing, and more documentation work. That means more time. And if we ever hope to have translated documentation, the documentation team needs to finish even earlier, so the translators have a chance. The documentation team can't conceivable consider anything finished until after the UI and string freezes. In 2.16, that gave us four weeks. Now let's try to finish two weeks early to give translators a sporting chance. That gives us two weeks. Two weeks to document whatever programmers can manage to do in four to five months. That's insane. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
What in particular isn't possible with the 6-month cycle? -David On 9/7/06, Pat Suwalski [EMAIL PROTECTED] wrote: Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi, On Thu, 2006-09-07 at 12:59 -0400, Hubert Figuiere wrote: There have been a large pimping of project Topaz, and I strongly believe that this is the kind of goal that would need a longer development cycle for a big leap forward towards world domination. The counterargument here is always that this development can and should go on, but should be done on a branch and merged in when it's considered ready. This was the idea behind libegg too: once code there was considered ready it would move into GTK+ or some other more stable library. It's worked quite successfully for new software developed entirely outside of GNOME (deskbar and tomboy being two recent examples). I'd agree that our release methodology is geared more toward releasing in stages leading up to a stable release and that we don't have a good way to release preview software that might be going on in a branch, but we also have a problem that we don't get probably enough testing on our actual unstable branches leading up to a release either. We've got a good thing going with our six month release cycle. Not all the interesting work we do on our existing code has to happen within these cycles, though. Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? Nothing's impossible, but a longer cycle every so often would encourage larger and better thought-out changes. I always get the feeling that GNOME contributors hold back on a lot of excellent ideas because they feel it will take longer to implement properly and test than the time they have before the next release. In a 12-month cycle, 9 months could be dedicated to development, 3 months to documentation and testing. What an amazing amount of time that would be to get things right. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hubert Figuiere wrote: Hi, I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. There have been a large pimping of project Topaz, and I strongly believe that this is the kind of goal that would need a longer development cycle for a big leap forward towards world domination. Why not thinking for after 2.18 starting on a 12 to 18 month release cycle. We must have a FIRM date (eventually flexible), but more importantly a FIRM features goal (eventually adapted to not become a Death March). What do people think? I think its worth experimenting with a longer release cycle but I would start at 9 months and see if that improves things before considering a 12 month or 18 month cycle. I dont know how topaz will transpire but I feel it should be written in a native high level language like D or Vala as its likely to be a rewrite of much of the existing code and could be doable in 9 months with a more productive language. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi, On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? For one thing: the documentation gets squeezed. We (the doc team) have, basically, 3 month to document all the changes, update all the docs and add any new documentation needed. The doc team is currently running at skeleton staff and is working right up until the tarball submission deadline. This knocks on and means that the doc translations (if present) are invariably a release behind. Don /me now waits to see if shaunm will release his top-secret plan for world domination... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
tor, 07 09 2006 kl. 11:24 -0700, skrev David Trowbridge: What in particular isn't possible with the 6-month cycle? I honestly don't think it's about the cycle length as much as the slight fear we seem to have of setting major goals for the project. I doubt we can do Topaz within the comfort of our tried and true 6 month cycle and we do need to decide what Topaz is going to be at some point. As the honorable Jono Bacon put it, he would hate to go to GUADEC 2007 and have Topaz still be something we talked about rather than actually worked on. This is likely to require someone to take the probably unappricated position of Topaz direction manager (or Topaz dictator, asbestosuit included). Basically I think Hub has the right idea but the wrong approach. We need to start thinking about what we want and if that requires us to extend the cycle, do things in parallel or whichever solution we need then we absolutely need to do it. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On 9/7/06, Pat Suwalski [EMAIL PROTECTED] wrote: David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? Nothing's impossible, but a longer cycle every so often would encourage larger and better thought-out changes. I always get the feeling that GNOME contributors hold back on a lot of excellent ideas because they feel it will take longer to implement properly and test than the time they have before the next release. This argument has never made any sense to me; I don't see why there's any truth in it. I'm not saying there isn't any, just that it does not match my experience[1] and my feelings have been quite the opposite on the matter. I've seen various arguments for longer release cycles, and perhaps we may want to move towards them at some point. The argument I personally found most convincing for a change was from Andrew Cowie. Not sure if I'll paraphrase him correctly, but basically his argument was that: We should have a stable version that is still actively supported by the time users have adopted it, and most (mainstream) users won't adopt new versions until they've been stable for more than 6 months. Because of our 6 month release cycle and lack of ability/desire to maintain more than two releases (our current handling with 2.odd.x and 2.even.x), we effectively don't support and miss out on a lot of the feedback of many mainstream users. I used to be firmly in favor of the 6-month cycle, but I found Andrew's argument quite convincing and it has turned me into more of a fence sitter for now. It isn't yet clear to me that a change would be a definite improvement, let alone enough of a benefit to merit the change in the process, but that may well change. Anyway, that's my $0.02; I hope it provides a couple useful viewpoints for the discussion. Elijah [1] I've often worked on big changes that couldn't possibly make it in by the next release, including during code freezes. Sure, I can't commit it to HEAD when I'm doing so, but I can keep working on it even during hard code freeze (in branches, of course), planning it out for some later release. How many years has work on compositing gone on? I don't think a 9-12 month (or even 18 or 24) would have helped it actually get in before the next release, nor that the overall quality of it when it finally does get in would be any higher. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Elijah Newren wrote: [1] I've often worked on big changes that couldn't possibly make it in by the next release, including during code freezes. Sure, I can't commit it to HEAD when I'm doing so, but I can keep working on it even during hard code freeze (in branches, of course), planning it out for some later release. How many years has work on compositing gone on? I don't think a 9-12 month (or even 18 or 24) would have helped it actually get in before the next release, nor that the overall quality of it when it finally does get in would be any higher. There's a good reason for this really; no matter how long you make the cycle, if you allow people to commit stuff to HEAD that essentially disassembles the engine and leaves parts all over the floor, you have a big problem - nobody else on the team can get anything done because they can't dogfood HEAD in order to work on their own changes. (cf. pre-GNOME-2.0 for an example of when this happened a lot...) So, there's a reality that HEAD has to always be roughly working since lots of people are trying to work with it. Given that reality, a longer cycle essentially does nothing to make it easier to make large changes, because a branch is required due to dogfooding, not due to the short cycle. Re: the overall discussion, a couple points I'd highlight: - perhaps the largest penalty for exceeding a 6-month cycle is that distribution vendors start maintaining their own substantial forks because they can't count on having HEAD in released form. - I don't think something like Topaz is even worth considering unless the community can figure out how to decide on some of the focus / target audience questions I've annoyingly raised ;-) if those aren't answered you end up doing the petrified wood rewrite (cf. http://log.ometer.com/2005-04.html) where it cleans up the code but you pretty much have the same thing as before. Just a .02 Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
RE: getting on a longer release cycled
Before you change something, you need to have a reason to; this is more so if you want to change something that is working out pretty well, such as GNOME's release cycle. I think you'd be hard pressed to find a universally accepted reason to change GNOME's release cycle. This leaves the GNOME 2 question unanswered. Because, how can you plan, code, and test such a major jump in just six months? If teams are already having problems with 2.x releases... Then how on earth can they manage the 2 release?? The solution has already been given: separate branches. Develop 2 alongside maintaining the current 2.x releases, much in the same way the KDE guys are working on KDE 4 while still updating KDE 3.x. Of course you can (and should, I think) always set a release plan for 2 while planning the whole thing; the point is: I think it is completely irresponsible to impose the same 6 months on 2 as on 2.x releases. I think most of you agree on that one. Anyway, all the above is pointless if GNOME, as Havoc pointed out, does not get going on 2 soon. With Microsoft gearing up for Vista, and KDE for KDE 4, I don't think GNOME can afford to dawdle that much longer. Thom Holwerda --- Managing editor at http://www.osnews.com -Original Message- From: [EMAIL PROTECTED] [mailto:desktop-devel-list- [EMAIL PROTECTED] On Behalf Of David Nielsen Sent: donderdag 7 september 2006 21:22 To: desktop-devel-list@gnome.org Subject: Re: getting on a longer release cycled tor, 07 09 2006 kl. 11:24 -0700, skrev David Trowbridge: What in particular isn't possible with the 6-month cycle? I honestly don't think it's about the cycle length as much as the slight fear we seem to have of setting major goals for the project. I doubt we can do Topaz within the comfort of our tried and true 6 month cycle and we do need to decide what Topaz is going to be at some point. As the honorable Jono Bacon put it, he would hate to go to GUADEC 2007 and have Topaz still be something we talked about rather than actually worked on. This is likely to require someone to take the probably unappricated position of Topaz direction manager (or Topaz dictator, asbestosuit included). Basically I think Hub has the right idea but the wrong approach. We need to start thinking about what we want and if that requires us to extend the cycle, do things in parallel or whichever solution we need then we absolutely need to do it. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On 9/7/06, Havoc Pennington [EMAIL PROTECTED] wrote: So, there's a reality that HEAD has to always be roughly working since lots of people are trying to work with it. Given that reality, a longer cycle essentially does nothing to make it easier to make large changes, because a branch is required due to dogfooding, not due to the short cycle. Given this, one thing that could improve the ability to work on larger disruptive features without necessarily needing to extend the release cycle is a source control system that didn't make it so painful. SVN is only an incremental improvement to CVS on this score, but at least it's an improvement. Does anybody know the status of that migration? I assume it was on hold until after 2.16 was released, but has it been re-scheduled? (apologies for the tangent) -- jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi, Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. More important than moving away from the time-based release is reinjecting some feature-based planning and goals. In the coming weeks, I'll be sending a mail to module maintainers (as listed in the MAINTAINERS files) asking them to identify major features they want to do for 2.18 and 2.20. The goal is to get maintainers thinking about what they're going to do next, rather than continue organic development, and to identify areas where maintainers or projects are moving in similar directions, and get alignment on those issues to generate momentum. This doesn't change time-based releasing. Some maintainers will choose not to answer my mail, and some maintainers will be deliberately pessimistic to avoid pressure to deliver features. That's not my vision of this, though. I expect maintainers to be honest about their short and medium term goals, and to have no qualms to bumping a major goal if it's not going to be production ready for 2.18. I will update this roadmap (or whatever you want to call it) at the half-way period in the 2.18 cycle and do my best to make sure it reflects reality most of the time. It's not a stick to beat people with, it's a central place for us to tell each other what we're working on or planning. Subversion uses a planning cycle like this, and it works very well. They get good incremental improvement, but they have their eyes on bigger features and goals all the time, and they knock at least one major goal off at each release. Thinking 2 releases ahead can help us do the same too. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
An innocent bystander who I'm going to flame now wrote: I doubt we can do Topaz within the comfort of our tried and true 6 month cycle and we do need to decide what Topaz is going to be at some point. But how can you say that we can't do Topaz in the 6 month cycle when you admit that WE DON'T EVEN KNOW WHAT TOPAZ IS? *That* is the reason no one is hacking on Topaz. Because there's no such thing as Topaz! The Topaz wiki pages are just a dumping ground where half-baked ideas with no one to implement them go to die. If we want to do Topaz, step one is to figure out what that means, and that doesn't require writing a single line of code, so the release cycle length is irrelevant. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On 9/7/06, Pat Suwalski [EMAIL PROTECTED] wrote: Nothing's impossible, but a longer cycle every so often would encourage larger and better thought-out changes. Or lots more not-so-well-thought-out changes... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hi all, I think the focus in this thread is a little imbalanced. I think we really, really need to focus on actually decided on what Topaz is going to be. I feel that the lack of direction in the project to say this is what will be in Topaz is actually starting to harm us - it is making us look like we can't make decisions. Much of the problem is that huge infrastructure changes cannot be easily hacked on by a single person to gain enough momentum to become Topaz. Sure, I have my idea of how Topaz should work, and I have blogged about how the GNOME desktop should be contextual to a project, and I also fleshed out ideas of interface with MacSlow at GUADEC. But, I think need to sit down, and make hard decisions about what is happening with Topaz. There are distinctive connections and threads of similarity between what people seem to want to achieve, and this seems to large fall into the domain of people as top-level objects and such. But, I think we need to get a core bunch of us together to sit down, thrash out some ideas and actually start scoping out what GNOME 3.0 should look like. I have a huge interest in usability, and Jokosher is a product of an application domain re-thought around usability - I think we need to decide on this before we start a flamewar about release scheduling. Jono ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thursday 07 September 2006 14:51, Jamie McCracken wrote: I dont know how topaz will transpire but I feel it should be written in a native high level language like D or Vala as its likely to be a rewrite of much of the existing code and could be doable in 9 months with a more productive language. Did you drink the cool-aid? (I'm talking about using either D or Vala) Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
On Thu, 2006-09-07 at 13:23 -0600, Elijah Newren wrote: Not sure if I'll paraphrase him correctly, You came close enough that I shan't quibble :) ++ This is what I've experienced in language binding land (and probably the story I told Elijah that he's paraphrasing): The people I work with on java-gnome won't be able to hack on GNOME 2.16 specific bindings until we have GNOME 2.16 desktops on our systems. My systems are otherwise production (in the sense that I use them to do business so I can't afford to have them hideously broken (s/business/what you do for a living and kinda want your computer working/ as you see fit). The others are in similar situations. Which means that we have to wait until the various distros that people use make a release that has a reasonably bugfixed GNOME 2.16 in it so they upgrade to it. Key point: that might be a while; 3-6 months at least! Meanwhile GNOME is movin' on. And then we have to do our porting work (if I can actually find anyone interested in doing so), and then do testing to get that work out the door; by the time THAT is ready it will probably be *past* the deadline for the next release cycle, so by the time our work on 2.16 features hits a distro it'll be the cycle *after* next. And it's not until THAT point that someone can get the code I've written to actually work on actual *applications* ... which in turn won't land in a distro until when, exactly? And meanwhile, GNOME continues movin' on. [That should be a song or something] We regularly have people showing up who are asking us questions about gtk 2.6 and using a version that is *FOUR* cycles old. We can't support that as we've long since moved on from there (shit, the people who wrote that code aren't even involved anymore), with the result that ISV developers are left out in the cold, and there's no momentum or support for new developers. [Yes, I realize that there are ways to cut corners off our iteration time. (making it easier to build from source; leveraging the .defs files that the pygtk guys use, etc). Working on it. But the point remains: people aren't using code we write now until 6-18 months from now] ++ I wouldn't dream of critiquing the GNOME community's hard won reputation for delivering code when it says it will. I also realize full well that six month time based releases got GNOME out of the 1.4 doldrums which makes it a religion that few are willing to give up. But releasing when you say you're going to does not imply that that the date has to be on a short period from the last one. Release engineering takes a LOT of work, both on the part of the people doing the tarballs and such through to people trying to keep up with translations and documentation - let alone the slavery that people doing the packaging in each distro have to put up with. It would therefore seem worth considering that we reduce the amount of time this takes as a percentage of cycle time - and one way to do that would be to lengthen the cycle. [And, note that in quite a few cases its the same person doing the work throughout the stack, meaning time spent on release engineering is time taken away from wizard hackery and innovation]. ... but all that is secondary to the bigger concern that GNOME is increasingly disconnected from its users. IMHO, but there you have it. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics Organizational strategy, change management, and technology innovation to help clients worldwide prevent crisis and improve operations. Website: http://www.operationaldynamics.com/ Blog: http://research.operationaldynamics.com/blogs/andrew/ GPG key: 0945 9282 449C 0058 1FF5 2852 2D51 130C 57F6 E7BD Sydney+61 2 9977 6866 New York +1 646 472 5054 Toronto +1 416 848 6072 London+44 207 1019201 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
