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; the slides can be viewed at http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=...
We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are:
- 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.
- Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla.
- 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.
- There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches.
- The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved.
- We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements.
These changes will be implemented over the next few weeks.
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.
Hello Everyone,
Due to prior commitments I was not available to attend this years conference. I have a few questions and suggestions maybe you guys can help me and others better understand the forthcoming changes.
I as well as others are not totally aware of the changes, see. : http://wine-staging.com/news/2015-09-25-winehq-integration.html
Would it be possible to have a wine-staging dev mailing list setup? A wine-staging patches mailing list setup? A wine-staging announce list setup?
A new section in the forums for wine-staging added?
Will the wine-staging releases be listed in the latest releases on winehg.org?
Will wine-staging releases be run in the news section of winehq.org?
Who will be the primary maintainer of wine-staging? Or list of maintainers if multiple people have commit privileges...
Was a overhaul of winehq.org discussed? The site really needs to be mobile friendly if you want the site to remain relevant in the future. :)
Wine-staging currently has Mac OSX binary builds, does winehq plan to have Mac OSX binary builds in the future?
Cheers, Tom On Sep 25, 2015 5:17 PM, "Alexandre Julliard" julliard@winehq.org 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; the slides can be viewed at
http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=...
We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are:
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.
Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla.
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.
There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches.
The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved.
We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements.
These changes will be implemented over the next few weeks.
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.
-- Alexandre Julliard julliard@winehq.org
On Sat, 26 Sep 2015 06:45:53 +0800 Tom Wickline twickline@gmail.com wrote:
A new section in the forums for wine-staging added?
Why? We don't have separate sections for stable and development. The point is to integrate wine-staging users, not separate them. Linux users should post in the Linux subforum, Mac users in the MacOSX subforum.
It's inclusion with options, but if *YOU* are against it, be prepared to ask end users if they are having issues or praise with what branch on a continues basis.
Because to most end users it will just be referred to simply as Wine. On Sep 26, 2015 8:57 AM, "Rosanne DiMesio" dimesio@earthlink.net wrote:
On Sat, 26 Sep 2015 06:45:53 +0800 Tom Wickline twickline@gmail.com wrote:
A new section in the forums for wine-staging added?
Why? We don't have separate sections for stable and development. The point is to integrate wine-staging users, not separate them. Linux users should post in the Linux subforum, Mac users in the MacOSX subforum.
-- Rosanne DiMesio dimesio@earthlink.net
On Sat, 26 Sep 2015 15:28:46 +0800 Tom Wickline twickline@gmail.com wrote:
It's inclusion with options, but if *YOU* are against it, be prepared to ask end users if they are having issues or praise with what branch on a continues basis.
Because to most end users it will just be referred to simply as Wine.
I guess you don't read the forum much, or you'd know that I already have to ask most users what Wine version they're using, and Wine-staging users have been posting there all along. The difference now is that I won't have to tell them to go away.
You are correct, I don't anymore! Or file bugs, or post here very often...
-Tom On Sep 26, 2015 7:46 PM, "Rosanne DiMesio" dimesio@earthlink.net wrote:
On Sat, 26 Sep 2015 15:28:46 +0800 Tom Wickline twickline@gmail.com wrote:
It's inclusion with options, but if *YOU* are against it, be prepared
to
ask end users if they are having issues or praise with what branch on a continues basis.
Because to most end users it will just be referred to simply as Wine.
I guess you don't read the forum much, or you'd know that I already have to ask most users what Wine version they're using, and Wine-staging users have been posting there all along. The difference now is that I won't have to tell them to go away.
-- Rosanne DiMesio dimesio@earthlink.net
Hi,
Who will be the primary maintainer of wine-staging? Or list of maintainers
if multiple people have commit privileges...
The same guys who maintained wine-staging before will now be maintaining it as a part of winehq. AFAIK Sebastian Lackner and Michael Müller are the current maintainers.
Wine-staging currently has Mac OSX binary builds, does winehq plan to have Mac OSX binary builds in the future?
Yes, we had discussed the possibility of using the build scripts for OSX too. Their build scripts have the option to build vanilla wine without the staging patches, so why not? :)
I'll notify the maintainers on IRC, hopefully they should answer the rest of your questions :)
Cheers, Aaryaman
Tom Wickline twickline@gmail.com writes:
Would it be possible to have a wine-staging dev mailing list setup? A wine-staging patches mailing list setup? A wine-staging announce list setup?
A new section in the forums for wine-staging added?
Will the wine-staging releases be listed in the latest releases on winehg.org?
Will wine-staging releases be run in the news section of winehq.org?
We haven't discussed all the implementation details yet, but the point is to treat wine-staging as just another Wine version. So there shouldn't be any reason to have separate mailing lists, announce channels, download pages, etc. It's all just Wine.
What if someone is interested in one version and not the other?
-Tom On Sep 26, 2015 7:35 PM, "Alexandre Julliard" julliard@winehq.org wrote:
Tom Wickline twickline@gmail.com writes:
Would it be possible to have a wine-staging dev mailing list setup? A wine-staging patches mailing list setup? A wine-staging announce list setup?
A new section in the forums for wine-staging added?
Will the wine-staging releases be listed in the latest releases on winehg.org?
Will wine-staging releases be run in the news section of winehq.org?
We haven't discussed all the implementation details yet, but the point is to treat wine-staging as just another Wine version. So there shouldn't be any reason to have separate mailing lists, announce channels, download pages, etc. It's all just Wine.
-- Alexandre Julliard julliard@winehq.org
Alexandre,
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.
Thanks, - Ben S.
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.
On Sat, 26 Sep 2015 13:11:59 -0500 Rosanne DiMesio dimesio@earthlink.net wrote:
They should be accepted, but getting the word out to all maintainers about that is going to be a problem.
I found an "Email all maintainers" link on the Maintainers list, and just sent an email informing maintainers of the change. I don't know how well that will work.
That was unexpected, thanks. Maybe putting a banner at the top of the AppDB area of the site for a while would help?
On Sat, Sep 26, 2015 at 11:11 AM, Rosanne DiMesio dimesio@earthlink.net 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.
-- Rosanne DiMesio dimesio@earthlink.net
On 26 September 2015 at 19:11, Rosanne DiMesio dimesio@earthlink.net 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.
-- Rosanne DiMesio dimesio@earthlink.net
Hi folks,
I noticed that AppDB screenshots haven't been updated to allow users to specify Wine Staging versions... Is that planned? Or should I file a bug against this??!! :-)
On Sat, 10 Oct 2015 23:37:01 +0100 Bob Wya bob.mt.wya@gmail.com wrote:
I noticed that AppDB screenshots haven't been updated to allow users to specify Wine Staging versions... Is that planned? Or should I file a bug against this??!! :-)
--
I've already filed a bug: https://bugs.winehq.org/show_bug.cgi?id=39382.
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
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.
+1 for python. I have basic experience with django. I can try to
contribute on the backend of things, if needed.
Cheers, Aaryaman
On Fri, Sep 25, 2015 at 2:16 AM, Alexandre Julliard julliard@winehq.org wrote:
- We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements.
This is encouraging and I'd really like to talk a bit further about this. I've been shirking my packaging duties for a while and complaint mails are piling up.
For Ubuntu I think maintaining the PPA is the correct way forward and at this point it should be relatively easy to set up automated builds of both wine and wine-staging that produce a new packages whenever there is an upstream release tag.
If anyone wants to talk about consolidating this more please message me directly.
-
Aaryaman Vasishta -
Alexandre Julliard -
Ben Shadwick -
Benjamin Shadwick
-
Bob Wya -
Kyle Auble -
Rosanne DiMesio -
Scott Ritchie -
Tom Wickline