WineConf 2015 decisions

[Kyle Auble]

On 09/25/2015 03:16 AM, Alexandre Julliard wrote:
> Over the last few months there have been a lot of discussions about how
> to improve our development process. I've been gathering feedback, and
> last week at WineConf I summarized the suggestions in my keynote
> presentation....
>
> ...
>
> I'm hoping that this will make the development process more pleasant for
> everybody, and enable us to better respond to users' needs.
>
> Once these changes are in place, I'll also encourage everybody who had
> given up in disgust to give us another chance; and if things are still
> not satisfactory, please send us feedback. This is a work in progress,
> and we will continue to listen and work on making things better.

I just wanted to say that beyond all of these ideas sounding good, I 
think the simple fact that everyone's discussing them is a very 
encouraging sign. I get the feeling a lot of problems that cropped up 
recently aren't anyone's personal fault so much as growing pains, 
natural feedback from the project's advance (and the popularity and 
heightened expectations that come with that).

After all, how long did it take before the first stable release was 
ready? Then compare that, in the past few years for example, to 
Pipelight or Andre H. being able to port everything to ARM64 in under a 
week. So the old approach actually made a lot of progress, until it 
started hitting new ceilings.

At this point, my involvement with Wine mainly consists of technical 
writing and simple web-design, but before I take another hiatus, I'd 
like to toss out a couple thoughts based on what I've seen from that 
POV, digging through old docs and emails scattered across WineHQ.

On 09/25/2015 03:16 AM, Alexandre Julliard wrote:
> - Wine-staging is now considered an integral part of the Wine
>    development process, and will be used as a mechanism to enable more
>    patches to meet the requirements for inclusion in the main tree. We
>    will all be working together as a team.

Regarding wine-staging, I haven't had any direct interaction with the 
branch, but I think nurturing it and bringing it back into the fold 
upstream is great. I know there was some concern that it would cause the 
code quality to start declining, but I could see the opposite happening 
too. Bugs either pop up for local reasons or subtler, structural ones; 
usually eyeballs (or maybe tools) can catch the former, but often only 
testing by a lot of users ultimately teases apart the the latter.

And wine-staging seems to have hit on a way to attract more 
contributors, eyeballs and all. Involving more people in the project 
would also really help on the support side of things too (documentation, 
forums, bug triage, etc.) My one concern isn't that wine-staging will 
harm anything, but that it isn't a panacea for other issues...

On 09/25/2015 03:16 AM, Alexandre Julliard wrote:
> - We will switch to a time-based stable release, on a yearly
>    schedule. The code freeze will start every year in the fall. Michael
>    Stefaniuc will be maintaining the stable branch starting with 1.8.
>
> - We will start enforcing a Signed-Off-By header on patches, to make it
>    possible to better distribute reviewing responsibility, and to allow
>    multiple authors to cooperate on a patch.
>
> - We will keep a list of maintainer contact information for the various
>    submodules; developers will be encouraged to go through the respective
>    maintainer before submitting to wine-patches.

... but in combination with these changes, it could pay extra dividends 
down the road. I don't know if it's ever been suggested, but on top of 
just doing releases on a time-line, what if every subsystem's maintainer 
submitted their queue of signed-off patches at fixed times, in rotating 
order? If every patch within, say the past few days, is from one 
subsystem, and a regular tester or prompt bug-reporter finds a 
regression, we would already know where the bug lives, or at least where 
it vacations.

Also, I was thinking that if every developer knows there are regular 
submission periods for the components they're interested in, they might 
feel like working more on things like refactoring, documentation, & 
bug-hunts during the rest periods. I'm biased because the wiki has 
partly become my baby in the project, but I think if there's one thing 
that might nudge more power-users/testers into becoming developers, it 
would be making the code-base easier to navigate. Refactoring and clear, 
up-to-date technical documentation (both specs like on WineAPI and 
implementation details) would be two immediate ways of accomplishing 
that, but both usually require the active developers' knowledge.

On 09/26/2015 12:11 PM, Rosanne DiMesio wrote:
> On Sat, 26 Sep 2015 09:07:56 -0700
> Ben Shadwick <benshadwick at gmail.com> wrote:
>> I know this is the devel list, but what does this mean for AppDB? You
>> mentioned being able to report bugs against wine-staging in the bug
>> tacker, but nothing about being able to submit compatibility reports
>> against it in the AppDB. These are currently rejected, which just
>> happened to me.
> They should be accepted, but getting the word out to all maintainers about that is going to be a problem.
>
> I've processed your report that was rejected.

Now for all of the user-facing parts of the project, I think if there's 
one smart investment we could make, it would be migrating WineHQ to a 
web-framework. With that, it should become much simpler to update static 
pages, coordinate AppDB, Bugzilla, the source, & the docs, give users a 
streamlined view of the whole project (and managing their account), and 
even cooler things hitherto unimagined.

I would be happy to try, but I really haven't had the time or energy to 
focus on that involved a project these past few years. If nobody else 
jumps on it first though, maybe I'll be available for that a year or two 
from now. I did do a little preliminary research, and was leaning away 
from the CMS-es (too restrictive and probably too much cruft) and 
towards Django actually.

That's largely just because Python has become my go-to language over the 
past few years, but it also seemed like Django is relatively good at 
sitting on top of independent components (or at least Google actually 
returned pages with advice on doing that; the docs for frameworks like 
Rails or CakePHP were vaguer). That way we shouldn't have to python-ize 
everything, but could just start with the views and account management, 
then make changes incrementally from there.

On 09/25/2015 04:45 PM, Tom Wickline wrote:
> Was a overhaul of winehq.org <http://winehq.org> discussed?  The site 
> really needs to be mobile friendly if you want the site to remain 
> relevant in the future.  :)

I could be wrong, but I expect this would be much simpler to do coming 
from a framework (with mobile helper packages) than the separate 
HTML/CSS for each sub-site we have now.

- Kyle