Re: [dev] git dmenu mirror with feature branches instead of separate patches

From: Anselm R Garbe <>
Date: Mon, 22 Nov 2010 09:21:46 +0100

On 21 November 2010 21:42, Dieter Plaetinck <> wrote:
> On Sun, 21 Nov 2010 19:56:07 +0000
> Connor Lane Smith <> wrote:
>> On 21 November 2010 19:33,  <> wrote:
>> > Another kinda heretic idea might be to have fairly feature-rich
>> > branches and feature-removing patches. Just thinking loud....
>> Trunk, a branch per patch, a spicy branch, and a plain branch? (Names
>> pending.)
>> Trunk would be mainline dmenu, a stable version to be packaged. The
>> spicy would have every patch merged, I guess for people who just can't
>> be bothered to mess around merging patches. And the plain would have
>> only the essence of what makes dmenu dmenu, for people who want the
>> simplest and smallest version. Read: no flags, no Xinerama.
>> I'm thinking out loud too. :p
>> cls
> I think we should just try it.  We can easily create new branches
> to create new versions, and we'll see soon what works and what doesn't.
> With the right choice of branches we can come up with a situation that
> is relatively easy to maintain, yet flexible and robust enough.

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.

Received on Mon Nov 22 2010 - 09:21:46 CET

This archive was generated by hypermail 2.2.0 : Mon Nov 22 2010 - 09:24:02 CET