open source terminal and scanning

[Brian K. White]

On 10/25/2010 6:47 PM, Fairlight wrote:
> On Mon, Oct 25, 2010 at 05:54:56PM -0400, after drawing runes in goat's blood,
> Brian K. White cast forth these immortal, mystical words:
>>
>> Also I put the source into a gitweb but I haven't really figured out git
>> or gitweb. I managed to create a git repo out of the source archive, and
>> get it publicly browseable via gitweb, then managed to get the url to be
>> nicer via vhost setup on the host machine, but in the process broke the
>> ability of gitweb to execute gzip, so the download snapshot button
>> doesn't work (you get a zero byte tar.gz and error_log on the host shows
>> permission denied executing /bin/gzip)
>
> Personally, I think SVN is a smarter move.  It's five years more mature
> than Git, and it's far more widely used, with variants like TortoiseSVN for
> Windows, etc.
>
>> Also, since I would wish this to become a more community effort I am
>> thinking of changing the name from Aljex to something generic like open
>> vertical terminal or similar. The idea is, the app is meant for use in a
>
> How about naming it Spackle?  Fits with the PuTTY theme, and it does fill
> in some of the functional holes identified in the original.  Could also
> call it "double-glaze" and use dg:// for your URI.  Just some thoughts...
>
>> If anyone knows anything about git and wants to help make this work and
>> have commit access to improve the code let me know.
>
> If you were using SVN, I could have you set up in an hour or two, both
> regular SVN port and Apache WebDAV access.  It's been about ten months
> since I last set up SVN from scratch, so that's why it'd take a bit longer
> than one might expect...that, and SVN isn't known for compiling terribly
> quickly in the first place--it's pretty big.
>
> I know nothing at all about using Git.  I can't speak to Git.  If you're
> married to Git, luck with that. :)

My thinking with git was A) since cvs and svn existed already a long 
time, there must have been some reason "they" went through the bother of 
inventing git. and B) since the linux kernel uses git, those reasons 
probably have some merit.

I'm not married to it exactly, but I have no reason to believe this 
reasoning is broken yet.

I'll give myself a little more time to either get git going or take you 
up on your offer if it's still open at that time.

One think I know is I don't think I want to switch systems later even if 
it's relatively easy to export/import the data, simply because I don't 
want to tell users (all one or two of them haha) to change how they do 
things after they've gone through the bother to get set up, which is why 
I'm not just saying ok thanks immediately. I haven't examined the pros & 
cons of the different systems enough to pick one based on anything more 
than the speculation above.

Maybe I'll just use a 3rd party like sourceforge or codeplex.

> I imagine no matter what CMS you use, you're going to need to manage
> accounts to which you give write permission to commit changes back, besides
> a generic access to read the project.  So if you do this, be aware you're
> going to likely be acting as an account manager for the project, and that
> it's not going to run itself.  You can automate sign-up and such with a
> little CGI, but I'd advise against it for a project like this.  Don't
> anticipate it being fire-and-forget, so make sure you're committed to doing
> this on an ongoing basis; even if the management is minimal, there will
> likely still be -some- ongoing management.

Oh sure I get that. How will I ever keep up with the constant flood of 
registration requests and patch submissions?

Now if a mere 100 people worldwide could put up 7.5k each (I would hands 
down right out of my own personal pocket let alone get Aljex to as 
well), or a mere 50 people put up 15k (I might do that too if it was a 
sure and final thing), or any combination that adds up to 750k, and if 
the talk that was loosed at that meeting including from Bud himself was 
more than hot air, we could buy fp and relase it to all once and for all 
and start clearing up the plethora of easily addressed things that cause 
idiotic amounts of developer effort to work around.

Then again, it's only existing apps that care about this. For a new 
project or a new consultant/developer, OpenPOS & OpenERP would seem to 
be a no brainer as a starting point for custom/niche apps.

Then again, again, one of the only reasons fp no longer competes with 
stuff like that is because the users who would gladly contribute, can't. 
Every day that goes by with things as they are, the less I think even I 
would bother even if I suddenly could do whatever I wanted. We've been 
working the last few years on all new completely web front ends to our 
stuff, and that has required us to make our stuff work more 
transactionally just as a natural consequence. Before that, it would 
have been laughably impractical to "rewrite everything in some other 
language and using some other db". But, once you are performing packaged 
discrete transactions instead of a rats nest tangle of multiple 
concurrent lookups and @triggers, it becomes almost easy to start 
swapping out pieces of the application from talking to filepro to 
talking to some other db, one piece at a time.

-- 
bkw