<div dir="ltr">Hi Ronny,<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 7:12 AM Ronny Pfannschmidt <<a href="mailto:opensource@ronnypfannschmidt.de" target="_blank">opensource@ronnypfannschmidt.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>...</blockquote></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
This is an accumulative cost in many ways - in particular for a project<br>
driven primarily by volunteers - every hour we sacrafice to this altar<br>
of technical debt is an hour lost for improving the project and/or<br>
working on actual features.<br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>I feel your frustration. I agree that the pytest codebase needs some refactorings in order for it to be maintainable and allow us to move forward.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From my perspective this issue directly grows out of driving a large<br>
part of pytests development by examples and tests, but precluding<br>
stepping back and doing actual design.<br>
<br>
The history of marks makes a perfect example of such an horror storry.<br>
Each iteration adding a new minimal element while adding a huge factor<br>
to the structural error as it grew.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>What I think often happens is that we can't foresee that a minimal increment might lead to a large technical debt in the future. Once we put something in the open, we try very hard to not change that behavior (even if considered incorrect now), which is the main point of your email.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I really want to hammer down there that "minimal" is very different<br>
from "minimal viable" - leaving design uncontested for too long is an<br>
ramp up for unsustainable technical debt.<br>
<br>
Its aslo critical to note that for **me** there is a inherent<br>
dishonesty in trying to stay backward compatible and not putting<br>
forward a design and development process that deeply supports it -<br>
right now we can observe a state of fragility from pytest where it<br>
feels like every feature release triggers some regression - while at<br>
the same time we keep and keep shipping features that are structurally<br>
and fundamentally broken since years (yield tests, config init, ...).<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I agree about the fact that every feature release we end up breaking something unintentionally. Of course that sometimes will happen, but I feel that happens more often in the murky areas of the code which have grown organically over the years. </div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This setup, which gives me the impression it is "designed" to make the<br>
project fail its user (aka its broken to begin with and now it will<br>
break some more), is a massive emotional drain. It painfully twists<br>
around the sense of responsibility simply due to the perceived inherent<br>
base-level of failure - and **I** want to do and feel better.<br>
<br>
However with the current flow of releases and with our backward<br>
compatibility policies in place i am under a very general impression<br>
that i cant really do anything about it, and even if i try it would<br>
drag on for years to generate even basic positive results - this<br>
impression is a killer to my motivation - as it **feels** like it would<br>
take years to even get a initial iteration out to the users - and the<br>
process of fixing the issues in general would drag on over not only<br>
years - but decades.<br>
<br>
A timeflow like that would commpletely disconnect me from perceptions<br>
of reward or archivement  - in turn making it even less likely to<br>
succeed or even start.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>About our backward compatibility policies, we don't have any minimal time restriction for major releases, we only state that we will issue deprecation warnings for two feature releases before actually changing/removing a feature.</div><div><br></div><div>Having said that, I see that it is possible for us to have major releases more often (a few per year even). As we have learned already, frequent releases which cause few incompatibilities are preferred over infrequent releases which cause a lot of incompatibilities, as it will affect less users and makes it easy to pin point problems.</div><div><br></div><div>My gut feeling is that those backward incompatible releases won't be that bad in the end: we only change little used features or porting the code to the new way of doing things is easy to apply to existing code. Of course some friction always happen.</div><div><br></div><div>Dragging deprecated features over many releases, specially if they get in the way of new implementations, is a certain way to needlessly increase the burden of us maintainers, as you point out.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a open source project that volunteer driven - fixing deeper<br>
issues should connect to feeling an archivement - but with out current<br>
setup what seems to be in for **me** is more like dread, fear and<br>
depression - a general defeat.<br>
<br>
Thats not something i want to allow anymore. <br>
<br>
**I** want to feel good about my work on pytest.<br>
**I** want to feel the archivements i have on pytest.<br>
<br>
and because of that<br>
<br>
**I** have to make sure the project can support that.<br>
<br>
So **I** want to invite all of you,<br>
<br>
<br>
Lets make pytest a project again where<br>
<br>
* we claim suport for backward compatibility and our actions and<br>
results show for it<br>
* we can enjoy the act of adding new features and enhancing the<br>
ecosystem<br>
* we can have better and quicker feedback, not just from the fabulous<br>
people that work on it - but also the users.<br>
<br>
<br>
**I** strongly beleive that this is doable, but it will require cutting<br>
some bad ends.<br>
<br>
We need to enhance layering, it doesnt have to be perfect but we do<br>
have to be able to keep things appart sanely and we need to have<br>
objects in valid states per default (invalid states should only be<br>
possible deliberately, not accidentially)<br>
<br>
We need to talk/write about design more - the difference between<br>
minimal and viable after all only shows itself in the heat and fruction<br>
of different perspectives and oppinions clashing.<br>
<br>
We need a conversation and interaction with our advanced users, so they<br>
dont end up on old and dead pytest versions (like pypy for example).<br>
<br>
We need a pervasive chain reason to bring trough the period of<br>
papercuts where we do shift around layering so the ecosystem can keep<br>
up (saving the structural integrity of pytest at the expense of<br>
destroying the ecosystem would be a dissaster).<br></blockquote><div><br></div><div>I agree with the points above Ronny, let's make it happen. :)</div><div><br></div><div>Cheers,</div><div>Bruno.</div></div></div></div>