Jonas Borgström | 1 Mar 17:29 2009

[Trac-dev] Re: Broken RST support on t.e.o. ?


On 2/23/09 12:32 PM, Emmanuel Blot wrote:
> Hi,
>
> It seems that the Restructured Text engine is not enabled anymore on t.e.o.
>
> While it is not a big deal for demonstration purposes (e.g.
> http://trac.edgewall.org/wiki/WikiRestructuredText), it's a real issue
> for other projects (such as Bitten) that rely on RST for their
> documentation, e.g.
> http://bitten.edgewall.org/wiki/Documentation/index.html
>
> Any status about RST ?

Yes, the docutil package was missing, sorry about the delay.

/ Jonas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Jonas Borgström | 1 Mar 18:32 2009

[Trac-dev] 0.11.4 and release testing


Hi all,

0.11.3 unfortunately contained a few regressions so we need to get 
0.11.4 out pretty soon.

Most issues seems to have been fixed in 0.11-stable already but are 
there any other bug fixes that need to go into 0.11.4 as well?

And to avoid similar regressions in the future we need to do something 
to improve our pre-release testing.

What is the best approach? Pre-release testing checklists, release 
candidates or both?

/ Jonas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Emmanuel Blot | 1 Mar 19:04 2009
Picon

[Trac-dev] Re: Broken RST support on t.e.o. ?


Hi Jonas,

> Yes, the docutil package was missing, sorry about the delay.

Thanks for the fix,

Cheers,
Manu

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Remy Blank | 1 Mar 19:19 2009
Picon

[Trac-dev] Re: 0.11.4 and release testing

Jonas Borgström wrote:
> Most issues seems to have been fixed in 0.11-stable already but are 
> there any other bug fixes that need to go into 0.11.4 as well?

I'd like to fix the following ticket for 0.11.4:

  http://trac.edgewall.org/ticket/8059

> What is the best approach? Pre-release testing checklists, release 
> candidates or both?

I would suggest at least one release candidate, and trying to enlist a
few people with various architectures and configurations (OS, database,
web server, front end) for testing. I'm sure we can find a few people on
this list who would be willing to test release candidates on their setups.

A standard testing procedure would be nice, but longer term we should
try to automate the procedure completely. A script that installs Trac
from a tarball or SVN tag, creates a new environment, and performs and
checks various operations on it would be very useful. There is some
overlap with functional tests, maybe they should just be extended to
allow using e.g. other databases, and to operate on an environment
created from scratch.

Not related to 0.11.4, we should also diversify the configurations on
which the automatic unit tests are run. I am in the process of setting
up an OS X machine with Python 2.3 - 2.6, and a Windows VM. Could these
be used as build bots for t.e.o?

-- Remy
(Continue reading)

Jonas Borgström | 1 Mar 21:38 2009

[Trac-dev] Re: 0.11.4 and release testing


On 3/1/09 7:19 PM, Remy Blank wrote:
> Jonas Borgström wrote:
>> Most issues seems to have been fixed in 0.11-stable already but are
>> there any other bug fixes that need to go into 0.11.4 as well?
>
> I'd like to fix the following ticket for 0.11.4:
>
>    http://trac.edgewall.org/ticket/8059
>
>> What is the best approach? Pre-release testing checklists, release
>> candidates or both?
>
> I would suggest at least one release candidate, and trying to enlist a
> few people with various architectures and configurations (OS, database,
> web server, front end) for testing. I'm sure we can find a few people on
> this list who would be willing to test release candidates on their setups.

Good idea, I created a simple wiki page where people interested in 
helping us out can sign up:

http://trac.edgewall.org/wiki/TracDev/ReleaseTesting

> A standard testing procedure would be nice, but longer term we should
> try to automate the procedure completely. A script that installs Trac
> from a tarball or SVN tag, creates a new environment, and performs and
> checks various operations on it would be very useful. There is some
> overlap with functional tests, maybe they should just be extended to
> allow using e.g. other databases, and to operate on an environment
> created from scratch.
(Continue reading)

Christian Boos | 2 Mar 11:15 2009
Picon

[Trac-dev] Re: 0.11.4 and release testing


Jonas Borgström wrote:
> Hi all,
>
> 0.11.3 unfortunately contained a few regressions so we need to get 
> 0.11.4 out pretty soon.
>
> Most issues seems to have been fixed in 0.11-stable already but are 
> there any other bug fixes that need to go into 0.11.4 as well?
>   

 * Stopped sync in 0.11.2.1
   http://trac.edgewall.org/ticket/8067

   Not sure the proposed patch really helps, as the rollback should
   happen anyway. Clarification of the installation requirements
   for MySQL seems to be the really important point there.

 * Trac does not send object names in quotes to PostgreSQL
   http://trac.edgewall.org/ticket/7600

   ecarter fixed it in r7923, independently from the provided patch,
   but there's also a contributed unit test on that ticket that could be
   checked in as well.

> And to avoid similar regressions in the future we need to do something 
> to improve our pre-release testing.
> What is the best approach? Pre-release testing checklists, release 
> candidates or both?
>   
(Continue reading)

Jon Greene | 1 Mar 06:55 2009

[Trac-dev] Re: Full-text search of attached documents


Returning to the original problem, does the patch posted by
anatoytechtonik now permit SearchAttachmentsPlugin to work with trac
0.11?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Xie | 2 Mar 05:08 2009
Picon

[Trac-dev] performance concern with ticket custom fields


Hi everybody

The company I'm working at (www.kingsoft.com, if you understand
Chinese :p) uses Trac heavily for bug/task tracking. There are some
custom fields in the ticket and we probably will have more. As the
design of Trac indicates, the support for custom field is poor and
we're having doubts about Trac's performances with ten or even twenty
custom ticket fields and >10k tickets. Has anyone the experience with
this kind of problem? Any plan with compatibility to future Trac
versions would be appreciated. Or perhaps we should customize more and
maintain our own version of Trac instead?

