WineConf action items
Folks, We've had many good discussions at WineConf, and decided to make a number of changes. Here are the resulting action items on my plate. I'll be working on putting these changes into place over the next days/weeks: * We'll merge the wine-devel and wine-patches mailing lists, with wine-devel becoming the single channel for both patches and discussions. * We'll be hosting vkd3d, the D3D12->Vulkan library, on winehq.org in its own git repository. * We'll create a new mailing list for AppDB maintainers. * We'll start to use more detailed git commit messages, including bug references. Jeremy volunteered to research best practices from other projects so we can come up with some standards for what the messages should look like. * We'll start building binary packages for Android. * We'll continue to assign reviewers at random from the maintainer pool for patches that don't have a specific maintainer. I was concerned that this wasn't working so well, but the general consensus was that it's worth trying some more. * Code freeze for 3.0 will start around the end of November, with a final release around the end of the year. -- Alexandre Julliard julliard(a)winehq.org
I've decided to spend some time researching staging patches and bringing them to the attention of maintainers or others who may be able to put in the extra work required to get them in. This is based on a discussion we had where some people complained about the number of patches in staging that aren't being merged. I think there's a lot of useful work in there that could benefit from the right people's attention.
There was some discussion about ideas for GSoC/etc. I'm a little dubious of the aptitude of any task, but I had some potential ideas nonetheless: * Implement the Indeo codec for VFW (bugs 27244, 36452, etc.) Potentially other codecs (e.g. msyuv, msh263.drv), but I was unable to find any bugs for these. * Implement the MSI user interface (bug 39359). I did a fair amount of work over this summer on getting the backend to work right and send a lot of the right messages, but we still don't have the frontend dialogs. * There are a few propsheet pages or similar we don't have—e.g. aclui, bthprops.cpl, irprops.cpl. I don't have a bug for any of these but I know that WinObj wants aclui and sndrec32 wants mmsys.cpl.
Am 02.11.2017 um 16:24 schrieb Alexandre Julliard:
* We'll be hosting vkd3d, the D3D12->Vulkan library, on winehq.org in its own git repository.
Maybe VK12 would be a great name, because of the existing VK9 project: http://techtinker.blogspot.de/2017/07/vk9-status-report.html
* We'll start building binary packages for Android.
I already offered my help to the staging guys, but it would be great to have the scripts from crossover for building the dependencies. Is it possible to get those?
* We'll start building binary packages for Android.
I already offered my help to the staging guys, but it would be great to have the scripts from crossover for building the dependencies. Is it possible to get those?
Unfortunately, I don't think we can cleanly separate this from the rest of the crossover source code.
On 3 November 2017 at 19:27, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 02.11.2017 um 16:24 schrieb Alexandre Julliard:
* We'll be hosting vkd3d, the D3D12->Vulkan library, on winehq.org in its own git repository.
Maybe VK12 would be a great name, because of the existing VK9 project: http://techtinker.blogspot.de/2017/07/vk9-status-report.html
I think we'd want to avoid that kind of confusion.
André Hentschel <nerv(a)dawncrow.de> writes:
* We'll start building binary packages for Android.
I already offered my help to the staging guys, but it would be great to have the scripts from crossover for building the dependencies. Is it possible to get those?
In Crossover it's part of the makefiles so that's a bit tricky, but I'm working on a standalone script. -- Alexandre Julliard julliard(a)winehq.org
On 11/02/2017 10:24 AM, Alexandre Julliard wrote:
* We'll start to use more detailed git commit messages, including bug references. Jeremy volunteered to research best practices from other projects so we can come up with some standards for what the messages should look like.
As far as I can tell, there is broad consensus on this. Of the 8 or 10 projects I sampled, if I could find a detailed description of how commit messages should be structured, they were more or less all the same. The keys are: Subject line < 78 characters (~ 50 best), no period, imperative Prefix subject with subsystem, e.g. 'ntdll: usleep everywhere'. Patch prefixes are quite common (e.g. [PATCH], [RFC], [n/m]), but I'm going to treat that out of scope for this research. The body of the commit message should contain a why and a how but not a what. URLs are to be avoided; better to summarize what would be linked. The kernel puts this nicely by saying that the ideal is that a commit log require no external resources to understand. Surprisingly, none of the guidelines I read emphasized brevity. That startled me. Bug # references are good to include, but sadly, this was the one area where I didn't find any real consensus. The kernel wants a URL to bugs. glibc uses [BZ #nnnn]. Github projects use just #nnnnn. OpenStack uses 'Closes-Bug: nnnnn' and (and Partial-Bug and Related-Bug). Other projects use 'Bug: nnnnn', and one uses 'bug #nnnnn'. I'd be tempted to argue for 'Bug nnnnn', with any automated scripts we write also accepting 'bug:nnnnn' (etc). I saw one project (and now I can't recall which one :-/), that requested related bug numbers be provided on a separate, final line. That struck me as overkill, although I can recall seeing the git log and thinking it looked pretty :-/. Cheers, Jeremy p.s. Here are 5 of the pages I reviewed: Git: https://github.com/git/git/blob/master/Documentation/SubmittingPatches Xorg: https://www.x.org/wiki/Development/Documentation/SubmittingPatches/ Kernel: https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html glibc: http://sourceware.org/glibc/wiki/Contribution%20checklist#Detailed_Explanati... A general discussion by an OpenStack Nova author who claimed to also do a survey like this: https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_mess....
2017-11-06 17:30 GMT+01:00 Jeremy White <jwhite(a)codeweavers.com>:
Subject line < 78 characters (~ 50 best), no period, imperative
As long as we're changing things, let's stop putting periods on the ends of our patch subject lines. Wine is one of very few projects that use trailing periods and it's caused me to accidentally format subject lines incorrectly when writing patches for other open source projects. For simplicity, I'd like the line length recommendation to be the same for the first line and all subsequent lines. When I rewrote <https://wiki.winehq.org/Submitting_Patches#The_commit_message> two years ago, I put 72 characters as the recommended limit everywhere. I chose 72 characters based on the recommendation at <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>. In practice, Alexandre really doesn't care how long the first line is, and probably doesn't care about the subsequent lines either.
Prefix subject with subsystem, e.g. 'ntdll: usleep everywhere'. Patch prefixes are quite common (e.g. [PATCH], [RFC], [n/m]), but I'm going to treat that out of scope for this research.
Since we're going to merge wine-patches and wine-devel, we're definitely going to want [PATCH] in the subject. Furthermore, the test bot depends on the n/m syntax to know whether a patch needs to be tested with a previous patch applied.
Bug # references are good to include, but sadly, this was the one area where I didn't find any real consensus.
The kernel wants a URL to bugs. glibc uses [BZ #nnnn]. Github projects use just #nnnnn. OpenStack uses 'Closes-Bug: nnnnn' and (and Partial-Bug and Related-Bug). Other projects use 'Bug: nnnnn', and one uses 'bug #nnnnn'. I'd be tempted to argue for 'Bug nnnnn', with any automated scripts we write also accepting 'bug:nnnnn' (etc).
I saw one project (and now I can't recall which one :-/), that requested related bug numbers be provided on a separate, final line. That struck me as overkill, although I can recall seeing the git log and thinking it looked pretty :-/.
"Bug: 123456" is nice because it follows the same header syntax we use for Signed-off-by, and the bug tag could go its own line before the Signed-off-by tags. I don't have a strong opinion, but I like that syntax better than any of the others you mentioned. Thanks for doing the best practices research! -Alex
Am 2017-11-06 um 17:30 schrieb Jeremy White:
The keys are: Subject line < 78 characters (~ 50 best), no period, imperative My 2c is that that something like < 100 would be better than < 78, mostly because some COM method names are quite long, and a subject "ddraw/tests: blabla device::DrawIndexedPrimitiveVB foobar" doesn't leave much room for a good description what the patch does in the remaining space. I'd rather have a longer subject than use unclear abbreviations (And I've already cut "IDirect3DDevice7" to "device").
participants (8)
-
Alex Henrie -
Alexandre Julliard -
André Hentschel -
Henri Verbeet -
Jeremy White -
Stefan Dösinger -
Vincent Povirk -
Zebediah Figura