Re: Holes in GNOME 3 process

On Tue, 2010-11-30 at 16:26 -0500, Owen Taylor wrote:
> 
> Plans for testing GNOME 3
> =========================
> Everybody knows what needs work in their own modules, but there are lot
> of gaps in between modules. How are we going to catch options in the
> control center not doing anything, etc?
> 
what do you mean with this? There are indeed a few things the new
control center is waiting for, like what to do with the /apps/metacity/*
config keys

UI Mockup for Gnome 3.XX "Share" section of System Settings

Hello everybody. 

I don't know if it's good, but I have make a UI mockup for the Share
section of System Settings for Gnome 3.XX.

It's just a first idea and it probably need more work.

Link to mockup: https://bugzilla.gnome.org/show_bug.cgi?id=636206

Link to "System Settings" design wiki for Gnome 3.XX:
http://live.gnome.org/Design/SystemSettings 

What do you think?

Re: UI Mockup for Gnome 3.XX "Share" section of System Settings

On 12/01/2010 12:33 PM, Gendre Sebastien wrote:
> Hello everybody.
>
> I don't know if it's good, but I have make a UI mockup for the Share
> section of System Settings for Gnome 3.XX.
>
> It's just a first idea and it probably need more work.
>
> Link to mockup: https://bugzilla.gnome.org/show_bug.cgi?id=636206
>
> Link to "System Settings" design wiki for Gnome 3.XX:
> http://live.gnome.org/Design/SystemSettings
>
> What do you think?
Hi Gendre!
That looks like a great start!
Come by #gnome-design on irc.gnome.org, and we can talk more about it. 
I'm andreasn there.
- Andreas

Re: Holes in GNOME 3 process

On Wed, 2010-12-01 at 10:12 +0100, Rodrigo Moya wrote:
> On Tue, 2010-11-30 at 16:26 -0500, Owen Taylor wrote:
> > 
> > Plans for testing GNOME 3
> > =========================
> > Everybody knows what needs work in their own modules, but there are lot
> > of gaps in between modules. How are we going to catch options in the
> > control center not doing anything, etc?
> > 
> what do you mean with this? There are indeed a few things the new
> control center is waiting for, like what to do with the /apps/metacity/*
> config keys

Wasn't a specific problem report. I was picking a random example of the
the kind of things we need to make sure that get testing  before 3.0.
(And not just testing, but tracking to make sure that the bugs we find
get resolved.)

- Owen

Re: Holes in GNOME 3 process

Owen Taylor wrote:
> That's not in itself going to get us to a good solid GNOME 3. There
> seems to a lot more stuff that needs doing on the coordination side, and
> if it's happening, it's not being very well advertised, because I
> couldn't find any evidence of it looking around. A few things that jump
> to mind listed below.

+1. What you're saying is that we need someone (or someones) doing
release management for 3.0 - I definitely see a gap there that the
release team are not currently filling (and which, to be fair, hasn't
traditionally been part of their role).

Cheers,
Dave.

--

-- 
Dave Neary
GNOME Foundation member
dneary <at> gnome.org

Re: Holes in GNOME 3 process

On Tue, 2010-11-30 at 16:26 -0500, Owen Taylor wrote:

> Central place for planning
> ==========================
>  http://live.gnome.org/GNOME3 is
>   "GNOME 2.30 == GNOME 3.0 release-team proposal"

As an unauthenticated user, this page says "You are not allowed to view
this page."  Don't know if that's intentional.

- ajax

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bump external dep on telepathy-glib

telepathy-glib version 0.13.2 does not build the file
telepathy-glib.vapi properly. I'd like to bump the external dependency
to version 0.13.7.

Any objections? If there are none I'll do this in a couple days.

Cheers,

Stef

Re: Holes in GNOME 3 process

From: Owen Taylor <otaylor <at> redhat.com>

> Someone watching the builds
> ===========================
> http://build.gnome.org/ is back up and running and has a build from
> yesterday. Yay. Has anybody looked? If packages going red on
> build.gnome.org aren't blocker material .... if packages don't have to
> be green, then there really is no point.

I agree that there is no point of having the build system if most of
packages are in red. Anyway, about this red status, this is something
that each build-slave maintainer should keep track of.

Other problem was that because the "dbus connection problem" we needed
to remove RHEL5 as a build slave, as this machine is also the
master. So right now there are just one stable build-slave (thanks to
Frederic). Several ideas were proposed, but no one was implemented
yet. My favourite is a virtual machine, but this is something that it
is required to be implemented by the sys-admin group (IMHO).

In the same way, when this RHEL5 build-slave was running, it was not
clear who should review the builds. I randomly checked that, but
pragmatically was not the best, as I can't install new packages on
that machine (ie [1], I just modify the slave and master
configuration).

Sometimes I feel that the review of the builds on the machine provided
by GNOME should be reviewed by GNOME sysadmin, but not sure
anyway.

Re: Holes in GNOME 3 process

On Wed, Dec 1, 2010 at 11:21 AM, Piñeiro <apinheiro <at> igalia.com> wrote:

> So, if you are suggesting a feature to avoid showing the non running
> slaves, I think that the current status is better.
>
> But, as RHEL5 is not a build-slave anymore by purpose, and we don't
> have news from the other build-slaves for ages, I agree that those
> shouldn't appear. I will try to contact the maintainers of these
> slaves, and meanwhile remove those machines from the master build-slave list.
>

The main problem with the build slaves is that there are none ...
We really need to make it easier to add new ones.

I tried, and failed.

Re: Holes in GNOME 3 process

Hi!

> Sometimes I feel that the review of the builds on the machine provided
> by GNOME should be reviewed by GNOME sysadmin, but not sure
> anyway.

Normally build servers are used to check if the build still succeeds.
Most setups I know reject a commit when it breaks the build. I wouldn't
recommend this for GNOME because there might be problems the maintainer
cannot solve himself and it would slow down population of changes.

Instead it would be great if the buildbot would automatically send a
message to the commiter when the build fails (after the build was
successful before). The committer can then decide if it is his fault or
if he needs to ping the buildbot maintainer or fixup jhbuild.

As addition it would be nice if others could subscribe to a mailing list
that works like the gnome-commit-lists which tracks build failures (or
even successfull builds.