Re: Modulesets Reorganization


> I understand the difficulties to maintain an Application moduleset, and
> the need to extend a bit the definition to more modules, but I don't
> think this is the right solution.
> With that definition, Pidgin is as GNOME as Empathy then ?!?
> That means that GNOME applications could live in any VCS, on any
> server/infrastructure, with any licence, etc ?!? That will be a mess.
> Also the current (already legacy?) method to propose an application in
> the GNOME desktop was a good opportunity to get community feedback, get
> more developers involved in the projects, and fix lots of GNOMEy issues
> the app could have. Also that was an opportunity for the app to move to
> the GNOME infrastructure. I take my experience with Empathy for this, we
> moved it to GNOME infrastructure in preparation of proposing it into
> desktop, it was a pain because of SVN but we did it (with new system I
> would certainly not have moved it to GNOME's SVN and would have kept it
> in Collabora's git). Also the first time I proposed Empathy it was
> rejected with a good list of reasons, those got worked on and that gave
> goals for the next 6months. That resulted in a better app proposed the
> next cycle and got approved. If we remove that module proposal for the
> desktop, things could have been different.
> And my last issue with the proposal: All applications could decide their
> own release schedule ?!? That would be a total nightmare for
> distributions I think. See how GTK not following GNOME schedule proved
> to be a recurrent issue... See for a concrete example that could happen:
> During the GNOME 3.1.x dev cycle, Empathy is following the same cycle
> and Ubuntu decide to ship Empathy 3.1.x for their dev cycle too. Then 2
> days before the GNOME 3.2.0 release, Empathy decide - since they are not
> really bound to any GNOME schedule anymore - to add new features to
> their 3.1.x unstable branch and delay the 3.2.0 stable release for 2
> extra months. What is supposed to do Ubuntu for their planned stable
> release?? They revert to Empathy 3.0, or they delay their distro release
> for 2 months?
> So my opinion is we really still need an *official* 'Applications'
> moduleset, with strong requirements to get in. Though, we could make it
> more flexible, for example we could accept 2 applications doing the same
> job without deciding which one is best (rhythmbox + banshee, empathy +
> ekiga). After all deciding which app is best is really a distro decision
> and does not limit to GNOME (epiphany VS firefox). I think we should
> give to distro a set of applications that follows strong rules (licence,
> release schedule, freeze periods, infrastructure used, defined set of
> external dependencies, etc) then let them pick the app they like in that
> set.

I couldn't agree more with Xavier! Guys, have you really though that through?

This will kill quite a couple of things in GNOME:
- The GTP projects despite translating the core (which might in turn
become obsolete over time). As GNOME applications will be hosted
everywhere there is no chance for translators to do some quality review
and to define some workflow. In addition, things like the "String freeze"
will be completely obsolete.
- The whole development model of freezes and stable/unstable releases
- Deprecations and GnomeGoals

Please, could you rethink that? Of course we can not host everything on
earth and there might be exceptions for hosting code and bug-tracking to
some extend (so a look at KDE doesn't make me too fond of that) but things
like release schedule, translations will become a mess if they aren't
centrally hosted.


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