[Sugar-devel] Code Review process changes

[Aleksey Lim]

On Fri, Apr 23, 2010 at 09:37:54AM -0400, Bernie Innocenti wrote:
> On Fri, 2010-04-23 at 15:17 +1000, James Cameron wrote:
> > Activities too?  I've been tracking #1571 for months now, and if posting
> > the patch here will work, I'm all for it.  ;-)
> 
> If you were just asking whether it's ok to post patches for activities
> here, sure: we have no separate mailing list for activities (*).
> 
> If, instead, you were proposing to relax the rules for approving patches
> to activities, I think we should discuss this carefully. Many activities
> would probably be better off with their only maintainer reviewing and
> approving each patch personally. What about the fructose activities?
> What about orphaned activities?
> 
> The question of how to handle the case of an unresponsive maintainer
> came up on #sugar last week: shall we define a formal procedure for
> taking over projects in ASLO and Gitorious? This is how Fedora handles
> it:

In my mind activities on ASLO are not something like packages in regular
GNU/Linux distribution. ASLO is not one centralized product, as already
was mentioned several times it is (or should) palace to share your work
(maybe in trash) with others thus we (will)have bunch of outdated/
forgotten projects. And it is ok for sugar (but not for GNU/Linux
distributions).

And also most of activities come from individuals i.e. it's their
masterpieces. So, lets talking about "forking" not about "taking over".

>   http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_Maintainer_is_absent
> 
> If it seems reasonable, we could adopt the very same procedure for ASLO
> and Gitorious, of course with some obvious changes: s/bugzilla/trac/,
> s/FESco/SLOBs/, s/CVS/Gitorious or ASLO/.

In case of forks we don't need all this bureaucracy by design.
If someone has any idea about improvement in activity, he can:

* fork it in gitorius (no need in asking someone)
* request fork for applying to master (ask only author not mailing
  lists/SLOBs etc)
* if there is no feedback from current maintainer/author, just publish
  forked code as a fork in Activities Library (no need in asking
  someone)

Yes, current ASLO can't handle all these forks in gitorius like scheme
to let users at least see if there are forks of particular activity.
Unfortunately it sounds pretty overkill to implement such features in
ASLO hack (until appears someone who will implement them).

In my mind instead of increasing level of bureaucracy in sugar, for now,
we could ping authors/nd publish forks on ASLO (with new bundle_id) and
start implementing new Activities Library with taking into account all
sugar specific (ASLO in case of AMO is not such, since Mozilla controls
AMO addons and it is mostly centralized repo w/ QA etc).

Also don't read this text like absolute. It is not about deployment
sugar distributions like OLPC, they have their list of stable/buggy
activities and QA team to check them. This post only about having one
repo for activities in gitorius free style. In my mind, ASLO was
intended to be such repo, not list of blessed activities.

I'm working on Activities Library (on early stage). It will look
like:

* server in the person of buddy in F1 view with shared instance of
  Library activity
* any user can join this instance to see what activities are on
  the server
* can just click to launch
* can share new activity or fork of existed
* any user can be such server, he just need to follow regular sugar
  practice, create new instance of Library and share it

Any ideas are welcome
http://wiki.sugarlabs.org/go/Activities/Library#Activity_Library

-- 
Aleksey