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 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. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
2010/10/12 Sandy Armstrong : > On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming wrote: >> On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: >>> >>> Good point. It's fair to expect projects not using the GNOME >>> development >>> cycle to publish a schedule with freezes. >> >> You would allow modules in the module sets that don't follow the GNOME >> schedule? Then it loses all meaning. Once again, the purpose of the >> release schedule (of which the module sets are just a part) is to >> release software. > > I agree here. I'm not sure how the i18n and docs teams are supposed > to do their jobs if they have to track dozens of different schedules. > > Maybe those teams should only devote resources to an application on > the occasion that a release matches up with the GNOME schedule? This > would allow for apps to have more or less frequent releases, but at > the same time encourage them to have their releases match up with the > GNOME schedule whenever possible. I would very much like to give a translators point of view here. I think that reorganising the module sets in some way is a good idea, because right now the current situation has us (translators) unfairly favouritising certain apps because they are part of the dekstop module set. The main thing that I care about, is to provide quality translations of GNOME related software (prioritised on some way after importance and popularity) to users, therefore the present situation where rhythmbox gets a lot more translations love than banshee (because one is part of the grand desktop module set and the other is lumped in with all the others in Extra applications) is far from optimal. I would like to see this resolved in some way. The problem here is off course that some compromises will have to be made. I would like to have all the popular apps gathered somewhere so we know what to focus on, I would also like them to all release following the GNOME schedule, but on the other hand I know that certain popular projects would rather stay out of such a grouping than to conform with our schedule, so something has to give. If I give it my best at being a little frexible, I think we can make it work from a l10n point of view. The key is information and overviews. I think not everybody understands just exactly how important damned lies like functionality is to us translators and how much we use it. The reason is that we usually touch a lot more modules than any other contributor group. We frequently browse through lists to find work and access progress. So if... the Apps module set will have its own page in damned lies and if... string freeze and release dates are present there on that overview list, for the apps that don't follow the GNOME release schedule, and if the number of those apps are kept low, then I think that is still a workable solution. Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
>> 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. The option to run on their own schedule is for modules in the new Apps module set only right? \Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel -> gtk3
On Wed, 2010-10-13 at 17:50 -0300, Jonh Wendell wrote: > Hi, folks. > > Will we have a gnome-panel ported to gtk3? We need it for gnome 3 as > fallback for gnome-shell, right? Porting gnome-panel will be pain I think, at least when we're talking about the bonobo applet loader plugin that is available for backwards compatibility now. If gnome-panel is ported to gtk3, either that module gets dropped, or it is changed to an out-of-process binary, as it depends on libbonobo, which will never ever get ported to gtk3. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
