Re: Design in the open
- From: Bastien Nocera <hadess hadess net>
- To: Shaun McCance <shaunm gnome org>
- Cc: desktop-devel-list gnome org
- Subject: Re: Design in the open
- Date: Mon, 30 Apr 2012 17:20:32 +0100
On Mon, 2012-04-30 at 12:05 -0400, Shaun McCance wrote:
> On Mon, 2012-04-30 at 16:36 +0100, Bastien Nocera wrote:
> > On Mon, 2012-04-30 at 16:52 +0200, Luca Ferretti wrote:
> > > I don't want and I don't have time and resources to help you with
> > > design or code writing. But I'm involved in this change and I feel I
> > > need more info[1]. And developers will need r-t approval before
> > > proceding with this change.
> >
> > Not wishing to diminish the role of the release-team, but if you expect
> > being able to block Totem/Videos from 3.6 when both the developers and
> > the designers agree it's the way forward, I think you're very mistaken.
>
> I don't think it's a matter of blocking the will of the designers or
> developers. The release team should, of course, follow the consensus
> of the community.
>
> But we do need to be able to judge whether the implementation is up
> to standards for inclusion. It's not a matter of saying "We won't
> include this feature." It's a matter of saying "This feature is not
> ready yet."
That's fair. Fedora already has a tick for that particular part of the
process. It's the "Contingency plan" section:
http://fedoraproject.org/wiki/Features/Policy/Proposals
In Videos' case, if it looks like a finished version won't make it in
time, we'll fork a 3.6 branch from 3.4, cherry-pick the most interesting
and tested changes, and ship that as 3.6.
> The problem with the feature proposal process is that we're approving
> wiki pages. But implementation matters. We have something like three
> months before we start hitting freezes. That's not a lot of time, and
> sometimes we just can't do everything we'd like.
>
> I'm not opposed to feature proposals, but I think they need to come
> with a detailed proposal for implementation, including all necessary
> new dependencies, and a deadline by which the release team can judge
> the implementation, not the design.
If we wanted to be able to judge the implementations when the feature
proposals are made, then we'd need to push them all back 6 months.
I'm not sure how we get to a discussion about the feature process in a
thread called "design in the open" though...
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]