On Wed, 2006-02-08 at 19:51 +0800, James Henstridge wrote: > >>Isn't what we got here exactly what has been asked for? That 'big' > >>changes to GNOME needs to come from 'outside' projects? Havoc for > >>instance was advocating that in his blog entries. So if people are > >>unhappy about XYZ in GNOME, for instance the current panel. Due to it > >>being so business critical we can't have experimentation going on in the > >>gnome-panel CVS head, so 'radical' changes would need to be done as a > >>separate project, and if it turns out good then it will at some point > >>replace the current module. > >> > >> > >> > >this is exactly what I was going to say :) It is indeed what some big > >GNOME names have been advocating for. And I agree with it. At novell, > >and I guess at other GNOME-related companies, we try to put as much > >fixes as possible upstream, but for radical changes, it makes sense to > >do them separately and merge them upstream if/when maintainers are ready > >to accept it. > > > > > Sure it makes sense to develop radical changes on a branch rather than > on the mainline, but this does not require secrecy. Collaboration > doesn't need to be restricted to mainline development. > > Some of the benefits include: > > * Rather than dumping the change fully formed on the maintainer, > they might take an early peak at the code and tell you whether > there are problems with the design that would cause them to reject > the change later on. > * Reduce duplicated work: say someone else saw the mockups, decided > that they were a great idea and started implementing it. What do > they do when they find out that you've also been developing the > feature. What should the maintainer do if both groups submit > their respective patches for inclusion. > > There definitely are benefits to secrecy (better signal/noise ratio > between developers, being first to market with the feature), but they > aren't all benefits to the community. > yes, completely agree with you.
> >Also, current 6 months schedules make it difficult, at least from my > >experience, to introduce big changes. For big things, you usually need a > >couple of releases. Maybe we could improve this a little bit by > >"forcing" people to branch as soon as we hit the freezes, so that big > >changes can start immediately, instead of 2/3 months later (which is > >mostly what happens now, that most people start branching a few weeks > >after the final *.*.0 release). > > > > > Who says that a big change needs to be completed in 6 months? For some > changes it might make sense to skip a release, which also lets you > continue working through the feature freeze. > yes, that's ok for maintainers, but for outsiders, not really. There are lots of feature-related patches in bugzilla waiting for maintainers to branch. > >Also, Federico suggested some time ago, IIRC, keeping the old stable > >branches more alive than what they are right now. For instance, NLD10 is > >based on GNOME 2.12, so it makes it impossible to introduce radical > >changes in the upstream GNOME version, which is frozen. Of course, I'm > >not saying we should allow companies to put whatever they want in old > >stable releases, but maybe following Federico's suggestions would make > >companies contribute better to upstream GNOME. > > > > > Would it have been possible to develop these changes as a public branch > of the gnome-2.12 branch of the affected modules? While the gnome-2.12 > branch is feature frozen, there is nothing stopping people from creating > sub-branches. This might also make it easier to merge the changes > forward if they turn out to be good :) > yes, also agree with you. I can say though that the changes are not as radical as you might imagine. xgl/compiz is, of course, but this is completely new material, and the new menu is not a patch to the panel, but a separate applet, which can, I guess, easily be integrated into the panel/desktop releases. As for other changes, most are upstream in one form or the other. Notifications (libnotify), login speedup improvements (g-c-c and gnome-session), gnome-volume-manager, networkmanager, etc, etc -- Rodrigo Moya <[EMAIL PROTECTED]> _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
