[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: Yep, core-workflow work has superseded this issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Has this been superseded by core_workflow issues? -- ___ Python tracker ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: I came across OpenStack's tool for this problem today: http://docs.openstack.org/developer/reno/design.html I think it's significantly more complex than we need for CPython, but also still interesting as a point of reference. It's already mentioned in PEP 512,

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: I never said they always had to be different, and "wholly different" is certainly not the case, nor do I think I implied that. So if your tool supports my scenario that's all I'm asking for :) -- ___ Python

[issue18967] Find a less conflict prone approach to Misc/NEWS

Larry Hastings added the comment: I don't agree that in all cases the Misc/NEWS entry and the checkin comment must be wholly different. While I concur that that's called for now and again, I believe this to be rare. Most checkins are small changes, and a single-line summary for both

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: I sometimes put a bit more info in the commit message, but it's true that generally it's a copy/paste job as far as I'm concerned. -- ___ Python tracker

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: Just noting a potential practical benefit of the "NEWS entry first" approach that David suggests: I believe it will help encourage the creation of a succinct answer to "Why are we making this change?" as part of the patch review process. That's then useful

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Because the two summaries should be *different* in most cases. The first line of the checkin should ideally be a single sentence of less than 80 characters, while the NEWS item will almost always be longer. The NEWS item should be a complete summary, while

[issue18967] Find a less conflict prone approach to Misc/NEWS

Larry Hastings added the comment: > [...] commit messages are for other developers, which news entries are > ultimately for users. Some developers want (insist on) the freedom to > make the two different, with different details. That's easy enough to accommodate. I updated "MergeNEWS" with

[issue18967] Find a less conflict prone approach to Misc/NEWS

