Roadmap to Trac 1.2

[Ryan Ollos]

It seems like a good time to discuss what we plan to deliver for Trac 1.2, and when we will deliver it. So far I see one big feature, and some components that have been significantly improved:

 - Enhanced notification system

 - Time custom fields
 - Numerous minor enhancements to the TracWorkflow

We've dropped support for Python 2.5 and removed a lot of deprecated code from the API, which will make Trac easier to develop going forward. There have been numerous minor enhancements to functionality, lots of tidying of the user interface and I like the improvements that Christian has been working on for the ticket changelog view. It's always nice to have a new look for pages when we push out a new release.

In addition to the tickets currently assigned to 1.0.4 and 1.1.4, there are a few key features that I'd like to implement for 1.2:

 - #11469: Custom field admin panel

 - #1233: Components and Versions become first-class objects in the TicketSystem with their own Roadmap-like pages, TracLinks, macros, permissions, ...

 - #3098: Repository README rendering

Some other features that have been worked and look promising for inclusion in the release are:

 - PyGit2 plugin

 - #8172: Plugin db upgrade infrastructure

 - #10672: Automatically minify Javascript and CSS
 - #11676: Reusable commenting module

What do others have in mind to include in the release? The question isn't only for current committers, but I'm hoping to hear from people that would be willing to step up and implement the changes as opposed to "please include feature X".

With a bimonthly release schedule, the next two releases will be:

March 1: 1.0.4 and 1.1.4

May 1: 1.0.5 and 1.1.5

I'd like to see 1.1.5 be released as 1.2, but if we aren't ready by May 1st, then release 1.2 on July 1st along with 1.0.6. After that I'm hoping we can release the minor versions on yearly intervals, which would be every 6th maintenance release.

Somewhere in there we should release Trac 0.12.7 as well, after pulling the latest translations from Transifex for several languages.

Looking forward to 1.2, is it too early to think about dropping support for Python 2.6 and support Python 2.7 and 3.3+ from a single codebase? As we get close to releasing 1.2 I'll raise another thread to talk about what features we have in mind for development in the 1.3.x line.

Finally, we still need a codename for the release, so that is something to think about as well.

http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.1#CodeName

I'm looking forward to hearing comments, and excited to push out some more releases!

- Ryan

[Leho Kraav]

On 21.01.2015 09:00, Ryan Ollos wrote:
> - #10672: Automatically minify Javascript and CSS
>

> What do others have in mind to include in the release? The question
> isn't only for current committers, but I'm hoping to hear from people
> that would be willing to step up and implement the changes as opposed to
> "please include feature X".
>

Would the CSS / JS enqueue system be able to gain a "handle" parameter?
This makes it simple for multiple plugins to set-up each others
resources for dependencies (a la "load this custom JS file only after
jquery-textcomplete is loaded") + also dequeue stuff occasionally in
favor of using your own updated JS library or similar.


References

https://codex.wordpress.org/Function_Reference/wp_enqueue_script
https://codex.wordpress.org/Function_Reference/wp_enqueue_style

[Christopher Nelson]

> ...

> In addition to the tickets currently assigned to 1.0.4 and 1.1.4, there are
> a few key features that I'd like to implement for 1.2:
> - #11469: Custom field admin panel
> - #1233: Components and Versions become first-class objects in the
> TicketSystem with their own Roadmap-like pages, TracLinks, macros,
> permissions, ...
> - #3098: Repository README rendering
>
> Some other features that have been worked and look promising for inclusion
> in the release are:
> - PyGit2 plugin
> - #8172: Plugin db upgrade infrastructure
> - #10672: Automatically minify Javascript and CSS
> - #11676: Reusable commenting module
>
> What do others have in mind to include in the release? The question isn't
> only for current committers, but I'm hoping to hear from people that would
> be willing to step up and implement the changes as opposed to "please
> include feature X".

http://trac.edgewall.org/ticket/10983 is important to me. If the
patch needs rework, I'd be happy to do that.

> > ...

[Greg Troxel]

Ryan Ollos <rjo...@gmail.com> writes:

> It seems like a good time to discuss what we plan to deliver for Trac 1.2,
> and when we will deliver it. So far I see one big feature, and some
> components that have been significantly improved:

The two things that I'd like to see long term (separate from what should
be in 1.2 or when there will be code) are:

