Re: Moduleset Reorganization -- Take two

On Wed, 2010-10-13 at 09:21 -0400, Matthias Clasen wrote:
> On Wed, Oct 13, 2010 at 3:15 AM, Murray Cumming <murrayc murrayc com> wrote:
> > Then I think your proposal will be a complete disaster. I'm horrified
> > that we must again justify the existence of a shared release schedule
> > and of a release-team that keeps modules on that schedule.
> >
> > This is little more than killing the GNOME release process just because
> > you have forgotten why we needed it in the first place.
> >
> A bit dramatic today, are we ?
> See, what we have today is an ever-growing set of modules (>200 !),

Not including external dependencies?

> that is almost impossible to get to build at any given time.

When modules don't even build, that's generally a sign that they need
_more_ release process, to provide more stability, not less. Those
modules' problems won't be fixed by ignoring those modules, though it
will make the release-team's life easier.

>  And many
> of these modules have very little to do with each other and very
> little reason to be forced into the same schedule.

Can you give us a list of actual modules that will no longer be on the
release schedule, please? That would help me judge the actual effect.

Note also that you are actually suggesting _adding_ the many Platform
Bindings modules to the Platform, which will require even _more_ work
for you. I am not confident that you will make the bindings stick to
these stricter rules given that the release-team has failed to make them
stick to the current looser Platform Bindings rules.

> It is time to cut back and focus on the core desktop a bit more, and
> let the wider set of apps run a little more freely.

So all the core modules (Stable Platform, Core Desktop) must be on the
release schedule? That's at least reassuring.

> If we didn't want to make any changes, we could just continue to do
> GNOME 2.x until we all retire...

I don't see how GNOME 3.x fundamentally requires this change of

Also, I generally think that you are making it hard for people to judge
this proposal by unnecessarily grouping several changes together, though
they don't need to all happen at once.

murrayc murrayc com

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