I wouldn't agree with the "Right from the get go" plan. I mean, if you were REALLY concerned you could, but its more work than its worth. You might want to note from what revision (hopefully subversion, which makes life significantly easier IMHO) your build came from in case you do need to build from source.
I think it also depends on how heavily trafficed the code is. Myfaces? I wouldn't worry about it so much. I'd just build when disaster struck. If we're comparing to commercial "black box" software, even if you have to get the source and set up the build, you're probably better off. Imagine how long it would take to explain to the commercial company your problem, convince them its their problem, get them to grab their own branched version of source (assuming, of course, they can), set up a test case, fix, build, package, send you the final output, and you still really should do some form of testing on it. Hmm. Sounds awesome. To drag BEA back through the mud, we had several days of production being down because of issues with their workflow product, and to be honest, we just ran profilers or decompiled (in violation of the EULA) to figure out the problems. I mean, sometimes we'd try to get them to look at things, but generally the problems were so buried and specific that explaining it would've taken more effort than figuring it out ourselves. I'm not saying BEA is bad. Just that having them try to fix your issue remotely is like building a ship in a bottle. On 10/4/06, Ryan Wynn <[EMAIL PROTECTED]> wrote:
I guess the tricky part is when do you build from source? Right from the get go or when something bad happens. I think it's nice to build the vanilla source from go so that you don't have to worry about integrating anything into a build on the day disaster strikes. But then you get into the business of building lots of things you really don't need to. On 10/4/06, Kevin Galligan <[EMAIL PROTECTED]> wrote: > In my personal experience, commercial support sounds nice, but you're > more likely to run into resistance and denail. No offense to BEA, but > we had to figure out all sorts of problems with their app server and > workflow product, and then convince them of their problems, and > essentially code around them, in proudction no less. > > There were times I would've begged to have been on an open source > platform. I don't think non-tech corporate people understand the > concept. > > Commercial support for myfaces doesn't seem like too bad of an idea. > > On 10/4/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > The best way to fix a showstopper in open source is to do it yourself > > and submit a patch back to the project :-) > > > > If you are asking if your local changes have to be submitted back to > > ASF, the answer is no. > > > > If you are asking what "guaranteed" support services are provided > > directly by ASF, the answer is none. The project (and community > > support) is provided on a voluntary basis. > > > > http://www.irian.at/ is one possibility for obtaining commercial > > support for JSF and MyFaces if that's something you want to purchase. > > A number of the MyFaces committers appear to do work for irian.at. > > > > There is currently no process in place for fixing bugs on older > > release branches, although I'm hopeful that we will start doing so > > from 1.1.4 onward. > > > > > > On 10/4/06, Ryan Wynn <[EMAIL PROTECTED]> wrote: > > > Trying to get approval for a myfaces-shale stack in a corporate > > > environment and facing the question of what is the strategy for fixing > > > a production showstopper in the open source code. Anyone have any > > > recommendations on this topic? Or any links regarding the topic? > > > > > > Filing through JIRA does not seem to be an answer for these > > > emergencies because there is really no guarantee there? Especially > > > for previous versions. > > > > > > What is the protocol if say myfaces-1.1.1 src is modified? Is the > > > requirement the same that the fix needs to be looped back in? Or is > > > the policy different for older versions? > > > > > > Thanks for the consideration. > > > > > >
