GSoC 2009 Final evaluations due
Hi folks, GSoC 2009 is wrapping up and the final evaluations are due. So far only one student and no mentors have filled out the surveys, so please take your time and take care of that soon. The results are due on Monday, but I'd prefer if I had some room to deal with any issues coming up, so please try to get the surveys in as soon as possible. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
GSoC 2009 final week of coding started
Hi GSoC students, hi mentors, just a little heads up that the final week of coding for GSoC started on Monday. The program timeline suggests that you start with writing documentation and tests now, but check with what your mentors think you should work on. Firm "pencils down" date is next Monday. Also see http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline for the timeline. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: GSoC 2009
2009/3/29 Tim Felgentreff : > > Owen Rudge wrote: >> If you have had exposure to Microsoft source code, then I believe I'm >> right in saying that you are not able to work on Wine, I'm afraid. > I have written to the Software Freedom Law Center about this, but the License > included with the Windows Research Kernel is actually pretty permissive (even > allowing me to copy a small number of lines of code, actually. Which I wasn't > going to do anyway though). It's not just about licensing, it's also about keeping Wine Wine. We don't really want people to say "this is how it's done in Windows, I've seen the source!", we want *proper* tests backing up patches and new implementations. At least, that's my interpretation of the SoC rules :)
Re: GSoC 2009
Owen Rudge wrote: > If you have had exposure to Microsoft source code, then I believe I'm > right in saying that you are not able to work on Wine, I'm afraid. I have written to the Software Freedom Law Center about this, but the License included with the Windows Research Kernel is actually pretty permissive (even allowing me to copy a small number of lines of code, actually. Which I wasn't going to do anyway though). > I worked on the control panel last year, and was in the process of > converting some winecfg pages to separate applets - indeed, there's some > outstanding work in my git repository that needs finishing/merging (but > I have had a lack of time to work on this year, sadly.) Assuming you > aren't barred from contributing for the aforementioned legal reasons, > then there is lots more work that can be done on improving Wine > configuration and so on if you're interested in that. Theming and the > test suite are also areas which could do with work though, and you may > be able to make a more substantial project out of those areas. Thanks, then I will have a closer look at the test suite and at the themeing stuff and maybe apply for a project in one of these areas. Regards, -Tim
Re: GSoC 2009
Hi Tim, I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. (I seem to recall reading somewhere that it might be OK for you to work on, say, client apps if you've only seen kernel code, but I might be wrong - somebody else will no doubt know better.) I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. I worked on the control panel last year, and was in the process of converting some winecfg pages to separate applets - indeed, there's some outstanding work in my git repository that needs finishing/merging (but I have had a lack of time to work on this year, sadly.) Assuming you aren't barred from contributing for the aforementioned legal reasons, then there is lots more work that can be done on improving Wine configuration and so on if you're interested in that. Theming and the test suite are also areas which could do with work though, and you may be able to make a more substantial project out of those areas. Cheers, -- Owen Rudge http://www.owenrudge.net/
GSoC 2009
Hi, I'm currently an IT student in Germany in my 2nd year. I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. Regards, Tim
Re: GSoC 2009 Proposal - AppDB Assistant
Ben Klein schrieb: Grabbing the version number of the application from the EXE metadata could prove to be unreliable. A lot of Windows apps don't include metadata, or include unusual values in the metadata. Then again, a lot of apps don't make it easy to see what the version you're using is in any other way, and as a result there are a lot of "1.0" versions on AppDB that map to "initial retail version". One example is Theme Hospital, which as the original retail version was released as "Beta 4", and Bullfrog provided a patch that upgraded to "Beta 5". The only hint of version numbers is provided by the patch itself, and as a result some user wanted to submit a "1.0" version to indicate the original retail release. As I was a supermaintainer of Theme Hospital and already had the "Beta 4" version, I removed the 1.0 version and engaged in a lengthy email discussion over whether the retail release was "Beta 4" or "1.0". I am also afraid of reading this data, but we could give the user the choice to review it and correct it. There has been discussion about "preconfiguring" Wine with AppDB data, and the general consensus is that it's a bad idea. We run the risk of becoming like wine-doors, playonlinux, and other tools we don't support at WineHQ. The biggest problem is that there is no way to determine if any particular configuration will still work when a new version of Wine or a new version of the app is installed. There are also cases where installing a workaround/native DLL for one app will cause a whole lot of others to break. It is a hard discussion, so lets have it when we got the AppDB Assistant running ;) No, really, the basic idea is great, but we don't should do all at once. For GSoC i think the best parts are the basic software implementation and the communication to the server.
Re: GSoC 2009 Proposal - AppDB Assistant
2009/3/22 Illya Klymov : > So, let's imagine we have a software which I call "AppDB Assistant" with > following functionality: There has been quite some activity on wine-devel recently regarding the AppDB, including a few ideas on how to automate uploading information or configuring Wine based on AppDB entries. > 1) an ability to quickly submit a report about application to AppDB. A lot > of data (Wine version, Linux distribution, wine settings) could be obtained > automatically. An application information with high probability could be > fetched from meta data, stored in EXE file. In general, i see that like > after closing an app I see additional screen "Please take a couple of > seconds and send feedback about your experience with $SOFTWARE_NAME to > AppDB", and buttons "Platinum","Gold", etc. Of course this should be > configured via winecfg (if user do not want to obtain such data) Grabbing the version number of the application from the EXE metadata could prove to be unreliable. A lot of Windows apps don't include metadata, or include unusual values in the metadata. Then again, a lot of apps don't make it easy to see what the version you're using is in any other way, and as a result there are a lot of "1.0" versions on AppDB that map to "initial retail version". One example is Theme Hospital, which as the original retail version was released as "Beta 4", and Bullfrog provided a patch that upgraded to "Beta 5". The only hint of version numbers is provided by the patch itself, and as a result some user wanted to submit a "1.0" version to indicate the original retail release. As I was a supermaintainer of Theme Hospital and already had the "Beta 4" version, I removed the 1.0 version and engaged in a lengthy email discussion over whether the retail release was "Beta 4" or "1.0". > 2) an ability to generate a "configuration guide" - in this mode an "expert > user" selects important data to be included into a guide (for example that > app runs _only_ under Windows XP emulation, an important registry values > etc.). As a result a special file, describing an app-specific configuration > of wine is uploaded to appdb > 3) an ability to "preconfigure Wine". That means that based on > "configuration guide" created on step 2 "AppDB Assistant" can configure wine > in one click. If any additional dlls are required a warning message is > displayed with possible information where to obtain them. There has been discussion about "preconfiguring" Wine with AppDB data, and the general consensus is that it's a bad idea. We run the risk of becoming like wine-doors, playonlinux, and other tools we don't support at WineHQ. The biggest problem is that there is no way to determine if any particular configuration will still work when a new version of Wine or a new version of the app is installed. There are also cases where installing a workaround/native DLL for one app will cause a whole lot of others to break. > I see the following benefits on such software: > 1) increasing appdb actuality - with a way more data from users we can > provide more accurate info; > 2) simplified regression testing - for example if user downloaded a > "configuration guide" and it didn't work with newer wine - this is a > possible regression (decreased chance of human error) Regression testing is *only* useful if there are no native DLL overrides configured. Test data submitted using a set of pre-configured overrides is nowhere near ideal for Wine.
GSoC 2009 Proposal - AppDB Assistant
Hi all! A new GSoC is coming, and i have an idea which can may (or may not) serve as a proposal for a Wine project. Let's speak about it not as an application (so I wouldn't tell a lot about myself) but as an idea for application. AppDB is an excellent service for helping users dealing with one or another software. Unfortunately, currently i see several problems, which decrease it's efficiency: 1) there are tons of successful (or maybe not successful) reports, which were not submitted to AppDB. People are too lazy to fill many forms. A lot of users will just go away instead of filling report about application. 2) often in order to run an application you should follow some weird instructions, which sometimes miss some important steps, or require additional research by yourself. So, let's imagine we have a software which I call "AppDB Assistant" with following functionality: 1) an ability to quickly submit a report about application to AppDB. A lot of data (Wine version, Linux distribution, wine settings) could be obtained automatically. An application information with high probability could be fetched from meta data, stored in EXE file. In general, i see that like after closing an app I see additional screen "Please take a couple of seconds and send feedback about your experience with $SOFTWARE_NAME to AppDB", and buttons "Platinum","Gold", etc. Of course this should be configured via winecfg (if user do not want to obtain such data) 2) an ability to generate a "configuration guide" - in this mode an "expert user" selects important data to be included into a guide (for example that app runs _only_ under Windows XP emulation, an important registry values etc.). As a result a special file, describing an app-specific configuration of wine is uploaded to appdb 3) an ability to "preconfigure Wine". That means that based on "configuration guide" created on step 2 "AppDB Assistant" can configure wine in one click. If any additional dlls are required a warning message is displayed with possible information where to obtain them. I see the following benefits on such software: 1) increasing appdb actuality - with a way more data from users we can provide more accurate info; 2) simplified regression testing - for example if user downloaded a "configuration guide" and it didn't work with newer wine - this is a possible regression (decreased chance of human error) I realize that this is quite a big project, involving a different parts of Wine, but I'll be glad to hear response from community about this idea and which part probably could fit best for GSoC. Feel free to ask any question if something is unclear. P.S. Sorry for my bad English, it is far away from being my mother tongue. Best regards, Illya Klymov
GStreamer plugin proposal for GSoC 2009
Hi, I'm interested in working with you as a student to create a GStreamer plugin for Wine. First, a little background about me. I'm a 2nd year student from Bucharest, Romania; my major is Systems Engineering. Last summer I spent my time developing kmemtrace (a memory tracer for the Linux kernel) under the mentorship of Pekka Enberg from Linux Foundation, that is GSoC 2008. So this would be my second year in GSoC. And I do tend to stick around after the SoC is over, since it's a great opportunity to get comfortable with a code base. You can check out my coding style and performance by looking at these Git repos: Ingo Molnar's -tip tree (my current "upstream"): http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftip%2Flinux-2.6-tip.git&a=search&h=HEAD&st=author&s=eduard.munteanu My repo holding kmemtrace's userspace app: http://repo.or.cz/w/kmemtrace-user.git However, I'm aware of the differences in coding style between Wine and the Linux kernel. Regarding my skills, I'm quite proficient at using Git (managing my own tree and sending patches), coding in C and using autoconf. I also know some very basic concepts about DirectX, OpenGL and Wine's architecture. Also, this isn't my first contact with Wine's source code. Even though I haven't sent any patches to the mailing-list, I've spent some time reading the source code (chasing performance issues in Direct3D, but to no avail). You might have also seen me on IRC, bugging people about those issues. :-) Now getting to the point... I find the GStreamer plugin a very good idea. Glancing over GStreamer docs, I see it's very modular and could solve more issues than those already mentioned on the GSoC ideas page. I'll focus on what hasn't already been told. Firstly, it could also improve GDI+'s handling of images, as GStreamer already handles some image formats. Secondly, I've seen a patch implementing texture handling in d3dx being rejected because there is no general image library support in Wine and FreeImage wasn't a comfortable dependency: http://archives.free.net.ph/message/20080828.215032.87fd785e.en.html So this work could also have a positive impact on the proposal regarding the implementation of d3d9_xx DLLs. Bottom line is this won't "just play movies for DirectShow/Quartz", but it has a much greater potential. I admit, my main interest in developing Wine is improving a few games (e.g. Oblivion). I find this GSoC idea quite achievable for my skills and positive towards this goal. I also hope this experience would make a good introduction to implementing better DirectX support on Wine, generally speaking. Please let me know what you think and whether I've missed something. And please keep me Cc-ed if more people pitch into the discussion, as I'm not subscribed to the mailing-list. Cheers, Eduard
Re: GSoC 2009 application sent
On Thursday 12 March 2009 16:58:19 Owen Rudge wrote: Hi Owen, > What kind of would be involved in being a backup admin? I could perhaps > put myself forward for this - hopefully of course you won't be hit by > any buses, though. ;-) Well, basically you need to take over for the org admin if needed and - at the start of the program, accept known developers as mentors and reject people you don't know - during the program, make sure that all the mentors are still active and organize a backup mentor if a mentor disappears (not happened to me before) - at the mid-term, chase all the mentors to turn in their mid-term evaluations - at the end of the program, chase all the mentors to turn in their final evaluations. That's pretty much it. If you admin or mentor, you can't participate in GSoC as a student. If you're interested, log into melange (http://socghop.appspot.com/), create a link_id and tell me that link_id. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: GSoC 2009 application sent
One more thing. Maarten doesn't have time to do this, so I would need someone as a backup admin to take over in case I'm hit by a bus or the like. I was acting as Maarten's backup last year, and I didn't have to do a thing. :) I'll also promise to be careful when crossing roads, it's just a safety measure to make sure I'm not the single point of failure. What kind of would be involved in being a backup admin? I could perhaps put myself forward for this - hopefully of course you won't be hit by any buses, though. ;-) Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSoC 2009 application sent
On Tuesday 10 March 2009 10:28:00 Kai Blin wrote: One more thing. Maarten doesn't have time to do this, so I would need someone as a backup admin to take over in case I'm hit by a bus or the like. I was acting as Maarten's backup last year, and I didn't have to do a thing. :) I'll also promise to be careful when crossing roads, it's just a safety measure to make sure I'm not the single point of failure. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
GSoC 2009 application sent
Hi folks, I've just sent our application for this year's Summer of Code. Could everyone please have another look at the proposed projects at http://wiki.winehq.org/SummerOfCode to see if all the proposals are still current. Feel free to discuss new project ideas on the mailing list as well. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: GSoC 2009 coming up
> My biggest motivation for requiring weekly status updates is that in the past > years I had a hard time following the GSoC projects I was not involved with > directly. At WorldForge, we required weekly reports to the mentor at first > and then decided that the weekly reports should go to the developer mailing > list. That kept everybody informed what was going on. I would say this seems sensible - the weekly reports would not necessarily have to be greatly detailed, but I imagine it would help to keep students on track, and would enable the rest of the community to know what's going on with the students. From experience, I would say that I probably only tended to post on the lists when I had specific problems, or patches to submit, so a weekly update would have likely resulted in more interaction. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSoC 2009 coming up
On Tuesday 17 February 2009 04:41:11 Brian Vincent wrote: > On Sat, Feb 14, 2009 at 2:39 AM, Kai Blin wrote: > > We should also investigate possible changes to the requirements (weekly > > reports to the mailing list come to mind). Maarten, any comments? > > My gut instinct was weekly reports would be a bad idea for students - of > course they're just going to procrastinate until the last month and then do > all the work at once. Yes, Kai, I realize you were the exception to that > rule. That's not going to work anyway. There's a mid-term evaluation you're going to get failed at if you didn't produce anything until the mid-term. :) > Then my second thought was: "Hey, if this was the real world their manager > would certainly be expecting progress reports. Therefore mentors should > too." And, it makes for simple updates to include for WWN issues. I > think it'd be interesting to weekly or bi-weekly reports, but I think > mentors will need to apply a little tactful pressure in order to get the > status report updates. My biggest motivation for requiring weekly status updates is that in the past years I had a hard time following the GSoC projects I was not involved with directly. At WorldForge, we required weekly reports to the mentor at first and then decided that the weekly reports should go to the developer mailing list. That kept everybody informed what was going on. Also, if the weekly reports don't only include "that's what I did last week" but also "this is my plan for the next week", students can get early feedback if whatever they're planning to do next looks like a bad idea to some other developer. It also helps integrating the students in the community, as they're not only talking to their mentor. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: GSoC 2009 coming up
Would it also be possible for someone to revisit the past GSOC's ( http://wiki.winehq.org/SummerOfCode/PreviousProjects ) and state what happened with each projects contributions in relation to being added to Wine, etc.. - Nat --- On Sat, 14/2/09, Kai Blin wrote: > From: Kai Blin > Subject: GSoC 2009 coming up > To: "wine-devel@winehq.org" > Received: Saturday, 14 February, 2009, 8:39 PM > Hi folks, > > the organization application period for GSoC 2009 is > starting on March 9th, so > it's time to get our > http://wiki.winehq.org/SummerOfCode wiki page in shape > again. Detlef Riekenberg and Roderick Colenbrander made a > good start, so if > the rest of you could check and make sure that all the > projects on there > still make sense? > > We should also investigate possible changes to the > requirements (weekly > reports to the mailing list come to mind). Maarten, any > comments? > > Cheers, > Kai > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developerhttp://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more
GSoC 2009 coming up
Hi folks, the organization application period for GSoC 2009 is starting on March 9th, so it's time to get our http://wiki.winehq.org/SummerOfCode wiki page in shape again. Detlef Riekenberg and Roderick Colenbrander made a good start, so if the rest of you could check and make sure that all the projects on there still make sense? We should also investigate possible changes to the requirements (weekly reports to the mailing list come to mind). Maarten, any comments? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
