Developer mailing list for the Trac Project

Christian Boos | 3 Jun 2012 20:38

Picon

[Trac-dev] Next steps towards 1.0

Hello,

Things were very quiet from my side these past months, but I intend to 
progressively come back to a more intensive participation.

Among the first steps I'd like to take would be to work towards a 
1.0beta1 release (as it's going to be 1.0 and not 0.13, remember? see 
[1] if not  )

We have a pretty good state on trunk, and though it feels a bit 
unfinished here and there, I think it's at least as good as 0.12-stable 
stability wise, so why not get more exposure for the new features and 
APIs? We can always make things a bit better and more polished in a 
later 1.0.x maintenance release.

One big reorganization that I think would still be important to do even 
before the beta1 is the move of the svn support to tracopt. Now that we 
have Git support there, there's no reason to keep svn directly in 
trac/versioncontrol (see [2]). I think we can leave around a few imports 
for backward compatibility. I created #10712 for that.

Besides that, I'll go through some of the pending patches that can 
finished soon, then upgrade the version numbers, prepare the beta 
release and get some feedback from the field.

And then, what I'd really like to finish before the final 1.0 are the 
other tickets listed in TracDev/ToDo#Trac1.0.

That's the plan so far

(Continue reading)

Peter Stuge | 4 Jun 2012 10:53

Picon

Re: [Trac-dev] Next steps towards 1.0

Christian Boos wrote:
> One big reorganization that I think would still be important to do even 
> before the beta1 is the move of the svn support to tracopt. Now that we 
> have Git support there, there's no reason to keep svn directly in 
> trac/versioncontrol (see [2]). I think we can leave around a few
> imports for backward compatibility. I created #10712 for that.

IMO the current PyGIT isn't really suitable for a 1.0 release. :)
I've started work on a pygit2 based replacement, but am in the middle
of an interrupt storm at the moment, keeping me busy elsewhere. I'd
be happy if someone else wants to also work with this.

It would be very nice to have it included at least as an alternative.

Also, while doing this, I've understood just how badly the Git data
model fits into Trac's Repository data model. :\

The get_youngest_rev(), previous_rev() and child_revs() Repository
operations are very very expensive; they require traversing the
entire commit graph!

//Peter

--

-- 
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.

(Continue reading)

Christian Boos | 4 Jun 2012 22:32

Picon

Re: [Trac-dev] Next steps towards 1.0

On 6/4/2012 10:53 AM, Peter Stuge wrote:
> Christian Boos wrote:
>> One big reorganization that I think would still be important to do even
>> before the beta1 is the move of the svn support to tracopt. Now that we
>> have Git support there, there's no reason to keep svn directly in
>> trac/versioncontrol (see [2]). I think we can leave around a few
>> imports for backward compatibility. I created #10712 for that.
>
> IMO the current PyGIT isn't really suitable for a 1.0 release. :)

Well, we can label the git support as "experimental", like we did for 
the Mercurial support until it got improved to the point it is now able 
to handle huge repositories reasonably well. Note that you'll get 
similar performance issues for big Subversion repositories, as our svn 
support is also not lightning fast... This, as well as the numerous 
other known performance weak points (*) won't prevent us to make a 1.0 
release, as we're mainly doing it 1) for having a fresh start for a new 
release schedule (i.e. doing regular releases for both maintenance and 
development branches) and 2) to acknowledge the fact that after many 
years of continuous improvement, it's now more than reasonably stable 
and solid. We don't use 1.0 to mean it's perfect on all accounts (that 
will be 2.0!  ).

> I've started work on a pygit2 based replacement, but am in the middle
> of an interrupt storm at the moment, keeping me busy elsewhere. I'd
> be happy if someone else wants to also work with this.
>

I'd be happy to have a look, and experiment a bit. A fork and a few 
instructions about how to set up the dependencies would be a good start

(Continue reading)

Peter Stuge | 5 Jun 2012 03:10

