It seems to me that the corner stone here is the development process. If the work and review is done openly (e.g. on JIRA or Github) we wouldn't be having this post factum conversation, because all of the progress would be visible, so it would make sense to just squash before committing if so preferred.
It's indeed not really bisect friendly to drop squashed changes into the repository, but I've been guilty of that myself with SASI for a number of reasons, so I can't blame authors for this without sounding hypocritical. As I mentioned before I would be great if we could establish the process for how the development is supposed to happen, like other projects do. But it, as most of the other concerns, (if not all of them) could be discussed separately. On Fri, Apr 12, 2019 at 1:25 PM Benedict Elliott Smith <bened...@apache.org> wrote: > Can you start a new thread to build consensus on your proposals for > modifying the commit process? > > I do not share your views, as already laid out in my first email. The > community makes these decisions through building consensus, and potentially > a vote of the PMC. This scope of change requires its own thread of > discussion. > > > > > On 12 Apr 2019, at 20:46, Jordan West <jorda...@gmail.com> wrote: > > > > Since their seems to be an assumption that I haven’t read the code let me > > clarify: I am working on making time to be a reviewer on this and I have > > already spent a few hours with the patch before I sent any replies, > likely > > more than most who are replying here. Again, because I disagree on > > non-technical matters does not mean I haven’t considered the technical. I > > am sharing what I think is necessary for the authors > > to make review higher quality. I will not compromise my review standards > on > > a patch like this as I have said already. Telling me to review it to talk > > more about it directly ignores my feedback and requires me to acquiesce > all > > of my concerns, which as I said I won’t do as a reviewer. > > > > And yes I am arguing for changing how the Cassandra community approaches > > large patches. In the same way the freeze changed how we approached major > > releases and the decision to do so has been a net benefit as measured by > > quality and stability. Existing community members have already chimed in > in > > support of things like better commit hygiene. > > > > The past approaches haven’t prioritized quality and stability and it > really > > shows. What I and others here are suggesting has worked all over our > > industry and is adopted by companies big (like google as i linked > > previously) and small (like many startups I and others have worked for). > > Everything we want to do: better testing, better review, better code, is > > made easier with better design review, better discussion, and more > > digestible patches among many of the other things suggested in this > thread. > > > > Jordan > > > > On Fri, Apr 12, 2019 at 12:01 PM Benedict Elliott Smith < > bened...@apache.org> > > wrote: > > > >> I would once again exhort everyone making these kinds of comment to > >> actually read the code, and to comment on Jira. Preferably with a > >> justification by reference to the code for how or why it would improve > the > >> patch. > >> > >> As far as a design document is concerned, it’s very unclear what is > being > >> requested. We already had plans, as Jordan knows, to produce a wiki > page > >> for posterity, and a blog post closer to release. However, I have never > >> heard of this as a requirement for review, or for commit. We have so > far > >> taken two members of the community through the patch over video chat, > and > >> would be more than happy to do the same for others. So far nobody has > had > >> any difficulty getting to grips with its structure. > >> > >> If the project wants to modify its normal process for putting a patch > >> together, this is a whole different can of worms, and I am strongly -1. > >> I’m not sure what precedent we’re trying to set imposing arbitrary > >> constraints pre-commit for work that has already met the project’s > >> inclusion criteria. > >> > >> > >>> On 12 Apr 2019, at 18:58, Pavel Yaskevich <pove...@gmail.com> wrote: > >>> > >>> I haven't actually looked at the code > >> > >> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
