Hi Russell,
Russell Keith-Magee wrote:
> ...
> Obviously, simple changes are no brainers. However, if a patch is a
> deep change, I (as a developer) need to be convinced:
> 1) That the problem actually exists
> 2) That the proposed fix is the right approach to solve the problem
> (e.g., there are
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > Submitting a patch without tests is almost _exactly_ the _worst_ thing
> > you can do if you want your patch to be committed.
>
> When I submit a patch, I'd really like to see some serious
> interest from the
On 9/14/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> Michael Radziej wrote:
> > I'd appreciate if we could find a
> > way to state what kind of patches are interesting for the
> > committers and what not *before* the patch is created fully. This
> > is of course more important for large patches
Michael Radziej wrote:
> I'd appreciate if we could find a
> way to state what kind of patches are interesting for the
> committers and what not *before* the patch is created fully. This
> is of course more important for large patches.
I think this is the core of my underlying concerns of how t
On 9/13/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I understood the critics completely different. It's not about the
> committers not keeping on top, it's that there are not enough
> committers. Which is not easy to solve, as discussed before, and
> probably multiple times. And, I really app
Russell Keith-Magee wrote:
> On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
>>> Some tests for
>>> your patch wouldn't go amiss, though I realise it's a pain writing
>>> tests for code when you don't know if it's going to be used.
>> Unfortunately, I don't think I'll be able to find the time to wr