Picon

Re: [Trac-dev] Next steps towards 1.0

Christian Boos wrote:
>> IMO the current PyGIT isn't really suitable for a 1.0 release. :)
>
> Well, we can label the git support as "experimental"

Please include a prominent note about the moderate performance,
and/or mention that PyGIT works by forking and execing many git
processes per web request.

>> I've started work on a pygit2 based replacement
>
> I'd be happy to have a look, and experiment a bit.

http://git.stuge.se/?p=trac.git

> instructions about how to set up the dependencies would be a good start

http://libgit2.github.com/
https://github.com/libgit2/pygit2

They have no further dependencies. Both are possibly packaged in your
favorite distribution already. If you use Gentoo you can run

layman -a stuge && \
  echo -e 'dev-libs/libgit2 **\ndev-python/pygit2 **' >> \
  /etc/portage/package.keywords && \
  emerge =dev-libs/libgit2-9999 =dev-python/pygit2-9999

to get live ebuilds.

(Continue reading)

Niels Sascha Reedijk | 17 Jun 2012 12:52

Picon

Re: [Trac-dev] Next steps towards 1.0

Hi,

I would like to comment from the sidelines. At the Haiku project we
run one of these huge Git repositories, and for us currently the
trac-gitplugin is unusable. I myself have done some work and research
into getting insight into why this is, I have found that the main
issue is that the information that Trac wants to display is not by any
means efficiently retrievable due to the way the Git data model is
designed.

On Tue, Jun 5, 2012 at 3:10 AM, Peter Stuge <peter <at> stuge.se> wrote:
>>> The get_youngest_rev(), previous_rev() and child_revs() Repository
>>> operations are very very expensive; they require traversing the
>>> entire commit graph!
>>
>> That was pretty much my point in our little discussion in #10594.
>> I'm not convinced that simply switching the way we use git (command-line
>> vs. library bindings) will be enough to address the performance issues;
>
> You know that fork and exec are expensive, right? It's not cool to
> have web software work like this in 2012. It was halfway OK in 1995,
> but not anymore. :)
>
> Also, "simply" is downplaying PyGIT. Because it uses git commands it
> remains limited to what git commands can do, where the Git data model
> isn't very well exposed, nor in a manner which is very useful. It's
> all sorts of wrong.

I can concur. In my own experiments [1] I have tried to use Dulwich
[2] which is a pure-python implementation of the Git data model, and a

(Continue reading)

Remy Blank | 17 Jun 2012 23:53

Picon

Re: [Trac-dev] Next steps towards 1.0

Christian Boos wrote:
> Besides that, I'll go through some of the pending patches that can 
> finished soon, then upgrade the version numbers, prepare the beta 
> release and get some feedback from the field.

I have just updated the version numbers.

> And then, what I'd really like to finish before the final 1.0 are the 
> other tickets listed in TracDev/ToDo#Trac1.0.

I have triaged my remaining tickets for 1.0 (and fixed a few) this
week-end, and I'm down to the following:

 - http://trac.edgewall.org/ticket/7145 (concurrent edits)

I have implemented the "revert" operation for individual changes, and
I'm quite happy with the result. Patch available for review.

 - http://trac.edgewall.org/ticket/10451 (DB access in upgrade check)

Patch available for review that should at least mitigate the issue.

 - http://trac.edgewall.org/ticket/7894 (X-Sendfile)

Patch refreshed and ready for testing. Unfortunately, I still don't have
a setup to test it. I will try to set this up this week, but I won't be
angry if anyone beats me to it :) It's very low risk, as the code won't
be active if `[trac] use_xsendfile = false` (the default).

So from my side, all I need is some review and testing, and I'm done. I

(Continue reading)

Peter Stuge | 18 Jun 2012 00:10

Picon

Re: [Trac-dev] Next steps towards 1.0

