[Sugar-devel] review process follow-up.

[Tomeu Vizoso]

On Tue, May 25, 2010 at 17:48, David Farning <dfarning at gmail.com> wrote:
> On Tue, May 25, 2010 at 9:34 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>> Hi David,
>>
>> thanks a lot for putting some new energy on this discussion, there's
>> certainly more opportunities for us in revising this process.
>
> Certainly, and I will do my best to insure that the process revision
> is driven by an increase in useful patches which need to processed

And I will be happy to read the reviews from the submitters ;)

>> For background, Bernie and me talked on the phone last week and it
>> helped a lot in aligning our positions on this. When we get the
>> community team up and running I will propose that when a discussion
>> gets a bit too heated, that someone proposes the interested parties to
>> have a conf call.
>>
>> On Tue, May 25, 2010 at 16:00, David Farning <dfarning at gmail.com> wrote:
>>> I would like to invite input on the new process that Tomeu and Bernie
>>> have been developing.  I am specifically interested in see how Sugar
>>> Labs, OLPC, and third parties such as Activity Central can work
>>> together most effectively.
>>>
>>> Admittedly we are causing a disruption, hopefully one which will cause
>>> a net improvement.
>>> 1.  Value and review of patches.  The task we are doing are directly
>>> driven by deployments.  As such we need to deal with version issues.
>>> Most of the deployments are using and will continue to use .82/4 for
>>> the near future.  Paraguay is leading a push to stabilize on .88 by
>>> August of 2010.
>>>
>>> One of the mantras of Activity Central is upstream. We don't have our
>>> own mailing lists or bug trackers.  This begs the question of dealing
>>> with versions.  I am encouraging, but not requiring, that patches fix
>>> the issue for the version of sugar the customer uses plus the current
>>> develop version if applicable.
>>
>> About the specific issue of stable branches, my recommendation is that
>> they are maintained by someone a bit closer to downstreams and that
>> there's a strong requirement for only pushing backported bugfixes and,
>> occasionally, features.
>
> Yes, I am not asking of expecting Sugar Labs to carry they burden of
> backporting.  That is role is often played by a downstream
> distributor.

Well, but if a stable version is deployed by more than one entity,
they will have to work together, and isn't the main purpose of SLs to
provide a place where people interested in Sugar can work together?

Of course, resources will have to come from downstreams, but they will
be doing upstream work when they maintain a stable branch.

>>> 2. Maintainer-ship.  To avoid possible conflicts of interest, ie
>>> ramming ideas down the communitie's throat, I have avoided directly
>>> engaging key developers, comitters, and maintainer.  For this to work
>>> we must gain credibility as useful participants.  If and only if is
>>> acceptable to the current development team, I would like to make an
>>> effort to increase the number of activities maintained by Activity
>>> Central.
>>
>> Hmm, I'm not sure this decision belongs to the development team. What
>> if AC starts by taking a couple of the several orphaned activities
>> that are seeing more requests and we see how it works?
>
> The tricky thing here is that as a company, we are only interested in
> a few high value activities.  So this is a place where crowding out
> _can_ occur if we are not careful.

Sure, but may not be a problem right now if a downstream takes
maintenance of 2 orphaned activities. And it could help us understand
better how we want to work in the future.

>> In a couple of
>> months we should have the community and deployment teams running,
>> which could be more appropriate forums to discuss this.
>
> I support the idea of a stronger emphasis on community engagement via
> a community team.
>
> I am a bit more hesitant about a deployment team.  The needs of
> deployments are very specific and hard for a upstream community to
> effectively meet.  Rather than working top down, it might be more
> effective to work bottom up by focusing on helping projects like
> ceibaljam and Ole Nepal push their deployments driven innovations
> upstream.

Yes, this is how things would work ideally. And if it had worked that
way, we would have had release managers, a QA team, our modules would
be maintained, our teams would have coordinators with lively meetings,
and a long etc.

We have the same problem in GNOME and I cannot but suggest that
upstreams shouldn't expect for their downstreams to behave as they
should without some doing some serious and sustained talking.

Also, I don't think that having a place in SLs where downstreams talk
together about Sugar needs to mean that SLs will control them. SLs is
nothing without downstreams and if today's SLs is given shape by
people not affiliated to any downstream is because downstreams have
been slow to join. But it's not the normal state of an upstream.

I personally don't care if downstreams talk instead about Sugar in a
mailing list in laptop.org, in groups.google.com or anywhere else, but
I want them to stop doing redundant work, waiting for others to do
something that nobody ends up doing, and stop waiting for SLs to do
what they need without having to even talk about it.

I know there are several people working in finding ways for resources
to reach upstream right now, but I find quite scary that SLs is seen
as a group with a strong identity that intends to control users of
Sugar. It is supposed to be a _place_ where people work together on
Sugar, with its shape given by those people (downstreams). If SLs is
seen as a partner, provider or donor, we have an image problem.

Regards,

Tomeu

> david
>
>> We still need to see how we can improve the process so that code gets
>> in faster and new contributors find a more dynamic community, will be
>> proposing a few ideas in a bit.
>>
>> Regards,
>>
>> Tomeu
>>
>>> david
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>