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
release-process.

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
www.murrayc.com
www.openismus.com



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