Remy Blank wrote:
>  - http://trac.edgewall.org/ticket/7894 (X-Sendfile)
> 
> Patch refreshed and ready for testing. Unfortunately, I still don't have
> a setup to test it. I will try to set this up this week, but I won't be
> angry if anyone beats me to it :) It's very low risk, as the code won't
> be active if `[trac] use_xsendfile = false` (the default).

Nginx supports exactly the same thing, but using a X-Accel-Redirect
header with slightly different features.

See http://wiki.nginx.org/XSendfile and http://wiki.nginx.org/X-accel
for the documentation.

Perhaps the patch could support this too?

//Peter

Remy Blank | 18 Jun 2012 08:10

Picon

Re: [Trac-dev] Next steps towards 1.0

Peter Stuge wrote:
> Nginx supports exactly the same thing, but using a X-Accel-Redirect
> header with slightly different features.
> 
> See http://wiki.nginx.org/XSendfile and http://wiki.nginx.org/X-accel
> for the documentation.
> 
> Perhaps the patch could support this too?

Yes, I know, we discussed this on the ticket. We may support it at some
point, but it's less trivial with nginx, and currently we're trying to
close the feature set for the release, rather than adding new features.
So not for this release, sorry.

-- Remy

Brettschneider Falk | 18 Jun 2012 09:32

RE: [Trac-dev] Next steps towards 1.0

Hi,

Please, before you step to 1.0 could you insert a project_id column to most of the database tables? This way
it would be more easy to develop multi-project plugins.
At present, my team-mate and me are going on with implementing that
TracMultipleProjects/SingleEnvironment approach in
http://trac-hacks.org/wiki/SimpleMultiProjectPlugin. Because of the missing column we had to add
all those additional mapping tables project<->{resource}.

CU, F <at> lk

----
Falk Brettschneider
R&D Software
Baumer Optronic GmbH
www.baumer.com

Geschäftsführer: Marcel Seeber · Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE 189714583

--

-- 
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 | 18 Jun 2012 20:11

Picon

Re: [Trac-dev] Next steps towards 1.0

Brettschneider Falk wrote:
> Hi,
> 
> Please, before you step to 1.0 could you insert a project_id column to most of the database tables?

No, sorry. Adding a column without using and managing it doesn't make sense.

-- Remy

Peter Suter | 18 Jun 2012 21:49

Picon

Re: [Trac-dev] Next steps towards 1.0

On 17.06.2012 23:53, Remy Blank wrote:
> I'd like to ask each of the owners to go
> through your tickets in 1.0 and move those that you don't think you can
> fix within a week or two to a different milestone.

Sure. (Cheating a bit with #10594 but I really think it makes sense to 
close it.)

 > You may also want to
> browse through 1.0-triage to make sure I didn't move any important ones
> out. But please only move tickets to 1.0 if you are confident that you
> will fix them shortly.

"My" ticket here is "Add support for date type in custom ticket fields".
http://trac.edgewall.org/ticket/1942

I think the patches are good enough to be applied as they are. I could 
probably do that before the release.

But since the patches are kind of large, we could also wait until after 
the release, in case anyone wants to review, test or improve the patches 
some more.

> Oh, and one more thing: batch modifications rock! Thanks Peter for
> integrating this very useful feature.

If it helped you prepare for Trac 1.0, it has already been well worth it. :)

--
Peter

(Continue reading)

Peter Stuge | 18 Jun 2012 21:52

Picon

Re: [Trac-dev] Next steps towards 1.0

Peter Suter wrote:
>> I'd like to ask each of the owners to go
>> through your tickets in 1.0 and move those that you don't think you can
>> fix within a week or two to a different milestone.
>
> Sure. (Cheating a bit with #10594 but I really think it makes sense to 
> close it.)

I don't think it's so cool to close a ticket as fixed just because
you don't know enough to fix it. :\

I will reopen.

//Peter

--

-- 
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 | 18 Jun 2012 22:19

