REQUEST - Branch for Query Module

[ilias@…]

I don't know the process for asking for project resources and commit access.

The thread on the development list remained unanswered:

http://groups.google.com/group/trac-dev/browse_frm/thread/3f749fb8ebcad0cd

I rate this as an negative response, but would really need an concrete answer.

It should be clear that trac needs some more core developers which do full-time coding work.

[ilias@…]

answered within the mailinglist topic.

thanks for the reply.

[sid <sid.wiesner@…>]

fixed status is only used if there was a code change.

[ilias@…]

Replying to sid <sid.wiesner@gmail.com>:

fixed status is only used if there was a code change.

"fixed" is a "resolution", not a status.

so, it seems that there's a need for a resolution to closed tickets where something was done none-related to code.

[eblot]

Replying to ilias@lazaridis.com:

"fixed" is a "resolution", not a status.

Trac project follows this rule since the beginning. So maybe it does not match your taste/expectation/mind/whatever, but till the team decides to use another status (IMHO, we don't need one), please stick to the rules.

[ilias@…]

Replying to eblot:

Replying to ilias@lazaridis.com:

"fixed" is a "resolution", not a status.

Trac project follows this rule since the beginning. So maybe it does not match your taste/expectation/mind/whatever, but till the team decides to use another status (IMHO, we don't need one), please stick to the rules.

I assume you mean till the team decides to use another "resolution".

I will maybe 'stick to rules' which are publically written down within the project-documentation. Please point me to those rules.

This is not about my "taste/expectation/mind/whaterver", but about simple english and validity of query results. This ticket is not an invalid one, thus closing it as invalid provides false information (e.g. within a ticket query grouped by resolution).

A thin detail, but those thin details make a tool to become a professional one.

(It could be possibly be resolved as "duplicate", as it was solved in the duplicate thread dealing with this issue)

[eblot]

Replying to ilias@lazaridis.com:

(It could be possibly be resolved as "duplicate", as it was solved in the duplicate thread dealing with this issue)

I don't mind: the status of this ticket is not fixed as sid already pointed out, so re-open the ticket and close it with another status, but do not use fixed as this is reserved for tickets tied to a code change.

[ilias@…]

Replying to eblot:

Replying to ilias@lazaridis.com:

(It could be possibly be resolved as "duplicate", as it was solved in the duplicate thread dealing with this issue)

I don't mind: the status of this ticket is not fixed as sid already pointed out, so re-open the ticket and close it with another status, but do not use fixed as this is reserved for tickets tied to a code change.

placing such a strict rule without an option for non-code-fix resolution is nonsense. - think about it.

closing as duplicate, issue was addressed here

[sid]

I've started the TracTicketTriage page where we can document the Trac project conventions for ticket management.

[ilias@…]

Replying to sid:

I've started the TracTicketTriage page where we can document the Trac project conventions for ticket management.

very nice!

related ticket: #4212

[mgood]

This is not a "duplicate" since there is no duplicate ticket filed in Trac. This should be resolved as "wontfix" since the request was rejected in the MailingList thread.