[Sugar-devel] review process follow-up.
tomeu at tomeuvizoso.net
Tue May 25 10:34:58 EDT 2010
thanks a lot for putting some new energy on this discussion, there's
certainly more opportunities for us in revising this process.
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,
> 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
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? In a couple of
months we should have the community and deployment teams running,
which could be more appropriate forums to discuss this.
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.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel