proxool-developer

[Proxool-developer] Staring with the doc pages

[Abhishek M. <abh...@gm...>]

hi All,

Started using proxool and found some descrepencies in documentation to satrt
with. Just for an example, AdminServlet fully qualifies location in the
Configuration doc page is not right. That's not on wiki I presume and whom
or how to get that corrected? Pointers?

Abhishek Manocha
--

Re: [Proxool-developer] Staring with the doc pages

[Bill H. <bi...@lo...>]

Hello Abhishek,

No it's not a Wiki but probably should be. I'm minded to move the whole
project to Github - it allows a lot more collaboration through forking and
the Wiki works well. Anyone have an opinion on that?

-
Bill

2009/4/8 Abhishek Manocha <abh...@gm...>

> hi All,
>
> Started using proxool and found some descrepencies in documentation to
> satrt with. Just for an example, AdminServlet fully qualifies location in
> the Configuration doc page is not right. That's not on wiki I presume and
> whom or how to get that corrected? Pointers?
>
> Abhishek Manocha
> --
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>

Re: [Proxool-developer] Staring with the doc pages

[Christian N. <chr...@em...>]

Hi.

Long time no hear :)

I haven't familiarized myself with Git yet. Could you elaborate a bit on
what you mean by "collaboration through forking" and why that is desirable?

In my opinion a Wiki is fine for HOWTOs and other secondary documentation,
but I think it's better to keep the formal documentation under version
control to keep it under adequate quality control and in sync with the
version the user actually are using.

Christian

On Thu, Apr 9, 2009 at 7:47 AM, Bill Horsman <bi...@lo...>wrote:

> Hello Abhishek,
>
> No it's not a Wiki but probably should be. I'm minded to move the whole
> project to Github - it allows a lot more collaboration through forking and
> the Wiki works well. Anyone have an opinion on that?
>
> -
> Bill
>
> 2009/4/8 Abhishek Manocha <abh...@gm...>
>
>> hi All,
>>
>> Started using proxool and found some descrepencies in documentation to
>> satrt with. Just for an example, AdminServlet fully qualifies location in
>> the Configuration doc page is not right. That's not on wiki I presume and
>> whom or how to get that corrected? Pointers?
>>
>> Abhishek Manocha
>> --
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Proxool-developer mailing list
>> Pro...@li...
>> https://lists.sourceforge.net/lists/listinfo/proxool-developer
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Proxool-developer mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>

Re: [Proxool-developer] Staring with the doc pages

[Bill H. <bi...@lo...>]

Hei Christian!

Good to hear from you :)

Actually, as soon as I sent that last message I realised that I should have
been clearer and not confused a Wiki with forking. Let me deal with each of
those in turn:

GitHub is an obvious place to host a Git repository. It gives you a Wiki
that makes it much easier to maintain the documentation. The Wiki is only
editable by designated collaborators (equivalent to the small group of
committers we have at SourceForge). It's not the only solution by far but
it's much easier to change than the present documentation which is just
static HTML. I'm approaching this from the aspect of that there needs to be
almost zero developer effort since I'm not aware of anyone having time to
work on this. Copy and pasting from the current website into GitHub Wiki
would be relatively easy.

If anyone is prepared to put the effort in, getting the documentation under
source control would be wonderful. It isn't at the moment. I'm open to any
suggestions.

As to "collaboration through forking", Git makes it simple (even desirable)
for external collaborators (ones that we haven't chosen or selected in any
way) to fork the project and make their own changes as they see fit. Git
also makes it simple to pull those changes back into the master repository
(in a controlled way). The whole thing is much more democratic with each
commit making it back into the project on its own merits.

-
Bill

Re: [Proxool-developer] Staring with the doc pages

[Christian N. <chr...@em...>]

Hi again.

I don't want to appear as a dusty old conservative here, but I think its
important to point out that Proxool is a very mature product with wery
little development going on. My humble opinion is that we should have very
good reason for doing something as drastical as moving project host and
changing the version control system.

Here are few toughts regarding this:

Sourceforge provides support for Git (
http://apps.sourceforge.net/trac/sourceforge/wiki/Git) and Wiki (
http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted%20Apps), so I fail
to see the motiviation for changing project host on these grounds.