Ciao
Xie

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Noah Kantrowitz | 2 Mar 11:47 2009
Picon

[Trac-dev] Re: performance concern with ticket custom fields


Yes, 20 custom fields is likely to cause issues. Given the limitations  
of SQL there isn't really much of a way around this. Not sure I would  
really classify this as "poor support" since it is well beyond the  
expected use case. You could do some manual hacking and include extra  
columns on the ticket table for what you need, but it would be a non- 
trivial conversion. My vote would be to figure out why you need so  
many fields in the first place and fix that instead.

--Noah

On Mar 1, 2009, at 8:08 PM, Xie wrote:

>
> Hi everybody
>
> The company I'm working at (www.kingsoft.com, if you understand
> Chinese :p) uses Trac heavily for bug/task tracking. There are some
> custom fields in the ticket and we probably will have more. As the
> design of Trac indicates, the support for custom field is poor and
> we're having doubts about Trac's performances with ten or even twenty
> custom ticket fields and >10k tickets. Has anyone the experience with
> this kind of problem? Any plan with compatibility to future Trac
> versions would be appreciated. Or perhaps we should customize more and
> maintain our own version of Trac instead?
>
> Ciao
> Xie
>
> >
(Continue reading)

anatoly techtonik | 2 Mar 12:50 2009
Picon

[Trac-dev] Re: 0.11.4 and release testing


On Mon, Mar 2, 2009 at 12:15 PM, Christian Boos <cboos <at> neuf.fr> wrote:
>
>  * Stopped sync in 0.11.2.1
>   http://trac.edgewall.org/ticket/8067
>
>   Not sure the proposed patch really helps, as the rollback should
>   happen anyway. Clarification of the installation requirements
>   for MySQL seems to be the really important point there.

I agree that the patch won't help here much. A word of caution and a
message in log if DB frontend is MySQL and at least one table is
MyISAM. The check in SQL:

select table_name, engine from information_schema.tables where
table_schema=DATABASE();

>> And to avoid similar regressions in the future we need to do something
>> to improve our pre-release testing.
>> What is the best approach? Pre-release testing checklists, release
>> candidates or both?

Both, but also instructions and automation scripts.
http://trac.edgewall.org/wiki/TracDev/ReleaseTesting is not enough.
Ideally a person should be able to execute one test_trac.py script
that will ask a few questions if needed (or use config file) and
execute all tests itself.

In a distant future FitNesse-like framework may help to add/experiment
with tests more interactively.
(Continue reading)


Gmane