Hi,
Thought I might share insight as a relatively new contributor ;)
[...]
> My experience since moving to bzr branches:
> - Much, much faster updating of packages
> - Branching packages is possible (e.g. working in a PPA)
> - Patches are a little bit harder to do, as the branch doesn't contain
>
On Mon, Apr 11, 2011 at 7:25 PM, Jo-Erlend Schinstad
wrote:
> On 11 April 2011 13:22, Scott Ritchie wrote:
> [snip]
>> I think it's the height of arrogance for us to tell a user that we're
>> going to deliberately break his application because it wasn't updated to
>> use our new indicator library
On 11 April 2011 13:22, Scott Ritchie wrote:
[snip]
> I think it's the height of arrogance for us to tell a user that we're
> going to deliberately break his application because it wasn't updated to
> use our new indicator library. "Still working the way it used to" is a
> reasonable fall back.
On 04/11/2011 06:26 AM, Martin Owens wrote:
> On Mon, 2011-04-11 at 04:22 -0700, Scott Ritchie wrote:
>> I think it's the height of arrogance for us to tell a user that we're
>> going to deliberately break his application because it wasn't updated
>> to
>> use our new indicator library.
>
> We tell
On 7 April 2011 15:32, Rodrigo Moya wrote:
>
> About putting it in GTK, I don't know of all the appindicators patches,
> but most of the ones I've seen, more or less, are just a bunch of:
>
> #ifdef INDICATORS
> app_indicator_whatever...
> #else
> gtk_status_icon_whatever...
> #endif
>
Only FYI,
On 8 April 2011 00:23, Robert Ancell wrote:
> Can we get all our CD applications using GTK3? I'm thinking of Firefox
> here, we really don't want to have one or two applications requiring
> both packages on the CD..
FYI: Firefox GTK+3 port: https://bugzilla.mozilla.org/show_bug.cgi?id=627699
-
Le lundi 11 avril 2011 à 10:36 +1000, Robert Ancell a écrit :
> So, I propose that we move all the current packaging branches to using
> lp:ubuntu/package_name branches. We have a few branches using this
> mode and have had good success with them.
Hi,
I don't think the situation with those chan
On Mon, 11 Apr 2011 10:36:51 +1000, Robert Ancell
wrote:
> Some issues that will remain:
> - It is possible to screw up the branches so that bzr merge-package
> throws a confusing error (I keep doing it). Perhaps we need some hooks
> in bzr to stop this from occurring. If it can be broken, it w
On Thu, 2011-04-07 at 16:21 +0200, Krzysztof Klimonda wrote:
> On Thu, 2011-04-07 at 15:03 +0200, Sebastien Bacher wrote:
> >
> > Hi,
> >
> > The idea was never really dropped but it's not likely it will be an
> > official focus for the team, contributions to help getting it working
> > better ar
On 04/07/2011 11:52 PM, Martin Pitt wrote:
> Rick Spencer [2011-04-07 18:38 -0700]:
>> 1. There are key feature regressions, for example, there is no systray
>> support for many important applications.
>
> For the record, this is currently purely a design decision, not a
> technical problem. Unity
Le vendredi 08 avril 2011 à 19:05 +0200, Martin Pitt a écrit :
>
> I mean "GNOME" here, as most of the patches we carry for appindicator
> are against GNOME applications.
>
> But it really applies to all other upstreams, starting from hplip,
> mumble, etc.
Hi,
Not that I agree that unity shoul
On Fri, Apr 08, 2011, Robert Ancell wrote:
> - Speed improvements - we can run a greeter without running a full GNOME
> session
Running a "full" GNOME session sounds like a waste, but it kind of
makes sense to run a mini-session to start the essential GNOME services
and reuse GNOME infrastructu
On Fri, 2011-04-08 at 18:59 +0200, Sebastien Bacher wrote:
> Le vendredi 08 avril 2011 à 16:08 +0100, Chris Coulson a écrit :
> > - I'm not convinced that Evolutions additional features are that
> > important to our target users
>
> Hi,
>
> There seem to be some disagreement on how useful the ca
13 matches
Mail list logo
