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

[Art Hunkins]

Once you discover *where* to go to file a bug report, it is rather easy to 
file one IMO.

My observation is that the filing procedure is somewhat hidden in arcane 
terminology. Less technically astute persons of interest such as myself can 
get lost and discouraged when the path is not made plain - and as direct as 
possible.

Art Hunkins

----- Original Message ----- 
From: "Tomeu Vizoso" <tomeu at sugarlabs.org>
To: "Marco Pesenti Gritti" <marco at marcopg.org>
Cc: <sugar-devel at lists.sugarlabs.org>; "James Cameron" <quozl at laptop.org>
Sent: Monday, August 09, 2010 4:16 AM
Subject: Re: [Sugar-devel] Adding committers on gitorious (was: Re: 
[PATCH]Remove nbsp chars from the html string before parsing)


> 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
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel