Team Chat Logs

2006 7
Mo Tu We Th Fr Sa Su
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

August 28, 2006

[00:10:31] * Riccc has quit IRC
[00:12:23] * cmlenz has joined #trac
[00:12:58] <coderanger> cmlenz: G'morning
[00:13:07] <cmlenz> morning
[00:17:47] <coderanger> question for you
[00:18:08] <coderanger> How well do you think bitten would work for a project that lacks a compile step?
[00:18:17] <coderanger> i.e. Python+setuptools
[00:18:41] <coderanger> Just running it to gather unit test data
[00:23:44] <cmlenz> I see no problem with no compilation step
[00:24:09] <coderanger> Okay, I didn't see anything that said it was required, just wanted to make sure that wasnt some kind of tacit assumption
[00:24:23] * Riccc has joined #trac
[00:37:57] <coderanger> Hmm, I wonder how hard it would be to backport some of the stuff from dr project's Mail plugin
[00:40:23] * Nobody-AC1A1 has quit IRC
[00:44:02] * flox has joined #trac
[00:50:04] * PingYeh has joined #trac
[00:53:15] * Nobody-AC1A1 has joined #trac
[00:56:04] * Tetraboy has quit IRC
[01:08:46] * moolight has quit IRC
[01:08:55] * moolight has joined #trac
[01:10:56] * otaku42_away is now known as otaku42
[01:11:03] * Riccc has quit IRC
[01:16:14] <otaku42> moin
[01:17:18] * mbroeken has joined #trac
[01:28:41] * appel has joined #trac
[01:43:50] * appel has quit IRC
[01:46:28] * tuxipuxi has joined #trac
[01:54:15] * Riccc has joined #trac
[02:00:06] * appel has joined #trac
[02:10:31] * Nobody-AC1A1 has quit IRC
[02:21:04] * cedricOB has joined #trac
[02:21:34] <cedricOB> hello, I have just add a button to the navbar, how to set its position ?
[02:21:47] <cedricOB> (I want it to beright to view ticket
[02:22:45] <tuxipuxi> cmlenz, how's the release preparation going? :-)
[02:23:33] <cmlenz> well, I still need to do most of the non-fun part: proof-reading and updating the docs :-P
[02:23:44] <cmlenz> not many volunteers for that apparently
[02:25:07] <tuxipuxi> it's great that you're doing it. what the world doesn't need is yet another open source project with crap documentation ;)
[02:29:04] <cedricOB> I have RTFWiki and find the trac.ini ...
[02:43:03] <jkp_> cmlenz: hey dude
[02:43:16] <jkp_> you there?
[02:46:11] <cmlenz> yup
[02:46:27] <jkp_> hey man - long time no speak
[02:46:38] <jkp_> how goes?
[02:47:02] <cmlenz> fine :-)
[02:47:21] <jkp_> so, i hope you dont mind, but ive adopted trac.core for another project im working on
[02:47:37] <jkp_> i checked your license and it seemed permissable
[02:47:59] * maxb has joined #trac
[02:48:03] <cmlenz> absolutely
[02:48:11] <jkp_> ...basically i was looking for a way to structure everything and once i had done the requirements analysis it became clear that id need plugins with plugins etc
[02:48:23] <jkp_> and i didnt want to reinvent the wheel, so i went shopping before i did
[02:48:30] <jkp_> first thing that came up was trac.core
[02:48:42] <jkp_> and it looks perfect having looked into it some
[02:48:55] <jkp_> i just have a couple of questions about how you have approached using it
[02:49:19] <cmlenz> ah yeah, trac is #1 on google "python plugin architecture" ;-)
[02:49:37] <jkp_> if the components cant have constructors, how do you generally go about providing specialist data needed for component initialisation?
[02:49:40] <jkp_> yeah :)
[02:49:46] <jkp_> and rightly so....great design
[02:50:02] <jkp_> i might well port it to obj-c and use it for growl if i can get my head round it here
[02:50:31] <cmlenz> what do you mean with "specialist data"?
[02:50:46] <jkp_> well - i have a component in my app that is a channel list
[02:50:55] <jkp_> (im working on a set-top box)
[02:51:19] <jkp_> the controllers were previously constructed using a factory class
[02:51:29] <jkp_> since its quite involved work, i wanted to seperate out that code
[02:51:33] <cmlenz> if a component needs configurable data, in Trac it pulls that data from the environment/configuration
[02:51:57] <cmlenz> so in __init__() it would do something like self.data = self.config.get(bla)
[02:52:07] <jkp_> right, you have one global configuration....im gonna have many and ill need to be able to provide the right configuration to the right components
[02:52:34] <cmlenz> components in trac are singletons, so that isn't going to work AFAICT
[02:52:37] <jkp_> because dependent on the components they may need to grab their configuration from the web somewhere
[02:52:56] <jkp_> well, there is only one channel list object
[02:53:21] <jkp_> it can intelligently return different subsets of channels dependent on parameters passed to the selection methods
[02:53:37] <cmlenz> ok
[02:53:38] * real-dev has left #trac
[02:53:58] <jkp_> so it should work, the thing is about how to provide config data - which sometimes needs to be pulled from the web (i have a seperate class that manages trying to do that and retrying etc)
[02:53:59] <cmlenz> but still, the component will need to retrieve its settings somehow instead of having it passed to it in the ctor
[02:54:30] <jkp_> right, so then i started looking at having some sort of configuration interface
[02:55:22] <jkp_> that they could all conform too ...say if they need a remote config file, then id conform to IRemoteConfig or something...and then have an external object that made sure they were all configured right
[02:55:39] <jkp_> but then that seemed wrong because i wouldnt be able to control the ordering very easliy
[02:56:28] <jkp_> coz the code to fetch a remote config file and ensure it arrives is repetetive so it should be in its own class, but also a component cant be used till its properly configured or else it isnt going to do anything
[02:56:52] <jkp_> as you can see - there are some issues that need addressing here that arent *that* straightforward
[02:57:15] <jkp_> i guess i was just interested in how you might approach the issue since you have used this code for ages
[02:59:17] <cmlenz> I'm not sure I completely follow :-P do you need something like dependencies, where one component can only start up after a component it depends on has started up?
[02:59:24] <jkp_> kinda yeah
[02:59:58] <cmlenz> yeah, that would complicate the code somewhat
[03:00:11] <jkp_> i looked at subclassing the ComponentManager
[03:00:31] <cmlenz> because you'd probably want to make components depend on abstract roles, not concrete component, and then concrete components would declare to fulfill roles
[03:00:43] <cmlenz> or sth like that
[03:00:52] <jkp_> that sounds like a nice approach
[03:01:03] <cmlenz> or maybe depending on concrete components would be enough… definitely a lot simpler ;-)
[03:01:18] <cmlenz> IRemoteConfig(object): provides("config")
[03:01:27] <cmlenz> IBla(Component): requires("config")
[03:01:51] <jkp_> provides...requires? are these normal python construcs?
[03:01:58] <jkp_> (im fairly new on the block)
[03:02:06] <cmlenz> no, that would be similar to trac.core.implements
[03:02:17] <cmlenz> you'd have to implement all that ;-)
[03:02:20] <jkp_> right...id have to implement it
[03:14:27] <jkp_> so that was my other question
[03:14:44] <jkp_> is Environment the core of your app then?
[03:15:01] <cmlenz> in Trac it is
[03:15:07] <jkp_> coz i was kinda thinking that maybe that was the way to go, to make my main application controller a subclass of ComponentManager
[03:15:13] <cmlenz> in some other app it would be whatever extends ComponentManager
[03:15:19] <cmlenz> right
[03:16:01] <jkp_> but in your case it also subclasses Component
[03:16:12] <jkp_> how does it get instatiated, with another component manager?A
[03:18:02] <cmlenz> that's a special case
[03:18:22] <cmlenz> a component that is also a componentmanager can have a real ctor
[03:18:41] <jkp_> ahhhh - yeah, i read that in the code
[03:18:48] <jkp_> so you can instantiate it normally
[03:23:25] * Nobody-AC1A1 has joined #trac
[03:24:05] <jkp_> can a component tell what comnponent manager constructed / manages it?
[03:34:34] <cmlenz> self.compmgr
[03:34:41] <cmlenz> IIRC
[03:37:37] <jkp_> great
[03:40:34] * Riccc has quit IRC
[03:47:09] * moolight has quit IRC
[03:53:01] <jkp_> cmlenz: also, is there a way to tell if a component implements a specific interface?
[03:53:03] * Riccc has joined #trac
[03:55:55] <cmlenz> not really, only manually checking component._implements
[03:57:32] <jkp_> coz what im thinking of is this: when i create a component i need to configure by loading config files id want to check if it conformed to the IConfigConsumer interface and react accordingly
[03:58:08] <jkp_> its not quite the same model as a general class that has an extension point for classes that implement a given interface
[03:58:32] <cmlenz> why not?
[03:59:23] <cmlenz> bbiab
[03:59:43] <jkp_> well, i guess i could do it the other way as well - component is created (not sure where that should happen btw) and as it creates it it checks if it is in the list of classes for that extension point and acts accordingly
[03:59:48] <jkp_> cool
[04:10:25] * Nobody-AC1A1 has quit IRC
[04:17:31] * nextime has joined #trac
[04:20:15] * renton has joined #trac
[04:20:22] <renton> hello
[04:20:25] * mbroeken has quit IRC
[04:20:43] * cookin_ has joined #trac
[04:23:13] * Nobody-AC1A1 has joined #trac
[04:28:58] * Miek has quit IRC
[04:29:43] * sanmarcos has quit IRC
[04:30:23] * sanmarcos has joined #trac
[04:31:52] <jkp_> cmlenz: is there a way to have an abstract component that implements some stuff that subcomponents can inherit?
[04:32:20] <jkp_> (ie so that isnt a singleton by itself but gets used to compose lower level components)
[04:38:07] * jrydberg has quit IRC
[04:40:07] * Riccc has quit IRC
[04:53:34] * Riccc has joined #trac
[04:55:50] <cmlenz> jkp_: there's an abstract flag for components
[04:55:58] <jkp_> yeah, just found it
[04:55:58] <cmlenz> class MyComp(Component): abstract=True
[04:56:20] <cmlenz> it will still be a singleton, but it won't be in extension point enumeration
[04:56:36] <jkp_> i presume that if i set that, then each class that inherits gets registered as implementing the things that the superclass does?
[04:57:06] <jkp_> ie- i can provide a default implementation for an interface
[04:58:30] <cmlenz> yeah
[04:58:46] <jkp_> great - you thought of everything didnt you? ;p
[05:02:46] <cmlenz> heh
[05:02:52] <cmlenz> well, we needed that in trac, so :-P
[05:02:59] * converter has joined #trac
[05:10:16] * Nobody-AC1A1 has quit IRC
[05:21:14] <renton> i'd like to restrict the 'assign-to' field of a ticket to a subset of the members. Could someone guide me to what changes i'd have to make in the code and whether anyone's done it already?
[05:23:14] * Nobody-AC1A1 has joined #trac
[05:25:49] * Miek has joined #trac
[05:33:44] * milk-it has joined #trac
[05:34:16] * hpnadig has quit IRC
[05:34:18] * xjjk has quit IRC
[05:40:29] * Riccc has quit IRC
[05:44:50] <cedricOB> renton : look at trac-hacks.org
[05:45:00] <cedricOB> and perhaps suggest a new plugin ...
[05:45:19] <renton> ok. tnx
[05:45:45] <renton> i need it urgently, so will write a quick hack if i cant find it
[05:51:06] <cmlenz> renton: current trunk restricts the list to those users who have TICKET_MODIFY permissions
[05:53:28] * chjunior has joined #trac
[05:54:39] * Riccc has joined #trac
[05:55:40] <renton> i think that will do
[05:59:07] <renton> i'll allow TICKET_APPEND to all normal users and TICKET_MODIFY to the admins
[06:00:12] * flox has quit IRC
[06:04:46] * xjjk has joined #trac
[06:11:18] * Nobody-AC1A1 has quit IRC
[06:13:57] * flox has joined #trac
[06:16:15] * converter has quit IRC
[06:31:57] * renton has quit IRC
[06:37:03] * chandlerc has quit IRC
[06:37:11] * hpnadig has joined #trac
[06:44:14] <cmlenz> anyone here knowledgeable enough about FastCGI to proof-read and cleanup http://trac.edgewall.org/wiki/TracFastCgi ?
[06:54:11] * hpnadig has quit IRC
[06:54:49] * hpnadig has joined #trac
[06:57:41] * xjjk has quit IRC
[06:58:48] * tasoss has joined #trac
[06:58:52] <tasoss> hello
[07:01:02] <tasoss> i downloaded the latest version but i can't it work with mysql.is there an available version that work with mysql please?
[07:04:07] <cmlenz> trunk
[07:04:35] <cmlenz> http://trac.edgewall.org/wiki/TracDownload#LatestDevelopmentSourceCode
[07:04:59] <tasoss> sorry?
[07:05:12] * PingYeh_ has joined #trac
[07:05:17] <tasoss> i have downloaded the svn version
[07:06:02] <tasoss> but when i run trac-admin and i enter mysql:// etc it stops
[07:12:06] * tasoss has quit IRC
[07:13:15] <cmlenz> how so?
[07:13:27] <cmlenz> do you get an error?
[07:14:41] * xjjk has joined #trac
[07:19:39] * danbeck has joined #trac
[07:19:44] <pacopablo> morning
[07:25:19] * sanmarcos has quit IRC
[07:25:57] * sanmarcos has joined #trac
[07:26:47] <jkp_> cmlenz: when you get a list of extensions from an ExtensionPoint does it by default initialize them?
[07:27:08] <cmlenz> sure, as you get instances back, not classes
[07:27:13] <jkp_> hrm
[07:27:39] <jkp_> so i need to make sure that they do nothing in their init methods except set some basic vars
[07:27:56] <cmlenz> that would probably be a good idea
[07:28:19] <cmlenz> no SOAP calls in __init__ ;-)
[07:28:29] <jkp_> the other thing is this - does it return only the ones that the component manager allows to be created?
[07:28:39] <cmlenz> yes
[07:28:42] <jkp_> ok
[07:28:43] * PingYeh_ has left #trac
[07:28:48] <jkp_> so you can prefilter at that level
[07:29:22] <jkp_> also if i do
[07:29:37] <jkp_> self.comp = SomeComponent()
[07:29:49] <jkp_> or rather SomeComponent( self )
[07:30:06] <jkp_> presumably component_activated would be called before self.comp is assigned?
[07:30:24] <cmlenz> hmm, I don't think so
[07:30:34] <jkp_> ok - good, i was hoping not
[07:31:07] <jkp_> because i would like to be able to test in component_activated whether or not the component was a given component
[07:31:17] <jkp_> (thhere is a soecial case)
[07:32:54] <cmlenz> you'll have to try... the details of that escape me right now :-P
[07:39:39] * cedricOB is now known as klando
[07:40:09] * klando is now known as cedricOB
[07:57:11] * thecentric has joined #trac
[07:59:10] * MasterC has joined #trac
[07:59:51] * chandlerc has joined #trac
[08:02:48] <thecentric> hi all, i begun using trac a week ago now on a project at work. going to continue to use it for the coming weeks as we evaluate a number of tools to support us in our software development - would it be more appropriate for me to bang out questions on the mailing list than here?
[08:03:38] <pacopablo> not necessarily
[08:04:05] <pacopablo> depends on how fast you want a response, and the nature of the question
[08:04:13] <pacopablo> generally, IRC is faster
[08:04:24] <pacopablo> however, you get a wider audience on the ML
[08:04:49] <thecentric> cool; well one of the requirements or at the very least one of the things i'd like to have is the following: a user can only view tickets that he or she has opened... i delved a little bit into permissions - but is this possible?
[08:05:08] <pacopablo> not really
[08:05:23] <thecentric> pacopablo: cheers - well i'll start here :) I am *very* impressed with trac btw, excellent and useful software
[08:05:25] <pacopablo> at least not permission wise
[08:05:38] <pacopablo> in 0.11, there should be some support for that
[08:05:43] <pacopablo> but not currently
[08:05:59] <pacopablo> you could simply provide a report that only shows the tickets that they own
[08:06:04] <thecentric> pacopablo: the best way to approach it currently? possible via a plugin (that i may have to write myself say) ?
[08:06:21] <pacopablo> but they would still be able to access other tickets by simply typing in the number
[08:06:40] <thecentric> pacopablo: sure, i believe i thought of that as well, could probably live with it
[08:06:58] <pacopablo> you could look at the security sandbox
[08:07:14] <pacopablo> but that's probably a bit more work than you want to do
[08:07:29] <pacopablo> as it should be merged sometime after 0.10 is released
[08:07:56] <thecentric> pacopablo: right, probably a bit too much alright - but i may have a look anyways thanks.
[08:08:34] <thecentric> has anyone worked on scripts to convert media wiki or twiki -> trac wiki? Or indeed fogbuz ->trac ?
[08:09:09] <thecentric> began writing a twiki->trac wiki myself - if i get it more or less working i'd be glad to put it out there - but dont want to duplicate work.
[08:09:10] <pacopablo> not that I am aware of, but that's probably a better question for the mailing list
[08:09:33] <pacopablo> and if you do end up completing it, put it on trac-hacks.org
[08:09:40] <coderanger> [tickets only you opened] It is doable with some dumb hackery though
[08:10:18] <pacopablo> coderanger: how would you do it without basically replacing the whole ticket module?
[08:10:33] <pacopablo> I guess you could use a pre-request filter
[08:10:56] <pacopablo> and make a check to see if the requestor matches the creator of the ticket
[08:11:00] <coderanger> pacopablo: pre-request filter that checks if handler==TicketModule, and if so raises an error or something if you aren't the reporter
[08:11:23] * pacopablo isn't used to the pre-request filters
[08:11:36] <coderanger> Its not a great solution, but it would work
[08:11:37] <pacopablo> I've got to reimplement secsession in a pre-request filter
[08:11:48] <thecentric> coderanger: hey, thanks for that - will take a look at pre-request filters then...
[08:18:06] * bballizlife has quit IRC
[08:23:36] * xjjk-T42p has joined #trac
[08:24:10] * xjjk has quit IRC
[08:24:13] * xjjk-T42p is now known as xjjk
[08:27:12] * bballizlife has joined #trac
[08:30:24] * ksclarke has joined #trac
[08:39:38] * didier has joined #trac
[08:39:46] <didier> hello
[08:40:07] <didier> when I do <ALT-E> on a wiki page, the page is edited
[08:40:23] <didier> is there a <ALT-xxxx> for submit changes ?
[08:41:29] * agile has quit IRC
[08:43:08] * otaku42 is now known as otaku42_away
[08:43:17] * chandlerc has quit IRC
[08:46:00] * chandlerc has joined #trac
[08:47:40] <didier> ok I find it in a subversion changeset :)
[08:50:49] * agile has joined #trac
[08:54:01] * bryanl_ has joined #trac
[08:54:22] <bryanl_> if i change the location of svn in trac, how do i update trac to let it know i made the change?
[08:55:28] <coderanger> trac-admin /path/to.env resync
[08:55:48] <coderanger> and make sure its correct in trac.ini
[08:56:00] <bryanl_> coderanger: cool... i just went to trac sqlilte db and did "delete from revision;
[08:56:01] <bryanl_> "
[08:56:07] <bryanl_> that seemed to fix the problem
[08:56:14] <bryanl_> thanks for the suggestion coderanger
[08:56:20] <coderanger> Its the same thing
[08:56:24] <bryanl_> ok
[08:56:28] <coderanger> Its trigger a resync on the first access then
[08:56:40] <coderanger> well you would want to empty both revision and node_change
[08:56:51] * coderanger -> Class
[08:57:17] * agile has quit IRC
[08:57:42] <bryanl_> ok
[08:57:44] <bryanl_> thanks
[09:00:39] * didier has left #trac
[09:02:11] * jborg has joined #trac
[09:02:25] <jborg> howdy
[09:02:30] <pacopablo> jello
[09:02:32] * chjunior has quit IRC
[09:04:04] * agile has joined #trac
[09:07:36] * razor has joined #trac
[09:08:45] <razor> does someone know of a module to note time usage on bug reports in order to set up a client billing report?
[09:09:07] <razor> or should I start hacking trac myself
[09:09:10] <razor> ? :)
[09:10:38] <pacopablo> http://trac-hacks.org/wiki/TimingAndEstimationPlugin
[09:10:43] * chandlerc has quit IRC
[09:10:47] <pacopablo> http://trac-hacks.org/wiki/ScrumBurndownPlugin
[09:11:28] <razor> great :)
[09:11:44] <pacopablo> http://trac.edgewall.org/wiki/TimeTracking
[09:16:10] <razor> looks good
[09:16:11] <razor> thanks
[09:16:45] * MasterC has quit IRC
[09:49:23] * chandlerc has joined #trac
[09:58:42] * ryepup has quit IRC
[09:59:40] * imajes has quit IRC
[10:00:02] * imajes has joined #trac
[10:03:56] * imajes has quit IRC
[10:05:00] * imajes has joined #trac
[10:06:04] * Nobody-AC1A1 has joined #trac
[10:17:34] * cookin_ is now known as jrydberg
[10:23:23] * Riccc has quit IRC
[10:26:43] * rbp has joined #trac
[10:32:48] * cboos has joined #trac
[10:33:29] <cboos> hi
[10:33:35] <pacopablo> jello
[10:34:04] <cboos> I'm currently reviewing the restructured text pages, I hope no one has started yet?
[10:34:21] <pacopablo> I haven't :)
[10:34:29] <cboos> cmlenz?
[10:34:42] <cmlenz> yeah, haven't started that yet
[10:34:52] <cboos> ok, so I'll take care of them
[10:35:12] <cmlenz> I think we'll pull in any further doc updates in the 0.10 final release
[10:35:25] <cmlenz> I was getting tired of proofreading and jonas has already pulled the changes
[10:35:26] * thecentric has left #trac
[10:35:27] <cmlenz> :-P
[10:35:42] * ksclarke has left #trac
[10:35:51] <cboos> so it will be a release on r3670, right?
[10:36:22] <cboos> ah. no the next one of course
[10:37:59] <cmlenz> I'll include the patch on #3295 to get more feedback on that change
[10:38:07] <cmlenz> currently integrating
[10:39:10] <cboos> while it's too late for the beta1, what do you think about the discussion we had on trac-dev about reworking the error.cs?
[10:39:47] <pacopablo> I think it would be good for 0.10
[10:39:56] <cboos> i.e. don't show the backtrace for anyone not TRAC_ADMIN, and simply redirect the user to first report the error to his trac admin,
[10:40:25] <cboos> then show to the trac admin not only the backtrace but also the relevant system information
[10:40:44] <pacopablo> generating an ID or something that the user can report to the admin would be helpful
[10:40:55] <pacopablo> and have that ID appear in the log along with the traceback
[10:41:35] <cboos> why not simply the time?
[10:41:42] <pacopablo> tha's sufficient
[10:42:00] <cmlenz> cboos: yeah, for the final release that would probably be a good idea
[10:42:03] <pacopablo> though you would need to make sure that the time in shown in the error.cs is that same time that is stamped in the log
[10:42:12] <pacopablo> so that the admin can grep on it
[10:42:52] <cboos> pacopablo: right
[10:43:04] <pacopablo> though I guess if just done by the minute, it should be close enough for the admin to find
[10:43:10] <cmlenz> right
[10:47:06] <jborg> We need some help testing the tarball before the release: http://people.edgewall.com/~jonas/trac-0.10b1.tar.gz
[10:47:18] <cboos> ok...
[10:47:37] <jborg> Especially if you got a 0.9 env so we can make sure the upgrade process works.
[10:50:12] <bryanl_> how does xhr work with simply restful? it seeems like i should create another controller to handle the ajaxy stuff
[10:50:14] <bryanl_> oops
[10:50:20] <bryanl_> wrong channel
[10:52:25] <cboos> in INSTALL, it's still pysqlite 1.1.6 which is recommend... that's a bit old now
[10:52:42] <cboos> we probably put 2.3.2 there
[10:53:22] * sanmarcos has quit IRC
[10:54:00] <Chutt> is there an easy way to make the ticket properties permissions more granular? say i wanted to remove only milestone & severity from anon users..
[10:54:01] * sanmarcos has joined #trac
[10:54:24] * flox has quit IRC
[10:54:40] <cmlenz> windows installer here: http://people.edgewall.com/~cmlenz/trac-0.10b1.win32.exe
[10:55:10] <cboos> Chutt: in 0.11 it will be possible, not before ... (check SecurityPolicy and WorkFlow in Trac's wiki)
[10:55:24] <Chutt> it's getting really annoying having to go reset those all the time :(
[10:55:40] <Chutt> cboos, excellent.
[10:58:06] <cboos> hm, jborg the UPGRADE file was not upgraded...
[10:58:48] <cboos> but there's not much to say actually, except maybe: "0.9.x to 0.10.x: the upgrade process should be harmless" ;)
[10:59:00] <cmlenz> TracUpgrade
[10:59:05] <cmlenz> has the contents in wiki form
[10:59:10] <cmlenz> I updated that already
[10:59:19] <cboos> sure, but I follow the path from README -> INSTALL -> UPGRADE
[10:59:28] <cmlenz> only the section 0.9 -> 0.10
[10:59:33] <cboos> (the text files)
[10:59:42] <cmlenz> I know, I'm just saying that jonas doesn't need to write all new content for UPGRADE
[11:00:43] <cboos> yes, but even, what's in TracUpgrade seems to be not appropriate for the UPGRADE file.
[11:00:44] <jborg> I'll update it
[11:01:34] <cmlenz> cboos: why? they're certainly intended to share most of the content
[11:01:46] <cboos> I think it's better to just say "the upgrade should be seemless" or something as those are trac-admin and installation level instructions.
[11:02:47] <cmlenz> no, they're "upgrading-in-general" instructions, pretty much the same as TracUpgrade
[11:03:14] <cboos> ah, I got that impression because the sync was not done since some time...
[11:03:31] <cmlenz> yeah, just noticed that too
[11:03:41] <cboos> OK, maybe it's better to keep them in sync after all
[11:04:12] <cmlenz> does 0.10 require a resync?
[11:04:39] <cboos> good question... don't think so but I'll check in the revision log
[11:04:58] <cmlenz> btw, I hope everyone in here has there champagne bottle ready... 0.10 is being released before the world ends :-P
[11:05:19] <cboos> most resync related changes happened during 0.9.3 - 0.9.4, so all depends from what version you upgrade.
[11:05:36] <cboos> I bet we'll eventually reach 2.0 before that ;)
[11:05:45] <cboos> it's only 2012 after all :)
[11:06:24] <cmlenz> jborg: upgrading from 0.9 seemed to work well on sqlite
[11:06:36] * hpnadig has quit IRC
[11:07:40] <cmlenz> anyone tested the windows installer yet, or do I need to do that again? :-P
[11:07:46] * cmlenz hates working in windoze
[11:07:57] <cboos> ok, ok I could do it...
[11:08:04] <cmlenz> heh :-D