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.
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.
What do others have in mind to include in the release? The question isn't only for current committers
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. :)
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 !
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 !
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
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!