[Sugar-devel] R&D vs Product Support

[Tomeu Vizoso]

On Sun, Jun 20, 2010 at 01:34, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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.

Sorry, I was asking about splitting the "staff". The only similar
resources split in upstream projects I can think of is when you have
someone devoted entirely to a stable branch, for backporting bug
fixes. The rest of the people in the project keep hacking with their
eyes on having their work merged in master.

> 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.

You mean that we have people working on substantial projects and not
publishing their trees? That's bad indeed.

>> 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.

I see, then I agree with James in that we should have some guideline
that prevents this from happening. Or maybe I'm not seeing the
maintainers' POV?

> 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.

Don't see how Record is special in this regard, unless the proposed
patches introduce regressions?

> 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.

But we do have "stabilization branches", what we need are maintainers
for those branches, which I think should be maintained by people
closer to downstreams. Sayamindu and Daniel took maintenance of the
0.84 stable branch because of that.

Regards,

Tomeu