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 <jp.malr...@free.fr> 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 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/probert%40macti.ca > > This email sent to prob...@macti.ca _______________________________________________ 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
