Re: more gnome 2 proposal

[Havoc Pennington <hp redhat com>]

Iain <tigermilk btinternet com> writes:   
> I would like that we can be proud of gnome 2.0, without saying "Hold on
> till 2.2, look at all the stuff that'll be in it".

Part of the problem right now is that people have the (correct)
impression that we are constantly saying that about the next
release. More regular releases are the best way to fix that. 
2.2 will be shortly after 2.0.

i.e. hypothetically if we can have 2 releases 6 months apart, or 1
release after 9 months, I think the 2 releases are better, since you
have the 6-month and the 12-month stuff going out to users. Even
though the 6-month release will be less snazzy than a 9-month release
would have been.

Just to reiterate the advantages of regular releases:

 - we get to refine the release process, since people actually remember
   how we did the previous release
 - we stabilize the tree more regularly, so it doesn't become 
   totally broken and bitrotted
 - people don't try to cram new features in stable releases, since
   they can actually expect the unstable release to happen soon
 - users get new fixes and features more regularly
 - developers get faster feedback loops between making a contribution
   and being able to use it
 - less divergence between stable and unstable branch, so porting 
   fixes between them isn't so difficult, and it's easier to 
   maintain stable
 - releases aren't Doomsday; you make the release with the features
   that are there, confident that missing a release won't delay
   deployment of the feature more than a fixed short time

The only way to make regular releases is to say it's OK to postpone
features. As soon as you start saying "oh, but XYZ would be cool,
let's delay" then you're back to a 2-year release cycle.

GNOME 2 need not contain _everything_ we can think of that would be
cool, just some good collection of highest-priority stuff that we can
do in the available time.

> With it in gnome-libs it will be installed on every system. Therefore
> one/two less dependancies for people using obsolete methods
> of obtaining software (Downloading tarballs, or RPMs
> manually!!!!!!!!).

Note that Debian explodes gnome-libs into a million little packages
anyhow, despite us shipping them as one.

> With it still as an optional extra people who want to minimise
> their dependancies (remember the whole gtkhtml is evil because it needs
> 3 extra libraries crap?) will not feel so reluctant to use it.

The point about dependencies I think is that people don't want extra
stuff they aren't using. It's not about number of packages you depend
on. The real objection here is about bundling together unrelated
items.
 
> I think we're misunderstanding each other.
> By tightly integrated I mean that gnome-libs depends on it, but it can
> still be a seperate thing. Kinda like
> libgnome <- libbonobo <- libgnomeui <- libbonoboui (or libbonoboX or
> whatever)
> Or possibly even libgnome and libbonobo could be merged (although thats
> an totally unthought about idea...)

It should be:
 libbonobo->libgnome

That is, a component system is logically on the lowest level, and used
to create a desktop environment, rather than vice-versa.
 
> I still think July is too soon. I know we're trying to emulate the KDE
> release schedule with a release every 6 months,
> but how long did they have between the last 1.x and 2.0? I thought it
> was around a year, although I've not found anything
> to confirm it.

We are talking about nearly a year for 2.0 - 9 months or so, more if
you count time already spent on 2.0.

I think it might be more productive to give the specific features you
think we can't ship without. Maybe the features you want can actually
be done by July. i.e. propose revisions to the chart of
versions/features that we came up with.

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers