On 23 Nov 2010, at 9:52 am, Anselm R Garbe wrote:
On 22 November 2010 23:37, Wolf Tivy 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
choos
On 22 November 2010 23:37, Wolf Tivy 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 p
> 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 wa
2010/11/22 Anselm R Garbe :
>
> 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 featu
On 21 November 2010 21:42, Dieter Plaetinck wrote:
> On Sun, 21 Nov 2010 19:56:07 +
> 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
>>
>>
On Sun, 21 Nov 2010 19:56:07 +
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 branc
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
* Dieter Plaetinck [2010-11-21 17:12]:
> On Sun, 21 Nov 2010 16:30:55 +0100
> v4hn 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 surf-flavour (e.g. vertica
On Sun, 21 Nov 2010 16:30:55 +0100
v4hn 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 keep st
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 keep stuff up to date with master remains.
Yes, there are problem
* Dieter Plaetinck [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
> should at lea
Hey,
On 21 November 2010 12:49, Dieter Plaetinck 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 publish the correspon
12 matches
Mail list logo
