Context Navigation

Changes between Version 30 and Version 31 of TracTicketsCustomTimeFields

Timestamp:: Apr 24, 2010, 9:09:20 PM (14 years ago)
Author:: hoff.st@…
Comment:: more editorial changes, format corrections and re-arrangement of text sections

Legend:

: Unmodified
: Added
: Removed
: Modified

TracTicketsCustomTimeFields

-              v30
+              v31
 = Custom Ticket Time Fields  =
 This page presents information on adding a new type 'time' to the list of all currently available [wiki:TracTicketsCustomFields custom ticket fields].
+== Alternative approaches ==
+Making a long story short: They are there for years to cure the lack of custom time fields for various project management purposes. I've seen them, but I don't like all the string manipulation, at least, if it comes to queries and report generation. I met others feeling the same.
+Believe me, it's time for a sane extension of current custom fields support. And custom time fields backed by true POSIX microsecond time stamps stored in ticket_custom db table is the best way I could think of. Read on and, if you like it, join in to make it happen, please.
 == Proposed Implementation ==
 …
 ==== Code ====
+Patches against Trac trunk are published as Mercurial queue at bitbucket.org now:
+ http://bitbucket.org/hasienda/custom-time/
+''base'': patches apply cleanly to Trac trunk r~~9443~~9478, cloned/pulled from rblank's Mercurial repository at bitbucket.org.[[BR]]
+''base'': patches apply cleanly to Trac trunk ~~r9443~~ r9478[[BR]]
 ''quality'': beta - read: code flaws should have not much effect, at least not to trac db, '''start of testing announced on 21-Apr-2010''', now expect on only minor changes to core of implementation until my stable release[[BR]]
 ''focus'': bug-fixes, working ticket change notification for both [TracNotification Trac Notification] system and [th:wiki:AnnouncerPlugin AnnouncerPlugin][[BR]]
 ''reviews'': so far just me, I need your help now
+''reviews'': so far just me, I need your help now[[BR]]
 ''prospect'': hopefully merge with Trac trunk for official release with any of version 0.12.x or even 0.13
+You're invited to pull right now, but save a backup of your db before testing, please. I never broke the db of my development system. There might still lure some serious bugs, that I'm currently not aware of but could hit you, so you may need the data to recover from a bad db state. You've been warned. See [#KnownBugs Known Bugs] for more details.
+This is work in progress. Proposed code changes for Trac trunk reside in a Mercurial repository at bitbucket.org ^note 1^. The Mercurial Queue (MQ) aside that repo is the patch stack itself with some meta-data ^note 2^:
+ http://bitbucket.org/hasienda/custom-time/
+The repo will be more or less behind current SVN HEAD most of the time, while the MQ linked above is updated quite often to reflect the development of custom time field support ^note 3^.
+You're invited to pull right now, but save a backup of your db before testing, please. I never broke the db of my development system. However, there might still lure some serious bugs, that I'm currently not aware of but could hit you, so you may need your backup to recover from a bad db. You've been warned. See [#KnownBugs Known Bugs] for more details.
 Feedback could happen through
  * chat, while I'm arround in IRC channel #trac at freenode.net
+ * chat, while I'm around in IRC channel #trac at freenode.net (nickname: hasienda)
  * edits to (the discussion section of) this wiki page
  * comments to #1942
  * work on publicly reachable clone of my Mercurial Queue
