[Sugar-devel] R&D vs Product Support

[Bernie Innocenti]

El Fri, 18-06-2010 a las 11:29 +0200, Tomeu Vizoso escribió:

> > Long term, both approaches are essential to the evolution of a project.
> > Some large hi-tech companies I worked for in my previous life solved the
> > conflict of approaches by splitting their engineering staff into two
> > departments: R&D lab and Design/Engineering office.
> 
> Do you have an example of a FOSS community that has done such a split?

The linux kernel folks do it a lot. besides the topic trees (linux-arm,
linux-acpi) vendor trees (like the fedora kernel) and integration trees
(linux-next, linux-mm), there are also a number of popular trees for
experimental work. One that's often covered in LWN is linux-rt, which
initially focused on real-time support, but later became the home of
other large-scale efforts to refactor the kernel.

We use the same tools of the linux kernel folks. What we're missing, I
think, is the culture of creating friendly forks.


> I'm also concerned about this, but frankly, if we haven't learned yet
> to discuss things in a productive way, no project reorganization will
> save us.
> 
> I see people worried about their work not being upstreamed because it
> doesn't match the maintainer criteria. This is about the most common
> conflict in FOSS communities and we really need to get better at
> handling it.
> 
> Downstreams and upstreams need first to, for every case, define
> together the problem space so we are all discussing the same thing.
> Often the maintainer would accept a change if she knew the whole story
> behind it, but that information is not passed upstream.
> 
> Sometimes, the maintainer will be mistaken (surprise!), and though I
> don't think we should override her prerogative about what gets in and
> what not, the submitter could try to gather some consensus from the
> community so the maintainer can reconsider her decision with more
> information.
> 
> But right now, there are some conflicts going on that haven't even
> been explained in the mailing list.
> 
> And one more thing: not EVERYTHING needs to be upstreamed, we should
> use common sense to decide what really needs to and what doesn't need
> to.

The natural contributor-maintainer interactions that you describe are
not the particular scenarios I was worried about.

In some cases, we see patches rejected not because the approach is
inherently wrong, but because the patch applies to the current code in
git and not to a future rewrite or that does not yet exist.

The journal and datastore are two such cases.

Record makes a case apart, in which the existing code is kludgy and
broken on anything but the XO screen with Sugar 0.84, the proposed patch
fixes the issue by introducing even more kludges, and nobody seems to
have the rewrite the UI in the proper way. Hence, Record remains broken.

If we don't want bugfixes and small urgent features to lower the quality
of mainline repositories, perhaps we should think of creating separate
stabilization branches. The worst possible scenario is the current one,
in which important patches remain relatively inside custom distro
packages.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/