headers
Christian Boos | 2 Mar 2012 23:44
Picon
Favicon

Re: [Trac-dev] New release policy of trunk

To hopefully conclude with this thread...

I just stumbled upon the recent release history of NGINX,
and that's very close to what I'd like to see in Trac:

2012-02-29	nginx-1.1.16 development version has been released.
2012-02-15	nginx-1.1.15 development version has been released.
2012-02-06	nginx-1.0.12 stable version has been released.
2012-01-30	nginx-1.1.14 development version has been released.
2012-01-16	nginx-1.1.13 development version has been released.
2011-12-26	nginx-1.1.12 development version has been released, 
introducing cache lock support and PCRE JIT support.
2011-12-15	nginx-1.0.11 stable version has been released.
2011-12-12	nginx-1.1.11 development version has been released.
2011-11-30	nginx-1.1.10 development version has been released.
2011-11-28	nginx-1.1.9 development version has been released.

(as seen on http://nginx.org)

i.e two 1.0.y minor stable versions released, interspersed in the 
release of many 1.1.y minor development versions.

On 2/22/2012 10:34 PM, Remy Blank wrote:
 > Christian Boos wrote:
 >> 2) Linux<  2.6 style:
 >>      - 0.12 LTS, with 0.12.{1,2,3,4,...}
 >>      - 0.13 "unstable", with 0.13.{1,2,3,...}
 >>        when 0.13.y is deemed stable it becomes 0.14
 >>      - 0.14 LTS (...)
 >
(Continue reading)

Permalink | Reply | 6 comments |
headers
Remy Blank | 3 Mar 2012 05:25
Picon
Favicon

Re: [Trac-dev] New release policy of trunk

Christian Boos wrote:
> So if everyone is OK with transitioning to that model, we could do it 
> this way:

Go for it ;)

-- Remy
Permalink | Reply | 0 comments |
headers
Peter Suter | 3 Mar 2012 08:51
Picon

Re: [Trac-dev] New release policy of trunk

On 02.03.2012 23:44, Christian Boos wrote:
> So if everyone is OK with transitioning to that model, we could do it
> this way:

+1

--
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.
Permalink | Reply | 4 comments |
headers
Remy Blank | 3 Mar 2012 17:23
Picon
Favicon

[Trac-dev] Re: Future of git-plugin

(CC: to trac-dev, we want to have such discussions in public.)

Peter Suter wrote:
> I think it would be great if we could include this plugin in Trac. 
> (Would be a nice "bonus" for Trac 1.0 :)

Yes, that would be awesome.

> While I'm not much of a git user, I'd like to know if there's anything I 
> could do to help. I'd (naively) expect the next steps are something like:
> 
>   * Commit that snapshot to SVN to 
> https://svn.edgewall.org/repos/trac/plugins/0.13/git-plugin/ or 
> https://svn.edgewall.org/repos/trac/trunk/tracopt/versioncontrol/git/

I'm not sure either what the best location would be. The Mercurial
plugin has to be separate from Trac itself due to the license, but this
wouldn't need to be the case for the Git plugin. So "tracopt" would be
the simplest for our users, and they would have it installed already and
would only need to enable it.

If we do that, we could also move `svn_fs.py` out of
`trac.versioncontrol` and into `tracopt.versioncontrol`, for consistency.

Just make sure you do each step in a separate changeset, so that we can
easily roll back one or the other if necessary. In particular, the
initial import should add the files from the git repository unchanged,
so that all diffs against the original are explicitly visible.

> * Adjust the license file headers somehow? (future27.py has a strange one)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Suter | 3 Mar 2012 18:28
Picon

[Trac-dev] Re: Future of git-plugin

On 03.03.2012 10:48, Herbert Valerio Riedel wrote:
> Just wondering, isn't the mercurial plugin self-hosted on t.e.o as a
> mercurial repo?

I don't think so. Would be nice to have though.

But as Remy pointed out, the Git plugin would be included in the Trac 
GitHub mirror [1] automatically (if we include it under 'tracopt' 
instead of under 'plugins' in SVN).

--
Peter

[1] https://github.com/edgewall/trac

--

-- 
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.
Permalink | Reply | 0 comments |
headers
Peter Suter | 3 Mar 2012 18:51
Picon

[Trac-dev] Re: Future of git-plugin

