re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?
Joeseph wrote:
Is there a Git Repositories for Unaccept Patches or (work in Progress)?
Not really, but people often attach patches to bugzilla entries if they're not quite good enough to submit. And if anybody wants to start such a git repository, more power to them.
An ntoskrnl.exe was written a couple of years ago to load drivers, specifically the Safedisc Windows kernel driver, but it still hasn't been accepted.
The article you read is out of date; ntoskrnl.exe is now part of wine.
Basically threat unaccepted patch as bugs(while keeping the patch out of wine), instead of chucking it out the window.
As I said above, developers are free to attach patches to bug reports. What you're really trying to get at is: sometimes developers get discouraged at how hard it is to get patches into Wine. But no mechanical aid will really help there. The only cure is persistance on the part of the developer, and assistance (chiefly good feedback) from other Wine developers. After a developer gets a few patches committed, the wine process starts to feel a lot smoother. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Dan Kegel <dank(a)kegel.com> wrote:Dan Kegel wrote
Joeseph wrote:
Is there a Git Repositories for Unaccept Patches or (work >in Progress)?
Not really, but people often attach patches to bugzilla entries if they're not quite good enough to submit. And if anybody wants to start such a git repository, more power to them.
Thank I did not know that.
An ntoskrnl.exe was written a couple of years ago to load drivers, specifically the Safedisc Windows kernel driver, but it still hasn't been accepted.
The article you read is out of date; ntoskrnl.exe is now part >>of >wine.
This is good to here to.
Basically threat unaccepted patch as bugs(while keeping >>the patch out of wine), instead of chucking it out the window.
As I said above, developers are free to attach patches to bug >reports.
What you're really trying to get at is: sometimes developers get discouraged at how hard it is to get patches into Wine. But no mechanical aid will really help there. The only cure is persistance on the part of the developer, and assistance (chiefly good feedback) from other Wine developers. After a developer gets a few patches committed, the wine process starts to feel a lot smoother.
That basically what i said yes but, the main reason I wanted the git Repositories was it more an acknowledge that you did do something and set a flag developer could use to help people if they wanted to. Please don't take this the wrong way but, Set a patch that was rejected as a bug report seem to be a round about way of doing thing and a little air-i-gent to me is it not to you? If this is the way thing are done, why is it not listed in the doc on found on winehq site, or was it there and I missed it. Thank Dan you where a big help. James Hawkins wrote:
And anyone can publish GIT repos, there is problem with that. (And repos.cz (?) has several of them already.)
-- James Hawkins
I never said you should allow everybody access just those who sud-met-ted a fairly good patch I never saw that site thou,(what is Thank for the tip. I browsed the wiki several times. I never really saw it as hack and i be-leave that why i missed it. Thanks. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Here we go again. Please read the archives. At least last few weeks would have pointed you to exactly the same topic which comes back again and again: http://www.winehq.org/pipermail/wine-devel/2006-September/thread.html#50915 And please respect everyone and don't use that color thingy in mailing lists (plain text no html). Vitaliy. Joseph Stein wrote:
skipped as it's impossible to read.
On Feb 10, 2008 1:55 PM, Dan Kegel <dank(a)kegel.com> wrote:
Joeseph wrote:
Is there a Git Repositories for Unaccept Patches or (work in Progress)?
Not really, but people often attach patches to bugzilla entries if they're not quite good enough to submit. And if anybody wants to start such a git repository, more power to them.
+1 I've got a local git repo setup where I have the winequartzdrv from darwine sitting and I have been trying to bring up to date but never have time to mess with it. It would be cool if we had a repo for unacceptable patches that we could write to and maintain branches on for projects like this because with others working on it it might one day evolve in to the shape of something he would accept. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
On Feb 10, 2008 1:55 PM, Dan Kegel <dank(a)kegel.com> wrote:
Joeseph wrote:
Is there a Git Repositories for Unaccept Patches or (work in Progress)?
Not really, but people often attach patches to bugzilla entries if they're not quite good enough to submit. And if anybody wants to start such a git repository, more power to them.
+1
I've got a local git repo setup where I have the winequartzdrv from darwine sitting and I have been trying to bring up to date but never have time to mess with it. It would be cool if we had a repo for unacceptable patches that we could write to and maintain branches on for projects like this because with others working on it it might one day evolve in to the shape of something he would accept.
I would like to 'chime' in here. If you have it local and it is not complete, why submit to the main program flow. Create a bug and put it there. Simple and it keeps the code tree "clean". This allows others to become aware of what you are up to and can increase collaboration. Otherwise, your work becomes 'lost' and will never be complete. I would NEVER submit anything to the tree that is not complete and ready for review by Alexandre. I have been a victim of the dreaded drop, but that is not because the code I submitted was incomplete, but parts of it have become irrelivant because of changes to the tree. So, I've had to back up and redo the work and then collaborate with the original submitter and have a peer review and then submit. Hopefully this will be applicable to your project. Again, to summarize, if your code is not ready for Alexandre's review, open a bug, put your changes there, let the development list know and kick back and see what happens. If you need help, submit your code and then let others help. Don't expect things to happen overnight, sometimes it can take weeks or months. Also, I am very interested in your work on winequartz, please let me know what the bug number is. James McKenzie
On Feb 10, 2008 11:18 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote:
I would like to 'chime' in here. If you have it local and it is not complete, why submit to the main program flow. Create a bug and put it there. Simple and it keeps the code tree "clean". This allows others to become aware of what you are up to and can increase collaboration. Otherwise, your work becomes 'lost' and will never be complete. I would NEVER submit anything to the tree that is not complete and ready for review by Alexandre. I have been a victim of the dreaded drop, but that is not because the code I submitted was incomplete, but parts of it have become irrelivant because of changes to the tree. So, I've had to back up and redo the work and then collaborate with the original submitter and have a peer review and then submit. Hopefully this will be applicable to your project. Again, to summarize, if your code is not ready for Alexandre's review, open a bug, put your changes there, let the development list know and kick back and see what happens. If you need help, submit your code and then let others help. Don't expect things to happen overnight, sometimes it can take weeks or months. Also, I am very interested in your work on winequartz, please let me know what the bug number is.
I am not talking about submitting anything broken to the main Wine tree. I was talking about having seperate repo that would allow for a limited amount of brokeness on public branches. The simple fact is that too much in mainline Winehq has changed from when winequartzdrv was first written and it needs to be in a tree somewhere that is public so there can be a merge and collaboration to fix the brokeness. Off the top of my head there is problems with visable region handling that was moved in to wineserver and CreateWindow abstraction that need to be fixed. Not to mention the fact Alexandre views the entire design to be flawed as is...Development of major new features like this out of bugzilla is a non-starter. See ntoskrnl development history for example. Let me put it another way. Having worked on multiple maintainer projects with public write access repositories and a single maintainer repo like Wine I know the up and down side of both methods, but it will be a cold day in hell before I waste my time trying to do any sort of major infrastructure work over bugzilla with plain diffs. Gits design is supposed to remove the need for such development practices. Its already in CVS in darwine but that does not make for easy merging so I fail to see how bugzilla + diff's is supposed to be a more effective development method. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Feb 11, 2008 12:52 AM, Steven Edwards <winehacker(a)gmail.com> wrote:
Let me put it another way. Having worked on multiple maintainer projects with public write access repositories and a single maintainer repo like Wine I know the up and down side of both methods, but it will be a cold day in hell before I waste my time trying to do any sort of major infrastructure work over bugzilla with plain diffs. Gits design is supposed to remove the need for such development practices. Its already in CVS in darwine but that does not make for easy merging so I fail to see how bugzilla + diff's is supposed to be a more effective development method.
Sorry I didn't mean for that to sound quite so rude. Having invested a good bit of time in trying to understand git, I think I git it now so to speak and not having a public repo where there can be really collaborative development seems to be a step back to me. Not that bugzilla + diff's is bad. Its great for minor enhancements and small patches that are not ready to go in but for major new developments requiring multiple eye balls, a shared repository is the only sane way to go. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Feb 10, 2008 9:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
... Having invested a good bit of time in trying to understand git, I think I git it now so to speak and not having a public repo where there can be really collaborative development seems to be a step back to me.
? But you don't need a central public git repository to do collaborative development, that's the whole point of git... - Dan
On Feb 11, 2008 12:59 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Feb 10, 2008 9:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
... Having invested a good bit of time in trying to understand git, I think I git it now so to speak and not having a public repo where there can be really collaborative development seems to be a step back to me.
? But you don't need a central public git repository to do collaborative development, that's the whole point of git...
Maybe I still don't get git. Right now there are not many others interested in winequartzdrv and the only place its hosted is in CVS. I've got it imported locally and I can publish changesets on wine-patches or bugzilla but thats going to spam wine-patches or be very sucky for development if its not ready to merge in to master for months++ or longer. For a proper push or pull to work, I'd either have to publish my repo here or someone else would have to pick it up and import it right? Then we could rebase off of each others changes? We could push and pull to each other via email and still pull in from winehq and rebase right? Then wouldn't that imply that I'd have to push my changes to everyone via a mailing or something or still host my own public repo if multiple people want to pull from my most recent bleeding edge broken stuff? It seems to me that its less trouble to have a central repo hosted somewhere like repo.or.cz where winehq origin is imported in parallel and as changes come in they are merged on to a public winequartzdrv branch. Then I fix the stuff I know I can fix in my local tree like the keyboard input handling changes, push those changes up, while leaving other broken stuff like visable region handling for someone else to work on. If others come along with an existing winehq tree, they can pull from that repo without much trouble. I've still got my local git repo I can branch off of and hack the hell out of and cherry pick patches from, push them up to the winequartdrv branch on the public repo, etc. Thats in effect what I have here. I've got a faux-public git repo and a private repo where I pull winehq origin in I pull the faux-public's quartzdrv branch in, I rebase winehq on top of my private branch, fix the changes and then push the new "stable" winequartzdrv up to my faux-public repos winequartzdrv branch. It would work really well for others to pull and push from except. A. I don't want to host it on my cable modem and B. I can't commit to running it due to lack of time and skill with the code in question. I can do minor enhancements like fix up the changes for mouse/keyboard handling now that its moved to the server but as far as actual design and real programming go I don't view myself and competent enough to waste my or anyone elses time publicly hosting. I just did all of this as a experiment to teach myself git. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Feb 11, 2008 1:28 AM, Steven Edwards <winehacker(a)gmail.com> wrote:
It seems to me that its less trouble to have a central repo hosted somewhere like repo.or.cz where winehq origin is imported in parallel and as changes come in they are merged on to a public winequartzdrv branch. Then I fix the stuff I know I can fix in my local tree like
So now that I've spammed the list enough I see in the other thread people already have branches hosted on repo.or.cz. I guess I will push my winequartzdrv there. Before these threads I didn't know anyone was hosting wine related stuff there so send my spam to /dev/null -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Feb 10, 2008 11:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
On Feb 11, 2008 12:52 AM, Steven Edwards <winehacker(a)gmail.com> wrote:
Let me put it another way. Having worked on multiple maintainer projects with public write access repositories and a single maintainer repo like Wine I know the up and down side of both methods, but it will be a cold day in hell before I waste my time trying to do any sort of major infrastructure work over bugzilla with plain diffs. Gits design is supposed to remove the need for such development practices. Its already in CVS in darwine but that does not make for easy merging so I fail to see how bugzilla + diff's is supposed to be a more effective development method.
Sorry I didn't mean for that to sound quite so rude. Having invested a good bit of time in trying to understand git, I think I git it now so to speak and not having a public repo where there can be really collaborative development seems to be a step back to me. Not that bugzilla + diff's is bad. Its great for minor enhancements and small patches that are not ready to go in but for major new developments requiring multiple eye balls, a shared repository is the only sane way to go.
This sparked a memory of the discussion about having a -devel and a -stable branch after we release 1.0. -- James Hawkins
On Feb 10, 2008 10:02 PM, James Hawkins <truiken(a)gmail.com>
This sparked a memory of the discussion about having a -devel and a -stable branch after we release 1.0.
Oh, yeah. IMHO we should release 1.0.0 and 1.1.0 at the same time, and treat 1.0.x as our stable branch.
participants (6)
-
Dan Kegel -
James Hawkins -
James McKenzie -
Joseph Stein -
Steven Edwards -
Vitaliy Margolen