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

On 23 Nov 2010, at 9:52 am, Anselm R Garbe wrote:

> 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 ;)

I'm probably missing the point, but the words "waste time" just kinda
produced this little script as a response. A few patches are
desirable, after all, such as different layouts for dwm.

#!/bin/sh

for p in *.patch; do
        patch -p1 < "$p" 2>&1 | tee "$p".log
done

--------------------

Makes one logfile per patch. Alternatively, make one logfile:

#!/bin/sh

rm patch.log
for p in *.patch; do
        patch -p1 < "$p" 2>&1 | tee -a patch.log
done

>
> Cheers,
> Anselm
>
Received on Tue Nov 23 2010 - 13:30:25 CET