Integration of ticket dependencies into the base; this seems too
fundamental to make optional. There are two kinds of dependencies:
one is parent/child for hierarchical WBS (for task/enhancement
tickets), and the other is blocking (for those, or for defects). With
mastertickets you can one or the other, or have it be a little
confused and do both.

Change of scheme to store numbers as numbers, rather than as strings,
and generally to thereby use database consistency checking.

> Looking forward to 1.2, is it too early to think about dropping support for
> Python 2.6 and support Python 2.7 and 3.3+ from a single codebase? As we
> get close to releasing 1.2 I'll raise another thread to talk about what
> features we have in mind for development in the 1.3.x line.

From the pkgsrc viewpoint, dropping 2.6 is fine, as 2.6 is getting
pretty crufty.

[Ryan Ollos]

On Wed, Jan 21, 2015 at 7:17 AM, Greg Troxel <g...@ir.bbn.com> wrote:

Ryan Ollos <rjo...@gmail.com> writes:

> It seems like a good time to discuss what we plan to deliver for Trac 1.2,
> and when we will deliver it. So far I see one big feature, and some
> components that have been significantly improved:

The two things that I'd like to see long term (separate from what should
be in 1.2 or when there will be code) are:

  Integration of ticket dependencies into the base; this seems too
  fundamental to make optional.  There are two kinds of dependencies:
  one is parent/child for hierarchical WBS (for task/enhancement
  tickets), and the other is blocking (for those, or for defects).  With
  mastertickets you can one or the other, or have it be a little
  confused and do both.

That is one of the features I have in mind for development in 1.3.x. The BloodhoundRelationsPlugin looks promising for backporting into Trac.
http://trac.edgewall.org/ticket/31#comment:180

[Christopher Nelson]

On Wed, Jan 21, 2015 at 10:17 AM, Greg Troxel <g...@ir.bbn.com> wrote:
> The two things that I'd like to see long term (separate from what should
> be in 1.2 or when there will be code) are:
>
> Integration of ticket dependencies into the base; this seems too
> fundamental to make optional. There are two kinds of dependencies:
> one is parent/child for hierarchical WBS (for task/enhancement
> tickets), and the other is blocking (for those, or for defects). With
> mastertickets you can one or the other, or have it be a little
> confused and do both.

>...

We use MasterTickets for blocking and Subtickets for WBS. It works
quite well for us. Though I agree core support would be preferable.

[Ryan Ollos]

On Wed, Jan 21, 2015 at 7:17 AM, Greg Troxel <g...@ir.bbn.com> wrote:

Ryan Ollos <rjo...@gmail.com> writes:

> It seems like a good time to discuss what we plan to deliver for Trac 1.2,
> and when we will deliver it. So far I see one big feature, and some
> components that have been significantly improved:

The two things that I'd like to see long term (separate from what should
be in 1.2 or when there will be code) are:

  Integration of ticket dependencies into the base; this seems too
  fundamental to make optional.  There are two kinds of dependencies:
  one is parent/child for hierarchical WBS (for task/enhancement
  tickets), and the other is blocking (for those, or for defects).  With
  mastertickets you can one or the other, or have it be a little
  confused and do both.

  Change of scheme to store numbers as numbers, rather than as strings,
  and generally to thereby use database consistency checking.

There are many columns in the database that store values as int and int64. Do you have some specific fields in mind?
http://trac.edgewall.org/browser/trunk/trac/db_default.py
 

[Greg Troxel]

Ryan Ollos <rjo...@gmail.com> writes:

>> Change of scheme to store numbers as numbers, rather than as strings,
>> and generally to thereby use database consistency checking.
>>
> There are many columns in the database that store values as int and int64.
> Do you have some specific fields in mind?
> http://trac.edgewall.org/browser/trunk/trac/db_default.py

I think I really meant ticket_custom, which loses type safety for pretty
much everything that isn't a string.

[Ryan Ollos]

Thanks, I'll take a look in a few days and follow-up in the ticket if it looks like there are any issues remaining with the patch.

[Ryan Ollos]

It looks like #10040 has a patch for the behavior you are requesting:
http://trac.edgewall.org/ticket/10040

[Greg Troxel]

That looks like an improvement, but I'd like to see integers be integers
in the database, so that custom sql queries can sort on them, inside or
outside of trac. But I admit that I am just making observations and
not offering running code

[falkb]

Am Mittwoch, 21. Januar 2015 08:00:32 UTC+1 schrieb RjOllos:
 