As far as I can see there are several negative aspects of moving project
host:
* User familiarity: The project would be moved away from where it has always
been found.
* Fragmented statistics: Statistics such as download and visiting users
would be interrupted.
* Fragmentetd issue and forum history.
* Need to spend resources on setting up the project in a new environment.
* Loss of SouceForge services such as JDK availability.

A few questions about starting to use Git:
* Will a move to Git would spark a frenzy of new activity?
* Do developers find it particularly hard to develop patches and try them
out locally today?
* Is it particualary hard to incoroprate contributed patches in the Proxool
trunk today?
* What is the ratio of Git-familiarity amongst potential Proxool
contributors today?

Concerning usage of Wiki for documentation I would like to reiterate my
points from my last mail. Please let us discuss this closely before we do
anything, because I would consider it a grat loss to get the documentation
dis-attached from the Proxool versions:
* Wiki is fine for HOWTOs and other secondary documentation
* Formal documentation should be kept under version control to keep it under
adequate quality control and in sync with the version the user actually are
using. This is doubly true if you want Proxool to exists as several forks.
Then you will have two axis of versioning.

To summarise my standings on this in the old OS project voting lingo:
Move project host: -1
Change version control to Git: 0
Start using Wiki for Proxool homepage and secondary docs: +1
Disconnect the formal documentation from version control: -1

Are we sure this is were we want to spend the limited resources available to
Proxool develompent? Personally I think the most important develoment that
could be done is to add support for request queueing when the pool runs out
of connections. A feature I have always oposed, but user feedback has proved
me wrong. I think maye I could spare som time to work on that this spring.

Kind regards
Christian

2009/4/9 Bill Horsman <bi...@lo...>

> Hei Christian!
>
> Good to hear from you :)
>
> Actually, as soon as I sent that last message I realised that I should have
> been clearer and not confused a Wiki with forking. Let me deal with each of
> those in turn:
>
> GitHub is an obvious place to host a Git repository. It gives you a Wiki
> that makes it much easier to maintain the documentation. The Wiki is only
> editable by designated collaborators (equivalent to the small group of
> committers we have at SourceForge). It's not the only solution by far but
> it's much easier to change than the present documentation which is just
> static HTML. I'm approaching this from the aspect of that there needs to be
> almost zero developer effort since I'm not aware of anyone having time to
> work on this. Copy and pasting from the current website into GitHub Wiki
> would be relatively easy.
>
> If anyone is prepared to put the effort in, getting the documentation under
> source control would be wonderful. It isn't at the moment. I'm open to any
> suggestions.
>
> As to "collaboration through forking", Git makes it simple (even desirable)
> for external collaborators (ones that we haven't chosen or selected in any
> way) to fork the project and make their own changes as they see fit. Git
> also makes it simple to pull those changes back into the master repository
> (in a controlled way). The whole thing is much more democratic with each
> commit making it back into the project on its own merits.
>
> -
> Bill
>

Re: [Proxool-developer] Staring with the doc pages

[Bill H. <bi...@lo...>]

Hi Chr,

All good points, friend.

One of the things I like about Git is the democracy. People can fork it and
explore their own ideas. The important thing is that it becomes very easy to
reincorporate those ideas back into the original. In SVN, a fork almost
always diverges.

BUT, Git is a change. It's a lot more different than the difference between
CVS and SVN. Understanding it is almost easier if you've never used CVS or
SVN. It is beautful and far superior, imho, but that doesn't necessarily
mean we should switch.

OK. So let's leave things as we are. I'd hate to cause any pain just because
I like Git. I don't think there's any reason why someone can't put it into
Git if they want anyway. I don't mind either way.

Aside from the queued connections, I think the biggest thing missing from
Proxool is the documentation. It's not under version control now and never
has been. All that happens is that a snapshot of it is captured as HTML and
bundled inside the distribution for a version.  At the moment, there's no
easy way for someone to contribute any documentation and it's a pain in the
arse for even me to change it. Any body got any ideas and any one got any
time to put the documentation somewhere sensible?

-
Bill