Larry Hastings added the comment: Okay. I got tired of the constant Misc/NEWS merge conflicts, so I wrote a tool to fix the problem. It's checked in to Bitbucket here: https://bitbucket.org/larry/mergenews/ There's a readme, which you'll see rendered on that page. I don't know what you

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: Yes, a text box or something along those lines. I assume the selection label question is to specify a section of the change log for something to go into. That's actually not necessary as the proper section is implied by the Components label. And we could allow

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Larry: commit messages are for other developers, which news entries are ultimately for users. Some developers want (insist on) the freedom to make the two different, with different details. I am using that for Idle patches since NEWS entries become 'What

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: I believe auto-filling it from the commit message (for those who don't put in the effort to treat the two audiences differently :) was something we discussed, but it would be a separate enhancement after the news box is added to the tracker. Which I might

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: I think Larry's "split news" and "merge news" ideas are still useful as a bridging mechanism to help us get from the status quo to a tracker based solution. It would just mean that, at some point in the future, the commit hook would change to be a post-commit

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: As soon as someone finds the time to make the change we can switch. While this is a necessary requirement to change the workflow it isn't gated by it either. -- ___ Python tracker

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Is that something that might happen 'soon' or only when the whole workflow is redone? -- ___ Python tracker ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: It should be mentioned in this issue that the core-workflow mailing list decided on having NEWS entries being attached to the related issue in the issue tracker. This was then presented to python-committers and no one objected to the idea. --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Larry Hastings : -- nosy: +larry ___ Python tracker ___ ___ Python-bugs-list

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: As an interim step, should we add Ezio's newsmerge.py to Tools/scripts and instructions for enabling it to the devguide? That seems straightforward enough, and doesn't require any global workflow changes. -- ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Thanks for the reminder/suggestion. Re-reading Ezio's two patches (newsmerge.py and .hg/hgrc additions in msg217079), they appear to jointly automate what I now do by hand (revert to local and dump merge artifacts, replace with edited file with new entries

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: I would like fixing NEWS to be the top infrastructure improvement project, as it is my biggest time waster, and certainly the most obnoxious. It definite makes working on Idle less pleasant. Since an empty 3.4.2a1 section was added to 3.4 NEWS, after 3.4.1

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: Le 02/12/2014 00:11, Terry J. Reedy a écrit : Terry J. Reedy added the comment: I would like fixing NEWS to be the top infrastructure improvement project, as it is my biggest time waster, and certainly the most obnoxious. It definite makes working on

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Good idea. I will send him a note. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Donald Stufft added the comment: So Twisted is actually in the process of pulling out their tooling they use for the separate files technique and making it a stand alone project. Seems like it'd make sense to reuse/contribute to that? It's at https://github.com/twisted/newsbuilder --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Ezio Melotti ezio.melo...@gmail.com: Added file: http://bugs.python.org/file35032/newsmerge.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Ezio Melotti ezio.melo...@gmail.com: Removed file: http://bugs.python.org/file35011/newsmerge.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: One of the Mercurial devs convinced me to pursue what I had initially proposed in msg197645 and write a merge script (attached). The script is still a proof of concept, it makes a few assumptions and doesn't handle all the cases, but I did a few tests and it

[issue18967] Find a less conflict prone approach to Misc/NEWS

Marc-Andre Lemburg added the comment: FWIW: I don't think we need to manage the news entries in the NEWS file. Instead, we could simply add a field to the bug tracker called news entry and populate that as necessary. During release, this information can then be used to create a NEWS file per

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: In order for things to work with a patch gating system, I believe it will be the most practical for the news items to be each in a separate file. -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: Unless one looks carefully, it does not help the problen of merging maintenance bugfix items into a default list that also contains enhancement news not in the maintenance list*. What if instead of having sections in Misc/NEWS for

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: That would probably work for now, but it wouldn't work for the patch gating system. On the other hand, it would sure make it easier to build/check whatsnew. -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: Also having a list of enhancements and bug fixes might be more meaningful for users than a list of core issues vs library issues vs other similar sections. This could also be done with two separate files, with the new features/enhancements file existing only on

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: That makes the tooling of the gating system harder, though. If the NEWS can just be a file in the patch, we don't have to have any special tooling for it in the gating system. -- ___ Python tracker

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: If we put news items in a database keyed by issue number (and I think it reasonable that all news-worthy patches should have a tracker issue), then there would be no conflicts. (We already avoid simultaneous commits to the same issue.) If the database had

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: Moving News items from the repository to the tracker, where I think they initially belong anyway, would also remove them as an issue for a future gating system. -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: Terry J. Reedy wrote: Moving News items from the repository to the tracker, where I think they initially belong anyway, would also remove them as an issue for a future gating system. I think News items are best left in the repository just so that for any given

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Yeah, Guido was strongly in favor of that too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: Agreed. Once the gating system is in place nothing prevent us to read the NEWS entry either from the patch that is being committed or from a field in the tracker and then including it together with the patch once it is approved. --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: A sequential log of commit messages for a particular branch would give one an even better snapshot view of activity since not all commits have news messages and even when they do, commit messages sometimes have additional info. But see below. The essence of

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: Folks, this is *really, really, simple*: one file per NEWS entry. How we arrange them is just a detail. Don't go off trying to invent wild exotic alternatives that spread state across multiple sources of truth - significant historical info belongs in the version

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: My concern with a file for each entry is a possible slowdown of some operations, like TortoiseHg resyncing the diff between repository and working directory (it is not instantaneous even now). However, if there are multiple directories and if they are emptied

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: Have you considered how this is going to change if/when PEP 462 will be implemented? AFAIU PEP 462 suggests that commits happen directly from the bug tracker (or something equivalent), so we will likely start to add the NEWS entry there as well. Assuming this

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: PEP 462 is months away from going anywhere, and I personally find the current NEWS handling a major barrier to feeling inclined to work on bug fixes. The status quo will *definitely* be PEP 462 incompatible, though, since it would typically prevent applying the

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Yes, after thinking about this this weekend, it is clear to me that in the future we will *need* a scheme where by the NEWS entry can be safely included in the patch in some form. I think the commit message is also going to be in the patch, which will be in

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: A file per news entry seems a bit much, but an optional file per developer would solve most of the problem for those who have a problem with the status quo. Add a directory named, for instance, news.3.4.1. Put in a template with the allowed section headings.

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: This is already not a rule because the devguide mentions inserting new items at random positions to avoid conflicts due to another commit. Really? New NEWS entries are customarily added at or near the top of their respective sections, so that entries

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: On 4/20/2014 7:59 PM, Antoine Pitrou wrote: Antoine Pitrou added the comment: This is already not a rule because the devguide mentions inserting new items at random positions to avoid conflicts due to another commit. Really? New NEWS entries are

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: For the recommendation actually put in the devguide, change 'random position' to 'position near but not at the top'. https://docs.python.org/devguide/committing.html#news-entries ends with A nice trick to make Mercurial’s automatic file merge work more smoothly

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Senthil Kumaran sent...@uthcode.com: -- nosy: -orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Well, I guess you could sum it up as -0. I personally don't feel the need for a change, but if the chronology problem is solved and it isn't *harder* to make the needed NEWS changes, then I'm not going to object. --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: Like David I don't really care, but it seems Zach's script may show promise. I think it would be nice if news.py --commit: 1) popped up an editor window (like hg commit does) 2) processed the editor results and looked for hints of an issue number 3)

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: Note that the editor may be pre-filled with a skeleton: # --- Fill in the NEWS message here # (lines prefixed with '#' will be removed) Issue #xxx: # --- Additional text for the commit message below # (won't be reflected in NEWS) # --- Commit information

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: There also needs to be a way to specify a different NEWS entry from the commit message first line. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: You lose chronology in the directory, but not necessarily in the output; if you sort based on first commit time then you retain the chronological ordering in the merge. -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: R. David Murray wrote: I want no script asking me questions. Post-facto errors for omissions are fine (and if I have to positively say no in the input file, that's fine). tkinter is right out. I have been planning a command line interface, something along the

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: The earlier in a release cycle we switch NEWS methods, the better. Does anyone have any thoughts to share about this, either on Brett's newsworthy.py, my news.py/news_release.py, or another approach entirely? I've updated the playground branch of

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Zachary Ware zachary.w...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file34536/0607c4a2e890.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: So the `hg commit -l` bit is going to run afoul of the same group of people who didn't like my commit message reuse idea unless you explicitly try to make it very clear that e.g. the first line is for Misc/NEWS and the latter is for the commit. Otherwise we

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: The `hg commit -l ...` tricks are just for those who tend to use exactly the same text for commit message and NEWS, and I only point them out simply because I don't know how many people are even aware of the -l option :). If you want to use a NEWS entry as a

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: I want no script asking me questions. Post-facto errors for omissions are fine (and if I have to positively say no in the input file, that's fine). tkinter is right out. If you *also* want to make a script that asks questions (or even a tkinter ap),

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: There's a bare-bones experimental version in hg.python.org/sandbox/new_news that you can play around with in the 'playground' branch. It's not pretty, but it (mostly) works :). So far, there's just news.py, no news_release.py; but news_release.py should be

[issue18967] Find a less conflict prone approach to Misc/NEWS

Zachary Ware added the comment: Here's my half-baked idea on the topic, based largely on what I could learn of Twisted's method from looking through their source repo online. I liked their use of separate files for each NEWS entry, especially since it should make merge conflicts exceedingly

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: Sounds plausible to me - I'd be interested in seeing an experimental version :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Zachary Ware zachary.w...@gmail.com: -- nosy: +zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list

[issue18967] Find a less conflict prone approach to Misc/NEWS

Terry J. Reedy added the comment: +lots on ending News Merge Hell. After too many bad experiences, I now avoid pushing non-Idle patches that require a News entry. Even for those who do not mind merge conflicts, there is still the waste of time. The premise of non-checkout code management is

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: Even for those who do not mind merge conflicts, there is still the waste of time. If you know what you are doing the waste is minimal. I sometimes import, check, commit, merge, and push a patch on 3 branches in less than a minute (it was a trivial patch that

[issue18967] Find a less conflict prone approach to Misc/NEWS

Georg Brandl added the comment: [MAL] * Commit messages only provide a very terse hint at what a particular patch set was meant for. The target audience is other core developers. * News entries explain these patches (there may be more than one for a particular issue or project) to

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: I agree the different audiences problem can be addressed by using appropriate commit message formatting to say this bit goes in NEWS (perhaps with some metadata to say which section). However, that doesn't solve the question of how we fix inevitable mistakes.

[issue18967] Find a less conflict prone approach to Misc/NEWS

Marc-Andre Lemburg added the comment: On 17.09.2013 11:09, Nick Coghlan wrote: Nick Coghlan added the comment: I agree the different audiences problem can be addressed by using appropriate commit message formatting to say this bit goes in NEWS (perhaps with some metadata to say which

[issue18967] Find a less conflict prone approach to Misc/NEWS

Richard Oudkerk added the comment: An alternative would be to have separate files NEWS-3.2, NEWS-3.3, NEWS-3.4 etc. If a fix is added to 3.2 and will be merged to 3.3 and 3.4 then you add an entry to NEWS-3.2 and append some sort of tags to indicate merges: - Issue #1234: Fix something

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: Attached is my rough attempt at a script to auto-generate Misc/NEWS from commit logs. Key points: - Works from the hg log in XML format as dumped to a file - Considers a commit newsworthy if it isn't a merge and either has an issue number or has an interesting

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: I like the script name :-)... Other than that, can you attach a NEWS file such as generated by this script? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: Example file at Antoine's request. Just don't forget, very rough and not at all finished. =) We probably can't use something like this until Python 3.5 in order to make sure everyone uses commit messages that make sense, but you can get a sense of whether it

[issue18967] Find a less conflict prone approach to Misc/NEWS

Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: Decisions to make: Another important question: how do we manage manual edits to Misc/NEWS? Is the script smart enough to recognize those edits and not override them? -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Just to be clear: the reason I am opposed is that the audience for Misc/NEWS is different from the audience for commit messages, and I would prefer that the text reflect that. Mine do :) -- ___ Python tracker

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: If the goal is avoiding merging conflicts, a Mercurial hook might solve this problem. This has been already suggested and discussed on python-dev a while ago. Anything more complex than that would likely cause more problems that it solves. --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: Antoine: Script isn't far enough along to care about manual edits. David: That's fine, but I'm opposed to having to manually edit Misc/NEWS. =) -- ___ Python tracker rep...@bugs.python.org

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: I am opposed to generating NEWS from the commit messages. I thought Antoine was too. I am *a priori* skeptical that auto-generating NEWS can give good enough results, but I don't mind being proven wrong :-) --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: I get the argument against, but from my experience the difference between the opening line of a commit and what goes into Misc/NEWS is negligible at best. All of the commit-specific stuff for me goes below the fold after \n\n. And while the goal is partially to

[issue18967] Find a less conflict prone approach to Misc/NEWS

Marc-Andre Lemburg added the comment: On 13.09.2013 22:23, R. David Murray wrote: R. David Murray added the comment: Just to be clear: the reason I am opposed is that the audience for Misc/NEWS is different from the audience for commit messages, and I would prefer that the text reflect

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: I am opposed to generating NEWS from the commit messages. I thought Antoine was too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: it's also to avoid writing the same thing essentially twice Before committing I always make an hg di to double-check, and then copy (part of) the Misc/NEWS entry (that usually happens to be conveniently placed at the end of the diff) in the commit message.

[issue18967] Find a less conflict prone approach to Misc/NEWS

Brett Cannon added the comment: I would argue, MAL, that what you want Misc/NEWS to be should instead be merged into the end of What's New. If something changed which could potentially break a user it should be listed in the most visible upgrade doc we have. Otherwise pouring through

[issue18967] Find a less conflict prone approach to Misc/NEWS

Marc-Andre Lemburg added the comment: On 13.09.2013 22:51, Brett Cannon wrote: Brett Cannon added the comment: I would argue, MAL, that what you want Misc/NEWS to be should instead be merged into the end of What's New. If something changed which could potentially break a user it should

[issue18967] Find a less conflict prone approach to Misc/NEWS

Antoine Pitrou added the comment: Automatic generation of NEWS file from commit logs. Commit messages can't be modified after being published, this would be annoying to fix typos etc. From what I record of the ML discussions, the proposed solutions actually sounded more annoying than the

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: I agree with Antoine, but then as I said I don't run into huge merge conflicts very often. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___

[issue18967] Find a less conflict prone approach to Misc/NEWS

Ezio Melotti added the comment: IMHO the status quo is fine. Most of the time HG gets the merge right on its own. Some times kdiff3 pops up and asks me to solve the conflict [0]. Rarely something goes wrong so I just revert Misc/NEWS and re-add the entry manually. It seems to me that they

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: I don't think I've *ever* had NEWS successfully merge when working on a bug fix (even after the move to hg). It's one of the reasons I prefer working on new features, or bugs where the fix is too intrusive for a maintenance release :P --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Senthil Kumaran added the comment: Couple of strategies I thought for tacking this problem. 1) Documenting the resolution of NEWS specific merge conflict. Observing/recording when those arises and when it was there was no-conflict will be helpful. This could help us in organizing NEWS file

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: The one I ran into earlier today tried to merge the entirety of the 3.3.x RC NEWS into the 3.4 NEWS :P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Were you changing something in core/builtins? I'm wondering if just making some same-between-versions space between the version header/date and the beginning of that section would be enough to solve 99% of the problems. --

[issue18967] Find a less conflict prone approach to Misc/NEWS

Nick Coghlan added the comment: No, way down in Tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list mailing

[issue18967] Find a less conflict prone approach to Misc/NEWS

New submission from Nick Coghlan: We keep muttering about coming up with a less conflict-prone approach to Misc/NEWS updates, without ever settling on a concrete solution. For the last big discussion on this, see the subthread starting at

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: For what it is worth, I haven't had a non-trivial merge conflict on Misc/NEWS for quite some time now. It seems to me that they are much rarer than they were with svn. (By 'trivial' I mean that the conflicts I see is that there's a new entry on 3.4 that

[issue18967] Find a less conflict prone approach to Misc/NEWS

R. David Murray added the comment: Then, again, I pretty much only do Library fixes. Maybe 'Core and builtins' fixes get messier because of the proximity of the date and version-specific header? That should be easy enough to fix -- ___ Python