What do others have in mind to include in the release? The question isn't only for current committers

 I'd like to see the ticket field "project" as standard field. This would make it much easier for the multiproject plugin to integrate. I cannot promise to implement that plugin code for the Trac core due a big lack of time and knowledge about the core. But doing so would a huge pro to push Trac as alternative to Redmine and all those tools. Furthermore, I recommend to drop the idea of combining several Trac instances to a Meta-Trac in favour to the SingleEnvironment approach which fits the need of 95% of all users.

CU, F@lk

[Peter Suter]

On 21.01.2015 08:00, Ryan Ollos wrote:
> Some other features that have been worked and look promising for
> inclusion in the release are:
> - PyGit2 plugin
> - #8172: Plugin db upgrade infrastructure
> - #10672: Automatically minify Javascript and CSS
> - #11676: Reusable commenting module

I neglected this a bit, focusing more on notifications. It might be good
to include new interfaces and DB tables in at least one development
release (i.e. 1.1.x or 1.3.x etc.) before freezing them for long-term
compatibility in a stable release (like 1.2).

> What do others have in mind to include in the release? The question
> isn't only for current committers, but I'm hoping to hear from people
> that would be willing to step up and implement the changes as opposed to
> "please include feature X".

The other notification improvements might keep me be busy for a bit.

> I'd like to see 1.1.5 be released as 1.2, but if we aren't ready by May
> 1st, then release 1.2 on July 1st along with 1.0.6. After that I'm
> hoping we can release the minor versions on yearly intervals, which
> would be every 6th maintenance release.

Sounds great.

> Looking forward to 1.2, is it too early to think about dropping support
> for Python 2.6 and support Python 2.7 and 3.3+ from a single codebase?

Has anyone tried Trac on Python 3?
On #10083 I see SVN and HG will be "unlikely". I guess that's less
important now that Git is so popular.
http://trac.edgewall.org/ticket/10083

For HG a command-server backend would be an interesting option.
http://trac.edgewall.org/ticket/10411

Trac 1.0 still supports Python 2.5. Maybe Trac 1.2 should still support
Python 2.6?

> Finally, we still need a codename for the release, so that is something
> to think about as well.
> http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.1#CodeName

Added my suggestion. :)

--
Peter

[Ryan Ollos]

Yeah I think that Trac 1.2 will support Python 2.6. However, as soon as 1.2 is released we start development on the 1.3.x line and we'll need to decide what to support in 1.3.x, which determines what will be supported in 1.4.

Even if we don't officially support Python 3.3+ for Trac 1.4, dropping support for 2.6 should allow us to start making more modifications that will lead to a smoother transition to supporting 3.3+. I haven't looked closely at the specifics though.

 

Finally, we still need a codename for the release, so that is something
to think about as well.
http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.1#CodeName

Added my suggestion. :)

Looks like we have a few choices now. I think we should give the "old guard" (Jonas, Christian, Remy) the first shot at picking the name. If they don't want to make the choice, we could hold a vote in a trac-dev thread.

 

[Remy Blank]

Ryan Ollos wrote on 2015-01-22 20:58:
> Looks like we have a few choices now. I think we should give the "old
> guard" (Jonas, Christian, Remy) the first shot at picking the name.

Now I feel *really* old. The good news is, Christian is even older than
me :)

I didn't even know we had code names, so feel free to pick anything you
like. He who does the work, gets to choose the name.

-- Remy

[figaro]

Planning to do the following, which is incidentally not tied to any release:

- Updates to user documentation: Trac wiki and trac-hacks

- API documentation

- Ticket triage

- Functional testing of development releases

[Mael Lavault]

How about having an official Docker image in library on docker hub ?

[Mael Lavault]

How about having an official Docker image in library on docker hub ?

I will try to provide a Dockerfile, I dont see any blockers, should be quite easy.

I'll investigate on how to get accepted on Docker hub !

Thx !

Le mercredi 21 janvier 2015 08:00:32 UTC+1, RjOllos a écrit :

[RjOllos]

On Wednesday, June 24, 2015 at 9:06:59 AM UTC-7, Mael Lavault wrote:

How about having an official Docker image in library on docker hub ?

I will try to provide a Dockerfile, I dont see any blockers, should be quite easy.

I'll investigate on how to get accepted on Docker hub !

Thx !

Thanks. I haven't used Docker, but I'm looking forward to trying it out using your configuration file. I imagine it is something we could include in the "contrib" directory of the Trac distribution.

