On 27/01/17 17:58, Selva Nair wrote: > > On Fri, Jan 27, 2017 at 10:08 AM, David Sommerseth > <open...@sf.lists.topphemmelig.net > <mailto:open...@sf.lists.topphemmelig.net>> wrote: > > On 27/01/17 14:56, Илья Шипицин wrote: > > > > > > > may I ask you something in turn ? > > I cannot read other people thoughts, if there's something wrong with my > > patch, there's no other known way, but your reply. > > > > since, you are keeping silence, I've no idea whether is it wrong or not. > > It would be really nice if you will tell "that and that is wrong". I'm > > sure, there are sites about git, where it is written. > > Fair point, and this is a very common issue in most open source > projects. We are not necessarily ignoring you just for the fun of it. > But we do look through a lot of patches, and need to prioritise them. > For example: Patches which fixes real issues in released OpenVPN > versions naturally gets a higher priority than a patch fixing a man > page. > > > That is hardly true. I am not complaining, but just pointing out some > reality that can't be helped. > > We have a dozen man page or similar level improvements since 2.4.0 > though at least one critical bug fix I submitted is still awaiting > review. This has to be expected as it takes the right person and quality > time to get certain things reviewed. Sometimes trivialities like the > non-exiting inefficiency (save a microsecond once an hour?) of carrying > around [[INLINE]] tag may get multiple reviews, but a bug fix may wait > for ever and even lost under the pile. > > It all depends what catches our fancy, personal interest, expertise and > mood. No point in trying to rationalize it beyond that.
Also a fair point, Selva. I did generalize way too much. But I do not completely agree with you. I can't speak for the others, but I do actually scan the list for patches where I have knowledge and look for critical/important issues first. If there are patches outside my knowledge, I can definitely process the "lower hanging fruits" first if their in my field of expertise, to get them done. If I have some spare time, I often do look at stuff outside my "comfort zone" as well, but that usually can take quite a bit longer time as I need to completely understand the issue and implementation. And it's not too uncommon that some others actually manage to send the ACK/NAK before I complete my look at it. *And* towards the end of the 2.4.0 release cycle, it was a deliberate choice to not bring in any code changes unless absolutely needed. But we did pull in several documentation patches which would not jeopardize the release. Yes, we let known bugs pass - we evaluated these known issues and patches, considered the risks and decided that several of them should go into 2.4.1, to be sure 2.4.0 would be as stable as possible. Basically better to have a few known issues than adding more code which could make things even worse. That is a hard and tough decision to take, and it often doesn't look pretty to those not involved in those discussions. This may very well also have skewed the impression of the normal working approach we try to have. But I do understand and accept that from an outsiders point of view, seeing all reviewers as a single instance, it may very well be experienced very differently. But we're not a single unit. We're a handful persons with very different set of skills, working somewhat unsynchronized in parallel - mostly trying to prioritize the important things first, within our own scope of skills. The unified end result of that can indeed look much more like a bag filled of random patches. The fact is that there are quite few on this list who dare to ACK/NAK patches. If more had just done that, things could flow quicker into the git trees. Luckily the list of those giving ACK/NACK is growing slightly, but there is still too much on our list of open issues to manage everything in a timely and appropriate manner. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
