Re: ion3 license

On Tue, 18 Dec 2007 10:35:47 -0000, Tuomo Valkonen <[email protected]> wrote:

>> Probably not until they have aproblem,
> You're too optimist.
You're too cynical...

>> No - The fix , as with all fixes, should be applied in the fewest number
>> of places.
> No, the fix should be at the root of the problem.
i.e. your licence?
Seriously, the right place to put a "don't cry if you aren't bleeding  
edge" message is in the code - nowhere else will do the job nearly as well.

>> No - they just wouldn't bother.  Package maintainers aren't out to screw
>> you - they are out to make others lives easier
>
> Bullshit. They e.g. include patches and modules I will not have anything
> to do with
Are you talking about Xinerama support here? - the mod which works fine,  
doesn't cause probles on non Xineramra desktops but you have some bizarre  
notion is amoral on some grounds I've never quite grasped?

>> Most development should be cathedral style, with a bazzar as "unstable".
> The distros take the bazaar unstable snapshots of software, and  
> fraudulently provide them as "stable" in their megafrozen cathedrals.
Not in my experience with ion on various distros, obscure bugs will always  
exist - and unless you provide stable branches what is a maintainer meant  
to to? The path of least resistance is to take the latest release and test  
it for a while, then release it if it's stable on their box(es).  As you  
don't maintain a "stable" branch they can't rely on you to fix a bug  
without introducing more in line with some shiny new feature that you're  
preparing for.
So the correct solution here is for you to maintain two branches - Stable  
and devel. Fix bugs in stable and make a new stable branch every so often  
when there is a feature set you're happy to release (and consider feature  
complete and stable). Then abandon the old stable.
How hard can a single integrate be when a bug is found? Then the cathedral  
engineers can be confident in what they are using, and you get a limited  
set of code to support, which was your original complaint IIRC.

>> My work machine must "just work"(TM) I don't have time to fiddle with it
> The distros don't deliver.
Then try another one - I haven't had any problems recently.

> FOSS doesn't deliver. I don't have the time
> to fix fonts on every upgrade, and yet FOSS keeps becoming more and more
> AA/XML-fascist. I don't have the time for configuring udev brain damage
> to my needs. And I don't have the time to compile software when distros
> provide old and broken versions, instead of recent ones.
I really don't know what your problem is with AA or udev: Correctly done  
AA actually helps text (although it's not always available), udev doesn't  
exactly kick up a stink.  My machine "just works" (TM).
I only check the version of running software when I'm looking for a  
particular feature, or about to go and search online docs / ask for advice.

>> Yes - because "The Party" is the best placed to package them in a
>> consistent manner for their users.
> And this purported "consistency" comes at an expense of forming a few
> powerful central parties that oppress authors
Ah - you're feeling opressed.  Then again you seem to feel victimised by  
most walks of life if your blog is anything to go by. I think that's  
mostly how you view the world.

>> >I've had enough of the FOSS herd, and how it's destroying everything I
>> >once thought could be great. I really am universes distant from them.
>> Not really, you just regard yourself as the "one true way".
> If flexible dynamically extensible and non-monoculturist software is
> the "one true way", then so be it. For the FOSS herd, Party control,
> huge monoliths, anti-aliasing, udev, UTF-8, WIMP, etc. are the one
> true way.
non-monoculturist? So you'll support xinerama, anti aliasing, udev now  
will you? Rather than declaring them all to be anti-tuomo.


>> I'd also love to see a WM that encouragees it's users to contribute  
>> back,
> Ion is modular. But the moronic FOSS herd does not like modular code:
> it wants the original author to maintain their shoddy patches that he
> does not care about. That is, once again they want the authors to be
> their slave, just like the distros do.
So you're unable to take a shoddy patch and apply the correct fix to your  
own code? That seems pretty feeble


-- 
John Robson