[AOLSERVER] Question on two AOLserver tickets
Sep Ng
I'm trying to debug an AOLserver crash and the point of crash seems to
be AppendConn in NS_GetProcInfo... I will post the stack trace after
just for reference.
Looking through the ticket tracker on AOLserver, I found two tickets
of particular interest:
http://dev.aolserver.com/trac/ticket/325
--> My question with this ticket is was it ever resolved?
and the second ticket:
http://dev.aolserver.com/trac/ticket/152
--> This problem should only happen if the command ns_server was
called in a multi-threaded environment, right?
Here is the call stack trace I'm working with. I'm more interested in
Ticket #325 as it may be related to my problem.
----- Call Stack Trace -----
calling call entry argument values in
hex
location type point (? means dubious
value)
-------------------- -------- --------------------
----------------------------
kpedbg_dmp_stack()+ call B5B81884 B45FFB74 ? 0 ?
219
kpeDbgCrash()+72 call B5B75E14 0 ? 5 ? 0 ?
80BD810 ?
B45FFC08 ?
B45FFBF0 ?
kpeDbgSignalHandler call B5B867B4 0 ? 5 ? B72A331C ?
2 ? 4 ?
()+107 5F ? 4 ? B4600C5D ?
skgesig_sigactionHa call 00000000 B45FFC54 ?
B739FFE0 ?
ndler()+214
gsignal()+71 signal 00000000 6 ? B460110C ?
B460118C ?
abort()+265 call gsignal() 6 ? B460152C ? 0 ?
B7FC1E84 ?
B4601550 ?
B4601564 ?
NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ?
30 ? 46 ?
B7F565F0 ?
B7FC2420 call 00000000 B ? 33 ? 0 ? 7B ?
7B ? C ?
AppendConn()+117 call B7F74E20 B4601AE8 ? C ?
51C5 ? 0 ? 1 ?
B7E46FF4 ?
NsConnArgProc()+61 call AppendConn() B4601AE8 ?
80B0C1C ?
B7FB51A2 ?
FFFFFFFF ?
228E24D8 ? 0 ?
Ns_GetProcInfo()+16 call 00000000 B4601AE8 ?
CD298C0 ?
1 B4601A28 ?
B7F33C33 ?
B4DF4EA1 ?
B7E46BA0 ?
ThreadArgProc()+43 call B7F74410 B4601AE8 ?
B7F8E9B6 ?
CD298C0 ?
B7F6337C ?
CCF7A20 ?
Ns_ThreadList()+207 call 00000000 B4601AE8 ?
B7F8E9B6 ?
CD298C0 ? 0 ?
4A0935D9 ?
B7FBB174 ?
NsTclInfoObjCmd()+5 call B7F73B30 B4601AE8 ?
B7F8917B ?
46 B7FBC080 ?
B7FB34D3 ? 0 ?
B4601AE4 ?
TclEvalObjvInternal call 00000000 EF0B1C0 ? CE907D0 ?
2 ?
()+819 EC701D8 ?
B304D010 ?
A7DBAE50 ?
TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ?
EC701D8 ? 0 ?
)+10713 0 ? 0 ?
TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 0 ? 0 ?
0 ?
2 ) B4602924 ? 34ECE ?
TclObjInterpProc()+ call B7EBE8E0 CE907D0 ?
ABF19440 ?
645 120C4660 ? 1 ?
B7F565F0 ?
18 ?
TclEvalObjvInternal call 00000000 ABF78CE8 ?
CE907D0 ? 1 ?
()+819 EC701D4 ?
B7F565F0 ?
A7DBB540 ?
TclExecuteByteCode( call _init()+184 CE907D0 ? 1 ?
EC701D4 ? 0 ?
)+10713 0 ? 0 ?
TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 3 ? 3 ?
B7F565F0 ?
2 ) B4602924 ? 34EC2 ?
TclObjInterpProc()+ call B7EBE8E0 CE907D0 ?
ABF19320 ?
645 120C4260 ? 1 ?
100 ? 100 ?
TclEvalObjvInternal call 00000000 ABF76E28 ?
CE907D0 ? 2 ?
()+819 EC701CC ?
B7F565F0 ?
A7DBAE50 ?
TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ?
EC701CC ? 0 ?
)+10713 0 ? 0 ?
TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 0 ?
B7F2F0AB ?
2 ) B7F565F0 ?
A7DB7010 ? 87D6 ?
TclObjInterpProc()+ call B7EBE8E0 CE907D0 ?
ABF19158 ?
645 120C4260 ? 1 ?
CDDA468 ?
CC014B8 ?
TclEvalObjvInternal call 00000000 ABF3E9B0 ?
CE907D0 ? 3 ?
()+819 B460326C ?
A7DB6FC8 ?
EED6930 ?
Tcl_EvalEx()+1037 call _init()+184 CE907D0 ? 3 ?
B460326C ?
EED6908 ? 2D ? 0 ?
Ns_TclEval()+79 call B7F745A0 CE907D0 ? EED6908 ?
2D ? 0 ?
B7FBFC60 ?
B7FBFC60 ?
NsTclThread()+109 call B7F74610 0 ? 805FA80 ?
EED6908 ?
B4603420 ?
B4603330 ?
B46033DC ?
NsThreadMain()+117 call 00000000 EED6900 ?
B7F61CFE ?
B4603BB0 ? 0 ? 0 ?
0 ?
ThreadMain()+29 call B7F5EBC0 EED7480 ?
B7E9EFF4 ?
B46034C8 ?
B7E950BD ?
EED7480 ?
B4603490 ?
start_thread()+109 call 00000000 EED7480 ?
B4603490 ?
B4603490 ?
B4603490 ?
__clone()+94 call 00000000 B4603BB0 ? 0 ? 0 ?
0 ? 0 ?
0 ?
----- End of Call Stack Trace -----
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Jim Davidson
Do you have some sort of background job that calls "ns_server
active" (or similar) regularly? That could lead to random crashes.
The description in http://dev.aolserver.com/trac/ticket/152 is
accurate: The code, by design, is not strictly safe as it's assumed
to only be used interactively and occasionally as part of debugging
and performance monitoring/optimization.
To make it safe would require adding mutex locks around areas that are
assumed read-only and/or single-threaded which could possibly lead to
lock contention. I can't say it those assumptions have ever been
proven true or false but that was my thinking when the code was first
written.
-Jim
Jade Rubick
So our monitoring is killing our servers. Nice!
I'm removing that code now.
Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jru...@truist.com
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited.
Jim Davidson
Jade Rubick
Jade Rubick
TRUiST
120 Wall Street, 4th Floor
New York, NY 10005 USA
Tom Jackson
potential crash.
tom jackson
Jim Davidson
some config flag to enable?
Jim
Sent from my iPhone
Tom Jackson
> Good idea. Maybe it would make sense to disable it by default with
> some config flag to enable?
I was thinking the same, but I wasn't sure how many people actually use
this command.
This must be one of a very few commands that I have never used, so I'm
far from informed on what it is used for.
> Sent from my iPhone
Sent via a local network shared with an iTouch.
tom jackson
Sep Ng
on AOLserver?
On May 15, 6:08 am, Jim Davidson <jgdavid...@MAC.COM> wrote:
> Good idea. Maybe it would make sense to disable it by default with
> some config flag to enable?
> Jim
>
> Sent from my iPhone
>
> On May 14, 2009, at 4:49 PM, Tom Jackson <t...@RMADILO.COM> wrote:
>
> > Maybe calling the API should result in a ns_log Warning to indicate a
> > potential crash.
>
> > tom jackson
>
> > On Thu, 2009-05-14 at 13:26 -0700, Jade Rubick wrote:
> >> I'm just happy we figured it out.
>
> >> We were using this call:
>
> >> set connections [ns_server active]
>
> >> But it wasn't in a scheduled proc, so I just moved it behind a
> >> password protection section, and put a warning around it. We seldom
> >> (never) used that page anyway. I think a bot may have found it or
> >> something.
>
> >> Jade
>
> >> Jade Rubick
>
> >> Director of Development
> >> TRUiST
>
> >> 120 Wall Street, 4th Floor
>
> >> New York, NY 10005 USA
>
> >> jrub...@truist.com
> >> +1 503 285 4963
> >> +1 707 671 1333 fax
>
> >>www.truist.com
>
> >> The information contained in this email/document is confidential and
> >> may be legally privileged. Access to this email/document by anyone
> >> other than the intended recipient(s) is unauthorized. If you are not
> >> an intended recipient, any disclosure, copying, distribution, or any
> >> action taken or omitted to be taken in reliance to it, is prohibited.
>
> >> On May 14, 2009, at 12:33 PM, Jim Davidson wrote:
>
> >>> Yup -- should really have been documented better -- sorry about
> >>> that.
>
> >>> Anyway, what is the monitoring attempting to dig up? There may some
> >>> other safe ways to get the same.
>
> >>> -Jim
>
> >>> On May 14, 2009, at 2:04 PM, Jade Rubick wrote:
>
> >>>> Ironically, we have some monitoring code that does use that
> >>>> functionality.
>
> >>>> So our monitoring is killing our servers. Nice!
>
> >>>> I'm removing that code now.
>
> >>>> Jade Rubick
> >>>> Director of Development
> >>>> TRUiST
> >>>> 120 Wall Street, 4th Floor
> >>>> New York, NY USA
> >>>> jrub...@truist.com
> >>>> +1 503 285 4963
> >>>> +1 707 671 1333 fax
>
> >>>>www.truist.com
>
> >>>> The information contained in this email/document is confidential
> >>>> and may be legally privileged. Access to this mail/document by
> >>>> anyone other than the intended recipient(s) is unauthorized. If
> >>>> you are not an intended recipient, any disclosure, copying,
> >>>> distribution, or any action taken or omitted to be taken in
> >>>> reliance to it, is prohibited.
>
> >>>> On Thu, May 14, 2009 at 10:19 AM, Jim Davidson
> >>>> <jgdavid...@mac.com> wrote:
> >>>> Hi,
>
> >>>> Do you have some sort of background job that calls
> >>>> "ns_server active" (or similar) regularly? That could
> >>>> lead to random crashes. The description in
> >>>> http://dev.aolserver.com/trac/ticket/152is accurate: The
> ...
>
> read more »
Gustaf Neumann
> On Thu, 2009-05-14 at 18:08 -0400, Jim Davidson wrote:
>
>> Good idea. Maybe it would make sense to disable it by default with
>> some config flag to enable?
>>
>
> I was thinking the same, but I wasn't sure how many people actually use
> this command.
>
The (sub)command could be always available but return in
installed versions an empty result. The docs could say that
... this (sub)command is intended for debugging/developing
aolserver and is normally deactivated. In order to avtivate
it, compile aolsever with flag XXX. Be aware that this
(sub)command is not thread save and can kill the aolserver
when used with multiple threads ....
-gustaf neumann
Tom Jackson
as to be loaded, and keep the C API available in the core. It is
obviously more work, but the admin has to make a choice to load the Tcl
API, which is more open to misuse. I did something like this for a few
additional ns_conn options.
Gustaf's idea is easier to pull off at least initially, but it shouldn't
be tied to an unrelated option like debugging. I leave on debugging for
low traffic servers and I can also turn it on/off on a per-namespace
basis.
tom jackson
On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote:
> How about having the proc enable only if debug settings are turned on
> on AOLserver?
Jim Davidson
I'm looking at the head code and it appears it's now safe -- the
connection list is walked with a pool lock held and the request data
(method, url) seem to be copied with a global "reqlock" mutex held.
Jade: What version of AOLserver are you using?
-Jim
Jade Rubick
J
Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited.
Jack Schmidt
--
"A scrum a day keeps the pigs at bay"
Jim Davidson
Sep Ng
it seems that the ticket may have been addressed with aolserver 4.5
too... so I think it's looking like everything is resolved.
On May 20, 11:11 pm, Jim Davidson <jgdavid...@MAC.COM> wrote:
> Yup -- agreed. I was talking with Dossy who says the Trac stuff is
> generally out of date anyway, the definitive bug list is still on
> Sourceforge (definitive in it's the place, can't say how accurate the
> bug reports are).
>
> -Jim
>
> On May 15, 2009, at 6:35 PM, Jack Schmidt wrote:
>
>
>
> > I guess if it's thread safe now, the ticket should be closed with a
> > reference to aolserver 4.5.
>
> > 2009/5/16 Jim Davidson <jgdavid...@mac.com>
> > AOLserver -http://www.aolserver.com/
>
> > To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com
> > > 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 <lists...@listserv.aol.com
> > > with the
> > body of "SIGNOFF AOLSERVER" in the email message. You can leave the
> > Subject: field of your email blank.
>
> > --
> > "A scrum a day keeps the pigs at bay"
>
> > --
> > AOLserver -http://www.aolserver.com/
>
> > To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com
> > > 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 <lists...@listserv.aol.com> with the
Dossy Shiobara
> Yup -- agreed. I was talking with Dossy who says the Trac stuff is
> generally out of date anyway, the definitive bug list is still on
> Sourceforge (definitive in it's the place, can't say how accurate the
> bug reports are).
I would love to hear that the AOLserver community prefers Trac for
ticket tracking over SourceForge's tracker and that everyone would be
happy if I refreshed the Trac tickets with a current snapshot of
SourceForge data, and we could shut down the SourceForge tracker once
and for all ...
But, I don't want to kick that hornet's nest again, so I'll let someone
else do it this time. :-)
--
Dossy Shiobara | do...@panoptic.com | 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)
Sep Ng
To be frank, the only reason why I keep using the Trac ticket tracker
is that it's the one I found. Had I known that the sourceforge ticket
tracker was the active one, I would have used that one instead. Begs
to question though... why two ticket trackers?
Anyway, thanks everyone for all the valuable information!
On May 21, 1:22 am, Dossy Shiobara <do...@PANOPTIC.COM> wrote:
> On 5/20/09 11:11 AM, Jim Davidson wrote:
>
> > Yup -- agreed. I was talking with Dossy who says the Trac stuff is
> > generally out of date anyway, the definitive bug list is still on
> > Sourceforge (definitive in it's the place, can't say how accurate the
> > bug reports are).
>
> I would love to hear that the AOLserver community prefers Trac for
> ticket tracking over SourceForge's tracker and that everyone would be
> happy if I refreshed the Trac tickets with a current snapshot of
> SourceForge data, and we could shut down the SourceForge tracker once
> and for all ...
>
> But, I don't want to kick that hornet's nest again, so I'll let someone
> else do it this time. :-)
>
> --
> Dossy Shiobara | do...@panoptic.com |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 <lists...@listserv.aol.com> with the
Dossy Shiobara
> To be frank, the only reason why I keep using the Trac ticket tracker
> is that it's the one I found. Had I known that the sourceforge ticket
> tracker was the active one, I would have used that one instead. Begs
> to question though... why two ticket trackers?
We started at SourceForge, using the tracker there. At one point, I had
gotten tired of its clumsy interface and wanted to try something else.
So, I went and imported the tickets into Trac to let folks see what it
might look and feel like.
As an alternative, I'd be happy to import the data into Redmine [1],
another nice open source project management tool that has many of the
same features as Trac.
However, I don't want to do the work if the community would rather keep
using the SourceForge tracker.
I clearly suck at the whole "consensus-building" thing, and AOLserver
being an open source project means until someone steps up to volunteer
to do that, well, it won't get done. I'm more than happy and capable to
do the tech side of things, but time and again it's clear that this
project needs a people person to make sure everyone's happy with the
direction things are going in and I'm not that person.
--
Dossy Shiobara | do...@panoptic.com | 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)
--
Jade Rubick
Perhaps the problem is that there is no formal structure for Aolserver, so nobody has the "authority" to act on behalf of the community.
What if we had a simple voting application somewhere, and the members of this mailing list each got a vote?
J
Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited.
Dossy Shiobara
> Personally, even though I think many in the community don't like Dossy
> acting without community involvement, I'd rather see something done than
> nothing, as long as it isn't harming the project.
I definitely understand that people dislike my approach. I also know
that things get discussed to death and nothing actually happens as a
result, too. I lean heavily to the one extreme (action, little
discussion) which understandably bothers people. Unfortunately, it's
the way I am; it's how I know how to get things done. I like to believe
that nothing I do intentionally harms the project on a technical level.
> Perhaps the problem is that there is no formal structure for Aolserver,
> so nobody has the "authority" to act on behalf of the community.
I agree, this is probably a huge defect in the structure of the
AOLserver project's organization and management. Thanks for raising the
issue.
> What if we had a simple voting application somewhere, and the members of
> this mailing list each got a vote?
I am very, very worried about a pure democracy approach as it often
produces the Bikeshed Effect [1].
[1] http://en.wikipedia.org/wiki/Color_of_the_bikeshed
In short, a large number of individuals abstain from voting on complex
issues where they feel it would be inappropriate for them to vote as
they're not qualified to decide either way. This results in very skewed
representation of votes on difficult matters.
Similarly, a large number of individuals vote on the trivial issues,
which gives disproportionate weight to them, artificially inflating
their perceived importance. In cases where a majority of 2/3rd's or
some other criteria is required, reasonably trivial decisions can be
unnecessarily held up due to lack of consensus.
I'd really like to create a structure that empowers and enables the top
of the anecdotal Pyramid of Participation (1% creators, 9% contributors,
90% lurkers). Perhaps participants on this list can help by
brainstorming suggestions for such?
My thoughts on the matter: the US Presidential election system and many
corporations operate in a way that I think tries to achieve this goal,
using proxy voters (electoral college, board of directors) whose intent
is to represent its constituents. While polling the popular vote is
interesting, ultimately the electoral college votes and decides the
President. Of course, I'm very likely heavily biased being an American,
thinking this system is a good one - if (any of) you have alternative
models to suggest, please describe them.
Tom Jackson
do we have working on tickets? How many tickets/issues are worked on by
several people without broader community input?
My sense is that the same handful of developers respond to a half dozen
real bugs/issues per year. Half the time we discover that the bug is in
an old or patched version of AOLserver.
A ticket tracker sounds like a great place to let serious issues with
AOLserver go unaddressed by the whole community, not some great tool for
organizing a rapidly changing software project.
I have one observation of how our email-list based development cycle
works, and a possible fix requiring minimal to no organizational effort.
On the last adp bug I did a little bit of work, came up with some
working updates and then dropped the ball with submitting a formal
patch. Problem is I keep my own version of AOLserver, so I don't have an
up-to-date checkout from sourceforge. I'm lazy.
Forcing me to interact with a ticket tracker wouldn't improve my
community involvement, it would probably make contributions even less
likely.
What might help me, and maybe others, would be a weekly email summary of
unfinished business, dropped balls, or whatever, sort of a running tally
with new items on top, and stale items toward the bottom.
If weekly is too often, maybe every other week, but I tend to forget
about stuff after a week.
Not sure if the same person would need to do it every week, maybe a
rotating task.
tom jackson
Dave Bauer
Personally, even though I think many in the community don't like Dossy acting without community involvement, I'd rather see something done than nothing, as long as it isn't harming the project.
Perhaps the problem is that there is no formal structure for Aolserver, so nobody has the "authority" to act on behalf of the community.
What if we had a simple voting application somewhere, and the members of this mailing list each got a vote?
In the case of the bug tracker, the bug tracking software is clearly NOT the problem, but the lack of anyone doing anything about those bugs on way or the other. Until that is addressed any effort to change the presentation of the bugs is useless. There is no process or resources to deal with the bugs. That is the problem.
Dave
--
Dave Bauer
da...@solutiongrove.com
http://www.solutiongrove.com
Tom Jackson
> In the case of the bug tracker, the bug tracking software is clearly
> NOT the problem, but the lack of anyone doing anything about those
> bugs on way or the other. Until that is addressed any effort to
> change the presentation of the bugs is useless. There is no process or
> resources to deal with the bugs. That is the problem.
I pretty much agree with this, but it is important to point out that
there are no fatal bugs in AOLserver, no bugs which make it useless or
unreliable, no bugs which would cause someone to abandon AOLserver.
There is also basically nothing we can do to make it run any faster, it
is just too efficient at the C code level, and Tcl speed is handled by
the Tcl community.
Most bugs only show up under extreme usage conditions.
One area of concern is just a lack of documentation of all kinds.
At the moment my guess is that a ticket tracker, even the one at source
forge, is more likely to make it more difficult to find information
about bugs and get them fixed.
tom jackson
Dossy Shiobara
> Forcing me to interact with a ticket tracker wouldn't improve my
> community involvement, it would probably make contributions even less
> likely.
>
> What might help me, and maybe others, would be a weekly email summary of
> unfinished business, dropped balls, or whatever, sort of a running tally
> with new items on top, and stale items toward the bottom.
While SourceForge does have a "patch tracker" it leaves much to be desired.
Perhaps if we had a system where patches and issues could be tracked and
a report could be generated and emailed to the mailing list, it would
accomplish what you're describing?
If patches could be submitted, and someone else - anyone else - could
apply it and test it or otherwise review it and commit it, that would
let contributors who may not be prepared to commit the change to at
least provide the code that others could review and commit.
Great idea, Tom. Thanks.
Dossy Shiobara
1) Dave Bauer identifies the "lack of anyone doing anything about [open]
bugs" and the lack of "process or resources to deal with the bugs" as a
problem.
2) Tom Jackson identifies that there's little in-community support for
would-be contributors to get their changes merged into the codebase.
3) Tom Jackson identifies that there is "a lack of documentation of all
kinds".
Lets do a little wishful dreaming for a moment and brainstorm actionable
ways to try and address these deficiencies. Let me try to seed this
with a few questions:
How can we find resources to deal with bugs, support contributors and
write documentation? What would it take to get existing contributors to
contribute more? How can we recruit new contributors?
Would adequate funding aid in adressing these issues? In best-effort
accuracy round number estimates, what kind of funding levels would we
need to reach to achieve what kind of results?
If training were provided, could we transform more passive community
members into more active contributors and supporters? What kind of
training would be necessary? What subjects would need to be covered in
order to enable what kind of contributions?
...
Feel free to add more questions as appropriate, but especially answers
that have clear actions associated with them. I'll try to do my best to
collate the various actions and present them in a concise list. Then,
maybe we can try to find ways to make those things happen.
Tom Jackson
think so. Yes, the ticket tracker might have unresolved "tickets". But
just because we have stuff in our ticket tracker doesn't mean that any
particular item actually needs or demands resolution.
As I have stated before, most bugs are found by users who have demanding
needs, not casual users. If these bug finders don't have resources to
fix the bugs that they find, who cares?
Personally I have no economic sympathy for a user who has millions of
hits per week or month and just spent time "upgrading" from a forked
version of AOLserver to the current version only to discover "bugs".
Why not pay someone to fix your problems? Instead, with the AOLserver
community, you get a few hints of what to try for free! But if someone
needs documentation, this is really not a community problem. Most
community members know what they need to know and know how to ask about
the things they don't know.
By my estimate we get a handful of bugs per year. Almost everyone could
continue to use AOLserver without any fixes to these bugs. How much
organization do we need to deal with such an ideal situation? My guess
is about as much as we have right now.
One thing which make no sense to me is delegating documentation to those
who didn't write and can't maintain the code they are trying to
document. It isn't a matter of training, it is a matter of
responsibility. If you want to maintain some code, you should also
maintain the documentation. But, you know, sometimes documentation is
satisfied by responding to user questions when they use your code. This
is the highest form of documentation: maintain ownership and
responsibility for the code you write, and respond to user queries.
Personally I have no clue how we could recruit new community members who
could contribute at an acceptable level compared to long term members
who know all the ins and outs of the code. Just review how much effort
is involved getting agreement among current members. Why would less
experienced community members aid in code modification?
Anyway, the basic problem is that there isn't much real work that needs
to be done. Why is this so bad?
tom jackson
--
Sep Ng
to simply stress that no matter what technology we use, it does not
inherently solve any of the problem. So, Sourceforge or Trac itself
does not solve the problem. If we manage to identify the problem,
then we can find the technological means to solve the problem.
I think it's common in open source projects of the lack of anyone
doing anything. In some cases, I think documentation is a huge
hurdle, especially on getting new folks to help out. I'm in the
process of tracking down crashing bugs on old aolserver versions and
after weeks of compiling and code-testing, I still find the code
pretty daunting as it is.
I also think, and I could be dreadfully wrong here, that outside of
OpenACS and a few other cases, I don't think there's a huge number of
sites using AOLserver. Maybe it's a chicken and egg problem with
support vs userbase. Again, this is just my opinion and hope this
isn't taken the wrong way.
I guess also what would help is if interested developers understand
how the development cycle and process of contribution works, they can
understand better how they can help contribute back to aolserver.
Just my two cents.
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the
Robert Garron
assessment of the state of AOLserver. Our bugs compared to other "more
staffed" open source projects are far less and far fewer. In addition,
I have been working with Open Source for many years and I used
extensively, Apache, Apache2, Netscape, Cold Fusion, IIS (a paid for
enterprise environment), and other more esoteric servers... but the net
of my time and experience is that the AOLserver is the most robust,
stable, and very very secure (if you take the time to set it up
correctly) server that I have ever worked with.
As to your user base (I am one of your users), if our community truly
desires more users, it is simple -- marketing marketing and marketing --
how? -- Clear concise documentation for the masses (as Sep Ng talks of
documentation) and many many books (that people pay for to use the open
source) -- so all AOLserver coders out there of this GREAT "product",
write a book or two and get them published by O'Reilly Media,
Addison-Wesley, Safari, Kluwer, Artech House, and the like -- there are
many technical publishers out there looking for good books to print and
sell... And if you are a good negotiator, you will reap the rewards of
your internal knowledge of the open source code. Then, as Tom states,
if someone needs "their bug" fixed, they can hire one of the many
talented AOLserver coders to fix the problem and have the fix merged
back into the code base. I myself simply read the code to understand
what is going on... but it is a complex product that does amazing things
compared to Apache and the like...
So this has been an interesting conversation to watch and read, but the
net of this is that AOLserver rocks! I too want to thank all of the
core AOLserver coders for creating such a fantastic product over the
years!! Bravo to you all.
Regards,
Robert Garron
Gustaf Neumann
critical
bugs. The few severe issues showing up in the last few years were repaired
in short time. I am not sure, what kind of problems dave has with the
"list of bugs", aside optics; i dout he has a real issue with this.
Sure, the tickets
on the sourceforge tracker could/should be weeded our from
old/underspecified/obsolete entries, the documentation should be improved,
etc., but alltogether aolserver is in a good and stable state.
Concering bugtracker tools etc.: For what it is used, sourceforge is
good enough.
Sourceforge has a good visibility. I doubt, that changing to e.g. track will
change the frequency of bug reports and fixes.
by 2 cents
-gustaf neumann
Tom Jackson schrieb:
> Maybe I'm being too ambiguous. Do we have any critical bugs? I don't
> think so. Yes, the ticket tracker might have unresolved "tickets". But
> just because we have stuff in our ticket tracker doesn't mean that any
> particular item actually needs or demands resolution.
>
Dave Bauer
To quickly summarize:
1) Dave Bauer identifies the "lack of anyone doing anything about [open] bugs" and the lack of "process or resources to deal with the bugs" as a problem.
I really agree more with Tom. I just meant that voting for a ticket tracker solution was not productive unless someone was going to do something about the tickets.
As Tom reminded us, the main reason noone does anthing about the tickets is that they are not high priority. If there is a major bug, usually someone posts about it to the list, a patch is devised and applied to the source code. This happens maybe two or three times a year, at most.
So I don't want to suggest the AOLserver community has to do anything, we hardly ever touch our AOLserver, that is great, but boring. It is a fact of well written mature software that does exactly what it is supposed to do.
Dave
David Siktberg
I have several that have been running for six years, but I do not choose or
want to heavily advertise that they use AOLServer. What matters to me is
that they are rock solid, performance is never an issue, and that I have
incredible power and flexibility to quickly build the functionality I need,
as that emerges over time in the business applications that are being
hosted. I don't have to keep abreast of the mechanics of rapidly changing
server capabilities I don't need, don't have to worry monthly about new
security problems to protect against, don't have to spend a lot of resources
just keeping the technology platform current - resources which would NOT be
devoted to my business needs.
I get a sense there are others like me as well, though I don't know for
sure.
I totally resonate with Tom's points - it ain't broke!
Dave