Thanks Ben!
I wonder if the new guidelines belong in the "Committing" docs instead?
http://mesos.apache.org/documentation/latest/committing/
On Thu, Jul 26, 2018 at 2:18 PM, Benjamin Mahler wrote:
> Thanks to everyone who chimed in. To Gilbert's questions, I think that's
> outside the
Thanks to everyone who chimed in. To Gilbert's questions, I think that's
outside the territory of what a policy or guidelines will cover, and will
be up to the judgement of the committer.
My initial search for "backport" was insufficient and I missed the
following existing comment in a different
Thanks for clarifying the backporting policy, BenM!
I totally agree with the changes proposed for the backporting policy, but I
realize two more scenarios that are more clear to me yet:
- There are some bugs that are not fixable (due to legacy technical
decisions), and we end up with
I don’t have a big stake in, however, one opinion is if a large commercial
enterprise was using a specific release that is working the desire is often to
only upgrade if necessary. Necessary can be for a number of reasons including
new features; however if a new feature is not needed the
I just have a comment on a special case:
If a fix for a flaky test is easy to backport,
IMO we probably should backport it,
otherwise if someone backports another critical fix in the future,
it would take them extra effort to check all CI failures.
On Mon, Jul 16, 2018 at 11:39 AM Vinod Kone
I like how you summarized it Greg and I would vote for leaving the decision
to the committer too. In addition to what others mentioned, I think
committer should've the responsibility because if things break in a point
release (after it is released), it is the committer and contributor who are
on
Greg, I like your idea of adding a prescriptive "policy" when evaluating
whether a bug fix should be backported, and leave the decision to committer
(because they have the most context, and avoid a bottleneck in the process).
- Jie
On Mon, Jul 16, 2018 at 11:24 AM, Greg Mann wrote:
> My
My impression is that we have two opposing schools of thought here:
1. Backport as little as possible, to avoid unforeseen consequences
2. Backport as much as proves practical, to eliminate bugs in supported
versions
Do other people agree with this assessment?
If so, how can we find
Back porting as little as possible is the ultimate goal for me. My reasons
are closely aligned with what Andrew wrote above.
If we agree on this strategy, the next question is how to enforce it. My
intuition is that committers will lean towards back porting their patches
in arguable cases,
I believe I fall somewhere between Alex and Ben.
As for deciding what to backport or not, I lean toward Alex's view of
backporting as little as possible (and agree with his criteria). My
reasoning is that all changes can have unforeseen consequences, which I
believe is something to be
seems like more effort?
The backport policy strikes me as a community decision, rather than an
individual decision. The community discusses (as we're doing now :) and
settles on a policy, which individual committers then execute. Putting each
release manager in charge of the backport policy
I typically backport all bug fixes that cleanly apply and the risk is low.
It's a judgement call, but many of the time, you can easily tell the risk
is low.
I think my argument on why we want to do this is "why not". I want our
software to have less bugs!
Letting release manager decides which
This is exactly where our views differ, Ben : )
Ideally, I would like a release manager to have more ownership and less
manual work. In my imagination, a release manager has more power and
control about dates, features, backports and everything that is related to
"their" branch. I would also like
+user, I probably it would be good to hear from users as well.
Please see the original proposal as well as Alex's proposal and let us know
your thoughts.
To continue the discussion from where Alex left off:
> Other bugs and significant improvements, e.g., performance, may be back
> ported,
the
14 matches
Mail list logo
