Picon
Gravatar

[Trac-dev] Re: Following the right road


On Sep 24, 5:03 pm, Christopher Lenz <cml...@gmx.de> wrote:
> Am 24.09.2007 um 12:44 schrieb Manuzhai:
> > Rupert makes the same point I was thinking about last night (and I
> > think it merits its own thread). Now that there seems to be a
> > consensus that the road was wrong, where are we going with 0.11 now?
> > What needs to make it into 0.11, what API's need to be changed or
> > refined or scrapped, without resorting to feature creep?
>
> The most important thing we need to fix IMHO is the trac.context API,  
> and the ITimelineEventProvider/TimelineEvent API. The one feature  
> that should really be moved out into a plugin is "Clone Ticket".

which direction should it be fixed, and what would happen if it is
fixed in 0.12 not now?

rupert.

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

Christian Boos | 5 Oct 12:43
Picon

[Trac-dev] Re: Following the right road


Hi,

On Oct 5, 12:16 pm, "rupert.thur...@gmail.com"
<rupert.thur...@gmail.com> wrote:
> On Sep 24, 5:03 pm, Christopher Lenz <cml...@gmx.de> wrote:
>
> > Am 24.09.2007 um 12:44 schrieb Manuzhai:
> > > Rupert makes the same point I was thinking about last night (and I
> > > think it merits its own thread). Now that there seems to be a
> > > consensus that the road was wrong, where are we going with 0.11 now?
> > > What needs to make it into 0.11, what API's need to be changed or
> > > refined or scrapped, without resorting to feature creep?
>
> > The most important thing we need to fix IMHO is the trac.context API,
> > and the ITimelineEventProvider/TimelineEvent API. The one feature
> > that should really be moved out into a plugin is "Clone Ticket".
>
> which direction should it be fixed, and what would happen if it is
> fixed in 0.12 not now?
>

The context refactoring is progressing well, I have a working
prototype. What's still to be done is to push those changes in a
branch and justify the design the way it is. I've got time for neither
so far, but it's coming "soon".

The timeline API changes are of much smaller scope and will follow.

Then, for #4686 (Ticket cloning), it's true that it can be done as a
(Continue reading)

Christian Boos | 5 Oct 15:08
Picon

[Trac-dev] Monthly Ticket Summary (2007-10)


Hello all,

As the previous mail of that kind was well received, I've written
another report for tickets in the Trac project. I also give the
relative change since last month, in %.

== Ticket Statistics (2007-10-05) ==

On a total of 6133 tickets (+2.7%):
- 1932 tickets (+0.7%) are valid issues that have been addressed
        (i.e. closed as fixed)
- 3070 tickets (+3.5%) are closed as duplicates, wontfix, invalid and
worksforme
-  250 tickets (+12%) have been deleted (spam, offensive content,
etc.)

This leaves 866 issues opened, divided between untriaged tickets,
tickets awaiting for feedback and valid tickets (+1.7%)

- 155 tickets (-4.3%) with no Milestone            (see {20})
-  56 tickets (+9.9%) awaiting user feedback       (see {21})
- 688 valid tickets (+5.4%) with a milestone set,
   which can be further divided into:
    *  63 tickets (+3.3%) for 0.10-stable           (see {22})
    *  27 tickets (+35%) for 0.11                  (see {23})
    * 169 tickets (+1.8%) for 0.11-stable           (see {25})
    * 366 tickets (+1.4%) for future releases       (see {24})

The {x} number corresponds to a Trac report containing
(Continue reading)

Christopher Lenz | 5 Oct 19:10
Picon
Picon
Gravatar

[Trac-dev] Re: Context Refactoring


Am 27.09.2007 um 19:43 schrieb Christian Boos:
> Hm, it looks like your answer didn't cover the updated proposal of
> this morning:
>
> http://trac.edgewall.org/wiki/TracDev/ 
> ContextRefactoring#TheResourceclassforresourceidentification

To quote:

   "As fine-grained security and permission checks are becoming the  
rule in Trac, one shouldn't be able to access a resource without the  
appropriate credentials."

I *strongly* disagree with this. That *may* be something to think  
about for a future release, but most definitely not for 0.11.

And the whole concept of "resources have to be created through the  
permission system" is wrong IMO. But that's not the point. The point  
is that we should not be thinking about doing anything like that for  
0.11. Both Alec and myself have stated early on that we think this  
was out of scope for the release.

