Collaboration with Debian [was: Re: [Desktop13.04-Topic] GNOME plans review]
Robert Ancell [2012-10-17 10:48 +1300]: > - By updating packages in Debian and waiting for them to flow down to > Ubuntu kills our velocity. It can change the time from upstream release > to being in Ubuntu from hours (which is too long in my opinion) to days. Yes, I agree that this is an issue at times. It usually works reasonably well for me to upload a new version to Debian and fakesync it into Ubuntu at the same time, but I have (1) DD upload powers and (2) everything set up to build packages for Debian, which is not true for the majority of Ubuntu Desktop developers. However, at the same time I strongly believe that directly working on Debian's packaging VCSes has some major benefits: Technically we avoid duplicate work and potential conflicts (such as naming new packages slightly differently, or a bug fix independently done on both sides works in a different way/with different API), and socially it's a great way of giving something back to Debian in return for having Debian do the vast majority of work of building Ubuntu. It also avoids the need of having to wade through large and mostly pointless merge deltas every so often, a work that nobody is really very fond of. Would an acceptable compromise be to commit fixes and new releases to Debian's GNOME svn, but then just do a -Nubuntu1 upload from those, at least for the packages which we want to keep in sync by and large? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Robert Ancell [2012-10-17 10:24 +1300]:
> - It's about standardising the stack from the kernel to the
> applications.
Right, that was mostly what I've heard about the idea as well.
> This is mostly a non-issue for Ubuntu as the stack that is being
> standardised on is pretty much what we have in Ubuntu.
We deviate quite far already, using upstart, ConsoleKit, and upower,
while GNOME moves towards systemd. As you said, none of this is
insurmountable (it just comes with an ever-increasing maintenance
cost), but it certainly invalidates the upstream testing that this
would bring up to some degree, especially in areas like
settings-daemon and control-center. But we can solve that by running
all of upstream's tests (both automatic and manual) on our own again.
> - There's a logical conclusion that once you have Testable complete then
> that is a distribution. I get the impression that this is what some
> people want to go to but I've heard no actual strategy on how this will
> be a success for GNOME.
I don't think this will happen anytime soon. Anyone who says that
seriously underestimates what a distribution does and entails ("stuff
that other people do is always easy"). I don't have the impression
that most GNOME upstream devs want to carry the burden of supporting
several releases over years, providing security fixes, maintaining and
installer, preparing and testing images, doing user support, and all
that (that doesn't even begin to scratch the areas that Canonical does
very well, such as custom engineering or building relationships with
driver vendors). The pragmatic solution will probably be to declare
Fedora as the GNOME reference platform, which in a way it already is
anyway.
> In conclusion I don't think we have anything to be worried about with
> GNOME OS at this point and by the time it did matter we may be
> sufficiently different anyway that it doesn't matter.
I agree. I for one appreciate the practical efforts that have been
made in this area, such as OSTree. It's a very nice basis for doing
continuous integration testing on a standardized, and "hot off
plumbing git master" of current git master GNOME, and will hopefully
lead to a lot more robust upstream development process, as well as
allowing developers to easily reproduce bugs on the "standard" stack
locally.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
Hello all, Ted Gould [2012-10-16 15:06 -0500]: > So then can we really early (right now) rearrange the desktop startup to > start upstart when then start dbus and gnome-session? That would give > us the ability to start migrating jobs over to being upstart user jobs > over time without having to do all at once (like we have done with SysV > Init jobs in system startup). Not wanting to spoil the show, but before we make the desktop startup dependent on more Ubuntu-only technology: Is that really what we need here? I don't think the reason why starting Unity and starting the Dash takes so long is in any way related to startup order or that we wouldn't have a mechanism of starting things on demand (D-Bus activation works just fine for the most part). From what I can see, it's because Unity accepted one Python daemon after the other, compiz' architecture (fine-grained plugins, lots of XML parsing, inability to statically link to common plugins, etc) takes a high toll, and indicators/global menu is very chatty on the D-Bus (that alone takes ~ 1 second on an Atom CPU when e. g. starting nautilus!). I. e. when boot speed and memory consumption are really an issue, I'm afraid we actually need to reeinginer those things again; Using upstart won't help there. One opportunity where having session upstart (or systemd, FWIW) jobs would be handy is to finally replace update-notifier. It's become a collection of totally unrelated things (launching update-manager, launching Apport on crashes, launching Jockey on missing firmware, etc) just because we always need a session daemon to listen for events. This could be replaced by individual jobs that are triggered by uevents and inotify watches. This will help maintainability and improve memory usage a bit (2.5 MB RSS for upstart vs. 13 MB RSS update-notifier), and shouldn't noticeably increase CPU overhead. Do you have other cases in mind which would benefit from this? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Better Maintenance of IBus, i.e., the Input Framework
On Tue, Oct 16, 2012 at 5:01 AM, Sebastien Bacher wrote: > Le 16/10/2012 00:21, Ma Xiaojun a écrit : >> 1. Switching keyboard shortcuts are becoming more limited. > Well, that seems like a design choice of the UI in GNOME rather than an ibus > limitation though, right? E.g nothing stop us to use ibus 1.5 and design our > indicator/UI differently than what GNOME did? You can handle hotkeys yourself, as GNOME 3.6 But I'd like to make it upstream if possible. Hotkey issue let some users stay with SCIM even on 12.04 >> 3. Input methods has to be global. > Hum, is that "has" a GNOME choice or is ibus enforcing that in 1.5 as well? > Do you know why ibus went that direction? IBus enforcing. One IBus developer said on his blog that "Both IBus and GNOME upstream prefer the global status:" Maybe a front end can manage per window state instead of IBus. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On Tue, Oct 16, 2012 at 5:56 PM, Robert Ancell wrote: > My point is we *shouldn't* take the time to update Debian as it is all > cost and no benefit. If you think of Debian as being directly upstream > from Ubuntu it sounds good but in reality it is a more "sidestream". If > it is outdated in Ubuntu we should update it in Ubuntu and if Debian > also wants the update they should merge our changes across as we do the > other direction. The most appropriate person to decide if the changes > are appropriate is a Debian developer, not an Ubuntu developer. Do you mean "main" or "universe"? I have an example, TeX Live, which is quite important for academic people and some others. http://packages.ubuntu.com/search?keywords=texlive&searchon=names&suite=all§ion=main It is in "main" section. ( I thought it is in "universe" section) >From the link, you should easily see that it stuck on 2009 version since Lucid. And the version bumps to 2012 in Quantal. For sure there is a bug and now marked as "Fix Released" since 2012 is uploaded to Quantal. https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/712521 Note this comment from a Debian developer, what's your comment on this? https://bugs.launchpad.net/ubuntu/+source/texlive-base/+bug/712521/comments/70 > We don't need to switch from Debian to Arch as we don't need any > particular packaging. If you look at the versions page you see we > already maintain the majority of packages in Ubuntu anyway. Sounds like you mean more and more packages are going to "main". And we just need to take care of ourselves. I'm not convinced, though. The first thing is the experience from TeX Live gives little confidence on "main" packages. The second thing is that the documentation is still recommending go through Debian and then sync to Ubuntu. https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages I've filed need-packaging, upgrade-software-version bugs several times. The ridiculous thing for me is that I always find myself reports duplicated RFP bugs on Debian side. And I never get interesting reply from Ubuntu side. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 17/10/12 11:28, Ma Xiaojun wrote: > >> - By leaving some packages to be fully maintained by Debian we easily >> end up shipping old packages without noticing it. I was quite shocked >> when I updated the version tracker [1] how many out of date packages we >> ship. If we're going to ship a quality product we really should be more >> aware of the code we ship. > The page you mentioned is nice. > There ain't no such thing as a free lunch. > If a Ubuntu contributor/developer find something outdated in Debian, > she should help Debian as well as Ubuntu. > If you want a more updated upstream, consider Arch? > My point is we *shouldn't* take the time to update Debian as it is all cost and no benefit. If you think of Debian as being directly upstream from Ubuntu it sounds good but in reality it is a more "sidestream". If it is outdated in Ubuntu we should update it in Ubuntu and if Debian also wants the update they should merge our changes across as we do the other direction. The most appropriate person to decide if the changes are appropriate is a Debian developer, not an Ubuntu developer. We don't need to switch from Debian to Arch as we don't need any particular packaging. If you look at the versions page you see we already maintain the majority of packages in Ubuntu anyway. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On Tue, Oct 16, 2012 at 4:48 PM, Robert Ancell wrote: > - By updating packages in Debian and waiting for them to flow down to > Ubuntu kills our velocity. It can change the time from upstream release > to being in Ubuntu from hours (which is too long in my opinion) to days. In most cases, it just goes to the latest Ubuntu release. Users of older releases can help themselves or wanting for a (not always good) PPA. Longer supporting cycle, especially LTS releases, is really one of the advantage of Ubuntu. But the support is not that good, consider 10.04 today or 12.04 two years later. > - By leaving some packages to be fully maintained by Debian we easily > end up shipping old packages without noticing it. I was quite shocked > when I updated the version tracker [1] how many out of date packages we > ship. If we're going to ship a quality product we really should be more > aware of the code we ship. The page you mentioned is nice. There ain't no such thing as a free lunch. If a Ubuntu contributor/developer find something outdated in Debian, she should help Debian as well as Ubuntu. If you want a more updated upstream, consider Arch? -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 16/10/12 22:36, Iain Lane wrote: > Given the way that both projects are now design led, and the fact that > it's design decisions / philosophies that are driving many of these > difficulties, it would seem prudent for the respective design teams to > try to work together a bit more closely. I wonder if we can facilitate > something here, either at UDS depending on the people there or > elsewhere. It would be good to keep communication lines open here. I don't think there's going to be any meaningful Unity influence on GNOME as their focus is on things working with GNOME but we need to make sure that GNOME apps can work effectively in Ubuntu by making Unity handle them correctly. In terms of Ubuntu Design wanting to modify GNOME packages we do have to go to GNOME first as it's unsustainable to make the changes with Ubuntu engineering and then expect them to go upstream easily. > Back to the initial proposal quoted above. My initial reaction was that > I disliked it because my philosophy that I generally prefer to work as > close to upstreams as possible so that we can have a more productive > feedback loop when it comes to bugs and features. But it seems that > perhaps this is slightly broken for us, so neither party is getting much > benefit out of it. A benefit would be that tracking stable series lets > us work more closely with our other big upstream, Debian. We might be > able to reduce our deltas there quite a lot if we're tracking the same > stuff. I really question the idea that Debian is an upstream to us in the traditional sense. I see Debian as more of a "sidestream" project that we can transfer work between. Things that I think are bad about our close dependency on Debian: - We have wildly different release schedules and quality standards which means packages are constantly diverging - By updating packages in Debian and waiting for them to flow down to Ubuntu kills our velocity. It can change the time from upstream release to being in Ubuntu from hours (which is too long in my opinion) to days. - Debian carries a number of patches that have no relevance to Ubuntu (e.g. Hurd patches). This just complicates the packaging. - By leaving some packages to be fully maintained by Debian we easily end up shipping old packages without noticing it. I was quite shocked when I updated the version tracker [1] how many out of date packages we ship. If we're going to ship a quality product we really should be more aware of the code we ship. I don't think any of the above is likely to change at any point so I think the best way of reducing the delta is to not have a delta on our core packages (i.e. don't try and be in sync at all). The current work to be in sync is not really benefiting us or Debian and the more important upstream is the software author not Debian. Where we do need to be in sync: - Platform behaviour (e.g. library compatibility) so Universe continues to work (though I hope Universe will disappear at some point nullifying this). - Package naming. This is a problem that's getting worse not better with extras.ubuntu.com and the like. --Robert [1] http://people.canonical.com/~platform/desktop/versions.html -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Wed, Oct 17, 2012 at 08:38:59AM EST, Luke Yelavich wrote: > If using GTK3 apps, a11y is brought up by Dbus activation from within > libatk-bridge, which GTK now depends on. In other words, a11y as of GNOME 3.6 > is now always on. There is still a .desktop file in /etc/xdg/autostart, but > moving forward this is likely not to be needed, at least by GNOME/GTK2. Correctino, that should be GNOME/GTK3. Luke -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Wed, Oct 17, 2012 at 07:06:53AM EST, Ted Gould wrote: > So then can we really early (right now) rearrange the desktop startup to > start upstart when then start dbus and gnome-session? That would give > us the ability to start migrating jobs over to being upstart user jobs > over time without having to do all at once (like we have done with SysV > Init jobs in system startup). I'm sure when we do this at first it'll > cause some regressions with things like a11y, but if we start early we > can fix them by release time. If using GTK3 apps, a11y is brought up by Dbus activation from within libatk-bridge, which GTK now depends on. In other words, a11y as of GNOME 3.6 is now always on. There is still a .desktop file in /etc/xdg/autostart, but moving forward this is likely not to be needed, at least by GNOME/GTK2. Luke -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 16/10/12 23:47, Sebastien Bacher wrote: > Le 16/10/2012 06:08, Jeremy Bicha a écrit : >> On 15 October 2012 13:50, Sebastien Bacher wrote: >>> That's going to be a controversial topic but I want to suggest we >>> stay on >>> stable GNOME this cycle, the reasons are (in random order): >> Well you've been following GNOME development for longer than many of >> us. What is it that's making GNOME 3 releases more unstable than GNOME >> used to be? Is it just that GNOME development has sped up and the >> developers don't care enough about API stability? > I think there a different factors there: > > - we never had great quality, Ubuntu is trying to address that and aim > at better testing, less bugs, no regression, etc where GNOME didn't > make that shift (yet?) > > - GNOME2 has been "less dynamic" than GNOME3 (at least the 2.n > version during the Ubuntu time, which was not the start of the 2 > serie, by then things were already settled down and in maintenance > mode) which also made for less breakages > > - GNOME started to focus on "GNOME OS" and give less importance to > what distributors think or do. It's a fair choice, they think they > should better focus on building the best system they can do and should > not compromise to "accommodate" others. I'm not even sure they see > distributors as partners or if they just aim at deprecating those by > shipping GNOME OS directly... From what I have gathered GNOME OS is a number of things: - It's about standardising the stack from the kernel to the applications. This is mostly a non-issue for Ubuntu as the stack that is being standardised on is pretty much what we have in Ubuntu. There is a mismatch if GNOME standardises on systemd and we continue with upstart, but from what I understand about the technical differences the issues are being exaggerated and it is not something we can't solve. - It's about making GNOME testable [1]. It has been (correctly) identified that through distributors GNOME cannot ensure a consistent experience. In advisor board discussions at GUADEC it was suggested that perhaps the GNOME OS term should be dropped and Testable used instead due to the confusion surrounding GNOME OS. Testable is obviously a great thing for Ubuntu in that it will hopefully improve quality (so Seb GNOME is making that shift now) and allow people to run the Vanilla GNOME at any point. - Part of standardising the stack is increasing the scope of what GNOME is. So there's experimentation going on around packaging and user feedback which is the bread and butter of the traditional distributions. This seems like it could be a challenge for us, but it's too early to see where these experiments are going. - There's a logical conclusion that once you have Testable complete then that is a distribution. I get the impression that this is what some people want to go to but I've heard no actual strategy on how this will be a success for GNOME. I think this idea is built on the naive idea that you build the perfect OS the users will come. It would be suicide for GNOME to ruin their current distributor relationships at this point unless there was a strong chance of this succeeding and I haven't seen anything close to that. In conclusion I don't think we have anything to be worried about with GNOME OS at this point and by the time it did matter we may be sufficiently different anyway that it doesn't matter. --Robert [1] https://live.gnome.org/GnomeOS/Testable -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Tue, 2012-10-16 at 09:59 +0100, James Hunt wrote: > On 15/10/12 21:23, Ted Gould wrote: > > On Mon, 2012-10-15 at 21:19 +0200, Sebastien Bacher wrote: > >> Le 15/10/2012 21:10, Ted Gould a écrit : > >>> I don't believe that > >>> happened in the Q cycle, do we think that we could get upstart > >> > >> James pinged me recently because foundation is planning work for next > >> cycle and wanted to know what's the most important on the list for > >> desktop. I said it would be "user session jobs", do other still agree > >> with that? If you have other request I think there is still time at UDS > >> to discuss those > > > > I still don't understand why we want a single upstart instance and not > > one system one and one per session. I think that having a single > > instance is what makes user jobs difficult as you have to handle all the > > states of things like encrypted file systems, where if we started the > > upstart process later, PAM/lightdm would do it for us. There are other > > benefits too, but at least if I can move that out of the way I can get > > other features :-) > > The current thinking is in fact to have 1 process / user. I think Scott > was suggesting that everything _can_ be handled by PID 1, but whilst > that may be technically true, my view is that the benefits of 1 process > / user outweigh having PID 1 handle everything. It would make sense to > add in user job logging with enhanced user session support. I already > have a branch for this which went through a number of iterations to > ensure that the facility was safe, secure and fast. The only way that > all those requirements can be satisfied from my findings is to have a > user process handle user job logging. So this fits in with the overall > thinking on upstart user sessions too. Great! I think that makes a lot of sense. I think it also means that we can do additional AppArmor isolations that we couldn't do on PID 1. So then can we really early (right now) rearrange the desktop startup to start upstart when then start dbus and gnome-session? That would give us the ability to start migrating jobs over to being upstart user jobs over time without having to do all at once (like we have done with SysV Init jobs in system startup). I'm sure when we do this at first it'll cause some regressions with things like a11y, but if we start early we can fix them by release time. It would also be nice to get the user upstart as the DBus activation broker on the session bus. That way "it knows all" ;-) > > The feature that upstart doesn't have today that I think would help the > > most on the power/memory front is file watches. That way processes that > > watch a set of files for some change, could just be started when that > > change happens, deal with it, and then shut themselves down. > > Agreed. Again, I have a basic 'upstart-file-bridge' in development. > However, there are a quite a few issues that need to be dealt for such a > bridge to work reliably. One of the "biggies" is supporting recursive > watches explicitly, or atleast internally to minimise the risk of > possible fd-starvation. The first issue though is finding a suitable API > to use: I guess what I care about is that we provide a way to specify it in the job definition, if upstart does it a hacky way to get it bootstrapped that's fine. We can move from doing the shell based to an *notify based solution internally over time. I just want to start defining jobs and killing long running processes. > > Second for me would be DConf key watches. It is hard today to have > > something start when a key is set to "True" to enable a feature. > > Usually there has to be some sort of framework involved or a process has > > to sit around waiting to be enabled. > > Yes, and a D-Bus bridge might be useful too? In fact a modular bridge > design might be even better. Again, you could just do: > > dconf watch | initctl emit dconf DPATH=/desktop/unity/foo Again, same as above, if we could hide that from the task definition that would be fine IMHO. We should also look to see if we can have dconf help here, since we are paying the maintainer to work on it... --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 16/10/2012 20:14, Robert Bruce Park a écrit : Just a thought. I would like to see better cooperation, personally ;-) Right, I think we all do and ideas on how to improve cooperation are welcome ;-) Also, last I heard, 'GNOME OS' is not intended to obsolete distros, it is intended to obsolete jhbuild as a way for developers to hack on the absolute-cutting-edge-git-snapshots of GNOME. Well, I'm not sure what "GNOME OS" is about since there is a lack of definition for it and disagreement between groups of people. I've been to GUADEC though and I've been people on stage saying that GNOME should stop paying attention to distribution and their issue but focus on delivering a product. That's fair, mozilla doesn't look at distributors to define their reschedule schedule, freeze or whatever. That's a change in the relationship between GNOME and their distributors though and worth noting. GNOME also doesn't has the firefox brand and while mozilla can enforce their ways I'm not sure it's the case of GNOME... -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 16/10/2012 20:14, Robert Bruce Park a écrit : Whoa whoa whoa... I never hear about Fedora or SuSE having these clashes with GNOME. Are you sure the problem is really with GNOME and not with us? Maybe this problem isn't "GNOME doesn't cooperate with distributions" but rather "Canonical doesn't cooperate with GNOME." Did you hear about Ubuntu "having these clashes" with GNOME? I don't think we had strong public disagreements but it doesn' mean we don't have an opinion on how things are doing. I'm sure other distribution have similar issues (at least Debian has, from what I can tell by being on their channels and following their discussions). OpenSUSE is also not strictly following GNOME since they have a different release schedule. I've seen several discussions on the Gentoo side about issues with GNOME choices and how it impacts them recently as well. Sure Fedora doesn't have such issues, at the same time their focus is on shipping the current code from $upstream, they do target hackers and enthusiast users rather than enterprises and consumers, and most of GNOME hackers work for Redhat... -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 16 October 2012 14:14, Robert Bruce Park wrote: > Also, last I heard, 'GNOME OS' is not intended to obsolete distros, it is > intended to obsolete jhbuild as a way for developers to hack on the > absolute-cutting-edge-git-snapshots of GNOME. The "GNOME OS" discussion in Boston was pretty much a talk about jhbuild and ostree. If that's all "GNOME OS" is, then they really don't know how to pick project names. It seems that "GNOME OS" means a bunch of different, not really related things and badly needs a formal definition. Jeremy -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 12-10-16 05:47 AM, Sebastien Bacher wrote: - GNOME started to focus on "GNOME OS" and give less importance to what distributors think or do. It's a fair choice, they think they should better focus on building the best system they can do and should not compromise to "accommodate" others. I'm not even sure they see distributors as partners or if they just aim at deprecating those by shipping GNOME OS directly... Whoa whoa whoa... I never hear about Fedora or SuSE having these clashes with GNOME. Are you sure the problem is really with GNOME and not with us? Maybe this problem isn't "GNOME doesn't cooperate with distributions" but rather "Canonical doesn't cooperate with GNOME." Just a thought. I would like to see better cooperation, personally ;-) Also, last I heard, 'GNOME OS' is not intended to obsolete distros, it is intended to obsolete jhbuild as a way for developers to hack on the absolute-cutting-edge-git-snapshots of GNOME. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Reduce patch burden
On Tue, Oct 16, 2012 at 09:42:28AM -0500, Micah Gersten wrote: > On 10/16/2012 06:13 AM, Iain Lane wrote: > > […] > I think you mean DEP3 [1]. Yes. Many thanks! -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Reduce patch burden
On 10/16/2012 06:13 AM, Iain Lane wrote: > Hi, > > A lot of our packages are patched over upstream. Each of these comes > with a maintenance cost and is also a source of bugs and frustration > (quilt patches aren't the easiest things in the world to work with). > > I think we should systematically look at our patches and re-evaluate for > each one > > - Whether it is really (still) necessary — if not, drop > - If we can forward upstream if not already or if we can help > its upstream inclusion along > - Who is going to maintain the patch in the distro if it needs to be > kept as a local patch — desktop, PS, … > > It would be good if we could use something like DEP5 headers for all > patches, including adding them to existing patches. It's sometimes > really quite difficult to figure out what a particular patch is for, > whether it is upstream and so on. > > Cheers, > I think you mean DEP3 [1]. Thanks, Micah [1] http://dep.debian.net/deps/dep3/ -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Reduce patch burden
+1 Very good idea. -Matthew Lye Leadership is responsibility, not privilege, Action, not position, Guidance, not knowledge, and outcome, not disposition. On Tue, Oct 16, 2012 at 9:13 PM, Iain Lane wrote: > Hi, > > A lot of our packages are patched over upstream. Each of these comes > with a maintenance cost and is also a source of bugs and frustration > (quilt patches aren't the easiest things in the world to work with). > > I think we should systematically look at our patches and re-evaluate for > each one > > - Whether it is really (still) necessary — if not, drop > - If we can forward upstream if not already or if we can help > its upstream inclusion along > - Who is going to maintain the patch in the distro if it needs to be > kept as a local patch — desktop, PS, … > > It would be good if we could use something like DEP5 headers for all > patches, including adding them to existing patches. It's sometimes > really quite difficult to figure out what a particular patch is for, > whether it is upstream and so on. > > Cheers, > > -- > Iain Lane [ i...@orangesquash.org.uk ] > Debian Developer [ la...@debian.org ] > Ubuntu Developer [ la...@ubuntu.com ] > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > > -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] Reduce patch burden
Hi, A lot of our packages are patched over upstream. Each of these comes with a maintenance cost and is also a source of bugs and frustration (quilt patches aren't the easiest things in the world to work with). I think we should systematically look at our patches and re-evaluate for each one - Whether it is really (still) necessary — if not, drop - If we can forward upstream if not already or if we can help its upstream inclusion along - Who is going to maintain the patch in the distro if it needs to be kept as a local patch — desktop, PS, … It would be good if we could use something like DEP5 headers for all patches, including adding them to existing patches. It's sometimes really quite difficult to figure out what a particular patch is for, whether it is upstream and so on. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] improve ubuntu-system-service or look at systemd services
Hey, That's another potential topic, we currently still ship a "revert dropping of datetime helper" in our gsd package because we don't have a service providing timedated [1]. We should probably review what other services are in this case and either decide to implement those in ubuntu-system-service or to start using the systemd implementation of those (they are independant of the init system)... Cheers, Sebastien Bacher [1] http://www.freedesktop.org/wiki/Software/systemd/timedated -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 16/10/2012 06:08, Jeremy Bicha a écrit : On 15 October 2012 13:50, Sebastien Bacher wrote: That's going to be a controversial topic but I want to suggest we stay on stable GNOME this cycle, the reasons are (in random order): Well you've been following GNOME development for longer than many of us. What is it that's making GNOME 3 releases more unstable than GNOME used to be? Is it just that GNOME development has sped up and the developers don't care enough about API stability? I think there a different factors there: - we never had great quality, Ubuntu is trying to address that and aim at better testing, less bugs, no regression, etc where GNOME didn't make that shift (yet?) - GNOME2 has been "less dynamic" than GNOME3 (at least the 2.n version during the Ubuntu time, which was not the start of the 2 serie, by then things were already settled down and in maintenance mode) which also made for less breakages - GNOME started to focus on "GNOME OS" and give less importance to what distributors think or do. It's a fair choice, they think they should better focus on building the best system they can do and should not compromise to "accommodate" others. I'm not even sure they see distributors as partners or if they just aim at deprecating those by shipping GNOME OS directly... This will hurt GNOME some too as a decent amount of issues are reported first on Ubuntu. This will send some sort of message to GNOME but I'm not sure that there's much of a conversation happening though. In general, I think it would be a bad idea if we completely and permanently switched to shipping the old stable release instead of the latest stable release and the bug disconnect is one reason. From the way I see things, GNOME doesn't really support their stable releases much either. The final point release is only two months after the .0 release. Well, maybe we can see that the other way around. If we ship the stable serie we will fix bugs there, so by side effect we actually help to make the stable serie maintained. It might be a good move for GNOME and its users (for sure having stable series better maintained is a win for everyone right? distributations are supported for years and there are going to be lot of users benefiting of that). While maintaining the GTK milestones is a headache, it would also be a headache not to have them in Ubuntu. I don't think this strategy will really save much work. The GNOME milestone releases are likely to be packaged in a PPA any way. Well, my issue is not packaging, it's the number of people who come to us complaining that we landed GTK regressions in Ubuntu and that stopped them in their work... that includes: - the people looking at the archive and build issues - the people writing software on/for Ubuntu (ask the software-center guys how much time they spend tracking issues with GTK) - the people dealing with library transitions (look at e-d-s in quantal, we ended up dropping e.g evolution-indicator from the archive because we couldn't find somebody who could keep up with the changes) If we were just landing a new glib,GTK serie at the start of the cycle we would still have issues, but likely less of those (stable GTK ought to have less regressions than unstable versions leading to stable right?) and we would have them at the start of the cycle (where at the moment we often still fight new GTK regressions around beta1 and beta2 time...). It's somewhat similar to the toolchain in my opinion. On the other hand, I got involved on the Desktop team because there was packaging work that needed to be done and the GNOME3 PPA made it seem like less of a hurdle to contribute to. I think most GNOME apps shouldn't cause any issues for the Ubuntu desktop. There are about 2 weeks from Alpha2 to Feature Freeze, and Alpha 2 approximately corresponds with the 3.7.5 release. By then, it should be clear which apps could cause problems and there is time to get the safe ones in. Right, most apps are fine (they sometime turn out to be problematic, the new file-roller this cycle being an example, upstream rewrote quite some code and it has been really buggy since), the issue is that GNOME has a tendency to get everything depending on the last glib,GTK versions, so it somewhat forces us to update those... One element to think about also is how that would impact the GNOME remix if the plan there is not ship the latest GNOME... Seb, I blame the remix idea on you. ;) Heh, fair enough ;-) I'm glad you picked the idea and I wished things were easier to work out there that they are at the moment... Anyway, if the GNOME remix becomes an official flavor, I was hoping to then ask for permission to include the GNOME3 PPA due to our unique overlap with the flagship Ubuntu release. It's still a bit of a handicap as I don't think we could gain that trust if we included things that regressed Unity. Right. Is there any reason we think "GNOME remix" has to be t
Re: Better Maintenance of IBus, i.e., the Input Framework
Le 16/10/2012 00:21, Ma Xiaojun a écrit : On Mon, Oct 15, 2012 at 4:14 PM, Sebastien Bacher wrote: Thanks for your email. Could you give details on what in ibus 1.5 is gnome-shell specific? Could it be adapted to work on other desktop environments? http://desktopi18n.files.wordpress.com/2012/05/ibus-setup-for-1-5.png ( Compare with 1.4 ibus-setup if you can. ) 1. Switching keyboard shortcuts are becoming more limited. They now use single shortcut and rely on OSD to handle the case where there is more than two input methods. OSD: http://desktopi18n.files.wordpress.com/2012/02/gnome-shell-ibus-switcher-20120216.png But the controversial new design is not landed on GNOME 3.6. Well, that seems like a design choice of the UI in GNOME rather than an ibus limitation though, right? E.g nothing stop us to use ibus 1.5 and design our indicator/UI differently than what GNOME did? 2. No language panel any more; always use "Embedded in menu". "Embedded in menu", as a default, is totally broken (no menu at all) on current Unity environment. Ubuntu is currently using Python based GTK2 UI. IBus 1.5 is supposed to be used with new Vala based GTK3 U. https://github.com/ibus/ibus/tree/master/ui/gtk3 Right, we know that we need to rewrite our indicators for the new ibus/GNOME, that's the main reason we didn't update g-s-d/g-c-c in quantal. 3. Input methods has to be global. This seems to be another Nautilus story of GNOME. https://bugzilla.gnome.org/show_bug.cgi?id=684210 And IBus is following GNOME's policy. Fedora folks already suffered from this new change since Fedora ships pre-release IBus 1.4.99 since Fedora 17. http://code.google.com/p/ibus/issues/detail?id=1477 Hum, is that "has" a GNOME choice or is ibus enforcing that in 1.5 as well? Do you know why ibus went that direction? Cool. I'm an IBus member actually. I'd like to work with you guys. Great, thanks for the details you are providing, those will be useful to figure out what we need to do exactly next cycle! Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] Transition to gstreamer 1.0
Hey, On Mon, Oct 08, 2012 at 04:51:11PM +0200, Sebastien Bacher wrote: > Hey everybody, > > Setting that as a goal for next cycle, we delayed on that for > quantal but gstreamer 1.0 is out and GNOME 3.6 uses it so it seems > next cycle would be a good time to transition. We will probably have > a bit of porting to do on our side as well (ubiquity for example). Yeah, I agree. I see from fluendo's website that they aim to have a 1.0 compatible release available from November, which works for us. Checking the rdepends list (for main), it seems that most should be done upstream: ? bluez-gstreamer * brasero * brasero-cdrkit * empathy o finch * gnome-media * gstreamer0.10-alsa * gstreamer0.10-gconf * gstreamer0.10-gnonlin * gstreamer0.10-nice * gstreamer0.10-plugins-base * gstreamer0.10-plugins-base-apps * gstreamer0.10-plugins-good * gstreamer0.10-pulseaudio * gstreamer0.10-tools * gstreamer0.10-x * libbrasero-media3-1 * libcanberra-gstreamer * libclutter-gst-1.0-0 * libdmapsharing-3.0-2 * libevolution * libfarstream-0.1-0 * libgnome-media-profiles-3.0-0 * libgstreamer-plugins-base0.10-0 * libgstreamer0.10-0-dbg * libgstreamer0.10-dev o libpurple0 * libqtwebkit4 * libreoffice-core * librhythmbox-core6 * libtelepathy-farstream2 * libtotem0 * libubuntuoneui-3.0-1 * libwebkitgtk-1.0-0 * libwebkitgtk-3.0-0 * phonon-backend-gstreamer o pidgin * pitivi * python-gst0.10 * python-gst0.10-dbg * rhythmbox * rhythmbox-plugins o shotwell * totem - ubiquity-frontend-gtk - unity-lens-music pidgin: https://developer.pidgin.im/ticket/15299 shotwell: http://redmine.yorba.org/issues/5548 bluez-gstreamer: spotted upstream that perhaps they are integrating this into gstreamer itself? ubiquity-frontend-gtk, unity-lens-music: Ubuntu local, will have to port ourselves So yeah, seems doable. Thanks, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 16/10/2012 11:36, Iain Lane a écrit : Given the way that both projects are now design led, and the fact that it's design decisions / philosophies that are driving many of these difficulties, it would seem prudent for the respective design teams to try to work together a bit more closely. I wonder if we can facilitate something here, either at UDS depending on the people there or elsewhere. I don't think much of the issues we had this cycle were due to design though...do you have speaking design issues for quantal? (out of the fact that they design for different shells, and I don't think we should ask for Unity and G-S to have the same design, it's fair that different desktops take different decisions on e.g what to do with menus) GNOME rewriting their keyboard handling is just something we need time to catch up with. The other issues are mostly bugs, the fact that quality is not (yet) a focus for them as it is for us and the fact that they don't want to compromise on their decisions for the "real world" (or on distributor). Like when deciding for gstreamer they would care only for "GNOME" and ignore the fact that all distro ship e.g shotwell and rhythmbox and that those should be taken in account in the transition... The bottom line of the issue is that going to "GNOME OS" they are just not wanting to accommodate for classic distribution or downstream... Also, will we have enough upstream guys at UDS to have a GNOME relationship healthcheck like we had before? Not sure about "enough", I'm sure Ryan Lortie will be happy to speak for GNOME there, not sure who else will be at UDS Back to the initial proposal quoted above. My initial reaction was that I disliked it because my philosophy that I generally prefer to work as close to upstreams as possible so that we can have a more productive feedback loop when it comes to bugs and features. But it seems that perhaps this is slightly broken for us, so neither party is getting much benefit out of it. A benefit would be that tracking stable series lets us work more closely with our other big upstream, Debian. We might be able to reduce our deltas there quite a lot if we're tracking the same stuff. Right, the Debian thing is a good point as well in fact. By shifting our focus and use the stable GNOME serie we might help upstream as well to solve the issue that was raised in other emails on the list that "GNOME stable series are not maintained", not sure that GNOME is seeing that as an issue to be solved atm though but I'm sure it would benefit most users since at the end distributions do deliver stable GNOME versions to their users... Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Hiya, On Mon, Oct 15, 2012 at 07:50:04PM +0200, Sebastien Bacher wrote: > Hey, > > That's a "classic", we usually review our plans for GNOME for the > next cycle. > > That's going to be a controversial topic but I want to suggest we > stay on stable GNOME this cycle […] Ah, I think this is quite an interesting topic for us indeed. We don't seem to be getting any closer to GNOME, as indicated by the surprises you've pointed to. I wonder if we can fix/reduce that problem in future? Given the way that both projects are now design led, and the fact that it's design decisions / philosophies that are driving many of these difficulties, it would seem prudent for the respective design teams to try to work together a bit more closely. I wonder if we can facilitate something here, either at UDS depending on the people there or elsewhere. Also, will we have enough upstream guys at UDS to have a GNOME relationship healthcheck like we had before? Back to the initial proposal quoted above. My initial reaction was that I disliked it because my philosophy that I generally prefer to work as close to upstreams as possible so that we can have a more productive feedback loop when it comes to bugs and features. But it seems that perhaps this is slightly broken for us, so neither party is getting much benefit out of it. A benefit would be that tracking stable series lets us work more closely with our other big upstream, Debian. We might be able to reduce our deltas there quite a lot if we're tracking the same stuff. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
