Re: New module proposal: LightDM
Hello, Why replace GDM? What user-facing problem does this solve? In general, GDM code is ugly not because of what it does, but to prevent a wide range of security attacks that are attempted against login managers. Writing a login manager is not difficult, hardening one is. May I suggest that before this is considered, a security team performs an audit of all the security exploits that have been attempted against GDM, XDM and KDM and ensure that none of those can be exploited with the current code base. Additionally, we should compare the bug list from GDM and make sure that features that were implemented are not dropped, and that bugs that were fixed continued to be fixed here. This just be just to prevent another case of CADT [1]. Miguel [1] http://www.jwz.org/doc/cadt.html - LightDM is a cross-platform solution. Ubuntu is planning to switch to it this cycle, and other distributions have expressed interest in the project. By sharing this piece of infrastructure GNOME can spend more time working on important GNOME components. LightDM is aligned with freedesktop.org. - I am confident that the LightDM architecture is simpler than GDM. Some indicators of this: - Smaller code size - Well defined interface between greeter and session - Less dependencies - Less internal interfaces Architecture can be a personal opinion, and I encourage those with programming experience to look at the code and decide for themselves. Note that LightDM is not lighter in features, but in architecture. - By having a well defined interface between the greeter and daemon, it is significantly easier to develop a greeter without knowledge of how display management works. This is useful as the skillset and motivations of these two sets of developers are different. - LightDM is a platform for future work and is investigating the use of new technologies like Wayland. The details: Purpose: Cross-desktop display manager Target: desktop Dependencies: libglib, libpam, libxdmcp, libxcb, libxklavier, gobject-introspection, libgtk+ Resource Usage: Launchpad for source control and bug tracking [1], tarballs in public ftp [3] (in process of moving to freedesktop.org) Adoption: Accepted for use in Ubuntu 11.10, interest from other distributions GNOME-ness: Display manager is cross-desktop, example GTK+ greeter is fully GNOME compliant. I would recommend this module is maintained in the GNOME servers to get all the build and translation support. 3.0 readiness: GTK greeter currently using GTK2, but all other code uses latest GNOME standards. License: GPL3 [1] https://launchpad.net/lightdm [2] https://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00226.html [3] http://people.ubuntu.com/~robert-ancell/lightdm/releases/ ___ 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: Proposal: Moving d-d-l to moderated until after GNOME 3 release
I'd like to propose that we move the list to strict moderation for the next couple of months - anything not to do with development (code, docs, i18n, continuous integration) related to GNOME 3 should be filtered out. Priority should be given to maintainers developers and people doing release management. Perhaps you can create a moderated list for folks that need this kind of focused participation, call it desktop-devel-list-core-team. Or make that invite only, or something like that. And you keep this list open, to discuss things publicly as we have had it for years. Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hello, I know the issues splitting Gtk# can bring, but not splitting also brings issues from the GNOME point of view. And that's more important in my mind (maybe I'm alone in thinking that, though ;-)) I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. I do not know what those are. And it would help in discussing whether those issues are more important than breaking existing code. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hello, Miguel wrote: I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. Nothing is stopping embedded developers from just shipping the libraries from Gtk# that they need, they do not need to ship everything that the tarball contains. In addition, you might not even need a full binding of Gtk# or any of the component libraries, or even the Mono components in an embedded deployment, you might just need a subset. This is in fact, one of the problems with the Compact Framework from Microsoft. Someone decided This is what we will support on an embedded system with no consideration for the fact that embedded systems are hardly the same, and the kinds of applications are always different (the guys screwed by Microsoft are some of our major users: they copy-paste Mono's class library code so they can get features that Microsoft left out). The right approach is to use a tool that can take a library, and using a specification that contains the features required it produces a light version of this library. There are commercial tools that do this for CIL libraries, we have our own `monodiet' which is being replaced with a simpler and more complete `CIL Linker' based on the Cecil libraries. Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, Mono has been successfully used in embedded systems of different sorts. Examples? Or are we just talking about some guy who got it working once? Confidential, paying commercial customers. All we can say is that the PowerPC port was paid by them. Maemo are not using Python yet as far as I can tell. They would like to support it as a development environment, and maybe then use it for their own core stuff. But it needs some performance/memory/code-size work. Yeah, but users are. And they have been for a long time in the pre-Maemo GPE days. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. Mono works just fine on embedded devices, and considering that it consumes less memory than Python when running Gtk applications and people do not have a problem using Python on embedded devices I do not see the problem. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, I look forward to Mono development over time. I do think it is an exciting framework. My experience is from the embedded world. My engineers don't use Python with Gtk+. We use Gtk+ and Gtkmm. My concern is for the overall user experience. I come from a world of our own in-house kernel and rootstrap. My kernel is written in ARM assembly. All of my drivers from I2C to USB are written in ARM assembly. So as I transition my team's products to the Gnu/Linux and Gnome platform, the overall user experience should not regress. That is my gatekeeper in a way. You have to weigh the pros and cons of cost as well. Do I throw more money at more expensive processors, more memory, and more flash just so that software performance doesn't regress? Or do I compromize and stick with native for now, keep the price down and allow third party use of frameworks like Mono or Python and see it evolve over time. That is my balance. I think it is a fair one. It is a fair one. Our difference of opinion is that we are probably looking at different sides of the embedded world. Embedded can mean a million different things. Mono has been successfully used in embedded systems of different sorts. In the particular context of Gnome and Mono, I assumed you were talking about Maemo which is probably the high profile user of Gnome today on an small device, and on Maemo Mono is just a fine solution. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, I'm way past my quota of repeating myself, and deep in rant land, but this is what happened with Bonobo. Developers knew it wasn't ready, knew it wasn't suitable for such deep use, and knew there was a risk to making it central to GNOME. It was pushed through anyway, and that was allowed in order to avoid a split among the developers. But I hope that our community is stronger now. No, this is not what happened with Bonobo. Bonobo was a completely different ball game. It was a technology that we created initially for creating compound documents in Gnumeric, I was maintaining both at the time. Bonobo later got reused for embedding controls, which is something that we wanted in Evolution and something that Eazel decided they wanted to use to support menu merging across components. There was not even a discussion of this kind about Bonobo, Bonobo was merely a dependency to get certain features working. The problems Bonobo tried to solve, turned out to be very complex and the solution turned out to be very complex. In fact, the steering committee, which lead to the creation of the foundation, which lead to the board, and to today's release engineering was created out the need to have a stable release of a number of components at the time and to mediate between Eazel and Ximian's product schedules. We had some cross-company interlock dependencies. We needed to come to an agreement about how fast each company could deliver and complete the components they were in charge. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hello, Let's be sincere. Mono does not provide more benefits than what Java has been providing since more than a decade.. and we have not used it. Nobody joint the GCJ or Classpath library effort, and basically nobody cared about it. This is a bogus statement. Dan already posted the list of applications using Mono and Java from gnomefiles.org. 110 python/pygtk apps/libs 59 mono/C#/gtk# 37 gtkmm/C++ 27 perl 16 java 5 ruby So what about using facts and figures instead of empty rhetorical statements. Now, regarding why people have not helped free Java, I have covered that in the past in my blog. But here is a summary: Mono has benefited from two kinds of contributors: believers in free software and people that wanted to get their critical .NET application running on Mono.Free Java on the other hand has suffered because they only have the believers of free software helping them. The pragmatists just happen to run proprietary java. That is why you see a different level of caring between free Java and free .NET. How many Desktop Java based applications has you used in the last few years? Ok, and now, think again in all those benefits that Mono is supposed to bring to us. Azureus and Eclipse come to mind. I personally use these Mono apps: last-exit, banshee, beagle, f-spot, gfax, gimp# (it runs PhotoShop plugins) and tomboy. (And a couple more of Novell ones, but I doubt you care about those) Think of another desktop, choose the one you want.. let's say KDE: it's one framework, one desktop and innovative applications. So, yeah, rather than something strange, it's the usual business for everybody else. The KDE guys have no problems including Mono bindings (or Ruby, or Java, or JavaScript, or Python ones or Perl ones): http://developer.kde.org/language-bindings/ As for the Mono ones, they are actually on their second iteration (Qt# first, Kimono is the new one): http://www.kdedevelopers.org/node/2090 So maybe your KDE example is not the best one of a desktop that does not bring third-party frameworks into their system. The Mono case is exactly the same as the Python or the Java one; and from my point of view all them carry the same set of problems to GNOME: Huge dependencies, resource wasting, and the bast amount of APIs in which the applications will be based and that are controlled by somebody else (API may change, ABI may be broken, etc). By the way, I have no idea.. I'm just wondering.. Isn't the Mono Class libraries bigger than the GNOME ones. Wouldn't it look weird to depend on a secondary framework bigger than itself? The Linux Kernel and libc are also larger than Mono. That a weird dependency. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, And while there were almost no objections to Python, there are clearly many objections to Mono. What objections? So far, the only two objections I've heard are: Obviously, there are many. Please enumerate all the objections. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hello, Am not quite sure what you mean by the build system of Mono, there is no such thing as the build system of mono. Maybe you mean that you need to have the mono command installed? That + all the assemblies. Ok, so the runtime libraries. These are in no way different to any of our libraries that includes more than the shared library: they include pixmaps, data files, glade files, configuration files, schemas and so on. Contrast with GCJ which links in only whats needed to create a compact native stand alone executable - that is what AOT should be IMO. (is the SoC project to create a linker basically this?) No, the SoC code is for a different purpose. Its used for people that might want to embed Mono into a smaller space, or want to create smaller/larger libraries by linking one or more assemblies into one (for instance, the Compact profile of Mono will be created by passing a list of classes and methods to the linker). so in other words it will spike every now and again EG if under Boehm GC I have 50MB heap then in compacting mode its going to spike from 50 to 100+ MB (how much higher depends on the no. of generations you have and how incremental it is of course) Yes, but the spike is not 2x the memory you have allocated. The spike is the size of the nursery (512k). Im not sure how this helps mono though except maybe you can claim it will be faster. A compacting collector helps long running applications by returning unused memory to the OS. Memory that typically would be trapped in unusable gaps. These unusable gaps are hard to predict, and they depend on the allocation pattern of each application. Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hello, Jits on the desktop are usually bad not just because they do take more memory but also because you need the build system of mono installed which means more bloat. Considering that Gtk# applications consume less memory than PyGtk applications am puzzled by this blank statement. I'd be interested to see any numbers backing up that statement, otherwise I'm going to be as puzzled as you by blank statements. From my blog last year: http://tirania.org/blog/archive/2005/Feb-09.html And Paolo's: http://www.advogato.org/person/lupus/diary.html?start=15 Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, Ben presented a case (2 points) and you said there are many more. I appreciate your list, but your list contains multiple points that have been debunked by various people. Am sorry if this email seems dismissive, but you conveniently quoted the pieces you wanted and ignored follow up messages that addressed these problems. 1. Microsoft, the FUD argument, I wont say anything more that has not been addressed in the past, other than from a legal standpoint we created the Open Invention Network to protect open source with teeth. Status: FUD. 2. Additional Framework: yes, it is an additional and *optional* framework. Nobody is forcing you to use it. Status: minor concern, its optional. 3. GNOME is the only platform which would depend on an extra framework. Status: debunked. You quoted KDE, and I pointed to you that KDE has support for Mono, Ruby, Python, JavaScript and Perl. You conveniently have ignored the evidence contrary to your statements. 4. Resources: yes, Mono takes more memory, we are not making it mandatory for Mono applications to be part of the core desktop. It is optional; Dont like it, dont run it. Status: Minor concern. 5. Managed/interpret code is slow/larger Yes, it is. So we should block any managed/interpreted systems to provide bindings to Gnome, because everyone must use C/C++/another compiled language? Shortsighted. Status: Minor issue. 6. Original authors could not use it. You used a gossip article, I pointed to you to the real reason for the Longhorn failures, which you conveniently ignored. You did not reply to whether we can do better than Microsoft (again, conveniently ignored). But in addition, Microsoft has a lot of .NET code in shipping products, so the whole argument goes down: http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx Status: debunked. 7. Build Time Complexity A real issue, but someone has pointed out that every Linux distro has already sorted that out. Besides, Mono is only one extra tarball dependency. And its only a dependency for the Gtk# binding, what we are discussing. If we are going to have an issue over adding a new tarball as a dependency, we might as well not even have a process to expand Gnome in the first place. Status: unless we are willing to make a case for no-new-packages I do not consider this an issue. 8. Why Python can and Mono cant. Its hard to argue with someone that thinks that Python was a mistake in the first place (from your email). Status: pending. 9. Political Your company does not have to ship Mono, it is not mandatory, and the core is not being rewritten to use it. That being said, your company, Sun, of all companies, has a patent license to all Microsoft technologies, so there are no technical or legal barriers. There are merely strategical and ideological barriers that are barring Sun from shipping Mono. Status: Sun's problem. Not Gnome's. 10. Human Resources Status: minor. Your argument assumes that Gnome and Mono can not grow, that they are frozen in time. I do not believe for a second that Gnome has reached its peak, if anything more developers are joining the effort. Those choosing to use Mono will depend on Mono bug fixes for its bug fixes. But so does anyone depending on any other library, language and framework. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hello, so in other words it will spike every now and again EG if under Boehm GC I have 50MB heap then in compacting mode its going to spike from 50 to 100+ MB (how much higher depends on the no. of generations you have and how incremental it is of course) Yes, but the spike is not 2x the memory you have allocated. The spike is the size of the nursery (512k). Sure for young generation collections but major collections will be 2x the allocated memory as they must include the older generations as well as the nursery. (thats pretty much what the page link you gave says unless I have misinterpreted it?) The reason to perform a major collection would be to release some of the resources there (otherwise a new block would be allocated). So the new block allocated tends to be smaller than the sum of the existing memory sections, as it only accounts for live objects, not live objects plus dead objects. So we will see a doubling in size spike every now and again (it is after all one of the main disadvantages common to *all* copying collectors so no need to panic!) That is the worst case scenario, yes. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, Python was the first language to reach enough maturity and ruffle the least amount of feathers, and that is a point of differentiation with any language that comes in later. The important thing we wanted when Python got accepted was to have at least one higher-level language to be available for use, and not have a lot of them. So in short, I don't think there is an equal footing, and if people would want Mono in, it should replace Python, not sit side by side to it. This is radically different than your original proposal, when you brought Python up in September 2004. This is what you said: Why prove Havoc right so quickly ? The discussion on what language should go in has been hashed out numerous times already, don't give Havoc the satisfaction of predicting our behaviour of degenerating the discussion into a language discussion. I am asking a very concrete, specific thing - here's a module I'm maintainer of and which I feel would benefit from being written in something more flexible than C, and I want to use python for it. What would happen to the modules involved ? Today the issue of resource usage is brought up as if it were the end of the world, back in the day, Jonathan made the following comment: I would love to see limited use of python in the desktop release for GNOME 2.10. I'm not sure we want to see applets or core components written in python yet, primarily because of the assumed resource hit. I'd love to be proven that it is feasible, though. It certainly makes sense for applications with a limited lifespan, such as those in the control-center or gnome-utilities. Murray at the time posted the following eloquent email on this subject: What's the compelling reason to ship bindings? Great apps. I personally think that Great development environment is a more compelling reason, given that the majority of software development is in-house stuff that will never be on distros. That really is a vast huge immense amount of unseen software. The same applies here. I do not think there should be only one way of building applications for Gnome. We would not have the official language bindings release if we thought that only C code was worth having. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, What's the compelling reason to ship bindings? Great apps. I personally think that Great development environment is a more compelling reason, given that the majority of software development is in-house stuff that will never be on distros. That really is a vast huge immense amount of unseen software. More than once you have confused the acceptance of bindings with the acceptance of the use of those bindings in the desktop. My quote above does not contain this confusion. I stand corrected. The same applies here. I do not think there should be only one way of building applications for Gnome. We would not have the official language bindings release if we thought that only C code was worth having. -- Miguel de Icaza [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hey, Here's a heart felt thank you from one person for avoiding this. :) However, that seems to apply more to e.g. the panel changes. I'm curious about the joint window-manager/compositing manager (compiz) you were working on as it sounds like duplication of Soeren's work and something that largely wouldn't be affected by the bike shed stuff, at least not if the work discussion were restricted to the core gl part excluding plugins. My understanding while talking to David Reveman this past week was that the complexity of keeping a compositing manager as a separate process from the window manager was too high (too much bookkeeping that made it error prone, and there were some fundamental problems that he could not solve). So some time ago he abandoned his effort to patch Metacity and have a separate composition manager, reduced the complexity and eliminated a lot of bugs and the source of these bugs. That is what David explained to me, but I can only understand about 50% of the technical stuff that he talks about, so keep that in mind. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, We had already said apps should go forward with caution back in early June[1] (and apps likely started doing so sooner; it wasn't until Frederic brought up the issue[2] that we started considering not using gtk+-2.8 for Gnome 2.12). We said with caution at the time because The discussion that you are pointing to had plenty of people disagreeing on it. I hardly can see that long thread as a resolution. The first time this was proposed as official was Lluis' post from a day or two ago, after the deadline had passed. We use time-lines for a reason, so we can plan and execute without rushing things out. Notice that Gtk 2.8 had a number of major themes listed on its web page (Cairo support and RGBA visuals). Do we have a theme for Gnome 2.12? Lacking a theme, we should stick to the published dates. worried about needing to revert). Also, as already pointed out by Vincent[3] and Johnathan[4], apps have done this, it fixes bugs that are unfixable otherwise, and UI freeze isn't the last opportunity to take advantage of the new API. And most of those unfixable bugs are wishlist items, we are not talking about crasher bugs here, nor are we talking about something that would fundamentally stop someone from getting their work done. They all probably are in the eye-candy department. Really, though, the decision was made and finalized after it had been brought up lots of times. I'm sorry, but I don't see your current reason as cause enough for us to bring it onto the discussion table again. Because there is a violation of the agreed timelines and the promise that we have made to our users and the ISVs that ship the software. If you can not live without Gtk 2.8 for another minute, you can install your own version of Gtk 2.8 and build your own desktop with 2.8. But there is no reason to tarnish Gnome's reputation because some people feel that Gtk 2.8 is too cool to wait. Shipping a slower, more fragile version of Gnome and which in addition will not benefit for the most part on any of the new 2.8 stuff (if people are following the rules) seems like a loosing proposition. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, The QA team does not consider a GTK+ 2.8-based GNOME more fragile than a 2.6-based one. The QA team believes the issues involved in upgrading this component of the GNOME desktop are no greater than upgrading any other fundamental library. Let me rephrase a little: the QA team[1] has been testing gtk 2.7, and while we realize that gtk is deeper in the stack and as a result can cause some deeply hidden and hard-to-debug bugs, at this point we feel that gtk 2.7 is essentially as stable as 2.6 for the end-user, and more importantly, bugs in 2.7 are being fixed quickly and reliably by the gtk team; bugs in 2.6 are not. For how long has the QA team been running a Gtk 2.7.3 based desktop? And what kinds of tests have been done? I mean to get an idea of the testing happening in this area that lead to this very strong endorsement. We know that the testing at most has been running for six days. It is pretty bold to state that six days (max) of testing has produced a Gtk 2.7 that is as stable as 2.6; Lets not forget that after 2.6.0 was released, bug fixes were applied for six months after that. [1] worth noting that if Novell is concerned about the stability of HEAD, or the violation of promises about quality, Novell is more than welcome to participate in the QA team. As you well know, I am not in the desktop team at Novell, but I will let those on that group know of your offer. This is a breach of the time-line and a breach of deadlines that we have imposed upon ourselves to follow. When my candidacy for the Gnome Foundation two years ago was received a few hours late I was barred from participating in the elections. So when exactly did we begin to get lax with following rules? Seconded. If you believe gtk 2.7 is unstable, we need to know details and know now; we appreciate the efforts taken by the many who have actually used and tested it. Vague rumblings about potential instability don't count- I already played that card, have taken the plunge of using it, and have found it acceptable. No matter how well intentioned our developers are with a change in scope and size of this dimension Gtk 2.7 which has only been out for a month is bound to have problems. You of all people should know this. I do not run Gtk 2.7 nor work on the group that works on that, but that does not disqualify me from pointing out what has been a constant in the last 50 years of software development. I do not see how Gtk 2.7 can break away from the physics of software development. No company would bet its future on something like this with proper testing (which seems to have been decided by a few folks on irc). Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, We know that the testing at most has been running for six days. No, you don't. You asserted it. And it happens to be false. ;-) How exactly have you been testing Gnome with Gtk 2.7.3 for more than six days, I would love to know what kind of time machine you have. This is a breach of the time-line and a breach of deadlines that we have imposed upon ourselves to follow. We can't stick to a plan that doesn't exist. As pointed out by others, Gtk+ 2.6 with Gnome 2.12 was _never_ planned. Yes, gtk+-2.6 for Gnome 2.12 was discussed as a contingency plan, and some wanted to make it the plan, but that is it. Am talking about the time-line here: http://live.gnome.org/ReleasePlanning_2fTwoPointEleven You might want to familiarize yourself with the dates. The only formal communication coming out of the release team came out too late, no matter how much consensus you think you reached with the handful of people who were on the thread, you are past your deadline. Nope, another incorrect assertion; it was decided on d-d-l. Also, the gtk+ developers don't release 2.8.0 until it's stable. Releasing 2.8.0 is their way of saying it is stable. Now, you want to come in months after the discussions and final decision, and say that the gtk+ developers are not competent to determine stability of their product and that the release team and QA teams were also wrong in their judgement of whether to use it? Gee, thanks. In June 8th the issue was first brought up, in a question asked by Frederic. I do not see any consensus being reached on that thread. Then the second thread started this Monday (where a handful of people voted yes), so it is hardly an issue that was decided months ago. I am not making any statements about the competence of Gtk+ developers, so do not put words in my mouth. I consider this plain risk management. Specially considering: * There is little time to do any changes in software to take advantage of it (If we are going to respect the timelines that the release team is putting out). * There is little benefit from using Gtk 2.8 in Gnome 2.12 at a fairly high risk price. * Those who want Cairo in their apps can use it today *anyways*. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, This was sort of already decided in the thread, but after the release team meeting today, we figured it was worth mentioning officially. GNOME 2.12 *will* depend on gtk 2.8. This seems to add significant risk to Gnome 2.12 and I believe its reckless for Gnome to do such a release in the light of breaking up with the published plans that we have presented to various consumers of Gnome. There are only a few weeks left until Gnome 2.12 (six weeks) and introducing a large change like this as late in the process seems like a bad idea because this adds a significant risk to Gnome: * The new Gtk 2.8 API is not mature. By maturity I mean the Brad Cox metric of maturity: have the new API calls been used in at least three diverse applications and the feedback incorporated? Just to get app writers to target 2.8, release their apps and test it sounds like it would take more than six weeks (am assuming there are a number of freezes before this which would make this window smaller). * This breaks the published schedule, new features and modules were supposed to be locked-down on July 13th: http://live.gnome.org/ReleasePlanning_2fTwoPointEleven * The UI freeze for applications is five days from now, it seems reckless to inform developers that: go ahead and use new 2.8 APIs[1]. If you do, though, please make the change earlier rather than later, and test thoroughly and make sure you obsessively report problems to the gtk team, as you would with any new library with new API. I would like to propose that adopting Gtk+ 2.8 should happen after each module has branched for the 2.12 release which means that applications will get another 4-5 months of testing of Gtk+ and Gtk+ 2.8 will get 4-5 months of testing of APIs that until today have not been adopted by a single application. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, This seems to add significant risk to Gnome 2.12 and I believe its reckless for Gnome to do such a release in the light of breaking up with the published plans that we have presented to various consumers of Gnome. Having GTK+ 2.8 along with GNOME 2.12 was *always* the plan. Just that some people seemed to have cold feet. Well, Gtk+ 2.7.0 came out on June 20th, so that is a month ago. If someone was making plans to have GNOME 2.12 ship with Gtk 2.8 they were taking some very risky decisions. On that release it is recommended that people use Cairo from CVS as well: http://mail.gnome.org/archives/gnome-announce-list/2005-June/msg00029.html I can understand people having cold feed 5 months ago when there was not even a Gtk 2.7 to test with (and one would materialize only 4 months later). Again, read the API changes, you'll probably change your mind. The The API changes are incomplete, for instance, its missing the list that exposes Cairo. Which brings us to: biggest difference between 2.6 and 2.8 is the adoption of Cairo, and that seems to have gotten quite a bit of testing, and a lot of bugs crushed as a result. What is being suggested is that we should make Gnome 2.12 on Gtk 2.8 which in turn depends on Cairo 0.5-1 (as of today). Cairo is: * Not API frozen. * We do not have a schedule for Cairo being API frozen, which incidentally breaks the API rules: http://developer.gnome.org/dotplan/api_rules.html * Cairo itself has a list of requirements for 1.0 in cairo/ROADMAP and it looks far from finished. Section A9 will break the API, work remains on A10, A12 and possibly A13. This is in addition to various other items still on the queue before they release 1.0. * We do not have a commitment not to break the API after the GNOME 2.12 release in six weeks. I want a Cairo-based Gnome as much as everyone else, but this is not a sound decision. Breaking promises and changing schedules to get this feature is not right. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk 2.8 for gnome 2.12
Hello, * Not API frozen. * We do not have a schedule for Cairo being API frozen, which incidentally breaks the API rules: http://developer.gnome.org/dotplan/api_rules.html These are rules for libraries part of the GNOME platform. They're not enforced for everything stuck in the dependency stack below them, because that would essentially stop GNOME from depending on most libraries. And we do not expose the APIs of other libraries nor we make any guarantees about libjpeg, libtiff, libgif, libpng. But Cairo is a completely different beast, it is not an internal library of Gtk+ it is a fully exposed API exposed to widget authors and application developers. Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
