[Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)

[Tomeu Vizoso]

On Sun, Aug 8, 2010 at 02:20, Marco Pesenti Gritti <marco at marcopg.org> wrote:
> On 6 Aug 2010, at 13:35, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>
> I was just throwing in the idea here. I will bother you further only
>
> once I have a realistic plan in mind (and confidence in the ability to
>
> execute it with our limited resources) :)
>
> Sorry if I sounded harsh, I wanted to explain why some "reforms" are
> not going forward yet even if people agree are necessary.
>
>
> Oh, no worries, I don't think you sounded harsh at all.
>
> That's actually the other thing I'm planning to look into. Maybe I'm
>
> mistake but I feel we are stuck with a review process most of the
>
> existing contributors are unhappy with. I can work on a formal
>
> proposal and try to reach consensus, if that's what is missing...
>
> Sounds great, though I have felt that there was a bit of misdirected
> frustration during that conversation.
>
>
> As in the real problem not being the process but the slow response due to
> the lack of maintainers?

The real problem being that contributing to FOSS can be very
frustrating if you are not an expert already and there isn't a big
effort in place to support new contributors. Maintainers are in a very
good position to help new contributors but that doesn't mean that
nobody else can do something about it.

See for example the recent trend on sending patches to the mailing
list for reviews and comments, then submitting for acceptance. It
should have improved a lot the experience for new contributors and we
didn't had to wait for any maintainer to do anything.

Similarly, if creating trac tickets is so hard for a significant
segment of our contributors, then we can create simplified forms or
establish some sort of aggregator that submits those reports aftert
some consolidation, translation and triaging, as is being discussed in
another thread.

If putting patches in a queue is too much of a hassle, we could have
the figure of the Patch Manager, or write a tool similar to git-bz.

http://producingoss.com/en/producingoss.html#patch-manager
http://git.fishsoup.net/man/git-bz.html (it's python and git, we just
need to replace bugzilla with trac)

If having the queue in trac is too obscure because making a query is
hard, we could make the automated report you wrote to point to
bugs.sugarlabs.org and this mailing list.

http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/report.py#line12

But there are apparently no resources to do any of this, so we turn to
discuss about the process in the hope that we find one that allows us
to do more without having to work more.

> If distros drop a platform dependency in the same release where the
> replacement lands (what happens with gnome-python2-desktop in Fedora
> 14), it means that everybody needs to build that dependency until they
> update to that release.
>
> Moreover, if some distros only include the new dependency at a later
> release (as with Ubuntu Maverick and Gtk3), contributors running one
> of those distros need to build more stuff for longer.
>
> My feeling is that these are a bit of special situations due to the dynamic
> bindings migration and gtk 3, I don't see they happening normally. Also it
> seems like they will hurt in the same way when we actually get to package
> Sugar on these distributions.

Agreed, but if we keep Sugar aligned with the GNOME platform, then we
need to worry mostly about these transition phases.

> We can reduce the harm by keeping PPA-like repos for the distros that
> need it (what the telepathy guys do for Ubuntu), but then someone
> needs to do that work.
>
> I wouldn't spend resources on this, it's error prone and time consuming.
>
> In summary, I'm able to see the importance of making as easy as
> possible running latest sugar on all distros, but I'm afraid it's one
> more goal we want to attain but don't know how to resource.
>
> To be clear, my goal is not to support all distro. I think it would be
> reasonable to say that you need the latest Fedora/Debian/Ubuntu to be able
> to build Sugar without messing with dependencies.
> I think there is a bit of a chicken and egg problem here. Making it easy to
> start developing Sugar is probably one of the best ways to increase the
> resources we can spend on user visible improvements.

I'm afraid for the next 2-3 release cycles Fedora is going to force us
to make some changes in our dependencies that will make that more
difficult on Debian and Ubuntu.

Regards,

Tomeu

> Marco
>