> I think we should stop creating unwanted complexity. As for all
> suckless software our goal is to create software that works for
> everyone without having tons of configure options and features to
> choose from. For those exceptional cases where people use something
> like dmenu in a modified way the wiki-patch based approach which has
> evolved is perfectly fine imho and enough boundary to discourage going
> the route of highly patched dmenu/dwm/etc versions.
>
> I don't mind if you set up a git repo where each patch from the
> website resides in a separate branch, but I think you just organise
> the existing approach just differently. You don't fix the problem,
> which is having a suitable process to determine the best feature set
> for the software by default. So far the patch based approach was good
> enough to count the downloads and to decide on popularity or necessity
> of some patches to be applied to the mainstream repo at some point.
> And everyone can easily add a patch file to the wiki, apart from
> having a central place for the patch files.
I agree. The the patch + wiki system is good. The difficulty is just right,
and it is very easy to understand. One good thing is that it is not abstract
at all. The hg fork per patch model might be technically better, but it is
more abstract and not as transparent.
Patches can be understood by just reading one. On the other hand DVCS
repos are complex directory structures; much more to think about.
As a practical example, when I make a patch, I find myself removing personal
mods (config.h, config.mk, etc) from the patch so that it only does what I want.
This is possible because patches are so transparent and low level; with repos I
can't do this so I would have to redo the mod on a clean branch, commit,
somehow get it back on the wiki... Too complex.
I don't know what others feel about abstraction, but I personally prefer simple
transparency for this and I think it fits better in the suckless philosophy.
-Wolf
Received on Mon Nov 22 2010 - 23:37:23 CET
This archive was generated by hypermail 2.2.0 : Mon Nov 22 2010 - 23:48:02 CET