While setting up the tracker for doc bugs, I've come to an idea that it
would be usefull to have the CVS checkout's date and time displayed on
the http://grass.itc.it/gdp/manuals.php. So the user (who is not using
CVS) reporting a manual bug, can know if his issue is still actuall and
what CVS checkout he is reffering to, and supply this CVS date and time
in the bug report (see http://wald.intevation.org/tracker/?func=add&group_id=21&atid=184).
it's not entirely clear to me what you mean. Each manual
page (except for the index pages) contains the CVS timestamp.
Please explain it slowly
Markus
On Sun, Nov 12, 2006 at 06:15:33PM +0100, Maciej Sieczka wrote:
Hi Markus,
While setting up the tracker for doc bugs, I've come to an idea that it
would be usefull to have the CVS checkout's date and time displayed on
the http://grass.itc.it/gdp/manuals.php. So the user (who is not using
CVS) reporting a manual bug, can know if his issue is still actuall and
what CVS checkout he is reffering to, and supply this CVS date and time
in the bug report (see http://wald.intevation.org/tracker/?func=add&group_id=21&atid=184).
On Sun, 2006-11-12 at 18:15 +0100, Maciej Sieczka wrote:
Hi Markus,
While setting up the tracker for doc bugs, I've come to an idea that it
would be usefull to have the CVS checkout's date and time displayed on
the http://grass.itc.it/gdp/manuals.php. So the user (who is not using
CVS) reporting a manual bug, can know if his issue is still actuall and
what CVS checkout he is reffering to, and supply this CVS date and time
in the bug report (see http://wald.intevation.org/tracker/?func=add&group_id=21&atid=184).
Does it sound any good to you?
I like the idea.
Is that what is labeled 'postscript' under GRASS Component? Would
calling it 'documentation' or something similar be more intuitive to the
general user or is it for something different?
Does GForge have the ability to pull up different form elements for
different components? For example, changing the component to a doc bug
would refresh with (please, no DHTML or excessive JavaScript) inputs for
CVS dtime. That would be nice and keep clutter to a minimum, but may
also be a pain to develop and implement. WYSIWYG across all browsers is
not for the weak and impatient.
Are there two bug trackers? One for code and one for docs? Am I
interpreting that right?
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
Is that what is labeled 'postscript' under GRASS Component? Would
calling it 'documentation' or something similar be more intuitive to
the general user or is it for something different?
I guess 'postscript' means ps.map, documentation is in another tracker.
"doc issues" vs "code issues"
Such a timestamp will let the GRASS GForge user verify if the issue he
is about to report is still actuall, in the most recent doc version he
can access.
On Sun, Nov 12, 2006 at 06:15:33PM +0100, Maciej Sieczka wrote:
While setting up the tracker for doc bugs, I've come to an idea that it
would be usefull to have the CVS checkout's date and time displayed on
the http://grass.itc.it/gdp/manuals.php. So the user (who is not using
CVS) reporting a manual bug, can know if his issue is still actuall and
what CVS checkout he is reffering to, and supply this CVS date and time
in the bug report (see http://wald.intevation.org/tracker/?func=add&group_id=21&atid=184).
it's not entirely clear to me what you mean. Each manual
page (except for the index pages) contains the CVS timestamp.
Please explain it slowly
Such a timestamp will let the GRASS GForge user verify if the issue he
is about to report is still actuall, in the most recent doc version he
can access.
And, I've forgotten to write, he will be able to provide the CVS date
of the version he is referring to, in his eventuall bug report.
Such a timestamp will let the GRASS GForge user verify if the issue he
is about to report is still actuall, in the most recent doc version he
can access.
Maciek,
sure, why not. Every developer can modify the Web pages:
Set the CVSROOT variable (with your CVS ID)
cvs -z3 co web
Markus
On Sun, Nov 12, 2006 at 06:15:33PM +0100, Maciej Sieczka wrote:
While setting up the tracker for doc bugs, I've come to an idea that it
would be usefull to have the CVS checkout's date and time displayed on
the http://grass.itc.it/gdp/manuals.php. So the user (who is not using
CVS) reporting a manual bug, can know if his issue is still actuall and
what CVS checkout he is reffering to, and supply this CVS date and time
in the bug report (see http://wald.intevation.org/tracker/?func=add&group_id=21&atid=184).
Such a timestamp will let the GRASS GForge user verify if the issue
he is about to report is still actuall, in the most recent doc
version he can access.
I still don't understand what is missing. That URL and all the man pages
already have $date$ "last modified" cvs checkin times printed at the
bottom.
Such a timestamp will let the GRASS GForge user verify if the issue
he is about to report is still actuall, in the most recent doc
version he can access.
I still don't understand what is missing.
A timestamp on the very http://grass.itc.it/gdp/manuals.php site. This
would inform what was CVS date and time when the docs on this site
were built. So the user can know what is the timestamp of this doc
version. This helps him to provide a better information in his doc bug
report - let's him verify if his local doc is newer or older, and
provides the CVS date&time for him to include in his bug report.
A timestamp on the very http://grass.itc.it/gdp/manuals.php site. This
would inform what was CVS date and time when the docs on this site
were built. So the user can know what is the timestamp of this doc
version. This helps him to provide a better information in his doc bug
report - let's him verify if his local doc is newer or older, and
provides the CVS date&time for him to include in his bug report.
why is the release version not sufficient? 6.0, 5.4, etc..
for 6.3-cvs they are updated weekly(?) so there could be a "generated
$date$", but is that needed? each help page has its "last modified"
timestamp already, which is more important than the date its header was
connected.
i.e. description.html version is more important than g.module.html date.
On Wed, Nov 15, 2006 at 11:16:43PM +0100, Maciej Sieczka wrote:
Hamish wrote:
> Maciej Sieczka wrote:
>> I mean the main docs page, at http://grass.itc.it/gdp/manuals.php.
>> Could *this* site have the CVS timestamp on it as well?
>>
>> Such a timestamp will let the GRASS GForge user verify if the issue
>> he is about to report is still actuall, in the most recent doc
>> version he can access.
>
> I still don't understand what is missing.
A timestamp on the very http://grass.itc.it/gdp/manuals.php site. This
would inform what was CVS date and time when the docs on this site
were built.
So you mean to transfer the update timestamp from the underlying pages
into this page? I have no idea how to do that (some PHP based parsing maybe?).
So the user can know what is the timestamp of this doc
version. This helps him to provide a better information in his doc bug
report - let's him verify if his local doc is newer or older, and
provides the CVS date&time for him to include in his bug report.
As a quick-and-dirty solution I have added "updated weekly" to
- GRASS 6.3.x manual pages, and
- GRASS 6.2.x manual pages
I am even unsure if we should keep the links to the old stuff there
or move out ot manuals_old.php
I am even unsure if we should keep the links to the old stuff there
or move out ot manuals_old.php
my vote is for moving 6.0, 5.4, and 4.3 into manuals_old.php.
less noise -> quicker solutions
also, can we get generalize "6.2.x" as just "6.2"? As long as there is
no other "6.2" choice it isn't hard to figure out which link you want
and it looks a lot cleaner. I guess 6.3.x should be 6.3.cvs? (assumes
that the reader knows what cvs is, ...)
there is the lingering issue of content in the 5.4 help pages which
has never been transfered to the Grass 6 help pages.
A timestamp on the very http://grass.itc.it/gdp/manuals.php site. This
would inform what was CVS date and time when the docs on this site
were built. So the user can know what is the timestamp of this doc
version. This helps him to provide a better information in his doc bug
report - let's him verify if his local doc is newer or older, and
provides the CVS date&time for him to include in his bug report.
why is the release version not sufficient? 6.0, 5.4, etc..
Because many people build from CVS, or use the CVS snapshots.
for 6.3-cvs they are updated weekly(?)
I guess so. However, Markus happens to regenerate CVS shapshots
manually. Are the docs regenerated then too, Markus?
so there could be a "generated
$date$", but is that needed? each help page has its "last modified"
timestamp already, which is more important than the date its header was
connected.
I think the CVS timestamp is more important, than the "last modified"
timestamp:
Take a doc that was last modified one year ago. Say a user reports an
error for this doc, today; and you look into this bug a month later. If
there is a timestamp of the CVS version the bug was reported against,
you can say how fresh the bug is (a month). If there was the "last
modified" timestamp instead (ie. a year ago), your perception of how
actual the bug is would be biased.
Moreover, pretty important IMO: if we require the user to compare the
doc bug he found in his GRASS instalation, against the latest available
doc version, he is more likely not to report an outdated bug. Say he is
about to report a doc bug for his 2 months old GRASS 6.2 instalation,
but when he is filling the report, he is asked to provide the most
actuall doc's CVS timestamp he can check against, and he is informed he
can find a version few days old at grass.itc.it/gdp/manuals.php. Then
it shows that the doc bug has been solved recently - in the result a
redundant bug report is avoided and the user is better informed.
i.e. description.html version is more important than g.module.html date.
A timestamp on the very http://grass.itc.it/gdp/manuals.php site. This
would inform what was CVS date and time when the docs on this site
were built. So the user can know what is the timestamp of this doc
version. This helps him to provide a better information in his doc bug
report - let's him verify if his local doc is newer or older, and
provides the CVS date&time for him to include in his bug report.
why is the release version not sufficient? 6.0, 5.4, etc..
Because many people build from CVS, or use the CVS snapshots.
for 6.3-cvs they are updated weekly(?)
I guess so. However, Markus happens to regenerate CVS shapshots
manually.
No. I rarely trigger the cronjob in certain circumstances to have it before
saturday. But I have enough to do not to generate CVS shapshots
manually
This is a perfect job for a computer.
Are the docs regenerated then too, Markus?
During compilation of the binary Linux snapshot the HTML docs are
created and in the end copied into the Web space.
All this is described in my document (find in the source code)
doc/infrastructure.txt
On Thu, Nov 16, 2006 at 07:56:10PM +1300, Hamish wrote:
Markus Neteler wrote:
> I am even unsure if we should keep the links to the old stuff there
> or move out ot manuals_old.php
my vote is for moving 6.0, 5.4, and 4.3 into manuals_old.php.
less noise -> quicker solutions
Done so.
also, can we get generalize "6.2.x" as just "6.2"? As long as there is
no other "6.2" choice it isn't hard to figure out which link you want
and it looks a lot cleaner. I guess 6.3.x should be 6.3.cvs? (assumes
that the reader knows what cvs is, ...)
On Fri, Nov 17, 2006 at 06:48:24PM +0100, Maciej Sieczka wrote:
Markus Neteler wrote:
> Maciej Sieczka wrote on 11/16/2006 06:45 PM:
>> Hamish wrote:
>>> for 6.3-cvs they are updated weekly(?)
>> I guess so. However, Markus happens to regenerate CVS shapshots
>> manually.
> No. I rarely trigger the cronjob in certain circumstances to have it before
> saturday.
That's what I'm saying - that you *happen* to regenerate CVS shapshots
manually.
Since you insist:
- assume 8 manual triggers per year
- 52 weeks
- 17 cronjobs
8/(52 * 17)
[1] 0.009049774
-> the trigger rate is below 1%! It remains in the noise (for me).
This 0.9% does not justify at all any complex PHP programming just to tell
people that the HTML pages are weekly updated.
In the end the time stamp of the individual *document* matters. And that's
almost everywhere in the underlying description.html files.
- assume 8 manual triggers per year
- 52 weeks
- 17 cronjobs
8/(52 * 17)
[1] 0.009049774
-> the trigger rate is below 1%! It remains in the noise (for me).
"When it comes to quality, noise and detail are somewhat
interchangeable." (just kidding, mostly)
This 0.9% does not justify at all any complex PHP programming just to tell
people that the HTML pages are weekly updated.
In the end the time stamp of the individual *document* matters. And that's
almost everywhere in the underlying description.html files.
OK. Thanks. IMO individual doc timestamp is a next good thing to a CVS
timestamp. Fair enough (since you insist ).
).