Picon

Re: [Trac-dev] Next steps towards 1.0

Peter Suter wrote:
> Sure. (Cheating a bit with #10594 but I really think it makes sense to 
> close it.)

The post-commit script isn't a release blocker anyway, as we can provide
it through other channels if needed. Feel free to file a new ticket
about it already now, so that we don't forget. Of course, if someone
wants to contribute a script now, to be included in 1.0, even better.

> "My" ticket here is "Add support for date type in custom ticket fields".
> http://trac.edgewall.org/ticket/1942
> 
> I think the patches are good enough to be applied as they are. I could 
> probably do that before the release.
> 
> But since the patches are kind of large, we could also wait until after 
> the release, in case anyone wants to review, test or improve the patches 
> some more.

I hesitated for a long time with #1942. As Christian mentioned, current
trunk is very stable and has been for a long time. The patches in #1942
are sufficiently large and invasive that I'm not confident that they
won't affect this stability. I would rather apply them shortly after the
release, early in the development cycle, so that they get some exposure
on trunk and any issues get ironed out.

-- Remy

Peter Suter | 19 Jun 2012 07:17

Picon

Re: [Trac-dev] Next steps towards 1.0

On 18.06.2012 22:19, Remy Blank wrote:
> The post-commit script isn't a release blocker anyway, as we can provide
> it through other channels if needed. Feel free to file a new ticket
> about it already now, so that we don't forget. Of course, if someone
> wants to contribute a script now, to be included in 1.0, even better.

Right, I created #10730.

> I hesitated for a long time with #1942. As Christian mentioned, current
> trunk is very stable and has been for a long time. The patches in #1942
> are sufficiently large and invasive that I'm not confident that they
> won't affect this stability. I would rather apply them shortly after the
> release, early in the development cycle, so that they get some exposure
> on trunk and any issues get ironed out.

OK, makes sense.

--
Peter

--

-- 
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 | 22 Jun 2012 22:59

Picon

Re: [Trac-dev] Next steps towards 1.0

Christian Boos wrote:
> And then, what I'd really like to finish before the final 1.0 are the 
> other tickets listed in TracDev/ToDo#Trac1.0.

Short status update: we're down to 6 remaining tickets, 3 of which have
patches attached. I'm looking forward to seeing these patches land on
trunk, and to finishing the other 3!

Christian, are you sure you want to move SVN support to tracopt? If so,
I can do the work, so that you get a bit more time to work on the other
tickets (yes, they're all yours ;). Did you have anything special in
mind about backward compatibility? Keep stub modules in the old
locations, and import the global namespace from the new modules?

-- Remy

Christian Boos | 23 Jun 2012 00:11

Picon

Re: [Trac-dev] Next steps towards 1.0

On 6/22/2012 10:59 PM, Remy Blank wrote:
> Christian Boos wrote:
>> And then, what I'd really like to finish before the final 1.0 are the
>> other tickets listed in TracDev/ToDo#Trac1.0.
>
> Short status update: we're down to 6 remaining tickets, 3 of which have
> patches attached. I'm looking forward to seeing these patches land on
> trunk, and to finishing the other 3!

Yes! Great work from you, and also thanks to Jun and Peter who have been 
responsive.

>
> Christian, are you sure you want to move SVN support to tracopt?

Yes, I think the switch to 1.0 is also a good time to show that svn has 
no longer a "privileged" place within Trac, and is just one (optional) 
system supported among others.

> If so,
> I can do the work, so that you get a bit more time to work on the other
> tickets (yes, they're all yours ;).

Thanks! Indeed haven't started anything in this area, so your help will 
be welcome.

> Did you have anything special in
> mind about backward compatibility? Keep stub modules in the old
> locations, and import the global namespace from the new modules?

(Continue reading)

Return

Return to gmane.comp.version-control.subversion.trac.devel.

Project Web Page

Developer mailing list for the Trac Project

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane