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

On 22 November 2010 23:37, Wolf Tivy <wtivy1_AT_my.bcit.ca> wrote:
>> 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.

Well summarised Wolf. That's the whole point why I prefer the
wiki-based patch storage, transparency and simplicity. Having a patch
repo for each software we host does sound extreme and might not lead
to patches at all, but rather to big forks and will be less
maintainable (a http get request is a much simpler requirement than
requiring mercurial -- our releases do not require mercurial, and the
patches do not either).

In other words: Downloading a patch file and running the patch command
is preferable for this kind of use case.

But as said earlier: ideally the software does not need to be patched,
which is what we attempt to achieve. People shouldn't waste their time
with patching software, it's the point of the software to do a job
right and to save peoples time for their family ;)

Cheers,
Anselm
Received on Tue Nov 23 2010 - 10:52:36 CET