Organizing This Fork #164
Replies: 24 comments
-
|
Agree with your points in order to make this project, not an unnoficial fork, but an official project. Which in fact, reflects more precisely what is it, with lots of activity thanks to Jiri, as oposite to official project. Personally, I like a lot the name of "Free Watcom", which is more clear than even "Open Watcom", because it is not only open, but also free. So I would start with 1). Later points seems a bit more complicating, and with lots of management to be completed, so it maybe can happen in a second phase. |
Beta Was this translation helpful? Give feedback.
-
|
These ideas excite me, except for the name change. The path that you suggest, though, embraces the view that OWv2 is a HOSTILE fork of OW. I've conversed with one of the people involved with OW 1.9, and he seemed to be quite open to reconciling with Jiri. Before this fork becomes hostile to the OW group, both groups should reopen communication and make an energetic and sincere attempt to negotiate their disagreements. The disagreement appears to center on quality control (QC). I don't think that there is any difference of vision. As long as the disagreement is over "how to get there" rather than "where to go", everyone involved in this code (either fork) should remain united by the purpose and committed to working out any disagreements over method. My advice to Jiri: Do what you can to accommodate whoever wants more QC, as long as the processes that they propose will not hobble your creative flow and the rapid pace with which you are producing code. My advice to the 1.9 people: Do whatever you can to accommodate Jiri. Tread very lightly with your QC processes. As much as possible, impose them upon the code but not upon the coders. Becoming a hostile fork is premature. Work out your differences. You will all accomplish much more together than you are likely to accomplish as two hostile forks. Once the forks become openly hostile, as they would be with a name change, you have ensured that (1) one of the two forks will die, and (2) the contributors associated with that fork will be lost forever to the community. |
Beta Was this translation helpful? Give feedback.
-
|
@javiergutierrezchamorro I agree with your point about name changing being the easiest. The other items can wait. @ideafarm I don't have any problem per se with the projects merging back together. But if it hasn't happened in years now, why would it suddenly happen? Additionally, I would say there is zero chance of this fork moving back to Perforce (I certainly wouldn't support such a move). The QC "issues" seem a bit ridiculous as there are maybe 10 contributors here working on what is clearly stated to be a development branch (as opposed to a release branch). With this few people, we're not going to have code reviews and the like. I also don't know anyone in the 1.9 project except perhaps the handful that show up here. I have no problem with them, and I don't want anything to do with the politics between any parties involved. I just thought that maybe this fork should have an identifying name rather than an "unofficial" tag and no mention of its ongoing development on openwatcom.org. It gets pretty old telling people, "No, don't go there. I know, it's really old. You want to look at this GitHub page, though." |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how I feel about the name change idea. I see pros and cons either way. Right now I would characterize this fork as a "friendly" fork of Open Watcom. I agree with @ideafarm that changing the name could be interpreted as a step toward this becoming an "unfriendly" fork. That might not be good. On the other hand I sympathize with @ArmstrongJ about how the largely dead "official" Open Watcom site is starting to give the project a bad name. Regarding the practical matter of server support... I could likely donate server resources at my place of employment, Vermont Technical College. I have an older server class machine looking for something to do. I could probably justify the required electricity and bandwidth by noting that support of an open source project is in keeping with our educational mission. Maybe I can even get some students involved. The bad part is that since I'm not paid to do system administration I can't guarantee 100% availability. Also the system in question is old (but it has a new hard drive) so it might not have a long life. I'm sure I could find an alternative machine should the existing one fail but that might mean downtime of days/weeks when (if?) it happens. On the other hand, free is good. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Jeff in many points. I also don't want to do any politics with relation to official OW site. In contributors new group was publish information about me and that I "abandoned" official OW development for my "ego" or something similar. Jiri Malak 8. may 2012 08:55:11 Perforce access Hi Marty, From Yesterday I have no access to any any part of Perforce except openwatcom. Jiri It was followed, by some communication when Marty(current maintainer) promised correction, but up to now nothing happen, my account is still disabled. This was main reason for this fork not any "ego" as stated on OW site. Back to our discussion. I am not sure if the name change have sense. It could confuse users because all referencies for toolchain is as "Watcom" or "Open Watcom" in many projects. I agree that we should improve visibility of our effort for development of OW. If we decide that we want merge with official OW site codebase than I will accept only Git not Perforce. To get server/servers for OW, I think it is hardest part. Any help is welcome. Sorry for my English. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @jmalak that actions speak louder than words. In time this "fork" will become the defacto official branch of Open Watcom even if we do nothing special to make it so other than continuing to push it forward. I like the idea of using the GitHub Wiki because it can be cloned as its own Git repository and is thus easier to edit than something like the MediaWiki system www.openwatcom.org is using. Regarding the server I mentioned in my earlier message... I was thinking of installing 64 bit Linux on it. Is there value in running a build server there? I could possibly set up virtual machines to do testing. As Jiri knows I ran a build server at VTC for several years so I do have a track record in that area. I just want to use resources as effectively as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Peter, I agree we can not do anything and we will be official branch of Open Watcom. The last most important is with Windows 32-bit OS which should build/test most of OW distribution is missing. |
Beta Was this translation helpful? Give feedback.
-
|
I can setup both 32-bit and 64-bit Windows build servers at home, but they would not be available from the net. In addition to that, I'll check the RDOS part. We have a fairly large OW code-base for two different projects running on a few hundred installations. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Leif, Jiri |
Beta Was this translation helpful? Give feedback.
-
|
It sounds like most people agree that we should continue as-is for the time being as far as keeping the name. Although I fear we might have to revisit this issue when V2 is released (this year?!! that's great!), I'm fine with waiting for now. Whoever wants to try to get this fork on the Open Watcom main site, I wish them the best of luck. When I was talking about servers, I actually was referring to a much simpler idea of having servers that could host a site as opposed to build servers. However, as we approach a release, build servers would be a necessity. I currently "maintain" a build server that builds a nightly zip of Open Watcom on Linux x64 at buildbot.approximatrix.com. It is currently just building using OW1.9 and all the docs (except the .HLP files for Win 9x/3.x). It doesn't run any tests, though. I set it up with the selfish goal of providing myself with builds, but anyone can download the builds. The build server uses the buildbot framework to manage tasks. This software is what the Python Software Foundation uses to manage its build farm. The software isn't great, but it is free. If we had other build servers, they can be configured to listen for build instructions from the central server. Currently it only has a single worker server delivering, as I said, a nightly, untested zip. You could, for example, add Windows machines to the workers for building/testing. Look at Python's buildbot for an example of what's possible. Ideally, I think a suite of build servers would actually talk to a central server in an automated fashion rather than us all trying to copy files around. I could modify the build server to actually run tests and possibly generate an installer. Additionally, I could configure another task to at least attempt building with GCC on Linux x64. On a related note, I've begun configuring an OS/2 Warp 4 virtual machine for testing. A while ago someone mentioned that we should probably be testing building and running on that OS. I thought I'd give it a shot. |
Beta Was this translation helpful? Give feedback.
-
|
There is some custom build server software in For another project I'll be looking into using Jenkins to do builds of Ada software. I understand Jenkins is fairly powerful so perhaps it could do Open Watcom builds as well. I may learn enough about Jenkins as a side effect of my other project to try that. |
Beta Was this translation helpful? Give feedback.
-
|
I will try to do summary of some conclusion of this discussion. We stay for now with name "Open Watcom V2", but we can open this point again if anybody feel that it realy should be changed. Point about establishing some organization to cover our effort, to get some donation stay uncomment. I am personally a little sceptic, but I have no experiencies with similar organization. If it is possible to get some money and how much if effort to establish it cover potential gain. Point about dedicated server. It looks like we are able to use some private servers from contributors. I am pleasantly surprised by the willingness to provide servers. Thanks to all for server offer. |
Beta Was this translation helpful? Give feedback.
-
|
@jmalak (and others): Is there agreement that we should enable the Wiki here on GitHub to hold information similar to the way the Wiki on www.openwatcom.org is being used? The thing I like about the GitHub Wiki is that it is a Git repository making it easy to edit, move, and otherwise integrate into the same workflow as the main code base. For example I would move BUILD.md into the Wiki today if we wanted to go this route. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
It is great, any info there is fine. I think that in the past we agreed to use GitHub Wiki. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, I think the GitHub wiki is the way to go. @pchapin, I was unaware of the My buildbot setup is pretty basic at the moment. It basically replicates much of the shell scripts (like |
Beta Was this translation helpful? Give feedback.
-
|
Please move discussion about build servers to new issue "OW distribution Build/test servers" #165 |
Beta Was this translation helpful? Give feedback.
-
|
I enabled the Wiki and created a place holder page. I will fill in some details shortly. Right now the Wiki is editable by anyone. That might or might not be what we want long term. We can restrict it so that only contributors can edit it. |
Beta Was this translation helpful? Give feedback.
-
|
Peter, you have administrator rights to all repositories that you can change setup and access rights to Wiki repository. I did only initial setup. I think I defined some group for this purpose. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Jiri... I was aware. I just wanted to let people know, as a point of information, that the wiki is currently publicly editable. We can change that if it proves to be a problem. |
Beta Was this translation helpful? Give feedback.
-
|
Pls discuss the following idea with me either here or in https://groups.google.com/forum/?hl=en#!topic/openwatcom.contributors/CEKOBCIW3bw WDYT about this idea: Eliminate the concept of an "official fork". Instead, introduce the concept of "integration forks" and "development forks". I am thinking of personally doing the following and would like advice and comments: (1) Within IdeaFarm (tm) Operations (a GitHub "organization"), fork Jiri's repo and also the "official" 1.9 sources. If there are other active forks, fork each of them, too, so that clones of all active OW repos are maintained in one place on GitHub. (2) The mission of the IdeaFarm (tm) Operations OW forks would be QA/QC, not development. These forks would be passive in the sense that the IdeaFarm (tm) Operations organization would serve as a QA/QC department, passively keeping up with whatever technical visions Jiri and other developers pursue. IdeaFarm (tm) Operations's role would be to facilitate regression testing and, as far as possible, unification of the development effort. It seems to me that there is merit on both sides of the disagreement between Jiri and the OW 1.9 people. The issue is about QA/QC, not about functional vision. By setting up an external QA/QC "department" that would integrate contributions from both camps, Jiri would be free to pursue his high risk coding method, and the 1.9 people would be free to pursue their lower risk but plodding method. The effect of having a QA/QC department would be that both efforts would remain viable, and the accomplishments of both efforts would be preserved and integrated. One question is whether the QA/QC department should also be an integration department, producing its own release that competes for end users. My current thought is that it should not. My current plan is for the QA/QC department to only produce pull requests, and by doing that, encourage each development fork to accept the bug fixes produced by the QA/QC organization as well as the functional enhancements produced by the other development forks. WDYT? |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the need for the complex terminology here. If you want to focus on QA and testing in your work on Open Watcom, feel free to do so. Indeed, that would be a useful contribution. I think you are otherwise making things too complicated. As far as I know there is only one master version of Open Watcom here on GitHub, namely the one in the Open Watcom organization. I think you may be confusing two separate uses of the word "fork." Jiri's work could be considered a friendly fork of the project from www.openwatcom.org. However, the "forks" created by the GitHub contributors are part of GitHub's workflow and not forks in the earlier sense. We aren't developing different versions of Open Watcom, just contributing to Jiri's version. |
Beta Was this translation helpful? Give feedback.
-
|
A picture is worth a thousand words. Rather than try to describe what I have in mind, I'll just do it. But I will very much welcome participation and comments and suggestions as my "qa/qc department" takes shape. |
Beta Was this translation helpful? Give feedback.
-
|
@pchapin It seems perforce open sourced it’s openwatcom v2 branch the last commit date from 2012/05/11. Maybe it would be intersting to see if certain things aren’t in this fork yet ? They are starting to fix bugs again with daily countributions. It would defnitly worth to check if some are still present in this fork. |
Beta Was this translation helpful? Give feedback.
-
This "issue" might not be particularly popular, but I think it might be time for such a discussion. This fork, which is progressing at a surprisingly rapid pace thanks to contributors, suffers somewhat from being an unofficial fork of "official" Open Watcom. Explaining to outsiders that they should be using this code as opposed to anything mentioned on the official page is both tiresome and off-putting. Perhaps it's time we consider some options.
Glancing at the Open Watcom news server, it seems clear that there are some odd political issues and/or bad feelings between the few left "maintaining" official Open Watcom and this fork. Although we're a long way from a release, it seems doubtful that these wounds would heal. I don't completely know the history of this controversy other than what @jmalak has explained, and I also don't want to be part of it.
We might want to consider further distancing this fork from official Open Watcom. Currently, this fork is confusingly labeled as unofficial and not mentioned anywhere on the official site. I'd like to suggest a few enormous, but possibly necessary, changes:
1. Renaming
This step is extreme, but perhaps this fork should no longer be called "Open Watcom." We might want to consider a different name for a variety of reasons. First and foremost, it would allow this fork to be considered separate and free of the apparently stagnant official trunk of Open Watcom. It would also provide additional advantages such as an actual domain name and possibly a new server. Such changes are not unprecedented; the EGCS fork of GCC (which later became GCC) comes to mind.
Names to consider might be "Free Watcom" or "Enhanced Watcom." Anything along those lines would allow for a domain and a differentiated name from official Open Watcom. I'm not suggesting we reassign copyrights (not possible). Instead, we just refer to this fork under an entirely different name.
2. Actual Organization
We might also consider forming some sort of official organization such as a nonprofit to maintain servers, possibly collect donations, and ensure the project's longevity. As an American, I'm only familiar with 501c3 orgs, but anything along those lines could be useful. The only reasons I see for taking such action would be to provide an entity:
Obviously existing code can't be reassigned to such an organization. However, future contributions could be assigned. The donations would, in my mind, be used for server rental or, if there was any sizable amount of money, paying contributors. Don't misunderstand me, though. I strongly doubt anyone will be able to make a living on contributing to Open Watcom. But if we could buy Jiri lunch once a month, that might be nice (or whatever). I'm not actually concerned about the donations so much. I more concerned about getting a ...
3. Dedicated Server
The few left with official Open Watcom seem extraordinarily tied to and reliant on the Perforce parent company for their server. I don't particularly understand this mindset because servers are unbelievably cheap. If we had a unique name and, therefore, a domain, we could have a homepage that actually links to this fork. Since we rely on GitHub for source control, issue tracking, and a wiki, a server might just provide information and possibly downloads and mailing list. I don't think we should be in the business of maintaining a wiki or bug tracker ourselves with such limited manpower.
We would have a few options. First, we could flat-out rent a VPS, which isn't expensive. If we had an org, it might be simpler as nobody would be responsible personally for the bill. However, if we did have a real org, we could probably get a VPS donated for free for hosting from whoever.
I realize these views might not be popular here. Most of us seem far more interested in moving this package forward. I think, though, that we might get more contributors if we take some of these steps. I'd love to hear other people's thoughts. I don't particularly like the idea of name changing, but I also don't see many alternatives. The switch would be a one-time cost, though, and it could better promote this project.
I'm just brainstorming here. Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions