Re: Trac workflow assistance (commiter feedback needed)
Hello,
On Apr 23, 12:32 pm, Russell Keith-Magee
wrote:
> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> > Commiters and triagers,
> > I've gone through the contributing doc and tried to identify places
> > that tickets might get stuck (or other places that automation might
> > smooth the process).
> > If you could take a few minutes to give feedback on the list,
> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> > focus effort.
>
> Comments by row number from the spreadsheet:
>
> 2: Would be useful as a work list for people looking for. It would
> also be useful if tickets could be auto-disowned; i.e., if there's no
> activity from the owner after a month, post a comment asking for a
> status update; if no activity after another month, remove the
> ownership. This might get annoying for long-lived tickets with an
> owner that has a vested interest, though.
>
> 3: That's essentially just a list of people who can't (or won't) read
> the contribution guide. I'm not sure tracking that stat would help.
>
> 4: Is essentially a list of 'active tickets'. I keep track of that by
> manually eyeballing Trac updates; it might be a useful stat to have
> exposed for people who don't watch Trac as much as I do.
>
> 5-10: The most useful of the lot for me personally. An automated
> process that applies patches and runs tests would be nice; if it can
> autocheck the appropriate flags ("patch needs improvement", "needs
> tests" etc) that would be even better.
>
> There are edge cases that will make this difficult; e.g., patches that
> span multiple diffs, or tickets where the submitter provides multiple
> alternative patches.
>
> I would also add to this list checks that the test is actually a
> regression test - that is, that the contributed test fails unless the
> rest of the patch is applied.
>
> I'm also not sure if a direct email or adding a comment to the ticket
> in trac would be the best approach. I suspect a comment would be
> better, since it provides a public record of the automated reporting
> activity.
>
> 11: Useful as a working list for someone looking for something to do.
>
> 12-14: Nifty stats, but I'm not sure they would help much
>
> 15-17 would be useful if we wanted to audit the work of volunteers,
> but that's not really something we do. I keep a rough eye on every
> ticket change as they come in; if something looks way off, I'll jump
> on it, but otherwise I just live and let live and let the crowd sort
> it out.
>
> 18: I'd be interested to see what this produces. My gut tells me that
> tags aren't used often enough (or consistently enough) for this to
> provide any real patterns. However I might be wrong. If it works, it
> might be a handy way to work out common themes that need a broader
> approach.
>
> 19: Again, like 3; this is just a list of people who don't follow process.
>
> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> > (I'm assuming the live app can't easily have access to the DB, or that
> > the RPC API's abstractions are useful at the app level). Correct me
> > if I'm wrong.
>
> If you're looking to implement this as a standalone thing, it probably
> *could* access the Trac DB directly, but in the interests of
> everyone's sanity (including Trac's) it's probably best to keep to
> public interfaces like XMLRPC.
>
> However, it's also possible that some of these features would best be
> implemented as a Trac plugin.
>
> I'd also suggest that before you embark on a big Trac-specific
> tool-building exercise that we investigate what we could gain by
> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
> got lots of quirks and bugs that annoy the bejezus out of me, and
> there are many aspects of Django's development process that aren't
> well suited to Trac's model (as the recent discussions about process
> have indicated). If there are tools out there that are better suited
> to our needs, I'm interested in hearing options.
>
> Caveat: This isn't an invitation for people to just start listing Trac
> alternatives. If we're going to change, we're going to change because
> of a compelling reason, not just so we can change the color of the
> furniture. If you want to propose an alternative, you need to provide
> a list of features that Trac doesn't have, but are well aligned to
> Django's development process.
>
I have been thinking about this for a while and since launchpad [0]
has been drastically improving its usability recently. It is now
reasonably fast ... Launchpad.net provides a set of features that are
well aligned with django development process and not supported by
Trac.
* It has a built in notion of reputation "karma" which get credited
each time a user interact with the project on launchpad (Translation,
bug, code)
* It has a python api [2] to crunch the data
* There is a built in code review [3] mechanism that links on a single
page the diff the comments and the original branch and the
destinat
Re: Trac workflow assistance (commiter feedback needed)
On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> Hello,
>
> On Apr 23, 12:32 pm, Russell Keith-Magee
> wrote:
>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
>> > Commiters and triagers,
>> > I've gone through the contributing doc and tried to identify places
>> > that tickets might get stuck (or other places that automation might
>> > smooth the process).
>> > If you could take a few minutes to give feedback on the list,
>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
>> > focus effort.
>>
>> Comments by row number from the spreadsheet:
>>
>> 2: Would be useful as a work list for people looking for. It would
>> also be useful if tickets could be auto-disowned; i.e., if there's no
>> activity from the owner after a month, post a comment asking for a
>> status update; if no activity after another month, remove the
>> ownership. This might get annoying for long-lived tickets with an
>> owner that has a vested interest, though.
>>
>> 3: That's essentially just a list of people who can't (or won't) read
>> the contribution guide. I'm not sure tracking that stat would help.
>>
>> 4: Is essentially a list of 'active tickets'. I keep track of that by
>> manually eyeballing Trac updates; it might be a useful stat to have
>> exposed for people who don't watch Trac as much as I do.
>>
>> 5-10: The most useful of the lot for me personally. An automated
>> process that applies patches and runs tests would be nice; if it can
>> autocheck the appropriate flags ("patch needs improvement", "needs
>> tests" etc) that would be even better.
>>
>> There are edge cases that will make this difficult; e.g., patches that
>> span multiple diffs, or tickets where the submitter provides multiple
>> alternative patches.
>>
>> I would also add to this list checks that the test is actually a
>> regression test - that is, that the contributed test fails unless the
>> rest of the patch is applied.
>>
>> I'm also not sure if a direct email or adding a comment to the ticket
>> in trac would be the best approach. I suspect a comment would be
>> better, since it provides a public record of the automated reporting
>> activity.
>>
>> 11: Useful as a working list for someone looking for something to do.
>>
>> 12-14: Nifty stats, but I'm not sure they would help much
>>
>> 15-17 would be useful if we wanted to audit the work of volunteers,
>> but that's not really something we do. I keep a rough eye on every
>> ticket change as they come in; if something looks way off, I'll jump
>> on it, but otherwise I just live and let live and let the crowd sort
>> it out.
>>
>> 18: I'd be interested to see what this produces. My gut tells me that
>> tags aren't used often enough (or consistently enough) for this to
>> provide any real patterns. However I might be wrong. If it works, it
>> might be a handy way to work out common themes that need a broader
>> approach.
>>
>> 19: Again, like 3; this is just a list of people who don't follow process.
>>
>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
>> > (I'm assuming the live app can't easily have access to the DB, or that
>> > the RPC API's abstractions are useful at the app level). Correct me
>> > if I'm wrong.
>>
>> If you're looking to implement this as a standalone thing, it probably
>> *could* access the Trac DB directly, but in the interests of
>> everyone's sanity (including Trac's) it's probably best to keep to
>> public interfaces like XMLRPC.
>>
>> However, it's also possible that some of these features would best be
>> implemented as a Trac plugin.
>>
>> I'd also suggest that before you embark on a big Trac-specific
>> tool-building exercise that we investigate what we could gain by
>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
>> got lots of quirks and bugs that annoy the bejezus out of me, and
>> there are many aspects of Django's development process that aren't
>> well suited to Trac's model (as the recent discussions about process
>> have indicated). If there are tools out there that are better suited
>> to our needs, I'm interested in hearing options.
>>
>> Caveat: This isn't an invitation for people to just start listing Trac
>> alternatives. If we're going to change, we're going to change because
>> of a compelling reason, not just so we can change the color of the
>> furniture. If you want to propose an alternative, you need to provide
>> a list of features that Trac doesn't have, but are well aligned to
>> Django's development process.
>>
> I have been thinking about this for a while and since launchpad [0]
> has been drastically improving its usability recently. It is now
> reasonably fast ... Launchpad.net provides a set of features that are
> well aligned with django development process and not supported by
> Trac.
>
> * It has a built in notion of reputation "karma" which get credited
> each time a user interact with the project on launchpad (Translation,
> bug, code)
> * It has a python api
Re: Trac workflow assistance (commiter feedback needed)
On zo, 2010-04-25 at 23:15 +0800, Russell Keith-Magee wrote: > However, the *huge* impediment that you have avoided mentioning is > that moving to Launchpad would require moving Django to using Bazaar > for version control. You don't *have* to use the bzr/code bits of launchpad to use the bugtracking or translation features. > Even if we were to adopt a DVCS, given the popularity of Git and Hg in > the Django community, adopting Bazaar would be a strange choice for us > to make at a project level. Github has an issue tracker and merge request thing :) (Never used it though, I'm not suggesting it as an alternative to trac) -- Dennis K. They've gone to plaid! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
Hi Russell, Jacob,
What do you think, is it good idea to write django-based bug tracker
as a trac replacement?
As we all know, Django would be a perfect fit for such project!
Current Trac templates & layouts can be used for prototyping the project.
On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
wrote:
> On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
>> Hello,
>>
>> On Apr 23, 12:32 pm, Russell Keith-Magee
>> wrote:
>>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
>>> > Commiters and triagers,
>>> > I've gone through the contributing doc and tried to identify places
>>> > that tickets might get stuck (or other places that automation might
>>> > smooth the process).
>>> > If you could take a few minutes to give feedback on the list,
>>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
>>> > focus effort.
>>>
>>> Comments by row number from the spreadsheet:
>>>
>>> 2: Would be useful as a work list for people looking for. It would
>>> also be useful if tickets could be auto-disowned; i.e., if there's no
>>> activity from the owner after a month, post a comment asking for a
>>> status update; if no activity after another month, remove the
>>> ownership. This might get annoying for long-lived tickets with an
>>> owner that has a vested interest, though.
>>>
>>> 3: That's essentially just a list of people who can't (or won't) read
>>> the contribution guide. I'm not sure tracking that stat would help.
>>>
>>> 4: Is essentially a list of 'active tickets'. I keep track of that by
>>> manually eyeballing Trac updates; it might be a useful stat to have
>>> exposed for people who don't watch Trac as much as I do.
>>>
>>> 5-10: The most useful of the lot for me personally. An automated
>>> process that applies patches and runs tests would be nice; if it can
>>> autocheck the appropriate flags ("patch needs improvement", "needs
>>> tests" etc) that would be even better.
>>>
>>> There are edge cases that will make this difficult; e.g., patches that
>>> span multiple diffs, or tickets where the submitter provides multiple
>>> alternative patches.
>>>
>>> I would also add to this list checks that the test is actually a
>>> regression test - that is, that the contributed test fails unless the
>>> rest of the patch is applied.
>>>
>>> I'm also not sure if a direct email or adding a comment to the ticket
>>> in trac would be the best approach. I suspect a comment would be
>>> better, since it provides a public record of the automated reporting
>>> activity.
>>>
>>> 11: Useful as a working list for someone looking for something to do.
>>>
>>> 12-14: Nifty stats, but I'm not sure they would help much
>>>
>>> 15-17 would be useful if we wanted to audit the work of volunteers,
>>> but that's not really something we do. I keep a rough eye on every
>>> ticket change as they come in; if something looks way off, I'll jump
>>> on it, but otherwise I just live and let live and let the crowd sort
>>> it out.
>>>
>>> 18: I'd be interested to see what this produces. My gut tells me that
>>> tags aren't used often enough (or consistently enough) for this to
>>> provide any real patterns. However I might be wrong. If it works, it
>>> might be a handy way to work out common themes that need a broader
>>> approach.
>>>
>>> 19: Again, like 3; this is just a list of people who don't follow process.
>>>
>>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
>>> > (I'm assuming the live app can't easily have access to the DB, or that
>>> > the RPC API's abstractions are useful at the app level). Correct me
>>> > if I'm wrong.
>>>
>>> If you're looking to implement this as a standalone thing, it probably
>>> *could* access the Trac DB directly, but in the interests of
>>> everyone's sanity (including Trac's) it's probably best to keep to
>>> public interfaces like XMLRPC.
>>>
>>> However, it's also possible that some of these features would best be
>>> implemented as a Trac plugin.
>>>
>>> I'd also suggest that before you embark on a big Trac-specific
>>> tool-building exercise that we investigate what we could gain by
>>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
>>> got lots of quirks and bugs that annoy the bejezus out of me, and
>>> there are many aspects of Django's development process that aren't
>>> well suited to Trac's model (as the recent discussions about process
>>> have indicated). If there are tools out there that are better suited
>>> to our needs, I'm interested in hearing options.
>>>
>>> Caveat: This isn't an invitation for people to just start listing Trac
>>> alternatives. If we're going to change, we're going to change because
>>> of a compelling reason, not just so we can change the color of the
>>> furniture. If you want to propose an alternative, you need to provide
>>> a list of features that Trac doesn't have, but are well aligned to
>>> Django's development process.
>>>
>> I have been thinking about this for a while and since
Re: Trac workflow assistance (commiter feedback needed)
As you have noted I have avoided to the DVCS matter because I knew it
is a slippery slope and because it don't really matter. Launchpad
allows you to import branch from many of the popular VCS [1] cvs, svn,
git, hg. The documentation mention that drupal is using this feature
to import on a regular basis their "trunk" which is control in a CVS
repository. This import capability is the reason I kept the DVCS
aspect out of my initial post my understanding was that nothing
describes before would require a move from svn to bzr for django's
"canonical trunk".
I am adding a link to the "Karma calculation" [2].
Regards,
--yml
[1] https://help.launchpad.net/Code/Imports
[2]
https://help.launchpad.net/YourAccount/Karma?action=show&redirect=KarmaCalculation
On Apr 25, 11:15 am, Russell Keith-Magee
wrote:
> On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> > Hello,
>
> > On Apr 23, 12:32 pm, Russell Keith-Magee
> > wrote:
> >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> >> > Commiters and triagers,
> >> > I've gone through the contributing doc and tried to identify places
> >> > that tickets might get stuck (or other places that automation might
> >> > smooth the process).
> >> > If you could take a few minutes to give feedback on the list,
> >> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> >> > focus effort.
>
> >> Comments by row number from the spreadsheet:
>
> >> 2: Would be useful as a work list for people looking for. It would
> >> also be useful if tickets could be auto-disowned; i.e., if there's no
> >> activity from the owner after a month, post a comment asking for a
> >> status update; if no activity after another month, remove the
> >> ownership. This might get annoying for long-lived tickets with an
> >> owner that has a vested interest, though.
>
> >> 3: That's essentially just a list of people who can't (or won't) read
> >> the contribution guide. I'm not sure tracking that stat would help.
>
> >> 4: Is essentially a list of 'active tickets'. I keep track of that by
> >> manually eyeballing Trac updates; it might be a useful stat to have
> >> exposed for people who don't watch Trac as much as I do.
>
> >> 5-10: The most useful of the lot for me personally. An automated
> >> process that applies patches and runs tests would be nice; if it can
> >> autocheck the appropriate flags ("patch needs improvement", "needs
> >> tests" etc) that would be even better.
>
> >> There are edge cases that will make this difficult; e.g., patches that
> >> span multiple diffs, or tickets where the submitter provides multiple
> >> alternative patches.
>
> >> I would also add to this list checks that the test is actually a
> >> regression test - that is, that the contributed test fails unless the
> >> rest of the patch is applied.
>
> >> I'm also not sure if a direct email or adding a comment to the ticket
> >> in trac would be the best approach. I suspect a comment would be
> >> better, since it provides a public record of the automated reporting
> >> activity.
>
> >> 11: Useful as a working list for someone looking for something to do.
>
> >> 12-14: Nifty stats, but I'm not sure they would help much
>
> >> 15-17 would be useful if we wanted to audit the work of volunteers,
> >> but that's not really something we do. I keep a rough eye on every
> >> ticket change as they come in; if something looks way off, I'll jump
> >> on it, but otherwise I just live and let live and let the crowd sort
> >> it out.
>
> >> 18: I'd be interested to see what this produces. My gut tells me that
> >> tags aren't used often enough (or consistently enough) for this to
> >> provide any real patterns. However I might be wrong. If it works, it
> >> might be a handy way to work out common themes that need a broader
> >> approach.
>
> >> 19: Again, like 3; this is just a list of people who don't follow process.
>
> >> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> >> > (I'm assuming the live app can't easily have access to the DB, or that
> >> > the RPC API's abstractions are useful at the app level). Correct me
> >> > if I'm wrong.
>
> >> If you're looking to implement this as a standalone thing, it probably
> >> *could* access the Trac DB directly, but in the interests of
> >> everyone's sanity (including Trac's) it's probably best to keep to
> >> public interfaces like XMLRPC.
>
> >> However, it's also possible that some of these features would best be
> >> implemented as a Trac plugin.
>
> >> I'd also suggest that before you embark on a big Trac-specific
> >> tool-building exercise that we investigate what we could gain by
> >> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
> >> got lots of quirks and bugs that annoy the bejezus out of me, and
> >> there are many aspects of Django's development process that aren't
> >> well suited to Trac's model (as the recent discussions about process
> >> have indicated). If there are tools out there that are b
Re: Trac workflow assistance (commiter feedback needed)
I've been dancing around this idea for a while. I know it's not a new
thought, and Alex Gaynor and Justin Lilly even started work on "piano
man" [1]... I'd be curious to know what the state of that project is
and if a few more devs working on it might be able to bring it to a
place where it'd be ready for prime time.
Re-inventing the wheel is usually a bad idea, but at the same time a
Django-based tracker just seems like such a natural choice.
- Gabriel
[1] http://github.com/alex/piano-man
On Apr 25, 11:10 am, "burc...@gmail.com" wrote:
> Hi Russell, Jacob,
>
> What do you think, is it good idea to write django-based bug tracker
> as a trac replacement?
> As we all know, Django would be a perfect fit for such project!
>
> Current Trac templates & layouts can be used for prototyping the project.
>
> On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
>
>
>
>
>
> wrote:
> > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> >> Hello,
>
> >> On Apr 23, 12:32 pm, Russell Keith-Magee
> >> wrote:
> >>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> >>> > Commiters and triagers,
> >>> > I've gone through the contributing doc and tried to identify places
> >>> > that tickets might get stuck (or other places that automation might
> >>> > smooth the process).
> >>> > If you could take a few minutes to give feedback on the list,
> >>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> >>> > focus effort.
>
> >>> Comments by row number from the spreadsheet:
>
> >>> 2: Would be useful as a work list for people looking for. It would
> >>> also be useful if tickets could be auto-disowned; i.e., if there's no
> >>> activity from the owner after a month, post a comment asking for a
> >>> status update; if no activity after another month, remove the
> >>> ownership. This might get annoying for long-lived tickets with an
> >>> owner that has a vested interest, though.
>
> >>> 3: That's essentially just a list of people who can't (or won't) read
> >>> the contribution guide. I'm not sure tracking that stat would help.
>
> >>> 4: Is essentially a list of 'active tickets'. I keep track of that by
> >>> manually eyeballing Trac updates; it might be a useful stat to have
> >>> exposed for people who don't watch Trac as much as I do.
>
> >>> 5-10: The most useful of the lot for me personally. An automated
> >>> process that applies patches and runs tests would be nice; if it can
> >>> autocheck the appropriate flags ("patch needs improvement", "needs
> >>> tests" etc) that would be even better.
>
> >>> There are edge cases that will make this difficult; e.g., patches that
> >>> span multiple diffs, or tickets where the submitter provides multiple
> >>> alternative patches.
>
> >>> I would also add to this list checks that the test is actually a
> >>> regression test - that is, that the contributed test fails unless the
> >>> rest of the patch is applied.
>
> >>> I'm also not sure if a direct email or adding a comment to the ticket
> >>> in trac would be the best approach. I suspect a comment would be
> >>> better, since it provides a public record of the automated reporting
> >>> activity.
>
> >>> 11: Useful as a working list for someone looking for something to do.
>
> >>> 12-14: Nifty stats, but I'm not sure they would help much
>
> >>> 15-17 would be useful if we wanted to audit the work of volunteers,
> >>> but that's not really something we do. I keep a rough eye on every
> >>> ticket change as they come in; if something looks way off, I'll jump
> >>> on it, but otherwise I just live and let live and let the crowd sort
> >>> it out.
>
> >>> 18: I'd be interested to see what this produces. My gut tells me that
> >>> tags aren't used often enough (or consistently enough) for this to
> >>> provide any real patterns. However I might be wrong. If it works, it
> >>> might be a handy way to work out common themes that need a broader
> >>> approach.
>
> >>> 19: Again, like 3; this is just a list of people who don't follow process.
>
> >>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> >>> > (I'm assuming the live app can't easily have access to the DB, or that
> >>> > the RPC API's abstractions are useful at the app level). Correct me
> >>> > if I'm wrong.
>
> >>> If you're looking to implement this as a standalone thing, it probably
> >>> *could* access the Trac DB directly, but in the interests of
> >>> everyone's sanity (including Trac's) it's probably best to keep to
> >>> public interfaces like XMLRPC.
>
> >>> However, it's also possible that some of these features would best be
> >>> implemented as a Trac plugin.
>
> >>> I'd also suggest that before you embark on a big Trac-specific
> >>> tool-building exercise that we investigate what we could gain by
> >>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
> >>> got lots of quirks and bugs that annoy the bejezus out of me, and
> >>> there are many aspects of Django's development process
Re: Trac workflow assistance (commiter feedback needed)
On Sun, Apr 25, 2010 at 4:48 PM, Gabriel Hurley wrote:
> I've been dancing around this idea for a while. I know it's not a new
> thought, and Alex Gaynor and Justin Lilly even started work on "piano
> man" [1]... I'd be curious to know what the state of that project is
> and if a few more devs working on it might be able to bring it to a
> place where it'd be ready for prime time.
>
> Re-inventing the wheel is usually a bad idea, but at the same time a
> Django-based tracker just seems like such a natural choice.
>
> - Gabriel
>
> [1] http://github.com/alex/piano-man
>
> On Apr 25, 11:10 am, "burc...@gmail.com" wrote:
>> Hi Russell, Jacob,
>>
>> What do you think, is it good idea to write django-based bug tracker
>> as a trac replacement?
>> As we all know, Django would be a perfect fit for such project!
>>
>> Current Trac templates & layouts can be used for prototyping the project.
>>
>> On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
>>
>>
>>
>>
>>
>> wrote:
>> > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
>> >> Hello,
>>
>> >> On Apr 23, 12:32 pm, Russell Keith-Magee
>> >> wrote:
>> >>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
>> >>> > Commiters and triagers,
>> >>> > I've gone through the contributing doc and tried to identify places
>> >>> > that tickets might get stuck (or other places that automation might
>> >>> > smooth the process).
>> >>> > If you could take a few minutes to give feedback on the list,
>> >>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
>> >>> > focus effort.
>>
>> >>> Comments by row number from the spreadsheet:
>>
>> >>> 2: Would be useful as a work list for people looking for. It would
>> >>> also be useful if tickets could be auto-disowned; i.e., if there's no
>> >>> activity from the owner after a month, post a comment asking for a
>> >>> status update; if no activity after another month, remove the
>> >>> ownership. This might get annoying for long-lived tickets with an
>> >>> owner that has a vested interest, though.
>>
>> >>> 3: That's essentially just a list of people who can't (or won't) read
>> >>> the contribution guide. I'm not sure tracking that stat would help.
>>
>> >>> 4: Is essentially a list of 'active tickets'. I keep track of that by
>> >>> manually eyeballing Trac updates; it might be a useful stat to have
>> >>> exposed for people who don't watch Trac as much as I do.
>>
>> >>> 5-10: The most useful of the lot for me personally. An automated
>> >>> process that applies patches and runs tests would be nice; if it can
>> >>> autocheck the appropriate flags ("patch needs improvement", "needs
>> >>> tests" etc) that would be even better.
>>
>> >>> There are edge cases that will make this difficult; e.g., patches that
>> >>> span multiple diffs, or tickets where the submitter provides multiple
>> >>> alternative patches.
>>
>> >>> I would also add to this list checks that the test is actually a
>> >>> regression test - that is, that the contributed test fails unless the
>> >>> rest of the patch is applied.
>>
>> >>> I'm also not sure if a direct email or adding a comment to the ticket
>> >>> in trac would be the best approach. I suspect a comment would be
>> >>> better, since it provides a public record of the automated reporting
>> >>> activity.
>>
>> >>> 11: Useful as a working list for someone looking for something to do.
>>
>> >>> 12-14: Nifty stats, but I'm not sure they would help much
>>
>> >>> 15-17 would be useful if we wanted to audit the work of volunteers,
>> >>> but that's not really something we do. I keep a rough eye on every
>> >>> ticket change as they come in; if something looks way off, I'll jump
>> >>> on it, but otherwise I just live and let live and let the crowd sort
>> >>> it out.
>>
>> >>> 18: I'd be interested to see what this produces. My gut tells me that
>> >>> tags aren't used often enough (or consistently enough) for this to
>> >>> provide any real patterns. However I might be wrong. If it works, it
>> >>> might be a handy way to work out common themes that need a broader
>> >>> approach.
>>
>> >>> 19: Again, like 3; this is just a list of people who don't follow
>> >>> process.
>>
>> >>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
>> >>> > (I'm assuming the live app can't easily have access to the DB, or that
>> >>> > the RPC API's abstractions are useful at the app level). Correct me
>> >>> > if I'm wrong.
>>
>> >>> If you're looking to implement this as a standalone thing, it probably
>> >>> *could* access the Trac DB directly, but in the interests of
>> >>> everyone's sanity (including Trac's) it's probably best to keep to
>> >>> public interfaces like XMLRPC.
>>
>> >>> However, it's also possible that some of these features would best be
>> >>> implemented as a Trac plugin.
>>
>> >>> I'd also suggest that before you embark on a big Trac-specific
>> >>> tool-building exercise that we investigate what we could gain by
>> >>> moving to another b
Re: Trac workflow assistance (commiter feedback needed)
I'm in a similar boat to Russell... LaunchPad's UI always seemed like
a complete disaster to me...
However, in reading through LaunchPad's FAQ to give it a fair chance,
I saw a couple of other features that Trac doesn't have to add to the
list:
* Out-of-the-box OpenID support
* "Bug Expiry" to handle tickets that are both outdated and inactive
* Multi-project bugs (so that different projects can track, say, the
same bug in Python in a concerted manner)
* Sprint management
* Tracker interaction via email reply
* Concrete "triaged" statuses and indicators for "project
supervisors" beyond those available to the community.
* The ability for Launchpad to watch and integrate bugs from other
trackers (such as Trac) in an ongoing fashion.
Not necessarily advocating for Launchpad, just thought it was
interesting.
- Gabriel
On Apr 25, 11:34 am, yml wrote:
> As you have noted I have avoided to the DVCS matter because I knew it
> is a slippery slope and because it don't really matter. Launchpad
> allows you to import branch from many of the popular VCS [1] cvs, svn,
> git, hg. The documentation mention that drupal is using this feature
> to import on a regular basis their "trunk" which is control in a CVS
> repository. This import capability is the reason I kept the DVCS
> aspect out of my initial post my understanding was that nothing
> describes before would require a move from svn to bzr for django's
> "canonical trunk".
>
> I am adding a link to the "Karma calculation" [2].
> Regards,
> --yml
>
> [1]https://help.launchpad.net/Code/Imports
> [2]https://help.launchpad.net/YourAccount/Karma?action=show&redirect=Kar...
>
> On Apr 25, 11:15 am, Russell Keith-Magee
> wrote:
>
>
>
>
>
> > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> > > Hello,
>
> > > On Apr 23, 12:32 pm, Russell Keith-Magee
> > > wrote:
> > >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> > >> > Commiters and triagers,
> > >> > I've gone through the contributing doc and tried to identify places
> > >> > that tickets might get stuck (or other places that automation might
> > >> > smooth the process).
> > >> > If you could take a few minutes to give feedback on the list,
> > >> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> > >> > focus effort.
>
> > >> Comments by row number from the spreadsheet:
>
> > >> 2: Would be useful as a work list for people looking for. It would
> > >> also be useful if tickets could be auto-disowned; i.e., if there's no
> > >> activity from the owner after a month, post a comment asking for a
> > >> status update; if no activity after another month, remove the
> > >> ownership. This might get annoying for long-lived tickets with an
> > >> owner that has a vested interest, though.
>
> > >> 3: That's essentially just a list of people who can't (or won't) read
> > >> the contribution guide. I'm not sure tracking that stat would help.
>
> > >> 4: Is essentially a list of 'active tickets'. I keep track of that by
> > >> manually eyeballing Trac updates; it might be a useful stat to have
> > >> exposed for people who don't watch Trac as much as I do.
>
> > >> 5-10: The most useful of the lot for me personally. An automated
> > >> process that applies patches and runs tests would be nice; if it can
> > >> autocheck the appropriate flags ("patch needs improvement", "needs
> > >> tests" etc) that would be even better.
>
> > >> There are edge cases that will make this difficult; e.g., patches that
> > >> span multiple diffs, or tickets where the submitter provides multiple
> > >> alternative patches.
>
> > >> I would also add to this list checks that the test is actually a
> > >> regression test - that is, that the contributed test fails unless the
> > >> rest of the patch is applied.
>
> > >> I'm also not sure if a direct email or adding a comment to the ticket
> > >> in trac would be the best approach. I suspect a comment would be
> > >> better, since it provides a public record of the automated reporting
> > >> activity.
>
> > >> 11: Useful as a working list for someone looking for something to do.
>
> > >> 12-14: Nifty stats, but I'm not sure they would help much
>
> > >> 15-17 would be useful if we wanted to audit the work of volunteers,
> > >> but that's not really something we do. I keep a rough eye on every
> > >> ticket change as they come in; if something looks way off, I'll jump
> > >> on it, but otherwise I just live and let live and let the crowd sort
> > >> it out.
>
> > >> 18: I'd be interested to see what this produces. My gut tells me that
> > >> tags aren't used often enough (or consistently enough) for this to
> > >> provide any real patterns. However I might be wrong. If it works, it
> > >> might be a handy way to work out common themes that need a broader
> > >> approach.
>
> > >> 19: Again, like 3; this is just a list of people who don't follow
> > >> process.
>
> > >> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> > >> > (I'
Delete order of generic relation models
I have a model Article and a model Vote with a generic foreign key to track user votes on articles. When a vote is deleted, I have a post_delete hook that updates the score field on the parent article. My problem is when I delete an article, django sometimes deletes the generically-related votes after it deletes the article, causing my post_delete hook to re-save the deleted article. A decent workaround is for my post_delete hook to pass force_update=True and catch DatabaseError when saving the article, in case it has already been deleted. But I think it would be nice if django just deleted the generically-related objects first so I didn't have to worry about this. I've opened a ticket and submitted a patch so generically-related children are deleted before their parents: http://code.djangoproject.com/ticket/13416 Does anyone see any problems this could cause? Thanks. Ryan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
On Apr 25, 5:21 pm, Gabriel Hurley wrote:
> I'm in a similar boat to Russell... LaunchPad's UI always seemed like
> a complete disaster to me...
>
> However, in reading through LaunchPad's FAQ to give it a fair chance,
> I saw a couple of other features that Trac doesn't have to add to the
> list:
>
> * Out-of-the-box OpenID support
> * "Bug Expiry" to handle tickets that are both outdated and inactive
> * Multi-project bugs (so that different projects can track, say, the
> same bug in Python in a concerted manner)
> * Sprint management
> * Tracker interaction via email reply
> * Concrete "triaged" statuses and indicators for "project
> supervisors" beyond those available to the community.
> * The ability for Launchpad to watch and integrate bugs from other
> trackers (such as Trac) in an ongoing fashion.
>
> Not necessarily advocating for Launchpad, just thought it was
> interesting.
>
> - Gabriel
While spending some more time looking at launchpad.net I stumbled upon
another very neat feature you can also sort the bug by heat [1]. Here
it is an example of this feature on bazaar bug tracker [2]. This page
explain how the heat of a bug is calculated [3]. On of the parameter
used to calculate the "heat" is the number of people affected by the
bug. Launchpad provides 2 different indicators to show your interest
in a bug resolution : you can report that the bug affect you and you
can subscribe to a bug. This also addresses the complain I have see
many times about the usage (abuse) of the cc field in Trac.
Regards,
--yml
[1] http://blog.launchpad.net/bug-tracking/bug-heat
[2]
https://bugs.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-heat&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[3] https://dev.launchpad.net/Bugs/BugHeat#Algorithm
>
> On Apr 25, 11:34 am, yml wrote:
>
> > As you have noted I have avoided to the DVCS matter because I knew it
> > is a slippery slope and because it don't really matter. Launchpad
> > allows you to import branch from many of the popular VCS [1] cvs, svn,
> > git, hg. The documentation mention that drupal is using this feature
> > to import on a regular basis their "trunk" which is control in a CVS
> > repository. This import capability is the reason I kept the DVCS
> > aspect out of my initial post my understanding was that nothing
> > describes before would require a move from svn to bzr for django's
> > "canonical trunk".
>
> > I am adding a link to the "Karma calculation" [2].
> > Regards,
> > --yml
>
> > [1]https://help.launchpad.net/Code/Imports
> > [2]https://help.launchpad.net/YourAccount/Karma?action=show&redirect=Kar...
>
> > On Apr 25, 11:15 am, Russell Keith-Magee
> > wrote:
>
> > > On Sun, Apr 25, 2010 at 10:54 PM, yml wrote:
> > > > Hello,
>
> > > > On Apr 23, 12:32 pm, Russell Keith-Magee
> > > > wrote:
> > > >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck wrote:
> > > >> > Commiters and triagers,
> > > >> > I've gone through the contributing doc and tried to identify places
> > > >> > that tickets might get stuck (or other places that automation might
> > > >> > smooth the process).
> > > >> > If you could take a few minutes to give feedback on the list,
> > > >> > hopefully prioritizing in your named column with +/- 0/1, it'd help
> > > >> > me
> > > >> > focus effort.
>
> > > >> Comments by row number from the spreadsheet:
>
> > > >> 2: Would be useful as a work list for people looking for. It would
> > > >> also be useful if tickets could be auto-disowned; i.e., if there's no
> > > >> activity from the owner after a month, post a comment asking for a
> > > >> status update; if no activity after another month, remove the
> > > >> ownership. This might get annoying for long-lived tickets with an
> > > >> owner that has a vested interest, though.
>
> > > >> 3: That's essentially just a list of people who can't (or won't) read
> > > >> the contribution guide. I'm not sure tracking that stat would help.
>
> > > >> 4: Is essentially a list of 'active tickets'. I keep track of that by
> > > >> manually eyeballing Trac updates; it might be a useful stat to have
> > > >> exposed for people who don't watch Trac as much as I do.
>
> > > >> 5-10: The most useful of the lot for me personally. An automated
> > > >> process that applies patches and runs tests would be nice; if it can
> > > >> autocheck the appropriate flags ("patch needs improvement", "needs
> > > >> tests" etc) that would be even better.
>
> > > >> There are edge cases that will make this difficult; e.g., patches that
> > > >> span multiple diffs, or tickets where the submitter provides multiple
> > > >> alternative patches.
>
> > > >> I would also add to this list checks that the test is
Re: Trac workflow assistance (commiter feedback needed)
On Mon, Apr 26, 2010 at 2:34 AM, yml wrote: > As you have noted I have avoided to the DVCS matter because I knew it > is a slippery slope and because it don't really matter. Launchpad > allows you to import branch from many of the popular VCS [1] cvs, svn, > git, hg. The documentation mention that drupal is using this feature > to import on a regular basis their "trunk" which is control in a CVS > repository. This import capability is the reason I kept the DVCS > aspect out of my initial post my understanding was that nothing > describes before would require a move from svn to bzr for django's > "canonical trunk". My problem here is the enormous potential for confusion. We would have a bug tracking system that has an integrated and clearly visible version control system... but we wouldn't be using that version control system for actual development. Making matters worse, because Launchpad is hosted, we would have a limited ability to customize the appearance of the bug tracker to clarify the fact that the repository is unofficial, or only there as a prerequisite of the bug tracker, etc. As for Drupal using launchpad - are you sure? https://bugs.launchpad.net/drupal To illustrate the potential for confusion -- tell me how we can annotate the following page: https://code.launchpad.net/drupal to indicate that most these branches aren't *official* in any capacity, and even the ones that are official aren't officially stored in Bazaar. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac workflow assistance (commiter feedback needed)
On Mon, Apr 26, 2010 at 4:48 AM, Gabriel Hurley wrote: > I've been dancing around this idea for a while. I know it's not a new > thought, and Alex Gaynor and Justin Lilly even started work on "piano > man" [1]... I'd be curious to know what the state of that project is > and if a few more devs working on it might be able to bring it to a > place where it'd be ready for prime time. > > Re-inventing the wheel is usually a bad idea, but at the same time a > Django-based tracker just seems like such a natural choice. I'm of two minds on this question. One the one hand, a bug tracking system seems like a natural fit for Django. A bug tracker is pretty much a perfect example of a database-backed website. There would also be something to be said for Django eating its own dogfood in a highly visible way. There is also an argument to be made that bug tracking is due for a bit of a shakeup. The emergence of DVCS has changed the way software is developed. It may be time for a new bug tracking project to redefine what issue tracking means in a DVCS world. However, on the other hand, I'm *really* opposed to reinventing this particular wheel. There are literally dozens of bug trackers out there. "Because we can" isn't enough of a reason to fragment the bug tracking community a little bit more -- our bug tracking needs aren't unique. I'd much rather see development effort go into improving one of the existing bug trackers to meet our needs rather than start from scratch. I'm also very much aware of the "I could rebuild StackOverflow in a weekend" trap. Building a trivial bug tracker will be easy. Building a complex and reliable bug tracker that can be used in production is a serious undertaking. Maintaining a bug tracking project is also a serious undertaking; long term maintenance is just as important as initial development. That said, I won't (or rather, can't) stop anyone from building a Django-based bug tracker if they so desire. However, I would offer the following guidance: If you're considering working on a new bugtracking project with the aim of getting Django to adopt it: * It will need to work *before* it will be taken into consideration. code.djangoproject.com isn't going to be your beta test site. * The fact that a bug tracker runs on Django will be a secondary consideration. It would be *nice* if Django's bug tracker used Django, but it isn't a fundamental requirement. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
