Re: [AOLSERVER] Switching to Trac to manage the AOLserver project?
On 2007.09.04, Dave Bauer [EMAIL PROTECTED] wrote: Since you proposed changing to Trac, why can't you let us know your thinking behind it be listing 1) the problems you hope it will solve SourceForge's issue tracker is unattractive, IMO. Trac is simple and it just works. 2) the process we would use when these problems are solved. If people think Trac is better, they'll use it. Or, they won't use either, in which case it's a non-issue to them, anyway. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
Tom, You are welcome to propose a process that you feel will lead to success. Those who want to participate in the AOLserver Community are invited to read and respond to your proposal. If the community can arrive at some form of reasonable consensus around the process proposal, we can consider it adopted. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Dave Bauer [EMAIL PROTECTED] wrote: On 8/31/07, Dossy Shiobara [EMAIL PROTECTED] wrote: Agreed. How do other, successfull, open source projects--as well as closed-source commercial projects--get documentation written? Through my own personal (anecdotal) experience, the lead engineers are not the ones that do the majority of the documentation writing. Unfortunately for AOLserver 4.5 there isn't anyone else who CAN write the documentation. If the only way to know a new feature exists, and how to configure it is by reading C code, there aren't alot of non-engineers who can write that documentation. Be careful--please note that I didn't say non-engineers, I said [not] the lead engineers. There are certainly technical writers out there who are skilled in writing quality documentation who also have 15+ years of programming experience. I'm trying to reach out to one such technical communications communities to see if there's any interest in working on the AOLserver project. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 2007.09.01, Tom Jackson [EMAIL PROTECTED] wrote: Why don't we have an idea-raiser? Maybe it is a common disease among programmers: writing code is apparently the only thing which counts. Ideas are easy to come by; doing--or, getting people to do--is the hard part. One easy way to get people to do stuff is to pay them. There's no point in throwing ideas around if there's nobody--or, no funds to pay somebody--to do anything. If you have suggestions on ways to get people to do stuff for free, I'd love to hear them. Better yet: I'd like you to DO whatever it is you think will make it happen. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
Op Sun, 2 Sep 2007, schreef Dossy Shiobara: On 2007.09.01, Tom Jackson [EMAIL PROTECTED] wrote: Why don't we have an idea-raiser? Maybe it is a common disease among programmers: writing code is apparently the only thing which counts. Ideas are easy to come by; doing--or, getting people to do--is the hard part. One easy way to get people to do stuff is to pay them. There's no point in throwing ideas around if there's nobody--or, no funds to pay somebody--to do anything. If you have suggestions on ways to get people to do stuff for free, I'd love to hear them. Better yet: I'd like you to DO whatever it is you think will make it happen. Documentation certainly needs to be improved, we need a batteries included installation process, etc., but let us first create some conditions for a more active community. Currently, the way to contribute is to stick your neck out. The project needs to move to a model where users just need to stick their finger in. Example: Years ago I did contribute code: A reasonably simple patch to make AOLserver use the sendfile system call on Linux instead of read/write. It was ignored. Not because of bad intentions, but simply because all code had to go through Kriston and was burried in e-mails and to do lists. The bureaucracy of contributing needs to be reduced. I agree a package like Trac can help by providing Wikis and forums. I'd prefer OpenACS over Trac (replacing OpenACS by Sourceforge has IMO been the worst decision in AOLserver history), but it's a good thing that something happens here, the tool is of less importance. So, let's do this. If you need help, or want me to install/maintain such a package, please say so, as I'm willing to contribute. Simply installing a package won't do though, it has to be part of a strategy to make the community more active, make it easier to contribute. I suggest: * A low bureacracy way to contribute patches is built, perhaps using Trac or OpenACS * Active AOLserver users get SVN access and can peer review and apply patches. * Getting SVN access shouldn't be difficult. Daniël Mantione -- 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] Switching to Trac to manage the AOLserver project?
On Sunday 02 September 2007 12:08, Dossy Shiobara wrote: On 2007.09.01, Tom Jackson [EMAIL PROTECTED] wrote: Why don't we have an idea-raiser? Maybe it is a common disease among programmers: writing code is apparently the only thing which counts. Ideas are easy to come by; doing--or, getting people to do--is the hard part. One easy way to get people to do stuff is to pay them. There's no point in throwing ideas around if there's nobody--or, no funds to pay somebody--to do anything. What are you talking about? Shouldn't you actually need something to do first? Why collect funds, hire someone and then come up with the ideas? Is it at all important to you that the community agree with the reasons for paying someone, and agree on the expected results? If you have suggestions on ways to get people to do stuff for free, I'd love to hear them. Better yet: I'd like you to DO whatever it is you think will make it happen. How about allowing them to be part of the process? Dossy, you keep skipping past the necessary step of getting the community to be interested in your ideas before demanding action. Even if you were the one to do the work, this cannot be the sufficient condition for making changes. Do you just not agree with this, or just not get it? Either way, it is important to understand why you keep suggesting work before agreement, or even discussion. As a specific instance, I have suggested that before a wasting time, or doing documentation that we figure out what kind we want, what is important, what must be done, and what can wait. If we come up with some kind of plan, maybe examples of how to do it, and when, then at least we have some idea of what we want and why. And do this before we start hacking away any further on code which hasn't even been put into production, and has no documented behavior, limitations, etc. Anyone should be able to offer ideas or suggestions without first having to put up a bond somewhere, or be willing and able to do contribute any more. Or knowing how to persuade someone else to work for free, because this is not the question. Probably what we should require is that, other than fixing bugs, contributions of code changes to the core need to go through a process. Why? Yes why? For the exact reason you stated: how do you get people to do stuff for free? If you add something, or change something which requires other users to adapt, who pays for that? You are not asking them to work for free, your forcing them to work for free, or find someone and pay them to make the changes. As far as the AOLserver project is concerned, there are no lead engineers. Why are we talking about what lead engineers do or don't do? Or maybe I missed something? Are there members here that have more rights than others? Some of us can write code and not concern ourselves with documentation? Who are these people? I remember watching a video with the guys who started subversion. At one point they hired a person to be in charge of everything. The guy had to follow the same process as every other developer, paid or volunteer, I think he was on probation at the start. This project and this community is bigger than any one person or sponsor. Why is that important? Because the process was more important than the status of the developers. Exempt some members from the process and you show disrespect for the process, everyone else who follows it and the product. The main reason is that the end doesn't justify the means because the end result is only theoretical, it isn't guaranteed. The process of getting there isn't theoretical, and neither is the current state of the code. In fact, this is exactly what Dossy just said: Ideas are easy to come by; doing--or, getting people to do--is the hard part. Unfortunately, with writing code, even paying someone to do it doesn't guarantee results. Yes, doing is very hard, extremely hard, so maybe we better plan really well. tom jackson -- 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] Switching to Trac to manage the AOLserver project?
On Sunday 02 September 2007 13:51, Daniël Mantione wrote: The project needs to move to a model where users just need to stick their finger in. In general this is true, but as you explain below, this is the catch-22 of the history of AOLserver. If you have any respect for the community process, you create a patch for some core developer to review. Then it goes nowhere. Been there, done that. The other way is to just commit to cvs. I did that once for a pure bug-fix. Example: Years ago I did contribute code: A reasonably simple patch to make AOLserver use the sendfile system call on Linux instead of read/write. It was ignored. Not because of bad intentions, but simply because all code had to go through Kriston and was burried in e-mails and to do lists. The bureaucracy of contributing needs to be reduced. My suggestion is to replace bureaucracy with a consistent process that everyone follows. There really are no small core changes at this stage. Many times the process could start with a patch which provides a small change. But this should be the starting point. The fact that the patch works for the developer, and 'all the work' is already done except committing to cvs is frustrating for someone who just spent a lot of their time on it. Even producing the patch is extra work. On the other hand, some developers just commit straight to cvs and the community finds out about it whenever. If everyone had to follow the same path to committing code, it would be easier to explain to the rest of the community why code can't just be stuck in when it works on one computer somewhere. Of course the biggest change in process here would be requiring positive agreement instead of failure to object. Most people have no idea if a proposed change will be good or not. Who wants to object without knowing of any specifc problem with the change? In fact there should not be a need to object. We see here how poorly it works in identifying strengths and limitations of the current situation and the proposed situation. tom jackson -- 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] Switching to Trac to manage the AOLserver project?
On Friday 31 August 2007 18:19, Dossy Shiobara wrote: On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Although it is easy to try to jump in and start documenting stuff, there is so little current documentation that there might be an opportunity to rethink how to do this. Agreed. How do other, successfull, open source projects--as well as closed-source commercial projects--get documentation written? Through my own personal (anecdotal) experience, the lead engineers are not the ones that do the majority of the documentation writing. I'll bet that most successful projects have a roadmap of where they are and where they are going. In fact, AOLserver is a successful project as far as I can tell. And if it isn't, we damn better figure out, and agree, on the current limitations before heading off in some unknown direction. We really don't need lead engineers if nobody knows where we are going or why. There was a question of why nobody is working on bugs. This is very curious. I rarely hear of a significant bug that goes unaddressed. A recent one is apparently in Tcl, not AOLserver. It is possible that nobody is working on bugs because they don't bother anyone enough to really impact their application. The only other possibility is that our users are too dumb to figure out how to ask about a bug. I haven't seen any evidence of that. Unless someone is planning on introducing a bunch of new bugs, there probably isn't too much to do here at the moment except address the ones which really bug us. tom jackson -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Although it is easy to try to jump in and start documenting stuff, there is so little current documentation that there might be an opportunity to rethink how to do this. Agreed. How do other, successfull, open source projects--as well as closed-source commercial projects--get documentation written? Through my own personal (anecdotal) experience, the lead engineers are not the ones that do the majority of the documentation writing. I'll bet that most successful projects have a roadmap of where they are and where they are going. In fact, AOLserver is a successful project as far as I can tell. And if it isn't, we damn better figure out, and agree, on the current limitations before heading off in some unknown direction. We really don't need lead engineers if nobody knows where we are going or why. I agree, where is AOLserver going. What was the motivation to make the big changes for AOLserver 4.5? There was a question of why nobody is working on bugs. This is very curious. I rarely hear of a significant bug that goes unaddressed. A recent one is apparently in Tcl, not AOLserver. It is possible that nobody is working on bugs because they don't bother anyone enough to really impact their application. The only other possibility is that our users are too dumb to figure out how to ask about a bug. I haven't seen any evidence of that. Tom's right. There are 55 open items, some from 2003 but I would not say this is a major problem. The big problem is understanding where AOLserver should go from here, before people start working on it. Dave -- 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] Switching to Trac to manage the AOLserver project?
On 2007.09.01, Dave Bauer [EMAIL PROTECTED] wrote: I agree, where is AOLserver going. What was the motivation to make the big changes for AOLserver 4.5? Without violating terms of any NDAs I may still be bound to, I'll try to describe a real scenario (names changed to protect the ignorant, etc.): Suppose you have a large content management system, where application (Tcl) code of varying quality is contributed by a large number of developers. Some requests may be poorly behaved and take up more system resources than others. The pipe-dream of review all code, test it thoroughly, and prevent such poorly behaving code from making it to production just isn't respected, for whatever reason. How do you keep such a system operational? Being able to sandbox those requests might be one way: instead of letting those requests consume all server threads, resulting in an unresponsive server to all its users, you sandbox those requests to its own private thread pool. If users making those requests exhaust its pool, this doesn't affect the rest of the system's users making other requests. During key operational times, a server restart to define and/or tune these sandboxes isn't an option. While we can schedule restarts in advance, taking the system down during busy periods isn't acceptable. So, these pools need to be definable at system runtime and requests be assigned to them, all without a server restart. I would speculate that this was one of the key drivers behind the whole ns_pools/ns_limits change in 4.5. What other big changes were there in 4.5? The ns_proxy implementation was a fresh implementation (and hopefully an improvement) over the closed-source dci proxy code internal to AOL, as people continuously clamor for AOL to keep contributing more into the open source community. Tom's right. There are 55 open items, some from 2003 but I would not say this is a major problem. The big problem is understanding where AOLserver should go from here, before people start working on it. Absolutely. Where does the community want to take it? I do think shoring up the documentation should remain a key objective and I'm going to reach out to various tech. writing communities to see what kind of help they might offer. Would there be interest in funding a tech. writer for a short period of time? If we had a fund-raiser, perhaps we could hire one on a contract basis for a couple of months? In that case, what goals would we like to set? Those who would contribute funds: what documentation would you like to see authored and/or updated? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On Saturday 01 September 2007 09:13, Dossy Shiobara wrote: Would there be interest in funding a tech. writer for a short period of time? If we had a fund-raiser, perhaps we could hire one on a contract basis for a couple of months? In that case, what goals would we like to set? Those who would contribute funds: what documentation would you like to see authored and/or updated? Why don't we have an idea-raiser? Maybe it is a common disease among programmers: writing code is apparently the only thing which counts. Contributions to the community should be for things which are important, critical even. Why should we waste time doing unimportant tasks? There really are no degrees of importance: either it needs to be done, or it doesn't. Nice to have is way down the list. If documentation is so unimportant that it can be tasked to a contract tech writer and finished in a few months, why do it at all? I can't think of a single use for such a project. Current, very old, documentation is okay for beginners. Experienced users are probably not going to be helped by documentation written by someone unfamiliar with AOLserver. Documentation is more than a formalizm, it needs to have a purpose. Yes, not just code needs to be written for a purpose, but the documentation for the code needs a purpose. Nobody knows that purpose of the code, and the type of documentation that would best explain it, than those who write and use the code. Configuration settings, initialization and runtime information is also documentation. Writing code which provides initialization and runtime information can't be done by anyone else but the programmer. One thing left out so far is example code. Regardless of accepted practice of who writes or polishes up documentation in a given project, with no examples of use, how did the programmer/engineer test the API? Were there no design docs? No goal? If this isn't the exclusive task of a code writer, what in the hell is? Of course the programmer/engineer could claim that they just haven't written down their thoughts, but it is impossible to maintain that it isn't their job. My suggestion of revisiting how documentation is done doesn't apply to who should be doing it. It needs to be done by those writing, modifying and using the code. If someone doesn't think it is important to provide documentation, including discussion of goals, motivations, impact, etc. prior to doing coding, they don't deserve to be mucking around with the core API; do it in a module or in a private copy somewhere. We really need to grow up as a community and demand a quality, transparent process. The main reason for this is that the current code has not even been put into production by AOL. We should assume that this will remain the case. In addition, Jim Davidson has moved on, and like it or not, his guidance, although not visible, was known, or at least assumed and respected enough to accept the process as it was. Also, the team which was at least four inside AOL has been reduced to almost zero. This proves that we can't even rely on AOL to finish what they start. Nor should we, they are a commercial enterprise, and should be expected to operate for their own self-interest. In fact, we should expect anyone here to do so with respect to their business interests. BUT this self-interest does not extend into the core API. As community members, we need to act in the shared interest of the community. tom jackson -- 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] Switching to Trac to manage the AOLserver project?
Well, here's my take on it: This is a major change. The community should get at least 24 hours to react before we start seeing implementation notices. And Tom's right; I'd feel more respected if you'd mentioned _why_ you wanted to do this? In terms of an implementation plan, there are a number of questions I'd ask if this were a project I was trying to be sure was succesful. Since I'd like it to be successful: Bugs/Issues: * Are all the bugs in the current databases going to be issues in trac? Which databases will they be culled from? * Will the history of bug fixes be translated to trac? Wiki: * Will the whole wiki move, or will there be an information wiki (presumably where the current one is) and a management/issue wiki? * What belongs in which wiki? * What are the new documentation standards, presuming anybody continues to work on the API wiki entries? Management: * We've had no visibility into planned milestones or assignments before. Are you planning on providing some? That'd be the biggest community benefit I can see. Revision Control: * Given you've also suggested a move to SVN, similar questions should be asked: will the revision histories be moved, or just the tip revision? How much archeology will be required to find out that Adam Zell submitted this patch in 2002? Resource management: * What bug fixes or features will be missed due to spending time on this move? * What documentation, visibility, or reliability gains are we looking for from the move? I'm actually in favor of the move if it's (a) quick, and (b) the 'archeology' questions have answers that don't involve four databases on four sites. I'm in favor because my examination of trac-based projects shows more process milestone visibility than I've seen in this project, and gaining that visibility is something I know we'd all like. Also, it's a lot better looking than Bugzilla :-). -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: Thursday, August 30, 2007 10:09 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Switching to Trac to manage the AOLserver project? On 2007.08.30, Tom Jackson [EMAIL PROTECTED] wrote: Not a single word about benefits, pros and cons, what is the point of asking about strong feelings? Sorry, I assumed that folks were familiar with Trac and those who weren't would read up on it, as I even provided the URL. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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. -- 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] Switching to Trac to manage the AOLserver project?
Maybe the first thing to note is that 'trac' is python code running on Apache! And 'trac' does not appear to be a service provider like sourceforge, all setup, maintenance, upgrade, backup is the responsibility of the user. Use of 'trac' virtually requires subversion, which must run on the same machine as 'trac'. So the whole damn thing is on one machine, does everyone feel comfortable with that? Hell, I'm not too comfortable keeping my own software on my servers and they have mirrored disks and live in a building with 2 weeks of diesel fuel and batteries for power outages. Problem is, recovery from failure would still be painful, I might take a vacation or keel over dead. Btw, I love subversion and hate sourceforge, but I know what I'm getting. Sometimes you can hate the best solution. tcl/tk use sourceforge even with major sponsors, OpenACS seems to be able to coordinate cvs, bugtracking, forums and everything else, and it is built upon AOLserver and Tcl. Maybe support our own instead of moving to python and Apache. tom jackson On Thursday 30 August 2007 23:13, Rick Cobb wrote: Well, here's my take on it: This is a major change. The community should get at least 24 hours to react before we start seeing implementation notices. And Tom's right; I'd feel more respected if you'd mentioned _why_ you wanted to do this? In terms of an implementation plan, there are a number of questions I'd ask if this were a project I was trying to be sure was succesful. Since I'd like it to be successful: Bugs/Issues: * Are all the bugs in the current databases going to be issues in trac? Which databases will they be culled from? * Will the history of bug fixes be translated to trac? Wiki: * Will the whole wiki move, or will there be an information wiki (presumably where the current one is) and a management/issue wiki? * What belongs in which wiki? * What are the new documentation standards, presuming anybody continues to work on the API wiki entries? Management: * We've had no visibility into planned milestones or assignments before. Are you planning on providing some? That'd be the biggest community benefit I can see. Revision Control: * Given you've also suggested a move to SVN, similar questions should be asked: will the revision histories be moved, or just the tip revision? How much archeology will be required to find out that Adam Zell submitted this patch in 2002? Resource management: * What bug fixes or features will be missed due to spending time on this move? * What documentation, visibility, or reliability gains are we looking for from the move? I'm actually in favor of the move if it's (a) quick, and (b) the 'archeology' questions have answers that don't involve four databases on four sites. I'm in favor because my examination of trac-based projects shows more process milestone visibility than I've seen in this project, and gaining that visibility is something I know we'd all like. Also, it's a lot better looking than Bugzilla :-). -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: Thursday, August 30, 2007 10:09 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Switching to Trac to manage the AOLserver project? On 2007.08.30, Tom Jackson [EMAIL PROTECTED] wrote: Not a single word about benefits, pros and cons, what is the point of asking about strong feelings? Sorry, I assumed that folks were familiar with Trac and those who weren't would read up on it, as I even provided the URL. -- Dossy -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.30, Rick Cobb [EMAIL PROTECTED] wrote: Well, here's my take on it: This is a major change. The community should get at least 24 hours to react before we start seeing implementation notices. And Tom's right; I'd feel more respected if you'd mentioned _why_ you wanted to do this? You're right, I wasn't very clear about this: None of the existing mechanisms (SourceForge tracker, etc.) are going to be affected. I just wanted to set up Trac and see how well it works. In the future, if Trac proves to be useful, then we can discuss migrating all of our information and assets into it and shutting existing stuff down in favor of it--but I viewed that as the drastic change. Right now, I'm just asking folks who are interested in playing with Trac to check it out, and provide some meaningful feedback, with regard to how it might fit in with our project. In terms of an implementation plan, there are a number of questions I'd ask if this were a project I was trying to be sure was succesful. Since I'd like it to be successful: Bugs/Issues: * Are all the bugs in the current databases going to be issues in trac? Which databases will they be culled from? * Will the history of bug fixes be translated to trac? Of course, I would love to see this happen! I don't know if I will have the time to do this, and I know that I can't make anyone ELSE do it, so it probably won't get done. If someone wants to step up and volunteer their time to do it, I certainly wouldn't refuse it. The only database that contains issues (that I know of) is the SourceForge tracker. If folks are tracking issues elsewhere, please speak up so we can have a complete list. Wiki: * Will the whole wiki move, or will there be an information wiki (presumably where the current one is) and a management/issue wiki? * What belongs in which wiki? I personally feel a wiki is best when it is comprehensive, so I'm in favor of one single wiki. Again, if we all agree that Trac is the best direction moving forward, I would definitely script something that would export out of MediaWiki and into TracWiki. * What are the new documentation standards, presuming anybody continues to work on the API wiki entries? I say whoever cares most strongly about the standards should sit down and spend the time to write them up. That is, as you say, if anyone continues to work on them. Management: * We've had no visibility into planned milestones or assignments before. Are you planning on providing some? That'd be the biggest community benefit I can see. And this is the single biggest reason why I (personally) want to use Trac. Once we get all the open issues in there, I can assign them to milestones based on might possibly be reasonable estimates and we can all finally have an idea as to what might be completed by when. Of course, this assumes that there will be anyone left to actually work on and close out tickets and contribute code. Revision Control: * Given you've also suggested a move to SVN, similar questions should be asked: will the revision histories be moved, or just the tip revision? How much archeology will be required to find out that Adam Zell submitted this patch in 2002? The reason why I haven't worked on moving things out of CVS (given how slow SourceForge has been lately) is because I want to make sure I can properly preserve the revision history in whatever SCC system I import it into. I personally feel that if the entire revision history isn't preserved, it isn't being done right. Others may feel it's less important to carry forward that old information, but especially in open source projects that audit trail is important, to know exactly who changed what. Resource management: * What bug fixes or features will be missed due to spending time on this move? Good point--any time spent playing with Trac is time spent not doing something else. If people are going to contribute to the AOLserver project, it means taking time away from other activities and that can be hard to justify. Within the AOLserver project itself, folks working on Trac aren't working on the code. I don't know how I could quantify this. Given the low level of project activity right now, people working on anything project-related might be considered an improvement. Whether people will devote effort to it, taking away from their existing work ... I have no idea. I'm personally willing to put in 5, maybe 10 hours, in the next few days, to work on this. * What documentation, visibility, or reliability gains are we looking for from the move? My personal interest is to get all outstanding issues into a system that's easy to maintain, looks nice, makes release management easier, and possibly encourages people to participate more. I'm actually in favor of the move if it's (a) quick, and (b) the 'archeology' questions have answers that don't involve four databases on four sites. I'm in favor because my examination of
Re: [AOLSERVER] Switching to Trac to manage the AOLserver project?
Dossy said: Revision Control: * Given you've also suggested a move to SVN, similar questions should be asked: will the revision histories be moved, or just the tip revision? How much archeology will be required to find out that Adam Zell submitted this patch in 2002? The reason why I haven't worked on moving things out of CVS (given how slow SourceForge has been lately) is because I want to make sure I can properly preserve the revision history in whatever SCC system I import it into. I personally feel that if the entire revision history isn't preserved, it isn't being done right. Others may feel it's less important to carry forward that old information, but especially in open source projects that audit trail is important, to know exactly who changed what. Resource management: CVS2SVN can do it. We recenetly experiemented with importing the entire OpenACS CVS tree into SVN and it was possible. OpenACS is gigantic compared to AOLserver so it seems likely its possible. What really more important here is what are you trying to fix. Are there really that many outstanding issues that we need to move everything from sourceforge? Wouldn't it be easier to just write up a page with the milestones? Dave -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Maybe support our own instead of moving to python and Apache. Is that your only reason to speak out against Trac? -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
El Fri, 31 Aug 2007 15:20:13 -0400 , Dave Bauer [EMAIL PROTECTED] escribió: CVS2SVN can do it. We recenetly experiemented with importing the entire OpenACS CVS tree into SVN and it was possible. OpenACS is gigantic compared to AOLserver so it seems likely its possible. I agree with Dave, we moved company whole repository from CVS to SVN using that script, and it worked fine. We did that like a year ago already, and we all are pretty happy with the change. What really more important here is what are you trying to fix. Are there really that many outstanding issues that we need to move everything from sourceforge? Wouldn't it be easier to just write up a page with the milestones? Well, I would like to have a better tool with support for tickets, and as far as I have seen, trac supports that and more, plus it *seems* (note that I have not worked with it yet) it supports many other useful features. I am ok with setting up TRAC. Regards, Juan José -- Juan José del Río Simple Option Oficina: 0034 951 930 122 Móvil: 0034 616 512 340 Fax: 0034 952 792 455 [EMAIL PROTECTED] http://www.simpleoption.com -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Dave Bauer [EMAIL PROTECTED] wrote: CVS2SVN can do it. We recenetly experiemented with importing the entire OpenACS CVS tree into SVN and it was possible. OpenACS is gigantic compared to AOLserver so it seems likely its possible. I've attempted cvs2svn conversion back in 2005 and ran into some problems which I didn't make notes on--I'm assuming lots of fixes have gone into cvs2svn since then. The concern I have around the conversion has to do with the logical organization of the repository: i.e., everything in one SVN repository, or one repository per module. Should we have: svn/branches ... svn/tags ... svn/trunk/aolserver svn/trunk/aolserver/nsd svn/trunk/aolserver/nsdb ... svn/trunk/nscache svn/trunk/nsencrypt ... Or: svn/aolserver/branches ... svn/aolserver/tags ... svn/aolserver/trunk svn/aolserver/trunk/nsd svn/aolserver/trunk/nsdb svn/nscache/branches ... svn/nscache/tags ... svn/nscache/trunk ... I'm leaning towards the latter--each module in its own repository--because any changeset to a repository increments the revision number. It might be annoying to svn up and see that the revision has changed because of a change in, say, nsoracle ... where no change to aolserver core was made. I don't believe SourceForge provides multiple SVN repositories to a project, though. As far as I know, it's one repository per project. And, I really don't want to go creating separate SourceForge projects per module, etc. (I believe Google Code project hosting is the same, with only one repository per project.) What really more important here is what are you trying to fix. Are there really that many outstanding issues that we need to move everything from sourceforge? Wouldn't it be easier to just write up a page with the milestones? Ultimately, I want to understand what real obstacles we have with respect to getting people to participate more in the project. John Buckman emailed the list with a bug the other day and nobody responded. I have intentionally held back to see who else might get involved to follow his reproduction steps, test his change, and eventually commit it. There are some 50+ people who have CVS commit access to the project--someone else has to be able to do these things, right? (Speaking of which: John, why don't you have CVS commit access? What's your SourceForge username ...?) -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
Why is this speaking out against Trac? Why isn't this speaking up for AOLserver, Tcl, OpenACS, and everyone in the community who supports and uses these high quality products? Anyway, I seem to remember my email being a little longer than a single line. Personally I think the standard for moving forward on something like this is _agreement_ that the current setup is not working, and what the real issues are, not _silence_ about a particular option. But it is impossible to agree or disagree based upon no information on what the goal is, why we can't do it with the current tools, and how the new tools are going to work. tom jackson On Friday 31 August 2007 13:17, Dossy Shiobara wrote: On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Maybe support our own instead of moving to python and Apache. Is that your only reason to speak out against Trac? -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Why is this speaking out against Trac? Why isn't this speaking up for AOLserver, Tcl, OpenACS, and everyone in the community who supports and uses these high quality products? I, personally, am in no position right now to volunteer and/or donate an AOLserver/OpenACS installation--and have no ability to make anyone else do so. Therefore, I'm not going to waste my limited time pursuing that line of thought. If someone would step forward and volunteer to set it up and maintain it and/or donate the resources and funding required to operate it, that would be fantastic. Anyway, I seem to remember my email being a little longer than a single line. Sorry, I try to follow good netiquette and trim quoted text. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
Dossy, All anyone on this list knows is 1) Dossy does not work for AOL 2) Dossy has decided that Trac would be good for the AOLserver project. We have no idea why you decided we need to have a NEW bug tracker when the bugs in the current one are never dealt with. What problems are you trying to solve? After your initial post you decided to explain a small part of your idea a little more fully. You said you wanted to setup Trac and have some folks try it out to see if its works better. Better than what, and for what purpose you really didn't explain. If the community has to resources to maintain the current bug tracker, what makes you think adding ANOTHER one, that has a seperate list of bugs would help at all? Dave -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Dave Bauer [EMAIL PROTECTED] wrote: We have no idea why you decided we need to have a NEW bug tracker when the bugs in the current one are never dealt with. You're right, we don't need a new bug tracker. Yes, the bugs in the current one are never dealt with. Do you have any explanation as to why that is? Any guesses? What problems are you trying to solve? None, really. I've just been running into Trac a lot on various unrelated open source projects that I interact with and contribute to, and the latest version has really impressed me. After your initial post you decided to explain a small part of your idea a little more fully. You said you wanted to setup Trac and have some folks try it out to see if its works better. Better than what, and for what purpose you really didn't explain. I didn't have a purpose in mind, honestly. I was looking for feedback. One thing this community seems to love to do is talk a lot and do very little. I tried to avoid that trend by actually doing something (setting up Trac) then seeking feedback. The more positive feedback I get, the more I'll continue to set it up (import the wiki, move over SourceForge tickets, etc.). If the feedback is negative, I'll kill it off. If the community has to resources to maintain the current bug tracker, ... it doesn't. what makes you think adding ANOTHER one, that has a seperate list of bugs would help at all? I'd like to understand why nobody is using the current bug tracker. Why aren't others working on open bugs, committing fixes, and closing them out? What will it take to get people to contribute? What do I have to do? Tell me. I only ask that the answer doesn't boil down to Dossy has to do everything. That's it. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 2007.08.31, Tom Jackson [EMAIL PROTECTED] wrote: Although it is easy to try to jump in and start documenting stuff, there is so little current documentation that there might be an opportunity to rethink how to do this. Agreed. How do other, successfull, open source projects--as well as closed-source commercial projects--get documentation written? Through my own personal (anecdotal) experience, the lead engineers are not the ones that do the majority of the documentation writing. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 8/31/07, Dossy Shiobara [EMAIL PROTECTED] wrote: Agreed. How do other, successfull, open source projects--as well as closed-source commercial projects--get documentation written? Through my own personal (anecdotal) experience, the lead engineers are not the ones that do the majority of the documentation writing. Unfortunately for AOLserver 4.5 there isn't anyone else who CAN write the documentation. If the only way to know a new feature exists, and how to configure it is by reading C code, there aren't alot of non-engineers who can write that documentation. Dave -- -- 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] Switching to Trac to manage the AOLserver project?
After looking more closely at Trac [1], I'm really thinking it might be a good idea to use it to manage the AOLserver project. Does anyone have any strong feelings about this, particularly against it? I think this is a great idea. -john -- 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] Switching to Trac to manage the AOLserver project?
On 2007.08.30, Bas Scheffers [EMAIL PROTECTED] wrote: Sounds good to me. They say it integrates with svn, does that also mean switching AOLserver to svn? I was hoping to do that too, yes, but not at the same time. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 2007.08.30, John Buckman [EMAIL PROTECTED] wrote: After looking more closely at Trac [1], I'm really thinking it might be a good idea to use it to manage the AOLserver project. Does anyone have any strong feelings about this, particularly against it? I think this is a great idea. Great! Temporarily, I have Trac set up here: http://static.panoptic.com/aolserver/trac/ The wiki requires login to edit, and anyone who wants a Trac account needs to email me with their desired username and password and I'll add the account. I'll also put in a request to have dev.aolserver.com DNS pointed to the Trac install. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
Update: I've installed the Account Manager plugin for Trac, and now you can register yourself for an account: http://static.panoptic.com/aolserver/trac/register I've also put in the DNS change request to have dev.aolserver.com point to the Trac install. As soon as that's done, this will be the final URL: http://dev.aolserver.com/ -- Dossy On 2007.08.30, Dossy Shiobara [EMAIL PROTECTED] wrote: Great! Temporarily, I have Trac set up here: http://static.panoptic.com/aolserver/trac/ The wiki requires login to edit, and anyone who wants a Trac account needs to email me with their desired username and password and I'll add the account. I'll also put in a request to have dev.aolserver.com DNS pointed to the Trac install. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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] Switching to Trac to manage the AOLserver project?
On 2007.08.30, Tom Jackson [EMAIL PROTECTED] wrote: Not a single word about benefits, pros and cons, what is the point of asking about strong feelings? Sorry, I assumed that folks were familiar with Trac and those who weren't would read up on it, as I even provided the URL. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://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.
