You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nutch.apache.org by Marcin Okraszewski <ok...@o2.pl> on 2007/08/08 21:30:27 UTC

Is there any chance that my patches will be considered?

Hello Nutch Developers,
On May 22 I have contributed two patches - NUTCH-487 and NUTCH-490. The next release is probably coming soon. I would be really pleased if they are merged by then I don't have to patch it. Is there any chance they will be merged into source code? I can port them to current head, but so far nobody asked for this. 

I would also like to point your attention to one point. It is already two and half month since I have added the patches. There is not even a single comment on this. This is really discouraging for me, as a contributor. I know that merging patches is not the thing that developers love to do, but you are the only one who can do it. Of course I don't mean you should thank to every contribution, but take it into account. Having someone's work being ignored, and it looks like this for me, really discourages from further work. Reviewing it and saying you won't merge it because something would be much better than leaving it without a single comment. This may reduce your active community.

Think of this.

Best regards,
Marcin Okraszewski

Re: Re: Is there any chance that my patches will be considered?

Posted by Doğacan Güney <do...@gmail.com>.
On 8/8/07, Marcin Okraszewski <ok...@o2.pl> wrote:
> Thanks for a quick answer.
>
> > As for NUTCH-490, I haven't taken an in-depth look at it, but I don't
> > see the point of it. Why not just use HtmlParseFilters since you have
> > access to the DOM object? What advantage do neko filters have? Also,
> > having an extension point for a library possibly used by a possibly
> > used plugin looks really really wrong from a design point.
>
> In my case I want to achieve two things:
> 1. Ensure there is always TBODY element.
> 2. Drop all SELECT elements (I don't want it to be in
>
> You are right, I could manipulate DOM for this. But filters seems to be less costly operation, this is why I took this approach first. Though I haven't done any tests - maybe I'm too concerned and it doesn't matter that much.
>
> Or possibly my suggestion to make extension point for parser is the best one? Then if you want to modify parsing itself, you can do whatever you want. Then you also wouldn't need any switch for parsing implementation as it is now. Simply modify plugin inclusion. I could do it, if you find it a good idea.
>
> Anyway, as I said, even if you find it all as not having much sense, just close the issue with this comment. I really prefer it over hanging request, because I know I should rather think of different solution for my case.

I would never close an issue such as yours (one that proposes an
improvement and has a patch) just because I disagree (and I don't
disagree with your issue, I just don't see the point of it) with it.
Others (other committers and users) may find it useful. So I think it
makes sense to assume that if an issue (proposing an improvement) has
not generated any comments, people who have looked at it were
indifferent to it (they neither wanted the feature nor objected it
strongly). Such issues are left lying around in case someone looks at
them and makes a strong enough case for them to go in. And that
someone may be you. I think it helps when people proposing
improvements also explain their use cases and rationale.

I generally try to check and comment on issues tracking bugs but I am
sure there are some that I have missed.

>
> Thanks,
> Marcin Okraszewski
>


-- 
Doğacan Güney

Re: Re: Is there any chance that my patches will be considered?

Posted by Marcin Okraszewski <ok...@o2.pl>.
Thanks for a quick answer.

> As for NUTCH-490, I haven't taken an in-depth look at it, but I don't
> see the point of it. Why not just use HtmlParseFilters since you have
> access to the DOM object? What advantage do neko filters have? Also,
> having an extension point for a library possibly used by a possibly
> used plugin looks really really wrong from a design point.

In my case I want to achieve two things:
1. Ensure there is always TBODY element.
2. Drop all SELECT elements (I don't want it to be in 

You are right, I could manipulate DOM for this. But filters seems to be less costly operation, this is why I took this approach first. Though I haven't done any tests - maybe I'm too concerned and it doesn't matter that much.

Or possibly my suggestion to make extension point for parser is the best one? Then if you want to modify parsing itself, you can do whatever you want. Then you also wouldn't need any switch for parsing implementation as it is now. Simply modify plugin inclusion. I could do it, if you find it a good idea.

Anyway, as I said, even if you find it all as not having much sense, just close the issue with this comment. I really prefer it over hanging request, because I know I should rather think of different solution for my case.

Thanks,
Marcin Okraszewski

Re: Is there any chance that my patches will be considered?

Posted by Doğacan Güney <do...@gmail.com>.
On 8/8/07, Marcin Okraszewski <ok...@o2.pl> wrote:
> Hello Nutch Developers,
> On May 22 I have contributed two patches - NUTCH-487 and NUTCH-490. The next release is probably coming soon. I would be really pleased if they are merged by then I don't have to patch it. Is there any chance they will be merged into source code? I can port them to current head, but so far nobody asked for this.

NUTCH-487 is mostly a duplicate of NUTCH-369. I merged patches from
both issues in NUTCH-25 since NUTCH-25 needs those patches to work
correctly (and I gave you and Renaud Richardet credit in comments).

As for NUTCH-490, I haven't taken an in-depth look at it, but I don't
see the point of it. Why not just use HtmlParseFilters since you have
access to the DOM object? What advantage do neko filters have? Also,
having an extension point for a library possibly used by a possibly
used plugin looks really really wrong from a design point.

>
> I would also like to point your attention to one point. It is already two and half month since I have added the patches. There is not even a single comment on this. This is really discouraging for me, as a contributor. I know that merging patches is not the thing that developers love to do, but you are the only one who can do it. Of course I don't mean you should thank to every contribution, but take it into account. Having someone's work being ignored, and it looks like this for me, really discourages from further work. Reviewing it and saying you won't merge it because something would be much better than leaving it without a single comment. This may reduce your active community.
>
> Think of this.
>
> Best regards,
> Marcin Okraszewski
>


-- 
Doğacan Güney