- Ryan 

[Mael Lavault]

Just a quick question, does trac allow to be configured by environment variables ? It would greatly simplify Docker packaging. If not I will have to write a script that convert env var into corresponding ini file properties.

Thx !

[Ryan Ollos]

On Mon, Jun 29, 2015 at 8:39 AM, Mael Lavault <moi...@gmail.com> wrote:

Just a quick question, does trac allow to be configured by environment variables ? It would greatly simplify Docker packaging. If not I will have to write a script that convert env var into corresponding ini file properties.

Thx !

I think it's not possible yet, but discussed in this ticket:

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

- Ryan 

[RjOllos]

I'm very interested in making Trac easier to install. If you can describe or point to resources that would help with understanding any changes that need to be made in order to package Trac in Docker, please do! I'd like to better understand why Docker would need to work with environment variables rather than a config.

- Ryan 

[Mael Lavault]

Ok, so a bit of context to better explain what is needed :)

Docker containers must be stateless, meaning that every installation specific configuration must be passed to Docker container at runtime.

The way Docker choose to do so, is by passing environment variables to the Docker container through different way (either command line, or yaml file with compose, or env file, ... that's not really your concern as app developer).

This means that ideally, every configuration key present in trac.ini should be overridable by env var (to begin you could just have the most important stuff that vary from one install to another like user/pass/db_host, ... that kind of stuff).

You can take a look at what spring boot do, feedbin is also a good example (and ruby app in general seems to use env var a lot by default) https://github.com/feedbin/feedbin

This mechanism could be directly bundled in trac core or, what some docker container do for app not conceived to get their conf via env var, have a startup script that convert env var passed to docker container to trac.ini keys for example.

Hope I am clear enough, do not hesitate to ask if something is unclear or if you want more details.

We are running a lot of webapps, in Docker container in our company and it is really a pleasure to work with, since we do not have to care about dependencies, os / version compatibility. It only takes a few seconds to have the app up and running.

Maël Lavault

[RjOllos]

On Thursday, July 23, 2015 at 12:48:43 AM UTC-7, Mael Lavault wrote:

Ok, so a bit of context to better explain what is needed :)

Docker containers must be stateless, meaning that every installation specific configuration must be passed to Docker container at runtime.

The way Docker choose to do so, is by passing environment variables to the Docker container through different way (either command line, or yaml file with compose, or env file, ... that's not really your concern as app developer).

This means that ideally, every configuration key present in trac.ini should be overridable by env var (to begin you could just have the most important stuff that vary from one install to another like user/pass/db_host, ... that kind of stuff).

You can take a look at what spring boot do, feedbin is also a good example (and ruby app in general seems to use env var a lot by default) https://github.com/feedbin/feedbin

This mechanism could be directly bundled in trac core or, what some docker container do for app not conceived to get their conf via env var, have a startup script that convert env var passed to docker container to trac.ini keys for example.

Hope I am clear enough, do not hesitate to ask if something is unclear or if you want more details.

We are running a lot of webapps, in Docker container in our company and it is really a pleasure to work with, since we do not have to care about dependencies, os / version compatibility. It only takes a few seconds to have the app up and running.

Maël Lavault

Thank you for the explanation. I think we can investigate a solution in #11339, but I'm not sure that will happen before the 1.2 release. You may want to follow the ticket.

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

[Tim Graham]

Hi Ryan, could you give an update on the release of Trac 1.2? I see some discussion on https://trac.edgewall.org/ticket/12120 but a high level update to this mailing list would be great. If you list the remaining tasks, maybe some other people would help chip in if you're overloaded. Thanks!

[RjOllos]

On Wednesday, August 3, 2016 at 12:02:12 PM UTC-7, Tim Graham wrote:

Hi Ryan, could you give an update on the release of Trac 1.2? I see some discussion on https://trac.edgewall.org/ticket/12120 but a high level update to this mailing list would be great. If you list the remaining tasks, maybe some other people would help chip in if you're overloaded. Thanks!

Someone could look at resolving issues with jQuery 1.12.4, described in #12348 (1). I haven't looked closely at it. Usually we update to the latest jQuery before releasing. 

Other than that, we are fixing some issues with recent changes to the database API and should be ready to prepare the release candidate for 1.2.

Work towards 1.3.1 has already started on the trunk, if that is what you are interested in.

- Ryan

(1) https://trac.edgewall.org/ticket/12348