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
>