[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vancouver revisited

Wouter Verhelst <wouter@grep.be> writes:

> On Tue, Aug 23, 2005 at 12:04:11AM +0200, Peter 'p2' De Schrijver wrote:
>> On Tue, Aug 23, 2005 at 12:00:07AM +0200, Wouter Verhelst wrote:
>> > On Mon, Aug 22, 2005 at 01:53:37PM +0200, Peter 'p2' De Schrijver wrote:
>> > > > Claiming "nobody sane will ever use that" means someone who's actually
>> > > > interested in using said software, even if it's slow is left out in the
>> > > > cold. That's silly.
>> > > 
>> > > The user can always ask to build it or provide resources to build it.
>> > 
>> > Rotfl.
>> > 
>> > Imagine:
>> > 
>> > You have one m68k machine, and want to use it as a lightweight browsing
>> > machine (yes, some people do that). To have a browser, however, you'll
>> > need to let it run for >24 hours because the browser isn't compiled...
>> > and then you end up with mozilla, but you prefer a lightweight browser,
>> > such as galeon. Add another bunch of hours.
>> Galeon is by no means a lightweight browser. If you want a lightweight
>> browser look at dillo or the GPE mini browser.
> Whatever.
> The point is that not compiling software because it takes too long is
> not a solution; all you do is to move the problem from the developer to
> the user, and you add some on top of that. Not very nice.

The point is that not compiling software because it takes long is not
a solution.

If the software does take _too_ long then the arch is in trouble. Too
long must be read as so long it never finishes before the next upload
(or before a urgency=low upload goes into testing). On the other hand,
architectures where packages do take that long tend to have so much
redundancy in the buildds that one buildd blocked does not matter in
the overall picture.

I would think that a weekly mozilla/galeon cvs snapshot upload could
fall into the 'too long' category. The usefullness of such a package
on m68k would be 0 since by the time it gets uploaded the architecture
independent packages are already on the next version.

But that line must be drawn very carefully.


Reply to: