Re: WOWODC 2015 talk about the state of Wonder
I think it worked great when we had the integration branch. People would do a pull request for that branch, committers did a quick look and if it was clean, it was committed. After a couple of weeks, the commits from integration were merged in master. Problem is: people started using the integration branch as their default branch, and complained that commits broke their production apps. Well, that was not the point of the integration branch. And sadly, someone decided that the integration branch should be gone, a decision that I dislike even after two years. We do need to be extra careful about some commits, especially anything that touch the databases plugin. Having unit tests for the plugins would be really useful. > Le 2015-04-28 à 16:41, Jean Pierre Malrieu a écrit : > > Hi all, > At the end of WOWODC 2015, there has been a discussion about the current > state of Wonder and it’s future. I try below to summarize this discussion, > but I did not take notes, and this is what I remembered from it, so this is > by no means an « official » or comprehensive summary. Please feel free to add > elements and correct me if my report is biased. > > An observation that can easily be made, and by which the discussion started, > is that Wonder is in a stale state. There are less and less pull requests, > and even fewer commits. According to the participants, there are several > reasons for this. The first one is that some of the most active, talented > contributors are either no longer doing WebObjects development, or are > working for/at Apple and can no longer contribute. The second reason might be > that some contributors have been disappointed by the fact that their pull > requests have been ignored (neither reviewed nor committed), perhaps due to > lack of time / knowledge from committers. The third reason, which has been > strongly emphasized during discussion, is that some of the current > maintainers of Wonder may have been over-conservative, and reluctant to make > changes (in fear that changes “might break something”). Thus pull requests > have not been accepted, and contributors have been deterred from making other > pull requests. More generally perhaps, given the strong uncertainty around > Wonder future, some companies, institutions, or developers, have adopted > “individual strategies” (by opposition to collective strategies): they work > on their own fork of Wonder, or subclass Wonder classes in their own code to > add functionality or fix bugs. Individual strategies are not bad per se, but > they often lead to suboptimal situations (redundant resources allocated to > solve the same problem). > > The first solution proposed during the discussion is to call for pull > requests (“guys, make more pull requests please!”) and make a promise that > they will be more actively reviewed (and maybe committed). Sure this is a > good step, but, given the situation, this probably won’t be enough… > > Another proposal would be to almost automatically commit, after a certain > period of time, pull requests that have not been reviewed and pulled. > > The previous strategy seems a bit too risky to some of the attendees, and a > proposal has been made to make a condition that, to be automatically accepted > (if not reviewed), a pull request should contain unit tests. But according to > other attendees, this condition will be a blocker (not exactly what we need > right now), and will not be very useful and won’t prevent undesirable > side-effects, given the fact that Wonder has very few tests implemented. > > As an alternative, a condition was proposed that at least, pull requests > should be well documented, so that reviewers get a good grasp at what the > problem at hand is and why that solution is proposed. > > 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. > > A point has been made that Wonder should be in the hands of the actors that > are actively using it (and enhancing it), and not in the hands of actors that > no longer use it. That should entail that each (major? willing?) company / > institution actively developing with Wonder should have at least one > contributor with commit rights. That could be an incentive to make pull > requests, and a signal that the community is decided to change the current > state of things and wants to share the responsibilities about our “public > good” (Wonder is a public good). Normally, in an active open-source project, > contributors gain commit rights by the number
Re: WOWODC 2015 talk about the state of Wonder
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
WOWODC 2015 talk about the state of Wonder
Hi all, At the end of WOWODC 2015, there has been a discussion about the current state of Wonder and it’s future. I try below to summarize this discussion, but I did not take notes, and this is what I remembered from it, so this is by no means an « official » or comprehensive summary. Please feel free to add elements and correct me if my report is biased. An observation that can easily be made, and by which the discussion started, is that Wonder is in a stale state. There are less and less pull requests, and even fewer commits. According to the participants, there are several reasons for this. The first one is that some of the most active, talented contributors are either no longer doing WebObjects development, or are working for/at Apple and can no longer contribute. The second reason might be that some contributors have been disappointed by the fact that their pull requests have been ignored (neither reviewed nor committed), perhaps due to lack of time / knowledge from committers. The third reason, which has been strongly emphasized during discussion, is that some of the current maintainers of Wonder may have been over-conservative, and reluctant to make changes (in fear that changes “might break something”). Thus pull requests have not been accepted, and contributors have been deterred from making other pull requests. More generally perhaps, given the strong uncertainty around Wonder future, some companies, institutions, or developers, have adopted “individual strategies” (by opposition to collective strategies): they work on their own fork of Wonder, or subclass Wonder classes in their own code to add functionality or fix bugs. Individual strategies are not bad per se, but they often lead to suboptimal situations (redundant resources allocated to solve the same problem). The first solution proposed during the discussion is to call for pull requests (“guys, make more pull requests please!”) and make a promise that they will be more actively reviewed (and maybe committed). Sure this is a good step, but, given the situation, this probably won’t be enough… Another proposal would be to almost automatically commit, after a certain period of time, pull requests that have not been reviewed and pulled. The previous strategy seems a bit too risky to some of the attendees, and a proposal has been made to make a condition that, to be automatically accepted (if not reviewed), a pull request should contain unit tests. But according to other attendees, this condition will be a blocker (not exactly what we need right now), and will not be very useful and won’t prevent undesirable side-effects, given the fact that Wonder has very few tests implemented. As an alternative, a condition was proposed that at least, pull requests should be well documented, so that reviewers get a good grasp at what the problem at hand is and why that solution is proposed. 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. A point has been made that Wonder should be in the hands of the actors that are actively using it (and enhancing it), and not in the hands of actors that no longer use it. That should entail that each (major? willing?) company / institution actively developing with Wonder should have at least one contributor with commit rights. That could be an incentive to make pull requests, and a signal that the community is decided to change the current state of things and wants to share the responsibilities about our “public good” (Wonder is a public good). Normally, in an active open-source project, contributors gain commit rights by the number and the quality of their pull requests. But Wonder is no longer an active project, and therefore, the grant of commit rights might serve the purpose of making it active again. Here is what I remember right now, and I just want to add that the discussion was very friendly, open, and constructive. JPM ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
