Re: Queries about release specifications [Was: who gets in and why]
- From: hobbit aloss ukuu org uk
- To: gnome-hackers gnome org, GNOME Desktop List <desktop-devel-list gnome org>
- Subject: Re: Queries about release specifications [Was: who gets in and why]
- Date: Thu, 29 Aug 2002 13:47:49 +0100
On Thu, Aug 29, 2002 at 11:34:58AM +0100 or thereabouts, Michael Meeks wrote:
> On Thu, 2002-08-29 at 08:12, Jeff Waugh wrote:
> > Telsa has just kindly lodged a bunch of relevant bugs on the release team
> > with regards to documentation and such (assigning them all to me in the
> > process - GAR!)... When the FTP and 2.0.2 stuff is done, I'm going to get
> > stuck into those.
[...]
> > Hopefully that will form the start of some (hopefully fairly casual)
> > policy documents on things like this.
As I said earlier, those docs aren't intended to define policy, just
to pull together information that is not pulled together and which
should be. IMO, at least.
> I do tend to agree with Mark though that one of the purposes
> of the GEP thing is to pull away from the release team some of the
> decisions that they have in the past made - so they are done in a
> more open and accountable way, by hackers.
Sounds good to me. Please don't think that I (with my release
team hat on for a minute) have hopes of saying "This is the
Gnome desktop. I say so, so it is." I don't want to :) I do
think we need to know what we think we're including in good
time, but that's different.
> Whether that applies to new applications I think does depend
> on how close we are to release and the panic level ;-) but in broad
> terms I think we need a whole lot more scrutiny of applications we're
> adding to the platform - particularly [!] guaging code quality,
> something that might seem revolutionary - but I think it's worth
> insisting on some minimal code quality requirements to get stuff in,
> in some formal way rather than "It works for me" sort of things -
I would love to see this. Would it be possible to start a
companion doc to the Coding Standards on in gnome-docu about
quality of code?
> but hopefully if I'm wrong there other people will point that out.
> Also, having a more formal approval process, might be a lever to
> encourage people to sync release schedules with Gnome, and feel
> more includeded in 'the community'.
Hadn't thought of that, but could be.
Telsa
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]