Menu
▾
▴
firebird-website
|
From: Pavel C. <pc...@ib...> - 2009-11-19 09:22:24
|
Lester Caine napsal(a): > Pavel Cisar wrote: >> The >> problem is JIRA VM. Again, the VM works ok, but due to all these fancy >> technologies used, it's very hard to maintain it (especially when one is >> no Java/Tomcat wizard). My point is that we want to keep the website >> simple and a breeze to work with, as there is no real reason to go >> JIRA-route with it. > > That was my own original objection to the new tracker ... ;) Well, the problem is mostly at our side than on JIRA itself. JIRA is great product, and we chose it because we need all this power and so far it handles our needs very well. But over time it happened that the JIRA maintenance ended up on me, and I know nothing about Java/Tomcat and I wasn't even one who installed it, so go figure. I could learn all that stuff at least to the degree necessary to handle JIRA installation at basic level (i.e. patchwork monkey following the Howto's), but it's huge area and this is not the only thing on my shoulders... So if there would be someone with these skills willing to help with it, it could be a quite different and much more pleasant story. best regards Pavel Cisar |
|
From: tjelvar e. <tj...@fa...> - 2009-11-18 20:51:21
|
Hi all, > 1. Site search could be actually faster from flat files than from > database if there isn't any full-text that could work with Firebird. a) I'm not a drupal evangelist, but it does have fulltext-search in the framework, others may have too - don't know about BW. b) Home of firebird - powered by flatfiles. True irony... > 2. We don't need blogs, forums or extensive news on Firebird website. > There are other sites that do them all already. Firebird website is > for > documentation, downloads, link "address book" to other resources and > for > Firebird project members (developers, docwritters, QA etc.) to help > them > do their work and to potentially attract new contributors. It's > definitely not a community site and shouldn't become one. It should > be a > display case for the project, static and tightly controlled. I do respect your opinion, and this is where the discussion should start. What to put in and what it should be. My original post, which started of this discussion as i belive, was based on a reflection that A.W Harrison wrote that the interest for firebird at last conference where null. Your reflections around "definitly not a community site" should be given a second thought. > 3. As wiki goes, it doesn't necessarily needs a database as backend, > and > we could probably use already existing one or use one provided by > SourceForge anyway, and soft-embed it into our site. I'm not sure what you mean with soft-embed but it sounds as dependent patch, and with a mysql-prefix. Hands down here. > 4. Using a database would force us to work with site content over the > web (or other) interface, which is unnecessary and in fact > counter-productive in our case. Pavel, please explain. I'm not sure which work you're refeering to, (doucment translation)? What's the benefits of the current setup? Those could/should be respected. Any web-interface could be coupled to dav or svn it that's the subject. For documentation,The database doesn't/shouldn't contain web-dependent formatting, markdown is there, others too. See previous post. (And are human translations effective - couldn't google do the work) >> WHy would you not use Firebird ..... > Database is a database, it doesn't matter which one. We use Firebird > at > our tracker, and as painless it is, it's still just a necessary evil > (JIRA doesn't work without a database) that adds to administrator's > responsibilities. I'm dizzy. Pavel, I may misundersand you, but you sound counter database, and counter web. I'm the opposite and have delivered stable webapplications for years to clients. One use firebird, (other do use mysql). I do belive however, that the tracker should be treated as another animal, not as part of a new homepage. > Any solution for our new website should have > zero-maintenance and nearly zero-complexity for backup/update/upgrade. > The fever "working" parts it would have, the better. I'm suspecting a serious problem with the mainainence of the tracker and possibly any new site. It's a less glorious work and the one willing to take the responsibility should earn the accumulated donations on yearly basis, my five cents.. Regardning the discussion of backup of firebird, my experiences are just fine, (it's not tera-bytes). I was lead to belive that firebird was the database that didn't need a dba?? ;-) Finally I belive we're not getting anywhere - I'm not happy anyway. Thing are compex. Yes... Efforts have been made. Yes.... ..but any progress? Do we wan't firebird to be fairly unknown? Maby. It's convinient in a way. But if firebird is an true open source project, the community should be heard and invited. PAUL, Are you still the official Coordinator of firebird documentation project, share your thoughts! respectfully, /tjelvare |
|
From: Lester C. <le...@ls...> - 2009-11-18 21:31:01
|
tjelvar eriksson wrote: > Hi all, > >> 1. Site search could be actually faster from flat files than from >> database if there isn't any full-text that could work with Firebird. > > a) I'm not a drupal evangelist, but it does have fulltext-search in > the framework, > others may have too - don't know about BW. Actually bw currently has 4 options depending on what you need, and one of the simple indexing ones is probably fine in this case, but that IS an area where accessing a better full text search IN Firebird would be useful :) And then a web site fully powered by it is an essential demonstration ;) As an aside, since 'security' has been mentioned. One thing that has been built into the basic search is filtering on content that a user is currently allowed access to. Many CMS systems will return a set of results, and then tell you you do not have permission to access a page. My own customers have material that has restricted access and can only be seen once you have the correct login. Very useful for private discussions before they are 'approved' for distribution, but difficult to implement when using some of the 'heavier' full text search options! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php |
|
From: Pavel C. <pc...@ib...> - 2009-11-19 11:14:42
|
tjelvar eriksson napsal(a): > Hi all, > >> 1. Site search could be actually faster from flat files than from >> database if there isn't any full-text that could work with Firebird. > > a) I'm not a drupal evangelist, but it does have fulltext-search in > the framework, > others may have too - don't know about BW. > > b) Home of firebird - powered by flatfiles. True irony... Technology should serve US, not by other way around. For content and services that we want on the Project's website it's best to be served as static pages, as there is almost NO dynamic content. For practical purposes, the pages are divided into snippets (header/footer, menu bar, sidebar, main page content) that are stored separately and assembled by page glue code. Except few information areas that are repeating patterns (list of web resources, news, sub-projects and members information) nothing really calls for a database. Database would be an overkill for this, period. These few info bits that *could* be served from database are few, so having them in "data text files" is cheaper and quicker. We DO use Firebird as backend on our TRACKER. We even adapted JIRA to work with Firebird as it wasn't originally supported database. But that was justified because tracker software needs a database backend if it should scale and work efficiently. Our website does not. I would agree to use a database if we would implement some forum facility on it or something that would have a lot of dynamic content with few data patterns, but it's NOT this case. > I do respect your opinion, and this is where the discussion should > start. > What to put in and what it should be. > My original post, which started of this discussion as i belive, was > based > on a reflection that A.W Harrison wrote that the interest for firebird > at > last conference where null. > Your reflections around "definitly not a community site" should be > given a second thought. As far as I remember, nobody ever expressed any problems with general concept, content and target audience for Firebird Project website. All objections were always targeted to site *structure* and *design*. For the record, the Firebird website served also as community portal (with CMS and db backend) many many years ago, when both project and community were young and relatively small. But these days are over. Even if we would like to add blogs, extensive news, forum etc. to our site, we would be just late to the party as all this is already covered by many thriving sites. There is no point to compete with them, as *our* duty is to work on Firebird and related sub-projects, and to help users to get and learn our products, not to operate the community portal. >> 3. As wiki goes, it doesn't necessarily needs a database as backend, >> and >> we could probably use already existing one or use one provided by >> SourceForge anyway, and soft-embed it into our site. > > I'm not sure what you mean with soft-embed but it sounds as dependent > patch, and with a mysql-prefix. Hands down here. It means that it would work on its separate site, but we'll link to it as an integral part of the site (the design could be even united). >> 4. Using a database would force us to work with site content over the >> web (or other) interface, which is unnecessary and in fact >> counter-productive in our case. > > Pavel, please explain. I'm not sure which work you're refeering to, > (doucment translation)? No, to provide content, generally. That's what we do. > What's the benefits of the current setup? Those could/should be > respected. I explained it earlier, it's dead simple for those who work with the content although we all use various OSes and favour different tools, and it's literally zero-maintenance for administrators and almost zero-configuration (you can get your own local copy up and running in few minutes). We like it that way. > Any web-interface could be coupled to dav or svn it that's the subject. Yes, it could, but why, when the current one is much simpler and works perfectly? > >> Database is a database, it doesn't matter which one. We use Firebird >> at >> our tracker, and as painless it is, it's still just a necessary evil >> (JIRA doesn't work without a database) that adds to administrator's >> responsibilities. > > I'm dizzy. Pavel, I may misundersand you, but you sound counter > database, > and counter web. Nope, I'm just practical. I do QA in Firebird, that's my primary objective. I and Helen work as webmasters because somebody has to. We do it from the beginning, and over the last nine years nobody ever expressed any real interest to join us (but we heard plenty of advices how we should do it). I take care of PHP code and low level plumbing (except the Foundation sub-site which is fully under Helen's control), Helen looks after the general content and last years also after the visual design. Few others (including me) work with the content in their areas of interest / parts of our site (sub-projects). We have other duties, but we also do some web publishing, and we want it dead simple for us. That's it. Maybe Helen could appreciate a full-blown CMS for the occasional news and download pages that represents the main portion of what she does frequently, but I doubt that. > Thing are compex. Yes... > Efforts have been made. Yes.... ..but any progress? Things are not complex, they're dead simple. The problem is that we have many talkers but few workers that are already overloaded. No wonder that progress in certain not-so-vital areas is slow (or do you prefer fancy website instead new stable FB delivered on schedule?). > But if firebird is an true open source project, the community should > be heard > and invited. Community is always invited and heard, but universe likes to grant wishes to those that contribute for real to make them a reality. Talk is cheap and candy grows on trees only in fairy-tales. Unfortunately, many people (even grown-ups) tend to live in fairy-tales. Just walk through the archives, and you'll see. If Firebird Project would be fueled by good advices given from the distance, then we would have enough in bank to pay our developers for rest of the century. best regards Pavel Cisar |
|
From: Carlos H. C. <li...@wa...> - 2009-11-19 12:11:06
|
PC> Except few information areas that are repeating patterns (list of PC> web resources, news, sub-projects and members information) nothing PC> really calls for a database. Database would be an overkill for PC> this, period. These few info bits that *could* be served from PC> database are few, so having them in "data text files" is cheaper PC> and quicker. I'll report my experience, with both cases. My FireBase portal started as static pages. The change for dynamic pages with content retrieved from a DB was a huge facilitator for me. Updating the site (aka. inserting news, articles, links or anything else) became a matter of starting a small Delphi app and inserting the content into the appropriate place (DB table), just that! Right now, FireBase uses PHP with direct access to FB database and it was really easy to be implemented (I never had programmed in PHP before that). Most difficult task (for me) was/is the webdesign. So, FirebirdSQL has news? Yes. Does it has articles (docs)? Yes, Does it has Download area? Yes. So, imho, this is enough to justify using a DB backend and dynamic pages. Also, DB backend makes it much easier to implement RSS feeds. Nowadays, this is one of the best ways to keep people updated, and a must for any decent site. Just my 2c. []s Carlos H. Cantu www.FireBase.com.br - www.firebirdnews.org www.warmboot.com.br - blog.firebase.com.br |
|
From: Pavel C. <pc...@ib...> - 2009-11-19 13:03:19
|
Carlos H. Cantu napsal(a): > > So, FirebirdSQL has news? Yes. Does it has articles (docs)? Yes, Does > it has Download area? Yes. So, imho, this is enough to justify using a > DB backend and dynamic pages. Well, there are about ~20 news entries per *year* on our site. Doesn't seems to me that it calls for a database. Articles are all static and change rarely, except Documentation that is in fact a single page that points to thousands of *generated* pages. Can't see how database fits to it either. Download is just few fancy pages that point to SourceForge downloads. Anybody can go directly to SF download page for them. > Also, DB backend makes it much easier to implement RSS feeds. Nowadays, > this is one of the best ways to keep people updated, and a must for > any decent site. What RSS feeds? For news? There are few and all are immediately taken by FirebirdNews and other sites (that have RSS feeds and much much more news content). For downloads? Go to SourceForge and subscribe to File releases RSS feed, it already exists. The same apply to news posted to SF. In fact, we should use the SF RSS feeds for news and releases to feed our own news and download pages, so we would entry the data only once. best regards Pavel Cisar |
|
From: Milan B. <mi...@pa...> - 2009-11-19 13:51:01
|
Pavel Cisar wrote: > Carlos H. Cantu napsal(a): >> So, FirebirdSQL has news? Yes. Does it has articles (docs)? Yes, Does >> it has Download area? Yes. So, imho, this is enough to justify using a >> DB backend and dynamic pages. > > Well, there are about ~20 news entries per *year* on our site. Doesn't > seems to me that it calls for a database. Articles are all static and > change rarely, except Documentation that is in fact a single page that > points to thousands of *generated* pages. Can't see how database fits to > it either. Download is just few fancy pages that point to SourceForge > downloads. Anybody can go directly to SF download page for them. > >> Also, DB backend makes it much easier to implement RSS feeds. Nowadays, >> this is one of the best ways to keep people updated, and a must for >> any decent site. > > What RSS feeds? For news? There are few and all are immediately taken by > FirebirdNews and other sites (that have RSS feeds and much much more > news content). For downloads? Go to SourceForge and subscribe to File > releases RSS feed, it already exists. The same apply to news posted to SF. > > In fact, we should use the SF RSS feeds for news and releases to feed > our own news and download pages, so we would entry the data only once. FWIW, I agree with Pavel. There are many ways that database can get broken and then the website is either down, or throws error messages which leaves a very ugly and unprofessional impression to visitors. -- Milan Babuskov ================================== The easiest way to import XML, CSV and textual files into Firebird: http://www.guacosoft.com/xmlwizard ================================== |
|
From: Carlos H. C. <li...@wa...> - 2009-11-19 14:14:27
|
MB> FWIW, I agree with Pavel. There are many ways that database can get MB> broken and then the website is either down, or throws error messages MB> which leaves a very ugly and unprofessional impression to visitors. This can happen, not only with DB, but with everything else. Apache can crash, PHP can crash, HD can crash, Internet can crash, etc. I think the major point of this discussion (static x dynamic) should be: make the life of the webmaster easier. My experience, as the FireBase webmaster, is that dynamic pages made my life much easier. If the FBSQL webmaster has enough free time to edit everything by hand and is comfortable with this, no problem. []s Carlos H. Cantu www.FireBase.com.br - www.firebirdnews.org www.warmboot.com.br - blog.firebase.com.br |
|
From: Giovanni P. <gpr...@so...> - 2009-11-19 15:50:45
|
Milan Babuskov wrote: > FWIW, I agree with Pavel. There are many ways that database can get > broken and then the website is either down, or throws error messages > which leaves a very ugly and unprofessional impression to visitors. > > A whole lot of other things leave a very ugly and unprofessional impression to visitors. Please have a look at: http://www.sqlite.org/ http://www.postgresql.org/ http://couchdb.apache.org/ http://www.ingres.com/ and then at http://www.firebirdsql.org/ and see how much it hurts. I don't even direct our clients the main site anymore, I just send them a direct link to the download. But in the last 10 years, any sugestion, offer, or actual contribution has been grounded by attacks and resistance to change. Want to talk about changing the layout? Talk is cheap, do not disturb the ones doing things. You actually do something? You should have talked about it before. Some years ago I even paid a graphic designer to produce some layouts, but before she was finished someone else proposed some reasonably good layouts and was attacked so badly that I decided to avoid the same fate. DB driven sites make change to the structure of the site quite painless. And 99% of the professional sites around the world are db driven. It can't be that bad. BTW it's really not the message an open source DBMS should give, unless we want people to believe that MySQL is stabler than Firebird. -- Giovanni |
|
From: Pavel C. <pc...@ib...> - 2009-11-19 17:26:04
|
Giovanni Premuda napsal(a): > > But in the last 10 years, any sugestion, offer, or actual contribution > has been grounded by attacks and resistance to change. You greatly exaggerate. The Firebird website was completely redesigned several times over last 10 years. All redesigns were made by Helen and me, based on changing project's needs and feedback from anybody who cared to express opinion. We heard countless *suggestions*, very few offers and saw almost zero real contributions (most of those were just images and other graphics). We've got no improved CSS, no content (except content created as part of our sub-projects), nothing, zero, nada. Yes, we're not professional web designers. We did our best, but we know it's not enough. I can handle the background code just fine and Helen can provide great content, but neither of us is HTML/CSS/Graphics wizard. However, any time we asked for help with that, we've got just talk (except Marius' contribution which is first *real* contribution to make appealing website we've ever got), especially how we should do it in this or that CMS. That's one hell of disappointment. Instead getting help in what we need, we are constantly offered opinions and advices about things that we don't need. I don't want to hear that I should spend hours of my time to learn Drupal or whatever CMS so I could code another non-appealing website. Give me appealing CSS that looks great in all browsers that we could use instead such advices, and we could implement it right away. Did we get any? Nope, just the same old "use this, use that technology" b****. I understand that it's mostly because we're all developers, so all help/advice is developer-related, but anyway, we're getting tired of this over all years it's thrown at us. > Want to talk about changing the layout? > Talk is cheap, do not disturb the ones doing things. We know what we want, we're just not skilled enough in design neither we have enough time to learn it as we have other more important duties. If you want to help us, help us with THAT. We don't need help with code, administration and all developer/administrator-related stuff. > You actually do something? > You should have talked about it before. If you put cart before the horse, then certainly. Ask what we want to achieve and then you can create and offer us a design that could be accepted. But don't throw at us any design you saw, liked and copied, and that may work for someone else but not for us. > Some years ago I even paid a graphic designer to produce some layouts, > but before she was finished someone else proposed some reasonably good > layouts and was attacked so badly that I decided to avoid the same fate. Too bad you wasted your money, you should rather submit the design. Even better would be if you would collect the reasons why the previous one was "attacked so badly" so you would come with one that would be accepted. > DB driven sites make change to the structure of the site quite painless. > And 99% of the professional sites around the world are db driven. It > can't be that bad. BTW it's really not the message an open source DBMS > should give, unless we want people to believe that MySQL is stabler than > Firebird. Yes, no, maybe. But underlying technology doesn't make an appealing website, design does. So, could we let it go and concentrate on design? Let the *real* requirements to dictate the technology once we'll get there, please? best regards Pavel Cisar |
|
From: Giovanni P. <gpr...@so...> - 2009-11-22 23:08:46
|
Pavel Cisar wrote: > We heard countless *suggestions*, very few > offers and saw almost zero real contributions (most of those were just > images and other graphics). We've got no improved CSS, no content > (except content created as part of our sub-projects), nothing, zero, nada. > You really never *encouraged* them. > ...especially how we should do it in this or that CMS. Because it's the easiest way to get started. Moving content around in a CMS is usually quite painless. Skinning most CMS is quite painless > Give me appealing CSS that looks great in > all browsers that we could use instead such advices, and we could > implement it right away. Did we get any? Nope, just the same old "use > this, use that technology" b****. I understand that it's mostly because > we're all developers, so all help/advice is developer-related, but > anyway, we're getting tired of this over all years it's thrown at us. > You seem to believe that CSS are developed in a vacuum. They are not. Developing a reasonable CSS requires a reasonable content structure and clean markup. And www.firebirdsql.org has neither. > We know what we want, we're just not skilled enough in design neither we > have enough time to learn it as we have other more important duties. If > you want to help us, help us with THAT. No, you don't. You believe you do, and seem fully committed in micromanaging the activity, but you obviously have no real idea of how a good design comes to life. > If you put cart before the horse, then certainly. Ask what we want to > achieve and then you can create and offer us a design that could be > accepted. But don't throw at us any design you saw, liked and copied, > and that may work for someone else but not for us. > No, because "what we want to achieve" means " We rule so you clean our toilets". And nobody is willing to spend free time cleaning toilets. If we start discussing what *should* be archieved in a constructive way, then you will probably see a lot more real interest and useful contributions. > >> DB driven sites make change to the structure of the site quite painless. >> And 99% of the professional sites around the world are db driven. It >> can't be that bad. BTW it's really not the message an open source DBMS >> should give, unless we want people to believe that MySQL is stabler than >> Firebird. >> > > Yes, no, maybe. But underlying technology doesn't make an appealing > website, design does. So, could we let it go and concentrate on design? > Let the *real* requirements to dictate the technology once we'll get > there, please? > No objection. Giovanni -- Giovanni Premuda |
|
From: tjelvar e. <tj...@fa...> - 2009-11-23 12:52:31
|
>> Yes, no, maybe. But underlying technology doesn't make an appealing >> website, design does. So, could we let it go and concentrate on >> design? >> Let the *real* requirements to dictate the technology once we'll get >> there, please? >> You do not need to look into design yet. First do your homework beginning with IF you want more support / interest from the community. If so, change your attitude accordingly. Primary target, community or enterprise, or both? That affects the rest. Stop behaving like goats looking for a horse. You're mainaining one of the finest open source databases in the world. If you're sick of it, quit, noone is forcing you. /t |
|
From: tjelvar e. <tj...@fa...> - 2009-11-19 19:28:56
|
Pavel, thank you for explaining things. I have no objections in what you're saying. It's just that this discussion originally started as a reply to AW Harrison, "absolutely no interest for the firebird", see post 10615 at firebird-general. As stated previously, all my respect to everyone involved in creating and maintaining firebird, period. IF we all, customers, end users, and docteam can gain of a new site I see good reason for such an initaitve. Have a good day, :-) //tjelvar 19 nov 2009 kl. 12.14 skrev Pavel Cisar: > tjelvar eriksson napsal(a): >> Hi all, >> >>> 1. Site search could be actually faster from flat files than from >>> database if there isn't any full-text that could work with Firebird. >> >> a) I'm not a drupal evangelist, but it does have fulltext-search in >> the framework, >> others may have too - don't know about BW. >> >> b) Home of firebird - powered by flatfiles. True irony... > > Technology should serve US, not by other way around. For content and > services that we want on the Project's website it's best to be > served as > static pages, as there is almost NO dynamic content. For practical > purposes, the pages are divided into snippets (header/footer, menu > bar, > sidebar, main page content) that are stored separately and assembled > by > page glue code. Except few information areas that are repeating > patterns > (list of web resources, news, sub-projects and members information) > nothing really calls for a database. Database would be an overkill for > this, period. These few info bits that *could* be served from database > are few, so having them in "data text files" is cheaper and quicker. > > We DO use Firebird as backend on our TRACKER. We even adapted JIRA to > work with Firebird as it wasn't originally supported database. But > that > was justified because tracker software needs a database backend if it > should scale and work efficiently. Our website does not. I would agree > to use a database if we would implement some forum facility on it or > something that would have a lot of dynamic content with few data > patterns, but it's NOT this case. > >> I do respect your opinion, and this is where the discussion should >> start. >> What to put in and what it should be. >> My original post, which started of this discussion as i belive, was >> based >> on a reflection that A.W Harrison wrote that the interest for >> firebird >> at >> last conference where null. >> Your reflections around "definitly not a community site" should be >> given a second thought. > > As far as I remember, nobody ever expressed any problems with general > concept, content and target audience for Firebird Project website. All > objections were always targeted to site *structure* and *design*. > > For the record, the Firebird website served also as community portal > (with CMS and db backend) many many years ago, when both project and > community were young and relatively small. But these days are over. > Even > if we would like to add blogs, extensive news, forum etc. to our site, > we would be just late to the party as all this is already covered by > many thriving sites. There is no point to compete with them, as *our* > duty is to work on Firebird and related sub-projects, and to help > users > to get and learn our products, not to operate the community portal. > >>> 3. As wiki goes, it doesn't necessarily needs a database as backend, >>> and >>> we could probably use already existing one or use one provided by >>> SourceForge anyway, and soft-embed it into our site. >> >> I'm not sure what you mean with soft-embed but it sounds as dependent >> patch, and with a mysql-prefix. Hands down here. > > It means that it would work on its separate site, but we'll link to it > as an integral part of the site (the design could be even united). > >>> 4. Using a database would force us to work with site content over >>> the >>> web (or other) interface, which is unnecessary and in fact >>> counter-productive in our case. >> >> Pavel, please explain. I'm not sure which work you're refeering to, >> (doucment translation)? > > No, to provide content, generally. That's what we do. > >> What's the benefits of the current setup? Those could/should be >> respected. > > I explained it earlier, it's dead simple for those who work with the > content although we all use various OSes and favour different tools, > and > it's literally zero-maintenance for administrators and almost > zero-configuration (you can get your own local copy up and running in > few minutes). We like it that way. > >> Any web-interface could be coupled to dav or svn it that's the >> subject. > > Yes, it could, but why, when the current one is much simpler and works > perfectly? > >> >>> Database is a database, it doesn't matter which one. We use Firebird >>> at >>> our tracker, and as painless it is, it's still just a necessary evil >>> (JIRA doesn't work without a database) that adds to administrator's >>> responsibilities. >> >> I'm dizzy. Pavel, I may misundersand you, but you sound counter >> database, >> and counter web. > > Nope, I'm just practical. I do QA in Firebird, that's my primary > objective. I and Helen work as webmasters because somebody has to. > We do > it from the beginning, and over the last nine years nobody ever > expressed any real interest to join us (but we heard plenty of advices > how we should do it). I take care of PHP code and low level plumbing > (except the Foundation sub-site which is fully under Helen's control), > Helen looks after the general content and last years also after the > visual design. Few others (including me) work with the content in > their > areas of interest / parts of our site (sub-projects). We have other > duties, but we also do some web publishing, and we want it dead simple > for us. That's it. Maybe Helen could appreciate a full-blown CMS for > the > occasional news and download pages that represents the main portion of > what she does frequently, but I doubt that. > >> Thing are compex. Yes... >> Efforts have been made. Yes.... ..but any progress? > > Things are not complex, they're dead simple. The problem is that we > have > many talkers but few workers that are already overloaded. No wonder > that > progress in certain not-so-vital areas is slow (or do you prefer fancy > website instead new stable FB delivered on schedule?). > >> But if firebird is an true open source project, the community should >> be heard >> and invited. > > Community is always invited and heard, but universe likes to grant > wishes to those that contribute for real to make them a reality. > Talk is > cheap and candy grows on trees only in fairy-tales. Unfortunately, > many > people (even grown-ups) tend to live in fairy-tales. Just walk through > the archives, and you'll see. If Firebird Project would be fueled by > good advices given from the distance, then we would have enough in > bank > to pay our developers for rest of the century. > > best regards > Pavel Cisar > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Firebird-website mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-website |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X