My idea (and I think I'm not alone here) was that we should go back  
and fix Context by removing/simplifying. What you're proposing here  
seems to go in a totally different direction.

> On Sep 27, 7:15 pm, Christopher Lenz <cml...@gmx.de> wrote:
>> Furthermore, I think some of the examples for resource identifiers
>> are bogus. For example, you'll *never* have something like:
(Continue reading)

mcr | 5 Oct 20:53

[Trac-dev] Re: Context Refactoring


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Christopher" == Christopher Lenz <cmlenz <at> gmx.de> writes:
   Christopher>    "As fine-grained security and permission checks are
    Christopher> becoming the rule in Trac, one shouldn't be able to
    Christopher> access a resource without the appropriate credentials."

    Christopher> I *strongly* disagree with this. That *may* be
    Christopher> something to think about for a future release, but most
    Christopher> definitely not for 0.11.

  I concur. Baby steps.
  Please release more often.

- -- 
Michael Richardson <mcr <at> xdsinc.net>
XDS Inc, Ottawa, ON             
Personal: http://www.sandelman.ca/mcr/ 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQDVAwUBRwaIFe0sRu40D6vCAQLs7gX7BXX6LKRtOBWsbDnZU+9kcQIHdNBDYXZ5
rvx2HQDLWJjXc3bYS3LIHGVbiX3LilNCsd9FLU+J1taYpl8AtNABd3rLyjv6UILH
9dF0fZuPf81KVSu5xBD5Rt7RVDAI3lEv8oRwU8d5hZWTVUT4lxrtJhxZxgUoQs8b
qqXGul+UPon9hqgYX9EcBASMnBoWINOlkKuB708QqvxwmovTth/0FYL79ZGDHPWF
YoeJi7Iz4zIoy1Scf9dhu1FrgO+HgBFN
=cGin
(Continue reading)

John Hampton | 5 Oct 23:54
Gravatar

[Trac-dev] Re: Context Refactoring


Christopher Lenz wrote:
>    "As fine-grained security and permission checks are becoming the  
> rule in Trac, one shouldn't be able to access a resource without the  
> appropriate credentials."
> 
> I *strongly* disagree with this. That *may* be something to think  
> about for a future release, but most definitely not for 0.11.

I agree that it should not be targeted for 0.11

> My idea (and I think I'm not alone here) was that we should go back  
> and fix Context by removing/simplifying. What you're proposing here  
> seems to go in a totally different direction.

That's how I feel too.

<snip mucho re: rendering contexts>

> What I meant was that I've seen examples of stuff that wouldn't ever  
> be an actual resource identifier. I may have gotten the wrong  
> impression here, or may be misremembering the examples

It would be interesting to know what examples these might be.  It would 
seem to me that most all links that are rendered would have *some* 
resource identifier behind them.

> Anyway, I strongly doubt we'll need to identify the "resource/ 
> context" in which some other resource is being rendered. The only use  
> case I can think of are relative links (as in ../foo instead of /bar/ 
(Continue reading)

Emmanuel Blot | 7 Oct 02:59
Picon
Gravatar

[Trac-dev] Re: Ticket #6139


> Anyone object to deleting this ticket and continuing on with life?
Sure not.

> I'm sure we all have better things to do and Ilias clearly hasn't changed
> his ways.
This ticket has somewhat been useful to find out if he has.

Cheers,
Manu

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

Noah Kantrowitz | 7 Oct 02:27
Picon
Favicon

[Trac-dev] Ticket #6139

Anyone object to deleting this ticket and continuing on with life? I'm
sure we all have better things to do and Ilias clearly hasn't changed
his ways. In the interests of sparing the moderation queue from his
vitriol maybe we should just outright ban him.

--Noah

Noah Kantrowitz | 7 Oct 03:10
Picon
Favicon

[Trac-dev] Re: Ticket #6139

Emmanuel Blot wrote:
>> Anyone object to deleting this ticket and continuing on with life?
>>     
> Sure not.
>
>   
>> I'm sure we all have better things to do and Ilias clearly hasn't changed
>> his ways.
>>     
> This ticket has somewhat been useful to find out if he has.
>
>   
I wouldn't mind just saying anything written by him (tickets, comment,
wiki changes) will be reverted/deleted on sight. Even if the
contributions are remotely useful I'm sure there is someone else that
can make them.

--Noah

Joshua Preston | 7 Oct 06:22

[Trac-dev] Re: Ticket #6139


I am just curious, and arguably not fully educated on this topic, but  
I am curious...  I have read the ticket and a couple of his posts;  
what was the exact offense?  Minus the ticket comments, I can't say I  
see how the punishment fits the crime.  The references posted seemed  
more to be critiques than insults.

Additionally, I am fully aware I have no say anyhow!  Just be patient.

Thanks!

Joshua Preston
Sent from my iPhone

On Oct 6, 2007, at 9:10 PM, Noah Kantrowitz <kantrn <at> rpi.edu> wrote:

> Emmanuel Blot wrote:
>>> Anyone object to deleting this ticket and continuing on with life?
>>>
>> Sure not.
>>
>>
>>> I'm sure we all have better things to do and Ilias clearly hasn't  
>>> changed
>>> his ways.
>>>
>> This ticket has somewhat been useful to find out if he has.
>>
>>
> I wouldn't mind just saying anything written by him (tickets, comment,
(Continue reading)


Gmane