On 03.03.2012 17:23, Remy Blank wrote:
 > (CC: to trac-dev, we want to have such discussions in public.)

Right, thanks!

 > This should probably include moving the few existing unit tests in
 > `future27.py` out of the `__main__` section of that file into
 > `tests/future27.py` and having it called as part of the normal unit 
tests.

I'm wondering, would it be best to drop `future27.py` entirely? It only 
defines (and tests) `namedtuple`, which is only used once to define 
`Storage.RevCache`. It seems it would be easier to define:
{{{
class RevCache(object):
     def __init__(self, youngest_rev, oldest_rev, rev_dict, tag_set,
                  srev_dict, branch_dict):
         self.youngest_rev = youngest_rev
         self.oldest_rev = oldest_rev
         self.rev_dict = rev_dict
         self.tag_set = tag_set
         self.srev_dict = srev_dict
         self.branch_dict = branch_dict

     def __iter__(self):
         yield self.youngest_rev
         yield self.oldest_rev
         yield self.rev_dict
         yield self.tag_set
         yield self.srev_dict
(Continue reading)

Permalink | Reply | 2 comments |
headers
Herbert Valerio Riedel | 3 Mar 2012 19:09
Picon
Gravatar

[Trac-dev] Re: Future of git-plugin

Peter Suter <petsuter <at> gmail.com> writes:

>> This should probably include moving the few existing unit tests in
>> `future27.py` out of the `__main__` section of that file into
>> `tests/future27.py` and having it called as part of the normal unit
>> tests.

> I'm wondering, would it be best to drop `future27.py` entirely? It
> only defines (and tests) `namedtuple`, which is only used once to
> define `Storage.RevCache`. It seems it would be easier to define:
> {{{
> class RevCache(object):
>     def __init__(self, youngest_rev, oldest_rev, rev_dict, tag_set,
>                  srev_dict, branch_dict):
>         self.youngest_rev = youngest_rev
>         self.oldest_rev = oldest_rev
>         self.rev_dict = rev_dict
>         self.tag_set = tag_set
>         self.srev_dict = srev_dict
>         self.branch_dict = branch_dict
>
>     def __iter__(self):
>         yield self.youngest_rev
>         yield self.oldest_rev
>         yield self.rev_dict
>         yield self.tag_set
>         yield self.srev_dict
>         yield self.branch_dict
> }}}
> Or is there more to it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Remy Blank | 3 Mar 2012 19:12
Picon
Favicon

Re: [Trac-dev] Re: Future of git-plugin

Peter Suter wrote:
> I'm wondering, would it be best to drop `future27.py` entirely? It only 
> defines (and tests) `namedtuple`, which is only used once to define 
> `Storage.RevCache`.

I haven't looked at the code closely, but if it's indeed the only use
case, then yes, defining the class explicitly would be even better.

> Which leaves, roughly categorized:

(... snip list ...)

> Probably we can merge some more of these as duplicates.

That's probably not enough to warrant writing an exporter and importer,
so I guess some copy / pasting of ticket descriptions is in order. Make
sure to reference the original ticket in the description of each new
one, so you don't need to copy the comments.

-- Remy
Permalink | Reply | 0 comments |
headers
Herbert Valerio Riedel | 3 Mar 2012 19:19
Picon
Gravatar

Re: [Trac-dev] Re: Future of git-plugin


> Peter Suter wrote:
>> While I'm not much of a git user, I'd like to know if there's anything I 
>> could do to help. I'd (naively) expect the next steps are something like:

>> == Wiki
>> * Create a page at http://trac.edgewall.org/wiki/TracGit or GitPlugin to 
>> document this.

...btw, someone should update http://trac-hacks.org/wiki/GitPlugin
to point/redirect to that new official wiki page when it's ready

-- 

--

-- 
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.
Permalink | Reply | 0 comments |
headers
Eduard-Cristian Stefan | 3 Mar 2012 20:39
Picon
Gravatar

[Trac-dev] Ticket #10595: [PATCH] Allow custom index page

Hi,

   I need to customize the index page location,
would you be so kind to review this patch?

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

If this one is ok, I will submit another one
to allow a custom start page.

Have a nice day,
   Eduard

--

-- 
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.
Permalink | Reply | 0 comments |

Gmane