Re: GNOME Productivity release set



On 6/11/05, Murray Cumming <murrayc murrayc com> wrote:
> On Sat, 2005-06-11 at 14:52 +1000, Martin Sevior wrote:
> > HI Vincent,
> >            You can include AbiWord-2.3.1 as the inaugrial package of the
> > gnome-productivity collection in this release.
> 
> When we discussed this new release set in the board meeting, there was
> some fear that, even without the initial proposal's references to
> OpenOffice, this might not be as inclusive as we like to be. I
> personally think that we can define it in a way that pleases everybody,
> but we need to show that we can do that.

Yeah. This is not more inclusive, just bigger; there is a difference.
We're still saying 'Open Office is not GNOME' in very stark terms,
just like we did with firefox. Of course, I don't think either of
those projects are part of GNOME, but we have to be able to meet them
in some constructive middle, and as currently constructed, this plan
doesn't help us do that.

[Not that it is a bad thing to bring the office suite closer to the
core, but it is not making us more inclusive in this important way.]

> So I think this release set should not be an official part of GNOME
> 2.12. But if it works outside of GNOME 2.12 (as Platform Bindings did at
> first), without controversy, then I think we'll have shown that it can
> become official for 2.13/2.14, 6 months from now. I think that means
> just listing them on separate wiki pages and linking to them as
> "associated projects on the same schedule".
> 
> At the very least, we need some text to define what this release set is,
> such as we have for the existing 3 sets here:
> http://developer.gnome.org/dotplan/tasks.html
> And any special guidelines, such as these for Platform Bindings:
> http://developer.gnome.org/dotplan/bindings/rules.html

As an aside, I'm fairly nervous about saying something is 'GNOME' when
our translators can't translate it and our QA can't track it. Those
are two of the key things that supposedly make something GNOME-y, and
we're cutting them off. I don't necessarily see a good answer to this
particular problem, so I won't squawk too hard on this point, but it
seems like something we should at least give consideration to before
rushing into this. I'd certainly like to see a plan for it in place
before we move further on this.

Luis



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]