firebird-docs — chat stuff about documentation

Re: [Firebird-docs] Doc funding - samples

[Alexey K. <ak...@ib...>]

Hi Jiří,

Here they are in Russian
http://www.ibase.ru/files/articles/firebird_examples/how_to_create_aplication_firebird_delphi_example_rus.pdf
http://www.ibase.ru/files/articles/firebird_examples/how_to_create_application_firebird_sql_entity_framework_net_example_rus.pdf
http://www.ibase.ru/files/articles/firebird_examples/how_to_create_application_firebird_sql_entity_framework_mvc_example_rus.pdf
http://www.ibase.ru/files/articles/firebird_examples/how_to_add_Firebird_support_to_the_Laravel_framework.pdf
http://www.ibase.ru/files/articles/firebird_examples/how_to_create_application_firebird_php.pdf
and draft for Java
https://github.com/sim1984/fbjavaex/releases/tag/1.0


Regards,
Alexey



> Hello,
>
> customer of mine wants to spend 1000-2000€ on doc funding
> (https://www.firebirdsql.org/en/doc-funding-2017/), but he'd like to see
> some samples of the content. Is it available somewhere?
>

[Firebird-docs] Doc funding - samples

[Jiří Č. <ji...@ci...>]

Hello,

customer of mine wants to spend 1000-2000€ on doc funding
(https://www.firebirdsql.org/en/doc-funding-2017/), but he'd like to see
some samples of the content. Is it available somewhere?

-- 
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

[Firebird-docs] Firebird 2.5 Language Reference Beta 1 (English) status

[marius a. p. <ma...@gm...>]

Hello i see that Firebird 2.5 is still in Beta status
what happened there ?

Also Firebird 3.0 Language Reference in English was promised ;)

This is related to the new Crowd funding campaign

https://www.firebirdsql.org/en/news/documentation-crowd-funding-2017/

Re: [Firebird-docs] German chapters of fblangref25

[Paul V. <pa...@vi...>]

Hi all,

>>> fblangref25-appx02-errorcodes-de.xml
>>> fblangref25-appx03-reskeywords-de.xml
>>> fblangref25-appx06-charsets-de.xml
>>> fblangref25-datatypes-de.xml
>>> fblangref25-de.xml
>>> fblangref25-intro-de.xml
>>> fblangref25-structure-de.xml

Last week, Martin Köditz has completed the translation of five more chapters:

fblangref25-appx01-supplement-de.xml
fblangref25-appx04-systables-de.xml
fblangref25-appx05-montables-de.xml
fblangref25-appx07-license-de.xml
fblangref25-dochist-de.xml

They've all been committed to CVS.

Thanks, Martin!


Cheers,
Paul Vinkenoog

Re: [Firebird-docs] Not working link on homepage

[Mark R. <ma...@la...>]

On 23-12-2016 08:46, Köditz, Martin wrote:
> Hi,
>
>
>
> on site http://www.firebirdsql.org/en/devel-docs/ the link in section
> resources to the CVS Module # manual doesn’t work. I’m getting error
> message “server not found”.

The correct link is: 
http://firebird.cvs.sourceforge.net/viewvc/firebird/manual/

> Maybe somebody can fix it.

I will do so in a few minutes.

Mark
-- 
Mark Rotteveel

[Firebird-docs] Not working link on homepage

[Köditz, M. <Mar...@it...>]

Hi,

on site http://www.firebirdsql.org/en/devel-docs/ the link in section resources to the CVS Module # manual doesn't work. I'm getting error message "server not found".

Maybe somebody can fix it.

Regards
Martin

Re: [Firebird-docs] Consider migrating to GitHub?

[marius a. p. <ma...@gm...>]

One argument i can give is that i can edit directly the files on github ,
so that is a lot faster for small fixes for the doc area

On Mon, Dec 19, 2016 at 7:13 PM, Mark Rotteveel <ma...@la...>
wrote:

> On 19-12-2016 11:08, Lester Caine wrote:
> > On 18/12/16 11:19, Mark Rotteveel wrote:
> >> Git != GitHub.
> >
> > But it's the reason most projects use as an excuse to promote git over
> > other options :(
> > And it's trying to promote itself as yet another social media site
> > detracts from the REAL jobs that many years ago SF did so well but
> > without actually achieving it.
> >
> > My point is that github is a distraction most of the time and promoting
> > it more does not help develop a better - fully integrated - solution to
> > project management. One can have a presence ON github and all the other
> > alternatives without 'moving to' github ... and moving a perfectly
> > functional repository does not need git messing it up when it does not
> > need the compromises git introduces.
>
> So your argument boils down to "I don't like git and GitHub, because
> they 'won' the hearts and minds of the majority of the (open source)
> development community".
>
> That is exactly one of the reasons I propose to move the repository to
> GitHub: that is where the people are, and a lot of people know how to
> use it.
>
> Lets face it: the Firebird documentation project could do with more
> active contributors. Is moving to GitHub going to solve that: of course
> not, but it might make it easier. Moving Jaybird to GitHub last year
> lead to at least 4 (small and large contributions), including the
> support for SRP.
>
> You mention downsides/compromises that git brings to the table: exactly
> what kind of compromises do you think the Firebird documentation project
> specifically would experience with moving to git? As far as I know the
> manual module is pretty straight-forward with a largely linear history,
> and without use of obscure CVS features, so I don't see where those
> compromises would be, and I'd really like to know. However, I can name
> at least one benefit of moving to git: rename/move or copy with history,
> and for moving to GitHub: contributions by pull request.
>
> Also to be clear: I'm talking about moving the repository: the rest can
> stay where it is if that is deemed better (eg you can disable issues if
> you don't want to use the GitHub issue tracker, etc).
>
> Mark
> --
> Mark Rotteveel
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> Firebird-docs mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>

Re: [Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

On 19-12-2016 11:08, Lester Caine wrote:
> On 18/12/16 11:19, Mark Rotteveel wrote:
>> Git != GitHub.
>
> But it's the reason most projects use as an excuse to promote git over
> other options :(
> And it's trying to promote itself as yet another social media site
> detracts from the REAL jobs that many years ago SF did so well but
> without actually achieving it.
>
> My point is that github is a distraction most of the time and promoting
> it more does not help develop a better - fully integrated - solution to
> project management. One can have a presence ON github and all the other
> alternatives without 'moving to' github ... and moving a perfectly
> functional repository does not need git messing it up when it does not
> need the compromises git introduces.

So your argument boils down to "I don't like git and GitHub, because 
they 'won' the hearts and minds of the majority of the (open source) 
development community".

That is exactly one of the reasons I propose to move the repository to 
GitHub: that is where the people are, and a lot of people know how to 
use it.

Lets face it: the Firebird documentation project could do with more 
active contributors. Is moving to GitHub going to solve that: of course 
not, but it might make it easier. Moving Jaybird to GitHub last year 
lead to at least 4 (small and large contributions), including the 
support for SRP.

You mention downsides/compromises that git brings to the table: exactly 
what kind of compromises do you think the Firebird documentation project 
specifically would experience with moving to git? As far as I know the 
manual module is pretty straight-forward with a largely linear history, 
and without use of obscure CVS features, so I don't see where those 
compromises would be, and I'd really like to know. However, I can name 
at least one benefit of moving to git: rename/move or copy with history, 
and for moving to GitHub: contributions by pull request.

Also to be clear: I'm talking about moving the repository: the rest can 
stay where it is if that is deemed better (eg you can disable issues if 
you don't want to use the GitHub issue tracker, etc).

Mark
-- 
Mark Rotteveel

Re: [Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

On 19-12-2016 11:39, Andre van Zuydam wrote:
> So bouncing in here on a tangent,  I've done this with a couple of
> Source forge projects, simply set Source forge to clone the Github
> project or visa versa.  The only reason I would suggest having things on
> Github is for more visibility.  Anyway my five cents.  You can still
> continue to commit as always, just have things cloned on both.   Each
> versioning system has its pros and cons, those of us who started with
> CVS may have moved on to use other systems but hey, its such a mission
> to switch things that work.

That works (barely) if you already have a git project on SourceForge, 
but as far as I know not if you have CVS project on SourceForge.

If a conversion is going to happen (but the strong resistance seems to 
indicate no), then I'd prefer going GitHub the way the core project did 
as well, instead of having a hybrid solution where you try to balance 
between GitHub and SourceForge and having to keep both repositories in-sync.

Mark
-- 
Mark Rotteveel

Re: [Firebird-docs] Clarification for MON$RECORD_STATS

[Köditz, M. <Mar...@it...>]

Ah, makes things clearer.

Thank you, Paul.

Re: [Firebird-docs] Clarification for MON$RECORD_STATS

[Paul B. <pb...@ib...>]

>From Helen's bible...

1.       MON$RECORD_BACKOUTS

Number of records where a new primary record version is
backed out due to a rollback or savepoint undo

2.       MON$RECORD_PURGES

Number of records where the record version chain is being
purged of versions no longer needed by OAT or younger transactions

3.       MON$RECORD_EXPUNGES

Number of records where record version chain is being deleted due
to deletions by transactions older than the OAT

Where OAT = Oldest Active Transaction.

Paul

[Firebird-docs] Clarification for MON$RECORD_STATS

[Köditz, M. <Mar...@it...>]

Hi,

currently I translate the chapter about monitoring tables. I'm a bit confused in section MON$RECORD_STATS.
Please show the differences of following columns:

1.       MON$RECORD_BACKOUTS

2.       MON$RECORD_PURGES

3.       MON$RECORD_EXPUNGES
I need more details here. Especially for MON$RECORD_PURGES and MON$RECORD_EXPUNGES. In German it means almost DELETE. But I think there is a huge difference to MON$RECORD_DELETES.

Regards
Martin

Re: [Firebird-docs] Consider migrating to GitHub?

[Andre v. Z. <an...@sp...>]

So bouncing in here on a tangent,  I've done this with a couple of Source
forge projects, simply set Source forge to clone the Github project or visa
versa.  The only reason I would suggest having things on Github is for more
visibility.  Anyway my five cents.  You can still continue to commit as
always, just have things cloned on both.   Each versioning system has its
pros and cons, those of us who started with CVS may have moved on to use
other systems but hey, its such a mission to switch things that work.

On Mon, Dec 19, 2016 at 12:08 PM, Lester Caine <le...@ls...> wrote:

> On 18/12/16 11:19, Mark Rotteveel wrote:
> > Git != GitHub.
>
> But it's the reason most projects use as an excuse to promote git over
> other options :(
> And it's trying to promote itself as yet another social media site
> detracts from the REAL jobs that many years ago SF did so well but
> without actually achieving it.
>
> My point is that github is a distraction most of the time and promoting
> it more does not help develop a better - fully integrated - solution to
> project management. One can have a presence ON github and all the other
> alternatives without 'moving to' github ... and moving a perfectly
> functional repository does not need git messing it up when it does not
> need the compromises git introduces.
>
> --
> 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
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Firebird-docs mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>



-- 
<http://spiceware.co.za>

Re: [Firebird-docs] Consider migrating to GitHub?

[Lester C. <le...@ls...>]

On 18/12/16 11:19, Mark Rotteveel wrote:
> Git != GitHub.

But it's the reason most projects use as an excuse to promote git over
other options :(
And it's trying to promote itself as yet another social media site
detracts from the REAL jobs that many years ago SF did so well but
without actually achieving it.

My point is that github is a distraction most of the time and promoting
it more does not help develop a better - fully integrated - solution to
project management. One can have a presence ON github and all the other
alternatives without 'moving to' github ... and moving a perfectly
functional repository does not need git messing it up when it does not
need the compromises git introduces.

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Re: [Firebird-docs] Consider migrating to GitHub?

[Köditz, M. <Mar...@it...>]

Though I'm a programmer, I find it very hard to use CVS. I had some problems using CVS when Helen committed some changes. I feel more comfortable using git.

>> SourceForge itself considers CVS deprecated, and having the repository
>> on GitHub might increase visibility and will likely lower the barrier
>> for contribution.

As mentioned earlier, CVS is considered as deprecated and I had problems finding an adequate client. Well this is not really a hurdle, but it's much easier to get modern git clients. We are trying to win new contributors, so we should make the entry as easy as possible.


> No objections here, but does anybody have any experience with this kind

> of migration? (Preferably including history.)

I've already migrated a CVS project to git (not in such a dimension). But I think it is possible and if wished I can do some research on this. And Mark has some experiences too.

Also I don't think we have to use git sub modules (it is really a nightmare). We could use an own git repo for the manual.

I would also offer myself to edit the docbuilders guide in that case (review by Helen).

What do you think?

Regards
Martin

Re: [Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

On 18-12-2016 10:41, Lester Caine wrote:
> CVS still has a number of plus features that github deliberately
> destroyed in order to make supporting CODE a priority.

Git != GitHub.

 > When PHP project
> was looking to move - yet again - Hg get the vote for a system that
> worked better, but the 'github' marketing angle won the day - even given
> it's know faults! So now I have an Hg/Mercurial setup locally, which
> handles CVS, SVN and GIT transparently and allows working easily between
> all four. BUT I would still prefer the clean way that CVS handled
> modular project. GIT ( and actually Hg) still does not accept that
> scripted languages and documentation is much better handled as a series
> of inter-related projects rather than one all encompassing code base.
> sub-repo's are frond on in both while CVS modules are still a perfect
> solution, and projects that broke perfectly good CVS repositories into a
> series of GIT repo's still have no tools to put the hwole back together
> again.

That is not really an argument against moving the documentation project 
given it is only one module.

And technically git has submodules etc, but that is really a pain to 
work with, and I've never really had the need for something like that.

-- 
Mark Rotteveel

Re: [Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

On 18-12-2016 03:24, Helen Borrie wrote:
>
>> On 18/12/2016 11:48:34 AM, Paul Vinkenoog <pa...@vi...> wrote:
>>
>> Mark Rotteveel wrote:
>>
>> > Isn't it time to consider migrating the documentation repository from
>> > SourceForge CVS to GitHub?
>> >
>> > SourceForge itself considers CVS deprecated, and having the repository
>> > on GitHub might increase visibility and will likely lower the barrier
>> > for contribution.

> *Helen Borrie:* I don't see how moving the source from one obscure
> repository to a different obscure repository would heighten visibility
> or lower any barrier.

For visibility: the documentation project will be in the same group on 
GitHub as the Firebird project itself. This makes discovery of the 
project a lot easier.

Also these days GitHub is the go-to place for hosting open-source 
projects. More people know git and GitHub than CVS. GitHub provides a 
lot of features that simplify contributing to a project even if you 
don't have commit rights (eg pull requests).

> If there's a good reason to change, I'd go with it, albeit it currently
> aint broke so there be nothing to fix.  PaulV has it nicely set up for
> use by the translators and it is all well documented, enough so that
> those of us who actually DO stuff regularly, rather than just talk about
> doing it, have our local setups that are more or less automated. One of
> us can always step in to assist people who don't want to work with a
> repository for whatever reason.  I don't see how changing the repository
> would (or should) alter that.

The main advantage I see are that one-off contributions become simpler, 
and those might lead to more.

> My personal experience so far with GitHub is that it is a dog to work
> with, actually, given that I don't upload or download any programming
> code, only documentation.  I guess if I had to, I'd find a way to make
> it useful for me to use.  I just can't think of a good reason right now
> to spend time and energy on creating a solution to a non-existent problem.

As a sidenote: SourceForge considers CVS type projects to be deprecated 
these days, don't be surprised if we get a notice in the future that we 
need to migrate anyway.

 From https://sourceforge.net/p/forge/documentation/CVS/ :

"CVS is no longer available for new projects, we only offer limited 
support for CVS for projects previously using it on the Classic 
SourceForge system.

We recommend that projects upgrade to a more modern SCM, like 
Subversion, rather than using CVS. CVS has limitations which newer SCM 
solutions have been designed to overcome. We continue to support CVS for 
those projects who decide that CVS adequately supports their needs."

-- 
Mark Rotteveel

Re: [Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

On 17-12-2016 23:46, Paul Vinkenoog wrote:
> Mark Rotteveel wrote:
>
>> Isn't it time to consider migrating the documentation repository from
>> SourceForge CVS to GitHub?
>>
>> SourceForge itself considers CVS deprecated, and having the repository
>> on GitHub might increase visibility and will likely lower the barrier
>> for contribution.
>
> No objections here, but does anybody have any experience with this kind
> of migration? (Preferably including history.)

I migrated Jaybird from CVS to Subversion and then to git (GitHub). The 
migration from Subversion to git was facilitated by GitHub, but their 
tooling does not support CVS. However the tool I used to go from CVS to 
Subversion also has a variant to go to git.

Mark
-- 
Mark Rotteveel

Re: [Firebird-docs] Consider migrating to GitHub?

[Lester C. <le...@ls...>]

On 18/12/16 02:24, Helen Borrie wrote:
>> Mark Rotteveel wrote:
>>
>> > Isn't it time to consider migrating the documentation repository from
>> > SourceForge CVS to GitHub?
>> >
>> > SourceForge itself considers CVS deprecated, and having the repository
>> > on GitHub might increase visibility and will likely lower the barrier
>> > for contribution.
> *Helen Borrie:* I don't see how moving the source from one obscure
> repository to a different obscure repository would heighten visibility
> or lower any barrier.
> 
> If there's a good reason to change, I'd go with it, albeit it currently
> aint broke so there be nothing to fix.  PaulV has it nicely set up for
> use by the translators and it is all well documented, enough so that
> those of us who actually DO stuff regularly, rather than just talk about
> doing it, have our local setups that are more or less automated. One of
> us can always step in to assist people who don't want to work with a
> repository for whatever reason.  I don't see how changing the repository
> would (or should) alter that. 
> My personal experience so far with GitHub is that it is a dog to work
> with, actually, given that I don't upload or download any programming
> code, only documentation.  I guess if I had to, I'd find a way to make
> it useful for me to use.  I just can't think of a good reason right now
> to spend time and energy on creating a solution to a non-existent problem.

CVS still has a number of plus features that github deliberately
destroyed in order to make supporting CODE a priority. When PHP project
was looking to move - yet again - Hg get the vote for a system that
worked better, but the 'github' marketing angle won the day - even given
it's know faults! So now I have an Hg/Mercurial setup locally, which
handles CVS, SVN and GIT transparently and allows working easily between
all four. BUT I would still prefer the clean way that CVS handled
modular project. GIT ( and actually Hg) still does not accept that
scripted languages and documentation is much better handled as a series
of inter-related projects rather than one all encompassing code base.
sub-repo's are frond on in both while CVS modules are still a perfect
solution, and projects that broke perfectly good CVS repositories into a
series of GIT repo's still have no tools to put the hwole back together
again.

PHP still has not plugged all the holes in it's GIT process and often
gets cross contamination, so until there IS a reason to change ... why
create all that extra work? And certainly don't put anything on github
... use a private git repository which is the one thing PHP has right.

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Re: [Firebird-docs] Consider migrating to GitHub?

[Helen B. <he...@ii...>]

On 18/12/2016 11:48:34 AM, Paul Vinkenoog <pa...@vi...> wrote:
Mark Rotteveel wrote:

> Isn't it time to consider migrating the documentation repository from
> SourceForge CVS to GitHub?
>
> SourceForge itself considers CVS deprecated, and having the repository
> on GitHub might increase visibility and will likely lower the barrier
> for contribution.
Helen Borrie: I don't see how moving the source from one obscure repository to a different obscure repository would heighten visibility or lower any barrier.

If there's a good reason to change, I'd go with it, albeit it currently aint broke so there be nothing to fix.  PaulV has it nicely set up for use by the translators and it is all well documented, enough so that those of us who actually DO stuff regularly, rather than just talk about doing it, have our local setups that are more or less automated. One of us can always step in to assist people who don't want to work with a repository for whatever reason.  I don't see how changing the repository would (or should) alter that. 
My personal experience so far with GitHub is that it is a dog to work with, actually, given that I don't upload or download any programming code, only documentation.  I guess if I had to, I'd find a way to make it useful for me to use.  I just can't think of a good reason right now to spend time and energy on creating a solution to a non-existent problem.

Helen

Re: [Firebird-docs] Consider migrating to GitHub?

[Paul V. <pa...@vi...>]

Mark Rotteveel wrote:

> Isn't it time to consider migrating the documentation repository from 
> SourceForge CVS to GitHub?
>
> SourceForge itself considers CVS deprecated, and having the repository 
> on GitHub might increase visibility and will likely lower the barrier 
> for contribution.

No objections here, but does anybody have any experience with this kind
of migration? (Preferably including history.)

Myself, I'm a basic GIT user and I only use it locally.


Paul Vinkenoog

[Firebird-docs] Consider migrating to GitHub?

[Mark R. <ma...@la...>]

Isn't it time to consider migrating the documentation repository from 
SourceForge CVS to GitHub?

SourceForge itself considers CVS deprecated, and having the repository 
on GitHub might increase visibility and will likely lower the barrier 
for contribution.

Mark
-- 
Mark Rotteveel

Re: [Firebird-docs] German chapters of fblangref25

[Paul V. <pa...@vi...>]

Hi all,

>> fblangref25-appx02-errorcodes-de.xml
>> fblangref25-appx03-reskeywords-de.xml
>> fblangref25-appx06-charsets-de.xml
>> fblangref25-datatypes-de.xml
>> fblangref25-de.xml
>> fblangref25-intro-de.xml
>> fblangref25-structure-de.xml

Martin's translations have been committed to CVS. Thanks again, Martin!


Cheers,
Paul Vinkenoog

Re: [Firebird-docs] German chapters of fblangref25

[Paul V. <pa...@vi...>]

Hello Martin,

> I've finished the German translations for:
> fblangref25-appx02-errorcodes-de.xml
> fblangref25-appx03-reskeywords-de.xml
> fblangref25-appx06-charsets-de.xml
> fblangref25-datatypes-de.xml
> fblangref25-de.xml
> fblangref25-intro-de.xml
> fblangref25-structure-de.xml
>
> Before I start with another chapter, I would like to commit the finished data. Or maybe someone else can that for me. How do we deal with that?

If you mail them to me, I will commit them.

Cheers,
Paul Vinkenoog

[Firebird-docs] German chapters of fblangref25

[Köditz, M. <Mar...@it...>]

Hi,

I've finished the German translations for:
fblangref25-appx02-errorcodes-de.xml
fblangref25-appx03-reskeywords-de.xml
fblangref25-appx06-charsets-de.xml
fblangref25-datatypes-de.xml
fblangref25-de.xml
fblangref25-intro-de.xml
fblangref25-structure-de.xml

Before I start with another chapter, I would like to commit the finished data. Or maybe someone else can that for me. How do we deal with that?

Regards
Martin