Re: [AOLSERVER] Hosting, discussions, branching, modules
On 2005.02.10, Zoran Vasiljevic [EMAIL PROTECTED] wrote: On Wednesday 09 February 2005 23:49, Dossy Shiobara wrote: If you don't believe that I truly feel this way, then put me to the test. Start making changes. Start committing code. I DID. See ChangeLog: [...] This is your answer: I wrote this to the list on Tue, 22 Jun 2004 12:24:01 -0400: TclX keyed list changes in HEAD http://listserv.aol.com/cgi-bin/wa?A2=ind0406L=aolserverP=15467 | Zoran implemented some recent changes to TclX keyed lists in CVS | HEAD which changed the C API, which broke at least some code at | AOL which was still using the old C API. | | Rather than a wholesale back-out of the changes, I'd like to | discuss two things: | | 1) Should changes that break backwards compatibility be allowed | between minor revisions (i.e., 4.0 - 4.1) or should they be | limited to major releases only (i.e., 4.x - 5.x). | | 2) Can we quickly implement some backwards compatibility for the | TclX keyed list C API so that existing C code won't need to be | modified/updated to use Zoran's new C API? What's the best way to | do this? Can it be done through #define's? Or thin wrapper C procs | that call the new C procs? Or, can we simply rename Zoran's new C | procs to the old names to preserve compatibility? At one point, Zoran replied: http://listserv.aol.com/cgi-bin/wa?A2=ind0406L=aolserverP=16550 | A wholesale back-out of the changes seems like a very desperate | step, hm? Since the CVS head is the development branch, changes | to it should be allowed. Or not? Besides, head should not be used | for any productive environment, AFAIK. If the checkin policy on | head should be that rigorous, then we'll advance very, very | slowly, which is bad, isn't it? In my original message, I clearly said rather than -- which meant, I wanted to avoid a wholesale back-out of the changes, so I presented two options that I thought we could consider. We quickly discussed #2, you went ahead and added the necessary C API for backwards compatibility, and the issue was quickly resolved. This worked out exactly the way I hoped these kinds of issues can be resolved. I think my approach then was exactly what I reiterated recently in the very message you replied to: http://listserv.aol.com/cgi-bin/wa?A2=ind0502L=aolserverP=18838 So, what's the problem? I think my behavior has been consistent with my messaging. Am I deluding myself? I'd like to think that I'm not, but it's hard to judge your own self-image from inside your own head ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Hosting, discussions, branching, modules
On Wednesday 09 February 2005 08:13, Malte Sussdorff wrote: On a related note, what is the downside of having an AOLserver stable branch, where only the AOL approved developers have access to and a testing branch where everyone can add their patches to. Needless to mention that from time to time the stable branch needs to be merged with the testing one. I believe the management overhead is/could be the issue. OTHO, I would not say AOL approved developers. This is supposed to be an Open Source project, right? As for importance of development, if Dossy is strikt about not letting others participate actively in the core development (read: give them CVS access without the need for one person to accept patches), then the main interest would be to rewrite the modules part of AOLserver to a degree where all the functionality that has been written and needs patches to work can work smoothly as a module. And while we are at it, we could write an Apache Modules wrapper ;-). I think that AS module infrastructure is already very good. But, there are spots which need touches for quite a long time already. Also, the tight integration of http protocol (understandably, if you see AS as pure web-server) has cut-off (or at least made difficult) additions of other pluggable protocol modules. This is one of the issues which is so fiercefully discussed here. See this (my personal) view: I'm all for refactoring the server to even better support modules of all kinds, including alternate protocol modules. I have the CVS write-commit privs, as about 58 other project members. I'm also convinced that some RFE's sitting in the queue are of quality to be included in the current dev branch. Yet, I'm not commiting them. Why? Am I lazy? Well, I'm not. I'm just *afraid* that this will/might/could collide with the global project direction and doing this will result in my additions being backed-out out of the repository, leaving me out in the rain with lost time and shattered self-confidence. And guess what? I do not know the direction! Isn't that absurd? Am I being too paranoic? So, the question is not wether core should be rewritten to support modules better or not (it definitely should). The question is: who is going (to be allowed) to do that? Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Hosting, discussions, branching, modules
On 2005.02.09, Zoran Vasiljevic [EMAIL PROTECTED] wrote: I have the CVS write-commit privs, as about 58 other project members. I'm also convinced that some RFE's sitting in the queue are of quality to be included in the current dev branch. Yet, I'm not commiting them. Why? Am I lazy? Well, I'm not. I'm just *afraid* that this will/might/could collide with the global project direction and doing this will result in my additions being backed-out out of the repository, leaving me out in the rain with lost time and shattered self-confidence. And guess what? I do not know the direction! Isn't that absurd? Am I being too paranoic? I don't know what I can say that'll make you believe me, but I am totally hoping you and others will commit changes. If there's problems with the changes, we'll discuss them. We'll work together to form a strategy to correct any real deficiencies either caused by the change, or illuminated elsewhere by the change. We'll continue to work together to improve the codebase. If a change-in-progress is holding up the release, we'll conservatively estimate what it'll really take to make things right, and if it's going to block the release, consider backing out the change to keep things moving forward. When I wrote the CVS Commit Guidelines on the wiki, it was serious. Everyone who has been given the authority to commit to CVS by being granted rights also has the responsibility that comes with it. If people start committing code that pulls the direction of the server in opposing ways, then we'll pause for a bit and discuss the problem. Lets get to the point where we've got enough committing going on to see if this problem ever arises. This has no dependency on knowing what the direction is -- suppose there is no one direction. What then? As long as everyone's individual directions can peacefully co-exist with all the other developers, who should care? Only when there's a conflict will we need to resolve the problem, and I don't think that's best done by pointing to someone's arbitrary vision and declaring I'm right, you're wrong: the vision says so. However, I do understand the importance of having a general direction or vision for the project so I'll be working on one, but it's for guidance and not law. The direction of this project is all about where we ALL want to take it. The vision is only a statement or capturing of that collective sentiment at one point in time in the past. ... If you don't believe that I truly feel this way, then put me to the test. Start making changes. Start committing code. We'll deal with the real problems as, when, and if they ever come up. And we'll be mature about it and find the best solutions that we can at the time. And, in the end, if we discover this isn't the best way for the project to exist, we'll discuss it again and come up with a new approach. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Hosting, discussions, branching, modules
After reading throught the digest of the discussion on this list and remembering Dossy's statement about donating a server, I'm more than inclined to ask the OpenACS Core Team to allow the creation of an AOLserver community at openacs.org or host a service on one of our machines. For one, I think using a forum is more user friendly, especially if you only read the digest. Furthermore the file storage would allow us to exchange files and patches without putting them on CVS and/or rely on sourceforge. On a related note, what is the downside of having an AOLserver stable branch, where only the AOL approved developers have access to and a testing branch where everyone can add their patches to. Needless to mention that from time to time the stable branch needs to be merged with the testing one. As for importance of development, if Dossy is strikt about not letting others participate actively in the core development (read: give them CVS access without the need for one person to accept patches), then the main interest would be to rewrite the modules part of AOLserver to a degree where all the functionality that has been written and needs patches to work can work smoothly as a module. And while we are at it, we could write an Apache Modules wrapper ;-). -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
