Re: Write-access to wiki -- Directions on how to document

Hello r2d2:

In message <[email protected]>,
[email protected] writes:
>I am evaluating roundup for the use as an inhouse maintenance tracker
>for around 100 facilities / sites (hence the need for recurring tasks).
>
>Currently I think the "Roundup TODO Template" (which I quickly got
>working yesterday) is a good starting point. [...]
>
>An estimate for the total numer of tasks does not exist but
>pessimistic me thinks there may be around 100 per site, so 100 x 100
>= 10.000

Is this per year or over the lifetime? If per year, you may want to
consider using either the postgresql or mysql database backends. I
have used the SQLite backend with a few thousands of issues and it
handles it fine. If you have a complex schema however, you might have
to migrate to one of the other db backends after a few years.

>- this is why I like the "Roundup TODO Template":
> > # By default, only the upcoming issue is added to the tracker.
>
>Going forward I am uncertain on how to document the proccess and
>modifications so others can use this.
>
>Would the https://wiki.roundup-tracker.org/ be a good place?

Having a pointer from:

  https://wiki.roundup-tracker.org/TrackerTemplates

to a development forge would be a better choice. Most of the tracker
templates listed on TrackerTemplates have links to some VCS repo (svn,
hg, git, fossil, ...). Documenting tracker development on a wiki is
going to be tedious as you have to attach files and update inline
code/docs in the browser. (This can be scripted to some extent, but
it's still tedious.)

We do archive some trackers using a zip or tarball where the originals
have been removed. But that is for archive purposes not ongoing
development/documentation.

>Or would a development forge be a better choice? I find the interface of
>https://sourceforge.net/ to be quite confusing, but there seems to be
>alternatives,
> - https://sourcehut.org/ and
> - https://codeberg.org/
>would either be a choice to track the changes?

Managing the development of your tracker using a VCS (git, mercurial,
fossil) would be easier using a forge. That's why my sysadmin tracker
is managed using Fossil.

You will want to put your tracker (but not the db subdirectory) under
VCS control anyway. Also you might not want to put (any of) your
config.ini files in a public VCS as it can have secrets/sensitive info
in the file. True secrets can often be specified in separate files so
the config.ini could be stored in a VCS. However sensitive but not
secret items like:

  the web URL for your tracker,
  the number of rounds used for pbkdf2 derivation,
  the location of your database server,
  etc.

are located in config.ini. For public consumption, adding a clean
config.ini, as config.ini.sample or using the tracker standard of
config_ini.ini to set required fields (see:
https://roundup-tracker.org/docs/tracker_templates.htm) are preferred.

Hope this helps.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.