first contribution

[Shane Shields]

hi all,

as my first contribution (implies that there is more to come ;-}) i have 
found and fixed a (very) minor bug in updown.c but i am at a loss as to what 
to do next. having read the documentation on cvs commit or cvs diff -u  i am 
still scratching my head in confusion. can somebody give me a newbie type 
pointer as to what i can do? i have downloaded the latest cvs (todays date 
13/1/2002) using cvs update -PAd, altered updown.c, tested that it compiles 
and am now waiting on fireproof instructions for the next steps (i burn 
easily :-)).

Shane Shields

To be a *nix programmer or to be a windows progammer that is the question. 
The answer is simple...Be a WINE programmer and do both.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Dan Kegel]

Shane Shields wrote:
> hi all,
>
> as my first contribution (implies that there is more to come ;-}) i have
> found and fixed a (very) minor bug in updown.c but i am at a loss as to what
> to do next. having read the documentation on cvs commit or cvs diff -u  i am
> still scratching my head in confusion. can somebody give me a newbie type
> pointer as to what i can do? i have downloaded the latest cvs (todays date
> 13/1/2002) using cvs update -PAd, altered updown.c, tested that it compiles
> and am now waiting on fireproof instructions for the next steps (i burn
> easily :-)).

http://www.winehq.com/dev.shtml#sourcetree says:
> Please submit patches to the Wine patches mailing list,
> [e-mail]. (Note that if you're not
> subscribed to the mailing list, the mailing list administrators
> must first check your submission to make sure it's not spam
> before they can let it through.)
>
> It's best to send small patches against the current tree. Update
> your tree first, then generate the patch from the top wine
> directory. cvs diff will always ignore newly added files, so
> you'll need to do something like
>   diff -u /dev/null newfile.c >> patch.diff
> to make a patch for newly added files. Include a comment for the logs.
> Use
>    diff -Nu olddir/ newdir/
> in case of multiple files to add.

I think that page needs some improvment.  Hmm, how about this:

--------

Please read through ten or twenty posts from the wine-patches 
mailing list to see what the prevailing style is.

To fix a single file and submit a patch for it, follow this
recipe (where $WINETOP stands for the top wine directory):
   # Back up the file you want to change
   cd $WINETOP/foo/bar
   cp blort.c blort.c.orig
   # Make your changes
   vi blort.c   
   # cd to the top of the wine tree, e.g.
   cd $WINETOP
   # Create a unified diff
   diff -u foo/bar/file.c{.orig,} > my-blort.patch

To make a fix that affects multiple files and perhaps adds new ones, follow these steps:
   # Save an untouched version of the whole wine
   # source tree in a directory named wine-yyyymmdd:
   cp -r wine wine-20020204
   # Make your changes
   ...
   # cd to the top of the wine tree, e.g.
   cd $WINETOP/..
   # Create a unified diff
   diff -Naur wine-20020204 wine > my-big.patch

To submit a patch:
   Write a description of your patch, including changelog entry showing 
   what you did to each file.  For instance:
> WaitForInputIdle is supposed to time out after a given time. But the
> algorithm was:
>
> while ( dwTimeOut > GetTickCount() - cur_time ...) {
>      MsgWaitForMultipleObjects(...dwTimeOut...);
>      ...
>    }
>
> So if dwTimeOut is 60 seconds, and a message is received after 59
> seconds, then WaitForInputIdle would be stuck in
> MsgWaitForMultipleObjects for an extra 60 seconds. Waiting 119 seconds
> in all.
>
> With this patch this should not longer be the case. Other interesting
> features: the unsigned int arithmetic, especially wrt. wrap-arounds.
> It's a bit weird but should work.
>
> Changelog:
>
> François Gouget
> - windows/message.c
> Better handling of the timeout in WaitForInputIdle
> Use WAIT_FAILED rather than the corresponding literal

Then email the description together with the patch to the 
wine-patches mailing list, using a descriptive subject 
line (e.g. "Prevent infinite wait in WaitForInputIdle").

(Be careful to not corrupt the patch; if you're using a gui
mailer like Outlook, you may need to attach the patch file
instead of simply inserting it in your message to avoid corruption.)

-----------

How's that look?

- Dan

[James Juran]

Dan Kegel wrote:
> http://www.winehq.com/dev.shtml#sourcetree says:

[...]
> I think that page needs some improvment.  Hmm, how about this:

[...]

Thanks.  I revised this a bit and added it to
http://www.winehq.com/dev.shtml.  It should be get updated out of the
CVS repository soon.  I left out the non-CVS patch generation
instructions to save space, since we want to encourage developers to use
CVS.  Please let me know what you think.

James

--
James Juran
[e-mail]

[Dan Kegel]

James Juran wrote:
> Dan Kegel wrote:
> > http://www.winehq.com/dev.shtml#sourcetree says...
> >
> > I think that page needs some improvment.  Hmm, how about ...
>
> Thanks.  I revised this a bit and added it to
> http://www.winehq.com/dev.shtml.  It should be get updated out of the
> CVS repository soon.  I left out the non-CVS patch generation
> instructions to save space, since we want to encourage developers to use
> CVS.  Please let me know what you think.

Looks good.  I would also suggest:
* add "Submitting Patches" to the table of contents, with a hyperlink,
  so I can link to it.
* Spring cleaning: get rid of the "policies" heading and the
  "daily build and test" section, and set the "Submitting Patches"
  section apart with <hr>'s
* Formatting: I'd suggest <blockquote> or <pre> around example code 
  rather than <br>.

Thanks for tidying that up!
- Dan