expectations from the community

Andrey Somov py4fun at gmail.com
Tue Feb 7 04:15:33 CST 2012


On Tue, Feb 7, 2012 at 10:46 AM, Patrick Mézard <patrick at mezard.eu> wrote:

>
> Can you be more specific? Are you talking about this patch:
>
>  [PATCH hglib] merge and resolve return boolean instead of raising an
> exception
>  http://selenic.com/pipermail/mercurial-devel/2012-January/037664.html
>
> which Idan commented afterwards?
>

 It is not the only one.  I totally agree with the review, but the question
is general: why does anyone spend time on a review if it would be quicker
and more efficient just to change it and apply to the code base ?


> So yes, when correct looking patches (commented code, good indentation,
> not kludgy) lands on mercurial-devel, they are considered as regular
> submission and their author are assumed to be OK to be motioned through the
> review process. If it is not your intent, which is perfectly fine, please
> make it clear and possibly open an issue in the bug tracker, and paste your
> diff there as a fix suggestion. But in this case, you explicitely give up
> on attribution, at least that is the way I see it.
>
> --
> Patrick Mézard
>

This is my question !!! HOW should I make it clear ??? Does the patchbomb
extension provide such an option ?
(I did not even know that some kind of  'attribution' is involved...)

>The BTS is not a patch submission channel. But my understanding is your
patch is more about describing the >problem, analyzing the issue. The BTS
sounds like a good place for this.

I did not quite catch you. Do you mean that the wiki shall say instead: "We
do appreciate patches on the BTS" ?

(By the way what BTS stands for ? I could find any explanation...)

If the way to report a problem is unclear and/or complex then I would
rather stop reporting. I am afraid I will not be the only one...

-
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120207/3c9f4c74/attachment.html>


More information about the Mercurial-devel mailing list