[ubuntu-art] Hacking / Kludging - WAS

[Steph]

Kido wrote :

> >
> >  It certainly isn't optimal, and I am well aware of the shortcomings.
> >  The point isn't to kludge / hack _everything_, but do it where it is
> >  required to achieve an innovation.  Animated progressbars might be an
> >  example here.
>
> Animated progressbars are already an option in clearlooks and murrine,
> afaik.
>
> >  Our track record for doing things _before_ other competing operating
> >  systems do something is not exactly stellar.
> >
> >  Putting in a kludge / hack accomplishes two things:
> >
> >  1) It clearly demonstrates the shortcoming in the current code set.
> >  2) Puts a little more pressure on the architecture to evolve
> _properly_.
> >
> >  Heck.  If it weren't for the kludges and hacks here and there, with the
> >  respective sarcastic comments in the code, where would FOSS be at all?
> >
>
> Instead of putting in the hack, you could file a bug. Yeah, the devs
> are reluctant to add new stuff (especially in the Gnome side of things
> :P), but a good case can make its way into good implementation.
>
> >  Sincerely,
> >  TJS
> >
> OT: How do I get my ubuntu-art mail in single-message form rather than
> in digest form? ^_^'
>
> I'm actually starting to see your point. :)
>
> ^kd



Well, a bug is not as "active" as a hack in the code. If you really want to
publish some clean codes, then you've got to check out all those hacks, and
see what can be implemented, or not, until next release. Filling bugs is a
good idea, but I think developpers won't care as if it was a hack.
Furthermore, a hack is already thought to be implemented : it's already some
code.

Cheers,

Steph.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-art/attachments/20080306/867c667f/attachment.htm