Hi, Sivan Greenberg wrote: > On Wed, Jan 12, 2011 at 1:14 PM, Dave Neary <[email protected]> wrote: >> Concretely, this is what "working upstream" actually means. > > So given this alleged time frame (I'm thinking out loud, and I thank > you greatly for this discussion, albeit a bit off topic now to > Carsten's original topic) , how extreme do we follow upstream?
My opinion? Very much. Let's take a real example: Evolution. The netbook UX people wanted to ship a nice mail client for a smaller form factor. Their choices are: * Start from scratch building a nice email client. This is what Nokia did with Tinymail/Modest. * Work from an existing piece of software like Sylpheed or Evolution, and make a netbook variant with the features required. In the latter case, it would be total madness not to work with the maintainers - so that's what Intel & Novell did. The worked on a netbook version of Evolution (in fact two... Evolution Express and the short-lived but promising Anjal) and packaged it to ship with MeeGo when it was ready. Let's say they decided to do this without getting that code upstream as a sub-project. The next time the Evolution project changes its internals for whatever reason, you now have a big development job to bring your variant up to scratch. You'd better have someone on staff working on your Evolution variant full-time to ensure fixes are being made & you're keeping pace with upstream. Now, that's not to say that you can't have situations like this: * February: Bug found in Evolution or EDS, not a release blocker * March: New Evolution version released (with GNOME) * April: Bug is fixed, and code is accepted into Evolution head, and back-ported to stable branch, but not included in a stable release * May: Bug fix, which was already on stable branch, is merged into MeeGo for a stable release * September: Evolution released with bug fix from April So that you have the bug fix from April in MeeGo in May, but not in Evolution for another few months. Synchronising feature requests and patches across distributions and upstream projects has always been hard. Witness the debate over when to include KDE 4.x in distros a few years back, or more recently whether GNOME should depend on GTK+ 3, when the GTK+ team does not have a time based release schedule. Will the next release of the distro have GIMP 2.6 or GIMP 2.8? That depends on whether & when the GIMP releases 2.8, and whether it'll be of a high enough standard for the distro... the only distro I know of that ships upstream code from GNOME without doing integration & regression testing is Foresight, otherwise, Ubuntu has the shortest lag time, and they're 6 weeks after the GNOME release date. And GNOME has never released more than a week after their announced release date. Taking the kernel as an example of a project that does not do time based releases, you can now more or less predict when releases will be coming, give or take a month... so will we be using 2.6.36.* or 2.6.37 in MeeGo 1.2? Arjan can tell you, but I'm sure he will not be planning on including a kernel released after the feature freeze window (when is that, again?). > I don't > think we'd have "usable out of the box" distro like Ubuntu (which is > for me almost a dream come true in terms of what I can offer to peopel > coming from other platforms) if Ubuntu was just 'following' upstream. Ubuntu is a very good integrator. They modify config files, themes, small behaviour changes, ensure that different applications play well together. But they do not do major code changes to upstream projects. Those that they do are either (a) written in Ayatana, which Ubuntu considers upstream (in the same way that Mutter and the MeeGo zone panels are upstream for MeeGo) or (b) submitted upstream. > I know for fact that great measure had been taken to include distro > specific patches until an upstream piece of software is actually > usable or usable for general consumption. Can you give an example, please? > As an example, gnome cups manager lacked support for controlling IPP > printer detection in gnome for a long time. After realizing upstream > is not going to deliver this, I did the GUI part and a core dev did > the backend part and we released this feature to the great > satisfaction of, in this case, corporate users[0]. It seems your pointer [0] is uninitialised... Cheers, Dave. -- Email: [email protected] Jabber: [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
