[Sugar-devel] jhbuild breakage (was Re: Bug tracking Vs Patch review)

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>>
>> Patches were promptly made available in the mailing list and some have
>> already been accepted by Sascha into jhbuild.
>
> Still doesn't work here, neither with jhbuild nor with Fedora packages.
> It's not a mere dependency issue:
>
>  http://bugs.sugarlabs.org/ticket/2269
>  http://bugs.sugarlabs.org/ticket/2270

Are you *sure* you applied the patch in http://bugs.sugarlabs.org/ticket/2228 ?

I have just went through a clean checkout and build of jhbuild on F13
and it just worked (the patch there has bitrotten a bit but the merge
is trivial). If you indeed applied the patch and it's something
system-specific we'll need more information than what is available on
the tickets right now.

If there are other people having trouble with jhbuild right now would
be good if they shared their experiences in this thread.

Thanks,

Tomeu

> A few days ago I was also seeing another error in the logs about a
> missing changed-activity signal, but it seems to have disappeared now.
>
>
>> > Regardless, we proceeded to
>> > release 0.89.5 tarballs that downstreams promptly turned into broken
>> > packages (tested on Fedora).
>>
>> You clearly had different results than me when testing on F14, have
>> you filed bugs or reported them in some place?
>
> What distro did you use? It also fails on Ubuntu and Fedora 13 according
> to other people on #sugar. Did you really hear about this for the first
> time for me?
>
>
>> By the way, this is called integration testing and it happens every
>> cycle in GNOME's jhbuild and again when stuff gets packaged at first
>> in Fedora.
>
> We're not talking about a minor integration glitch. It's broken on 3
> distros (minimum).
>
>
>> The problems found during the integration phase are due to the
>> unexpected effects of putting together for the first time specific
>> versions of hundreds of different dependencies built with specific
>> sets of build options (such as the gnome-keyring issue with
>> mission-control). How did you expected to catch those by reading Sugar
>> patches?
>
> Not by reading patches, but by having the maintainer test that at least
> jhbuild still runs before pushing, or at least before releasing
> tarballs.
>
> But I'm assuming that Sugar is currently broken for everyone, which does
> not seem to be the case at least for you.
>
>
>> > We seem to be missing the equivalent of a "product manager"... someone
>> > who cares for the product as a whole. In a different occasion, Walter
>> > noted the need for an "architect", but in a project like ours these are
>> > very much the same thing, just with an emphasis on the present or on the
>> > future.
>>
>> It would help if you described that role in some details, otherwise
>> can mean too many different things.
>
> This is more or less what I'm thinking of:
>
>  http://en.wikipedia.org/wiki/Product_manager
>
>
> This is common business practice. If you prefer the agile software
> development terminology, we need a "Product Owner" for Sugar.
>
> Walter some time ago called for an Architect, which is something close,
> but with a focus on technical aspects of the product and long-term
> evolution of the codebase.
>
>
>> > We merged a total of 355 patches in sugar over the last 365 months.
>> > Exactly one patch per day. Over the same period, Linus merged 100 times
>> > this number of patches,
>>
>> Looks like you are onto something big here. After you fix Sugar you
>> can go fix GNOME and the rest of FOSS projects, then with 100 times
>> more productivity Microsoft, Apple and Google will disappear in a puff
>> of smoke.
>>
>> > meaning that maintaining Sugar should be
>> > feasible even as a part-time job.
>>
>> And we have how many full-time maintainers?
>
> We have several, no? You, erikos, alsroot... plus several part-time
> ones.
>
> So complaining that we don't have enough maintainers for merging 350
> patches per year is clearly missing the point. The problem we have is
> one of organization, not one one of resources.
>
> The number of new features and bugfixes in Dextrose proves that there
> are abundant resources for Sugar development. We're just blocking them
> from contributing effectively because the processes we have in place
> don't work well.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>