On Thu, 31 Oct 2013 18:08:25 +0100
Peter Stuge wrote:
> Rich Freeman wrote:
> > If a package has a responsive maintainer, then pinging them isn't
> > really much of a hurdle.
>
> I'm not so sure. Waiting for a human round trip which due merely to
> time zones might occupy my attention for 24 hou
Kent Fredric gmail.com> writes:
> Useflags have their perks for giving variations on behaviour, but having 3
> effective packages in one, governed by useflags, means you'll have 3 much
> more tightly coupled packages, and the code will be much messier with
> useflag conditionals to pull dependenc
On Fri, 2013-11-01 at 16:52 +, Alessandro DE LAURENZIS wrote:
> Kent Fredric gmail.com> writes:
>
> > Useflags have their perks for giving variations on behaviour, but having 3
> > effective packages in one, governed by useflags, means you'll have 3 much
> > more tightly coupled packages, and
On Thu, 31 Oct 2013 23:02:12 +0100
Alessandro DE LAURENZIS wrote:
> I guess this is an already debated topic, but I only found this very
> old thread on the subject:
>
> http://article.gmane.org/gmane.linux.gentoo.devel/4328
>
> which contains the original communication of the ebuild split and s
Tom Wijsman wrote:
> For really severe bugs I think that pinging just anyone who is around
> will do, alternatively you could ping the proxy maintainers herd. In
> both cases there is most of the time someone available; so, it would be
> a matter of minutes to have the patch applied.
You're changi
On Fri, 1 Nov 2013 18:23:48 +
Ciaran McCreesh wrote:
> First, if your Vim breaks due to you upgrading insufficiently-slotted
> libraries (which it will), you're screwed. There's a lot of value in
> having a small vim that doesn't link to things, and a big gvim that
> does.
>
> Secondly, Vim'
Peter Stuge wrote:
> It matters a whole lot if I have to wait for someone else to
> unblock me, in practice that completely demotivates me to
> contribute back, and I would simply work around the block.
To clarify this point; contributing fixes back must always be the
least effort of all ways to i
On Fri, Nov 1, 2013 at 9:53 PM, Peter Stuge wrote:
> Peter Stuge wrote:
>> It matters a whole lot if I have to wait for someone else to
>> unblock me, in practice that completely demotivates me to
>> contribute back, and I would simply work around the block.
>
> To clarify this point; contributing
Alon Bar-Lev wrote:
> >> It matters a whole lot if I have to wait for someone else to
> >> unblock me, in practice that completely demotivates me to
> >> contribute back, and I would simply work around the block.
> >
> > To clarify this point; contributing fixes back must always be the
> > least ef
On Fri, Nov 1, 2013 at 10:06 PM, Peter Stuge wrote:
> Alon Bar-Lev wrote:
>> >> It matters a whole lot if I have to wait for someone else to
>> >> unblock me, in practice that completely demotivates me to
>> >> contribute back, and I would simply work around the block.
>> >
>> > To clarify this po
On Fri, 1 Nov 2013 22:11:38 +0200
Alon Bar-Lev wrote:
> I understand that you want to shorten the time between bug opening and
> commit... but I do not understand what you suggest...
Switching to Git would be a good start.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 1 Nov 2013 20:49:36 +0100
Peter Stuge wrote:
> You're changing the subject. Nobody was talking about really severe
> bugs, and those aren't really the common case.
Nobody has to for them to be an exception worth mentioning.
> Maybe delays don't matter to you, but you can't posit that th
On Fri, 1 Nov 2013 20:53:53 +0100
Peter Stuge wrote:
> To clarify this point; contributing fixes back must always be the
> least effort of all ways to implement the fix in my own system.
> Optimize for the (desired) common case. Anything else pushes
> contributions away.
Version control systems
On Nov 1, 2013, at 5:13 PM, Tom Wijsman wrote:
>> QA has nothing to do with committing, don't confuse Gentoo policy
>> with actual meaning of the terms. Testing, repoman and QA matters
>> are of course part of creating the patch in the first place.
>
> It does, the person whom commits has to do t
On 11/01/2013 05:18 PM, Tom Wijsman wrote:
> On Fri, 1 Nov 2013 20:53:53 +0100
> Peter Stuge wrote:
>
>> To clarify this point; contributing fixes back must always be the
>> least effort of all ways to implement the fix in my own system.
>> Optimize for the (desired) common case. Anything else pu
On 11/01/2013 04:14 PM, Ciaran McCreesh wrote:
> On Fri, 1 Nov 2013 22:11:38 +0200
> Alon Bar-Lev wrote:
>> I understand that you want to shorten the time between bug opening and
>> commit... but I do not understand what you suggest...
>
> Switching to Git would be a good start.
>
The original
On 11/25/2012 02:01 AM, Patrick Lauer wrote:
> On 11/23/12 22:32, Thomas Sachau wrote:
>> Ian Stakenvicius schrieb:
>>> On 22/11/12 11:22 PM, Robin H. Johnson wrote:
On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
> On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
>>
On Fri, 01 Nov 2013 18:05:20 -0400
Richard Yao wrote:
> On 11/01/2013 04:14 PM, Ciaran McCreesh wrote:
> > On Fri, 1 Nov 2013 22:11:38 +0200
> > Alon Bar-Lev wrote:
> >> I understand that you want to shorten the time between bug opening
> >> and commit... but I do not understand what you suggest.
On Fri, 01 Nov 2013 18:02:28 -0400
Richard Yao wrote:
> On 11/01/2013 05:18 PM, Tom Wijsman wrote:
> > On Fri, 1 Nov 2013 20:53:53 +0100
> > Peter Stuge wrote:
> >
> >> To clarify this point; contributing fixes back must always be the
> >> least effort of all ways to implement the fix in my own
19 matches
Mail list logo
