a release now would be great! i think alone genshi and pygments
deserve a release ... even more as the impact on plugins quite big.
what would happen if 0.11 gets released immediately and the branch
merges happen immediately afterwards?
-solo.
On 1/14/07, Christian Boos <[EMAIL PROTECTED]> wro
Hi,
A few updates on the topic, as I really want to get through this.
I'm willing to make changes as needed, but for that, I first need to
better understand cmlenz concerns.
Christian Boos wrote:
> Christopher Lenz wrote:
>
>> [...]
>> self_href() is an *awful* name. Even after reading the d
Christopher Lenz wrote:
> Am 20.01.2007 um 09:36 schrieb Christian Boos:
>
>> Christopher Lenz wrote:
>>
>>> I'm not yet entirely sure I like a number of aspects of the design.
>>> Some of my concerns are actually about the wiki-contextstuff that
>>> trac.resource is based upon... I n
Am 20.01.2007 um 09:36 schrieb Christian Boos:
> Christopher Lenz wrote:
>> I'm not yet entirely sure I like a number of aspects of the design.
>> Some of my concerns are actually about the wiki-contextstuff that
>> trac.resource is based upon... I need to catch up a bit, here.
>
> Then be s
Christopher Lenz wrote:
>
> Am 19.01.2007 um 22:41 schrieb Christian Boos:
>> ... I'm now proposing to merge these changes to the trunk
>
> Please give me a couple more days to review and provide feedback on
> that branch.
No problem.
> I'm not yet entirely sure I like a number of aspects of
> That way a user can individually grant attachment permissions on
> different parent objects. Actually, thinking about it, this will
> alleviate the need for an ATTACH permission altogether, as "CREATE" in
> the wiki:attachment security realm would provide this permission.
>
This could immediate
Am 19.01.2007 um 22:41 schrieb Christian Boos:
Christian Boos wrote:
... The current API looks quite fine to me, and behaves quite well
And I just fixed the remaining unit-tests and merged with latest
trunk, so I'm now proposing to merge these changes to the trunk:
http://trac.edgewall.or
Christian Boos wrote:
... So I think the original goals of the PermissionPolicy plan can be
fulfilled,
(see http://trac.edgewall.org/wiki/PermissionPolicy?version=20)
... The current API looks quite fine to me, and behaves quite well
And I just fixed the remaining unit-tests and merged wi
Alec Thomas wrote:
...
because the attachment module and its parent are co-reliant.
To make this work we'll need to have "sub-realms" for each realm that
supports attachments.
eg.
wiki
wiki//attachment
ticket//attachment
(or whatever syntax is decided on for separating
Manuzhai wrote:
...
I just always get confused when there's a notice about a merge
(whether it is about merging the branch up to latest trunk or merging
the branch *to* the trunk).
A notice on the mailing list or in changesets?
When we mention a merge here, it's always about merging the featu
On 1/14/07, Christian Boos <[EMAIL PROTECTED]> wrote:
Not really... there's still:
* Use setuptools for setup (see [source:sandbox/setuptools])
* ''Refactoring of the Mimeview API (see #3332,
[source:sandbox/mimeview])''
* ''Flexible/extensible ticket workflow (see WorkFlow,
[source:sandbox/
Manuzhai wrote:
On 1/12/07, Christian Boos <[EMAIL PROTECTED]> wrote:
So again, about the merge in trunk:
- I'd like we sort out the above first
- I'd like to merge my 3 other branches (blame and the 2 -tmp ones)
before ;)
And after that, maybe there should be some effort towards re
(Replying to myself more as a log of ideas :))
On Sat, Jan 13, 2007 at 07:31:08PM +1100, Alec Thomas wrote:
> Once the permissions are more uniform, we can begin removing the
> reliance on having a permission for each action on each object and move
> to a small set of permissions:
>
> VIEW
>
On 1/12/07, Christian Boos <[EMAIL PROTECTED]> wrote:
> So again, about the merge in trunk:
> - I'd like we sort out the above first
> - I'd like to merge my 3 other branches (blame and the 2 -tmp ones)
> before ;)
And after that, maybe there should be some effort towards releasing
0.11? It see
On Thu, Jan 11, 2007 at 05:36:01PM +0100, Christian Boos wrote:
> In particular, I'd like to see how we'll convert the attachment module,
> in a way that would allow generic attachments (see #3068). This
> shouldn't require any additional interface (i.e. /not/ the
> IAttachmentPointProvider way
On Fri, Jan 12, 2007 at 08:03:47PM +0100, Christian Boos wrote:
>
> A quick follow-up, I've implemented the above ideas in r4556 (which also
> finishes the renaming started in r4552).
> This also reverted r4551 for the reasons explained in the previous mail.
Excellent. Looks good to me :)
> ..
A quick follow-up, I've implemented the above ideas in r4556 (which also
finishes the renaming started in r4552).
This also reverted r4551 for the reasons explained in the previous mail.
Christian Boos wrote:
> ...
> class Resource(object):
> """Base class for resources."""
>
> realm =
Alec Thomas wrote:
> On Fri, Jan 12, 2007 at 09:56:57AM +1100, Alec Thomas wrote:
page = WikiPage(env, 'WikiStart')
context = Context.from_resource(env, req, page)
>>> ... or simply `context = page.get_context(req)`, instead of the more
>>> complex hops through the IReso
On Fri, Jan 12, 2007 at 09:56:57AM +1100, Alec Thomas wrote:
> > > page = WikiPage(env, 'WikiStart')
> > > context = Context.from_resource(env, req, page)
> > ... or simply `context = page.get_context(req)`, instead of the more
> > complex hops through the IResourceMapper implemen
On Thu, Jan 11, 2007 at 08:10:03AM -0800, John Hampton wrote:
> If I get some time, I'll try to test out the branch.
That would be much appreciated, thanks :)
--
Evolution: Taking care of those too stupid to take care of themselves.
--~--~-~--~~~---~--~~
You re
On Thu, Jan 11, 2007 at 05:36:01PM +0100, Christian Boos wrote:
> +1, that could be done ASAP on trunk, together with the move to
> trac.resource, I think.
Excellent.
> In particular, I'd like to see how we'll convert the attachment module,
> in a way that would allow generic attachments (see
Alec Thomas wrote:
> I've recently (re)started work on the security branch [1], using
> Christian's recent Context additions. Given that the Context contains all
> of the information necessary to enforce a policy decision, I think this
> is a good approach.
>
> In the security sandbox I've made a
While I haven't actually tested the code, I'd love to see the security
branch be merged sooner, rather than later, as I am chomping at the bit
for the functionality.
If I get some time, I'll try to test out the branch.
-John
--~--~-~--~~~---~--~~
You receive
23 matches
Mail list logo
