Default printer and patch management
mike at theoretic.com
Thu Nov 27 15:37:16 CST 2003
Hi, I've got a couple of questions tonight:
1) Currently the default printer is read from win.ini - setting this is
annoying and doesn't work out of the box. I think it'd make more sense
to have it also in the wine configuration, so if no win.ini string is
retrieved it'll still work. I have an app here that dies if there is no
default printer. Is it acceptable to make a fallback in the
registry/config branch? The default would be "Wine Postscript Driver",
though I guess we could be clever - enumerate the printers actually
installed and pick the first. I don't know enough about printing to say.
2) The reason I've been so quiet on the winecfg front lately (ignoring
university) is because I'm working on porting an app commercially. As a
part of that process, I'm generating patches and committing to a private
branch. However, I'm not sure how best to manage patch submission. There
are a few alternatives:
a) Just keep them "secret" until I get paid, at which point I send them
in all together. Pros: Simple, Cons: people might duplicate my work.
b) Notify the Wine community of what the patches do/are but keep their
contents secret. Pros: Less chance of duplication, Cons: if people need
the patch, knowing I have one won't be much use and it'd be hard to
notify people without spamming the mailing list. Not enough people
monitor bugzilla for me to be sure it'd work.
c) Post them all to wine-devel but under a license that prevents them
being merged unless you get a special exception from me. That way people
can see, peer review the patches etc but they don't get committed. Of
course, as this is just supposed to be insurance anyway, that seems a
d) Say "screw it", submit as usual and just hope I'm dealing with
trustworthy people (unfortunately no contract in this case, the job
isn't really big enough to warrant one).
Does anybody have any experience of this? What is the best approach?
More information about the wine-devel