+ * work on a publicly reachable clone of my Mercurial Queue
  * private e-mail
  * push to my Mercurial Queue after initial per-developer arrangement inside bitbucket.org
 I urge you to report back on any failure from your testing. Any feedback will help to make the patches ready for production and later bring the code into Trac itself. That was my goal right from the start, not produce just another [http://trac-hacks.org Trac hack].
+I urge you to report back on any failure from code review or your testing. For test results, as always, mention your local setup (Trac version/revision, if not taken from my repo, Mercurial revision id of the patches). Any feedback will help to make the patches ready for production and later bring the code into Trac itself. That was my goal right from the start, not to produce just another [http://trac-hacks.org Trac hack].
 ===== Notes =====
+. The common setup for Mercurial Queue puts patches into a Mercurial repo on their own. So looking at [http://bitbucket.org/hasienda/custom-time/changesets the changes] during development is easy.
+. Since there is no other sane way to push the changes to a repository without making them irreversible, I'll not dare to push anythink else (i.e. real revisions) to my repo before substantial clearing with core Trac developers. Still more patch files will get published somehow (starting with #9209).
+. My repository is a clone of rblank's Mercurial repository, that in turn consists of changesets imported from Trac SVN repo.
+. The common setup for Mercurial Queue puts the patches into a Mercurial repo on their own. So looking at [http://bitbucket.org/hasienda/custom-time/changesets the changes] during development is easy.
+. Since there is no other sane way to push the changes to a public repository without making them irreversible, I'll not dare to push real revisions before substantial clearing with core Trac developers. Some of the patches will get forwarded independently for early, stepwise adoption into Trac, like that published in #9209).
 ==== !HowTo testing ====
 For help on applying the patches to Trac trunk source the traditional way, i.e. with {{{patch}}}, look at the patch documentation in the [http://bitbucket.org/hasienda/custom-time/src/tip/series series] file. But you'll see, Mercurial will save you and me much time and hassle, even more for true collaboration on bugs and feature requests.
 For the lazy ones I recommend to just use Mercurial along the lines of the following walk-through (Debian way).
+For help on applying the patches to Trac trunk source the traditional way, i.e. with {{{patch}}}, look at the patch documentation in the [http://bitbucket.org/hasienda/custom-time/src/tip/series series] file.
+But you'll see, Mercurial will save you and me some time and hassle, even more for true collaboration on bugs and feature requests. For the lazy or impatient ones not familiar with Mercurial I recommend to go along the lines of the following walk-through (Debian way).
 ===== Before you start =====
 I can't guarantee and so can't be responsible on behalf of you for actions on your system. Please understand, what you type and think twice. Be careful especially while you act as root, and at the very least '''don't blame me''' for any mess YOU did.
+I tested this on my own, really, but can't guarantee and so can't be responsible on behalf of you for any action on your system. Please try to understand, what you type and think twice. Look at documentation I referenced as [#Externalrelatedresources external related resources] at the bottom of this page. Be careful especially while you act as root, and at the very least '''don't blame me''' for any mess YOU did.
 ===== Quickstart =====
+I assume that you'll have all pre-requisites like Python, setup-tools, Genshi and optionally Babel for the i18n support in place. If you're unsure or have issues with following procedure, look at the current [wiki:TracInstall Trac Install Guide] before crying at me.
 {{{
 $> apt-get install mercurial
 …
 $> env LANG=de_DE.UTF-8 /usr/local/bin/tracd -d -s --port 8000 /trac-environments/sandbox
 }}}
 That will
  * install Mercurial, if not installed before,
 …
  * copy patched sources to a build dir,
  * build Trac with custom time fields support and
+ * install it to your system,
+provided you have root permission or equivalent with sudo.
+I assume you have other pre-requisites like Python, setup-tools, Genshi and Babel (for i18n support) installed before. If you have issues, first look at the current [wiki:TracInstall Trac Install Guide].
+Install to /usr/local will normally overrule any other Trac installation without replacing it.
+Second {{{hg -v qpush}}} command is optional, but recommended to get verbose information from Trac log file, when Trac is configured with loglevel DEBUG, i.e. with a section in your trac.ini like the following:
+ * install it to your system, provided you have root permission or equivalent with sudo and last but not least
+ * fire up the standalone webserver tracd hosting a trac environment you've prepared before.
+You may have {{{/usr/bin/tracd}}} and {{{/usr/local/bin/tracd}}} than at different versions. Install to /usr/local will normally overrule the other Trac installation without replacing it. So calling just {{{tracd}}} will kick {{{/usr/local/bin/tracd}}}. However, just make sure, you always know, what is going on. (I mention all this because I messed up on my own and now refrain from having multiple versions at the same system at a time.)
+Second {{{hg -v qpush}}} command from above is optional, but recommended to get verbose information from Trac log file, when Trac is configured with log level DEBUG, i.e. with a section in your trac.ini like the following:
 {{{
 [logging]
 …
 log_type = file
 }}}
+(see: [wiki:TracLogging Trac Logging] for more details on the matter)
+See [wiki:TracLogging Trac Logging] for more details on the matter.
 ==== Known Bugs ====
 Problems (with priority) occurring arround ticket changes
+Issues (with priority) occurring around ticket changes
  * (B) [TracNotification Trac Notification] system unpatched, need to test and investigate, if necessary at all
  * (B) fix [th:wiki:AnnouncerPlugin AnnouncerPlugin], that already worked before introducing datetime.datetime format for all internal time variables
+ * (B) [th:wiki:AnnouncerPlugin AnnouncerPlugin] non-functional, that already worked before introducing datetime.datetime format for all internal time variables
 fixed:
  * {{{TypeError: unsupported type for timedelta microseconds component: unicode}}} on TracQuery: simply needed to take care for conversation of variable type 'string' to a number and handle custom time values in trac/ticket/templates/query_results.html separately from standard time fields
 …
  * add jQuery datepicker function to custom time fields or even more general to input forms for time stamps like was requested in a [http://trac.edgewall.org/ticket/1942#comment:18 comment to ticket #1942]
-=== Related Trac Plugins ===
- * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type, private patch done
- * [th:wiki:DateFieldPlugin DateFieldPlugin] working flawlessly with custom time fields, since these are still simple text input form fields
- * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings, private patch done
 === Discussion ===
 ==== Development questions ====
 …
       Re-based on r9478 meanwhile, nothing to update inside my patches. Nice. Time to move on.
 == Alternative approaches ==
+in short: They are there for years to cure the lack of custom time fields for various project management purposes. I've seen them, but I don't like all the string manipulation, at least, if it comes to queries and report generation. I met others feeling the same.
+Believe me, it's time for a sane extension of current custom fields support. And custom time fields backed by true POSIX microsecond time stamps stored in ticket_custom db table is the best way I could think of. Join now, to make it happen, please.
+== Related Trac plugins ==
+ * [th:wiki:CustomFieldAdminPlugin CustomFieldAdminPlugin], modified version to ease the setup for new field type, private patch done
+ * [th:wiki:DateFieldPlugin DateFieldPlugin] working flawlessly with custom time fields, since these are still simple text input form fields
+ * [th:wiki:AnnouncerPlugin AnnouncerPlugin], modified version produces reports with pretty date/time strings, private patch done
 == Related tickets ==