On 22 November 2010 23:37, Wolf Tivy wti...@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
On 23 Nov 2010, at 9:52 am, Anselm R Garbe wrote:
On 22 November 2010 23:37, Wolf Tivy wti...@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
On 21 November 2010 21:42, Dieter Plaetinck die...@plaetinck.be wrote:
On Sun, 21 Nov 2010 19:56:07 +
Connor Lane Smith c...@lubutu.com wrote:
On 21 November 2010 19:33, sta...@cs.tu-berlin.de wrote:
Another kinda heretic idea might be to have fairly feature-rich
branches and
2010/11/22 Anselm R Garbe garb...@gmail.com:
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
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
Hi,
I'm not sure if this is a good idea or not, but at least it's an
interesting experiment.
For the following reasons...
- It's easier to maintain and update separate versions/features using
vcs branches rather then separate patch files. (unless all the
patches posted are generated by vcs
Hey,
On 21 November 2010 12:49, Dieter Plaetinck die...@plaetinck.be wrote:
It's easier to maintain and update separate versions/features using
vcs branches rather then separate patch files. (unless all the
patches posted are generated by vcs systems, but in that case we
should at least
* Dieter Plaetinck die...@plaetinck.be [2010-11-21 13:50]:
For the following reasons...
- It's easier to maintain and update separate versions/features using
vcs branches rather then separate patch files. (unless all the
patches posted are generated by vcs systems, but in that case we
On Sun, 21 Nov 2010 16:30:55 +0100
v4hn m...@v4hn.de wrote:
On Sun, Nov 21, 2010 at 04:14:26PM +0100, sta...@cs.tu-berlin.de
wrote:
Often, issues arise when applying multiple patches. The prposal
doesn't solve this, does it? For single features -- sure, it's
beneficial, but the work to
* Dieter Plaetinck die...@plaetinck.be [2010-11-21 17:12]:
On Sun, 21 Nov 2010 16:30:55 +0100
v4hn m...@v4hn.de wrote:
On Sun, Nov 21, 2010 at 04:14:26PM +0100, sta...@cs.tu-berlin.de
wrote:
Set of branches based on multiple patches, representing different
dmenu flavours -- like
On 21 November 2010 19:33, sta...@cs.tu-berlin.de 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,
On Sun, 21 Nov 2010 19:56:07 +
Connor Lane Smith c...@lubutu.com wrote:
On 21 November 2010 19:33, sta...@cs.tu-berlin.de 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
12 matches
Mail list logo
