Process... Was : [cayenne] branch master updated: CAY-2589 Allow optionally using a local query cache that is separate from the shared query cache.

[Andrus Adamchik <an...@objectstyle.org>]

Hi John,

Thanks for starting this meta-discussion about the process. I changed the email subject to separate it from the conversation about caching.

I think we all are doing a great job reviewing and voting on releases, but for better or for worse it is hard to set expectations for PR reviews and general discussion. While there is a lot of software downstream of Cayenne that heavily depends on it, still Apache Cayenne is a volunteer project. While everyone is doing their best, any one committer's attention may slip, or their interests / focus may be in some other part of the framework. So feedback can be uneven, as we've all seen many times.

That's just accepted as a part of the open source process, and Apache way of handling it is via "lazy consensus" (ask for feedback, but don't let the lack of it block your progress). As long as everyone is acting in good faith, it works the best for the long-term health of the project.

In this case there's nothing you could've done better. You gave more than enough time for anyone to chime in. It is not your fault that no one did. You totally had the right to commit the code when you did. In fact the fault is mine that I tuned out of PRs on GitHub, and only noticed that there is an ObjectContext API change when I pulled the repo to fix an unrelated issue.

As for the process... IMO the formal part is pretty straightforward (and we are already mostly following it) :
------
If a code change constitutes a feature or a bug fix (as opposed to say a javadoc change or code reformatting), do the following:

1. Open a Jira
2. When committing code, reference Jira ID in the commit message
3. Add a line in RELEASE-NOTES (and if you are breaking something - upgrade instructions in UPGRADE.txt)

This ties commits to features and features to releases, and clearly communicates changesets to the end users. 
------

The rest of the process is more social and is harder to codify, so it will have to rely on good will and lazy consensus. IMO committers should use their judgement as to the amount of discussion and review they expect for a given feature. My only suggestion would be to "escalate" to dev@ from GitHub / Jira, if you want more people to pay attention.

I wonder if any other Apache projects were able to formalize the process better, considering the volunteer attention span constraint? I'd be open to suggestions.

> I would have appreciated some more credit
> since the test cases I submitted were often included wholesale into the
> correcting commits without any attribution. Personally I would have
> preferred a merge of the commit with my test case with a followup commit
> with the fix. 

This should not happen. Merge is absolutely the way to handle it. We should all pay attention to such things.

Andrus


> On Jul 8, 2019, at 5:56 PM, John Huss <jo...@gmail.com> wrote:
> 
>> 
>> BTW, while we are having this discussion, may I request to move 597376ae5
>> commit to a pull request or a dedicated branch and off of master?
>> 
> 
> Certainly. This was on GitHub as a pull request
> <https://github.com/apache/cayenne/pull/388> for over two weeks before I
> committed it to master and I didn't receive any comments on it during that
> time, which was why I felt ok committing it to master. Should I expect pull
> requests, especially ones from committers, to sit without comment for that
> long?
> 
> The first version <https://github.com/apache/cayenne/pull/292> of this
> change was also a pull request. It got some feedback initially, then after
> I made the requested changes the pull request sat open for basically an
> entire year without any more comments even after I requested them. In
> contrast, after I committed to master I got feedback in just a few days. If
> this is how interaction with the community (even a committer!) looks, then
> I'd suggest that we need to seriously look into ways of improving our
> process.
> 
> I'd love to hear suggestions about how I can do this better in the future.
> 
> On this topic, I don't think there is a process document or anything
> written up that indicates what steps need to be taken when committing code
> such as:
> 1) Creating a JIRA issue
> 2) Creating a pull request?
> 3) Emailing the dev list?
> 4) Updating the release notes
> 
> On a more positive note, I was pleased with the responses I got to bugs I
> reported with recent changes that were made on master. Many of them were
> fixed very promptly! However, I would have appreciated some more credit
> since the test cases I submitted were often included wholesale into the
> correcting commits without any attribution. Personally I would have
> preferred a merge of the commit with my test case with a followup commit
> with the fix. But maybe I'm asking for too much.
> 
> I do greatly value Cayenne and it plays a huge role in the software we
> make. I am very thankful for all the people who have contributed to it's
> success and continue to work to make it better.