| Hi everyone,
first of all thanks for the nice and concise summary of the discussion.
As one of the new commiters (in a first step to basically give back, what Xyrality changed in various projects; but in a controlled matter of course) I'd like to chime in here as well from the discussion we had afterwards.
This is mostly about the part of reviewing stuff; I think in this context, everyone should be invited to review patches in their area of expertise. While the so-often feared "blame" somewhat rests on the person creating the patch and the commiter that pulled it in, I think we can and should move away from blaming faults and work on this as a community. While only committers can pull in the requests, everyone is invited to comment on any pull request and/or issue. If you see something in your area of expertise, it is really appreciated, if you just take a look over the patch and either - comment that this "looks good" to you as well (which can be as simple as posting a "+1" or "looks good to me" in the pull request) - comment that you see an issue with this or that or fear that it might break something in another component - even just comment that you still have your doubts about this or that
In the end being a committer is about confidence in the patch, and the need to establish the proper amount. If you have a pull request with only a patch and no-one commenting on it for weeks, this gets harder. You review the stuff, think "looks good" but then you re-think "do I know enough about the consequences? Is this really good enough? Why is no-one commenting this?". The effort needed to consider a patch good for merging can rise easily to an amount, where a patch never gets merged.
This gets much easier, if you have some supporting data, this can either be in the form of comments such as above, or in the form of tests and especially good documentation about the patch. Basically it comes down to this: I, for example, have no real insight into D2W but: in this small community, if there are 10 people (that might even already be known by name thorough mailings and WOWODCs) that say "looks good to me" or even "yeah, tried it, helps me a lot and works", I would not have big issues, merging this. Being a committer does not always have to be expert work (and it looks like there are few experts left actually knowing the whole system; we're more experts in our specific subsystems), if there's enough feedback from the community itself, it can sometimes almost come down to janitorial work (except for basic quality assurance of course). On the other hand if no-one comments at all for weeks on this and both the request author and the committer are convinced that its okay to merge this, we should probably do that in the end. If something really breaks, we can still fix or revert (worst case) this properly, especially if there's no release scheduled immediately; and everyone had their possibility to protest ;-)
On the subject of breaking or broken stuff as well: Feel free to open issues for that. While "fix it yourself" is obviously the best way to address this, others (and especially the original author) can and should be aware of this and might fix it themselves; we can only address issues, if we know about them.
In the end the "blame" for wonder rests on all of us, may it be broken patches, the staleness of the code base or the success in moving forward. On the ease of doing that: everyone can watch any project (on github on the project page upper right side) to get email notifications, when issues and pull requests are opened. So its actually easy to keep track of these developments and give your opinion about anything in your field of interest/expertise.
Individual strategies are not bad per se, but they often lead to suboptimal situations (redundant resources allocated to solve the same problem).
I'd like to emphasize this, as there is definite evidence for that. One of the patches we did in our local wonder fork (and its not bad to have one per se; there's always an ugly really-applies-only-to-your-usecase-patch in there ;-)) was about skipping migrations for models that are in the skipModels properties and while we were sort of "dragging our feet" with having to clean that up etc., Larry basically created the same patch. So there are no excuses, we all have the same issues now and then :-) So don't be afraid so much to create a pull request. There has been a large consensus that the maintainers of Wonder must be less prudent and conservative about proposed code changes. The first reason for this is that Wonder developer’s community is not composed of teenagers but of professional programmers that have little chances to make very silly / dangerous pull requests. The second reason is that now that Wonder releases are versioned, it is easy for those who are more risk-adverse to work on versions that have proven stable.
Exactly, just as you cannot just throw in a Cayenne 4.0 in your old Cayenne-based project, we all have to be diligent when updating any dependency library. This does not have to be a difficult process, just review the changelog and if there's something applying to your application, test it; wonder is really no exception here. If you depend on some single patch, its still an option to use a private fork and cherry-pick the patches you require (we did this for some patches as well and just merged the next wonder release into our private branch again when it was released and tested. Sooo, lets poke some old issues and pull requests and see, if we can clean up the existing ones and successfully work on new ones :-)
Greetings Dennis
--XYRALITY GmbH • Friedensallee 290 • 22763 HamburgDennis Bliefernicht • Backend DevelopmentMail: email@hiddenTel: +49 (0) 40 35 73 001 - 62Fax: +49 (0) 40 35 73 001 - 99Web: http://www.xyrality.com/Registergericht: Hamburg HRB 115332Geschäftsführer: Sven Ossenbrüggen
|