Flip configure --enable-arch-native default #2261
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -157,6 +157,10 @@ This section gives an account of those changes in three categories: | |
| <p>Removed <em>LM_Group</em> helper. The LM protocol is | ||
| insecure and no longer supported on the market since 2008. | ||
|
|
||
| <tag>--disable-march-native</tag> | ||
kinkie marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| <p>The <em>-march=native</em> compiler option is not used by | ||
kinkie marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| default. It is possible to enable it by using the | ||
kinkie marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
kinkie marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| <em>--enable-march-native</em> option instead | ||
kinkie marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| </descrip> | ||
|
Contributor
There was a problem hiding this comment.
Moreover, after that manual backport, v8 release notes would have to be manually changed as well because the changes will no longer be done during v7-to-v8 upgrade! We should find a way to avoid this extra/unwanted manual work. On the other hand, we do not want to review PRs like this in the wrong context of a versioned branch, where very different tradeoffs may apply, both in terms of code and in terms of policy. Moreover, a v7 PR would not automatically upport to master either (even if we write a script that facilitates such automated upports) because master is unlikely to have an up-to-date copy of v7 release notes. Thus, some manual work is currently required regardless of the porting direction. Finally, changes that should be (eventually) backported to more than one versioned branch create a series of similar problems, arguably compounding their negative side effects. I suggest the following:
Contributor
Author
There was a problem hiding this comment. IIRC there have been proposals to rework how release notes are built, but nothing emerged that anyone is willing to invest in.
Contributor
There was a problem hiding this comment.
And that sad status quo will naturally continue if all proposals are met with a similar reaction. I am "willing to invest" in my long-term proposal1 if others support it. Do you support it?
Have they diverged enough to prevent an automated merge in this case? AFAIK, merging does not always require identical base files. Is there any solution that does not require manual work? If not, then we should be selecting the lesser evil (instead of rejecting all evil). Footnotes
Contributor
Author
There was a problem hiding this comment.
I don't think that proposal would help in this case, but code wins on opinions :)
Yes, I tried.
Not that I can imagine
Contributor
There was a problem hiding this comment.
Why do you think that moving each individual release change "note" into a dedicated file would not help in cases like this PR? Would not dedicated "note" files prevent/avoid all relevant merge conflicts (because master/v8 PRs would be adding files that do not exist in v7 and, hence, can be merged into v7 cleanly)? I am asking because I would rather not invest in code that is doomed to fail -- if you see a potential serious design flaw, I would like to know about it before doing the implementation legwork!..
Glad we agree on that.
Contributor
Author
There was a problem hiding this comment.
yes
I think it's a rare enough problem that I'm fine with it
Contributor
There was a problem hiding this comment. This is why we; Since the intended "first release" is to be v7.2 the release notes edited by this PR should be
Contributor
There was a problem hiding this comment.
Thank you for your support (in principle).
I am not sure what "this" refers to exactly, but I disagree with the implication that some release notes management problems should preclude us from backporting any changes. Instead, we should find a way to reduce release notes management overheads (during backports). My suggestion to generate release notes from individual note files aims to do that (among other things).
FWIW, I do not know what automation you have in mind. Is it something similar to the "generate release notes document from individual note files" suggestion being discussed on this thread?
I hope we can avoid requiring master/v8 PR to update v7 release notes in anticipation of a future backport. Such an update creates a mismatch (until backport actually happens), and there are use cases where we want to merge master/v8 PR first and decide whether to backport it much later, based on, for example, initial deployment experience. It is best to keep any backporting decisions separate from master/v8 PR decisions.
I think we should decide what that
My "generate release notes document from individual files" proposal supports either or even both models -- the generating script should not care much which git branches or tags it compares to find changes, but achieving release notes document scope clarity would obviously help when finalizing this automation. I suspect we want to start with the simpler "the latest v6 to v7.2" model. With a bit more work, we may even allow the user to specify the two branches/tags that the script should compare. In either case, the generated file should contain all notes relevant for the upgrade from X to Y, without distinguishing/marking intermediate changes like "From v7.2...", although that can be added later, after the bigger problems are solved. How would you define the scope for that "
Contributor
There was a problem hiding this comment.
I mean this entire discussion and planning of functionality to workaround of solve ... a non-problem. @kinkie simply edited the wrong SGML file. Moving those changes to the
FYI, the mechanism you propose does nothing to solve the actual problem that v8 release notes should not mention this change. The only release notes which should mention this build change are v7.N texts.
Yes. Where "individual note files" are the Nothing we do can solve the problem of vN+1 release notes being incorrect when a feature is backported. We simply should not be backporting features casually. The older vN is stable (promised not to change UI) already.
We must avoid backporting feature changes to what admin are expecting to be a seamless drop-in upgrade. Only in exceptional circumstances like this one can we backport, and that comes with pre-planning and reviewer approval of the correct release-N file being edited.
If the vN really is still "master/vN" then a parallel or followup PR correcting the master branch files should be done and is not related to the backport (which should move the relevant texts). It comes back to the fact that we have provided a guarantee that Squid X.a to X.z are drop in replacements for each other. It is an exceptional circumstances to break that, the extra work is good for us not to treat the case casually.
It is for both of the above. Ideally there should be no documented changes from v7.1 to v7.2. PS. you seem to still be trying to solve a problem. Remember there is no problem when we three are all following the Squid Project procedures properly.
Contributor
There was a problem hiding this comment.
The need for error-prone manual synchronization work (as illustrated by recent #2268) and persistent arguments about individual release notes indexing/placement prove that there is a problem here. Even if "editing the right file" were a solution, it would still be a problem.
The above assertion contradicts Francesco's earlier "Backporting to v7 will need to be manual, as release-notes will conflict" assertion and the actual manual backport of this PR (i.e. #2266): Editing v7 release notes did not allow this PR to be backported automatically. The "problem" cannot be fully solved by editing the right file: The problem is not limited to choosing the right file, and the correct file choice itself may change with time for the same code change (as code changes get backported to earlier and earlier releases).
I strongly disagree with the premise of this assertion: Until "this change" is backported, v8 release should mention "this change". After "this change" is backported, v8 release notes should stop mentioning it. The proposed solution would accomplish that automatically. Without it, we can only work around a part of the problem by waiving our "this v8 change is not really a v8 change because we plan to backport it to v7 very soon" hands.
... but only after this change lands in v7. And if it were to backported to v6 later, then v7 release notes should stop mentioning it as well. That complication may not apply to this particular change, but other changes were and will be backported to multiple versions. The proposed solution addresses that. "Editing the right file" does not.
That is a "no" answer -- each of my "individual note files" is dedicated to one change. Compiling template.sgml (where multiple notes reside) cannot solve the problems we need to solve. We need to generate (the equivalent of) template.sgml first.
What makes you thing that? My "generate release notes" proposal solves that problem AFAICT.
Casual or not, backports will continue to happen. We need to deal with them. And during earlier release cycles, backports will be happening often. They are not the only sub-problem we are trying to address here, but they are worth addressing IMO.
The proposed solution eliminates the need for that manual error-prone work.
I disagree that having a single document that covers two very different upgrade paths is a good idea.
Multiple documents (probably generated on demand rather than static/versioned), one for each upgrade jump would be ideal IMO, but we can start with major upgrades (i.e. the first bullet) and ignore the second bullet needs (or satisfy them at the lower priority).
@yadij, release notes maintenance problems are real and cannot be solved by "following procedures". You may not see those obstacles/complications as real problems (or as problems worth solving), but that disagreement itself does not really matter much in this context. What matters (for now) is whether you are going to block a transition to the proposed scheme, where each change is described in a dedicated "note" file and those individual "note" files are automatically assembled into a release notes document. AFAICT, Francesco supports that idea (in principle). I do not know whether you object to such a change, in principle. Do you? |
||
| </p> | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.