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