Re: How to write successful patches

>>>>> "JS" == Jan Safranek <jsafrane@redhat.com> writes:

JS> It's my job to maintain net-snmp in Red Hat Enterprise Linux and Fedora
JS> distributions. During this work I fix problems reported by users and I
JS> always try to send my bug fixes and extensions to Net-SNMP patch
JS> tracker. But I am quite disappointed that most of these patches were not
JS> accepted and they did not stimulate any discussion at all.

Jan,

I'd like to apologize for the slowness of our patch application. It's
not your fault, it's ours. We tend to operate in bursts of processing
them and they can sit for a while before being applied. The shouldn't
be, mind you, but that's how it ends up sadly. The reason we like using
the patch database is because it at least prevents us from loosing track
of what we need to examine.

Traditionally I personally tend to process patches closer to release
time. That's not the good way to do it, but it tends to be when I spent
my energy.

JS> In addition, together with IBM (namely c_varun, who did most of the job)
JS> we tried to extend IP-MIB support with latest kernel features. I think
JS> lot of users could benefit from such enhancements. Again, some of the
JS> patches were not accepted and there was no reply and I am curious
JS> why.

I assume when you say "not accepted" you mean that they simply have sat
there without being processed (IE, they weren't marked as invalid or
something else).

JS> I understand I cannot demand that you incorporate all my patches and
JS> you have limited resources, I'd just welcome a short sentence what's
JS> wrong or, preferably :), commit it to SVN if you find them OK.

One of the issues surrounding applying patches is that we have to be
very careful about making sure they don't affect other architectures and
are generally backwards compatible. Patches that affect deep agent
parts (like mib implementations) are the hardest to analyze.

For my personal time-line, I'm about to revamp the release
infrastructure after which I'll start targeting a new release (5.2.6 in
this case). When I do so, I'll certainly look through all the patches
to ensure we've hit all the ones that should apply to the next release.
It'll probably be a week or two before I get to that point though.

Don't stop submitting the patches... And again, I apologize for our
delay in looking at them. It's not your fault, it's ours.

--
Wes Hardaker
Sparta, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders