WineConf action items

[Alexandre Julliard]

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.

[Vincent Povirk]

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.

[Zebediah Figura]

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.

[André Hentschel]

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?

[Vincent Povirk]

> > - 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.

[Henri Verbeet]

On 3 November 2017 at 19:27, André Hentschel  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.

[Alexandre Julliard]

André Hentschel  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.

[Jeremy White]

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....

[Alex Henrie]

2017-11-06 17:30 GMT+01:00 Jeremy White :
> 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

[Stefan Dösinger]

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").