Trac workflow assistance (commiter feedback needed)

[Jeremy Dunck]

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.
http://spreadsheets.google.com/ccc?key=0ApFMbbFef2aVdE1TZThZY01ValRKUUVOT1oxck1VaWc&hl=en

I added people from the commiter page; we still don't have triagers
named publicly, I think, and so didn't hazard an incomplete list of
triagers. Please just add yourself if you're a triager and would like
to vote.

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.

In any case, I'd like to have a local copy of the trac DB so that I
can be abusive to the RPC API while testing/building, work offline,
etc.

Can a DB dump be shared?

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[bur...@gmail.com]

Hi Jeremy,

And what about information on the page if the patch commits cleanly,
and if all tests pass after applying patch?
Not just sending email to the patch author, but making it visible to everyone.

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[Russell Keith-Magee]

On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck <jdu...@gmail.com> 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.

> In any case, I'd like to have a local copy of the trac DB so that I
> can be abusive to the RPC API while testing/building, work offline,
> etc.
>
> Can a DB dump be shared?

I don't have any problem sharing the raw ticket data. However, I'm not
sure if there's anything else in the database (like emails and
passwords/hashes) that we would want to strip out before sharing.
James Bennett is probably the man to poke on this front.

Yours,
Russ Magee %-)

[Jeremy Dunck]

On Fri, Apr 23, 2010 at 11:32 AM, Russell Keith-Magee
<freakb...@gmail.com> wrote:
...

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

(I put numbers in the 1st column in case people decide to sort later.)

Thanks for the detailed feedback. I was mostly brainstorming based
off the doc. If you have other suggestions, they're welcome. I'm
happy to exclude things that aren't useful -- less work to be done.

But on the objection of people that won't follow the process -- to
some extent, all of the failings I'm hoping to make more visible here
are failures to follow the process. As one example, if a ticket with
a patch sits unreviewed for weeks, that's a failure. Keep in mind I'm
not blaming anyone for this problem -- I just think there's not enough
visibility when these failures occur. Similarly, if a person is
willingly ignoring the process and has a history of it, that's a basis
of reputation -- one that's recognizable, not just in the
triager/commiter's head, but by anyone looking at the history.

Frequent contributors are not the only audience for this tool -- I'm
trying to help answer the question -- where is help most needed right
now?

With that perspective, does your feedback change?

In any case, I plan to do whatever people agree is most useful first.

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

I recognize running tests w/ regressions pass would be useful, but
it's getting into CI-land -- once we have some CI infrastructure in
place, I'd be happy to use that.

I think automatically moving patches that don't apply cleanly to
patch_needs_improvement automatically would be a useful first step.

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

Yeah, hmm. I'll have to think about this. Multiple partial patches
is a bug, IMHO, but alternative patches is probably good practice.

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

Sure, probably I was premature to say what to do when X goes wrong. :-)

> 12-14: Nifty stats, but I'm not sure they would help much

I'm basically hoping to give guidance on whether we're bailing water
fast enough. Again, probably not a core committer issue, but perhaps
will persuade people to work an existing ticket rather than adding a
new one, or to organize a sprint, etc.

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

Do you feel it's a burden to keep that eye on it? Do you think stuff
slips through? I mostly agree with you -- don't look a gift horse in
the mouth, etc.

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

Yep, I had the same thought, probably would only work well if there
was some guidance on the existing vocabulary.

> 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'm not sure the RPC interface has all the pieces needed, but I'd
prefer to get as far as I can with it.

What version of trac are we on? I'll look to see what
incompatibilities there are between 0.x and 0.y once I know that to
try and decide between the options.

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

Ah, yes, I was afraid this would come up. :-)

This quickly veers into the DVCS debate, python-vs-*, etc. If there
are trackers that are substantially better, I'm interested in hearing
about them, but I imagine it'll be more heat than light to try to find
something that solves our ailments. :-/

> I'm not a huge fan of Trac - it's
> got lots of quirks and bugs that annoy the bejezus out of me,

...
Perhaps upgrading would get us some distance?

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

+1

...

>> Can a DB dump be shared?
>
> I don't have any problem sharing the raw ticket data. However, I'm not
> sure if there's anything else in the database (like emails and
> passwords/hashes) that we would want to strip out before sharing.
> James Bennett is probably the man to poke on this front.

James? :-)

[Jacob Kaplan-Moss]

On Fri, Apr 23, 2010 at 11:32 AM, Russell Keith-Magee
<freakb...@gmail.com> wrote:

>> Can a DB dump be shared?
>
> I don't have any problem sharing the raw ticket data. However, I'm not
> sure if there's anything else in the database (like emails and
> passwords/hashes) that we would want to strip out before sharing.
> James Bennett is probably the man to poke on this front.

Actually, I've got a DB dump; I've sent it to Jeremy off-list. Anyone
else who needs it can email me -- Trac uses email addresses as PKs in
some places, and as it'd be hard to mask those I don't want to link it
publicly.

Jacob

[Russell Keith-Magee]

On Sat, Apr 24, 2010 at 2:34 AM, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 11:32 AM, Russell Keith-Magee
> <freakb...@gmail.com> wrote:

> Frequent contributors are not the only audience for this tool -- I'm
> trying to help answer the question -- where is help most needed right
> now?
>
> With that perspective, does your feedback change?

I can see what you're driving at. I can certainly see the value in an
automated tool generating a list of tickets with work that needs to be
done. It's a matter of finding the right way to form this list. It's a
little difficult to answer in the abstract - the best approach is
probably to build up some potential queries/lists and work out which
ones looks like good lists to throw out there as todo lists.

>> 12-14: Nifty stats, but I'm not sure they would help much
>
> I'm basically hoping to give guidance on whether we're bailing water
> fast enough.  Again, probably not a core committer issue, but perhaps
> will persuade people to work an existing ticket rather than adding a
> new one, or to organize a sprint, etc.

My fear is that the opposite could actually happen - some people
already seem to view "1700 open tickets" as "project in crisis";
giving lots of charts with slopes going the "wrong" way could have the
effect of providing more ammunition for these claims, and drive people
away.

>> 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.
>
> Do you feel it's a burden to keep that eye on it?  Do you think stuff
> slips through?  I mostly agree with you -- don't look a gift horse in
> the mouth, etc.

I don't think it's a particular burden - I'm not saying I read every
ticket in detail; I just do enough of a scan so that if I start seeing
a lot of tickets in a particular area, I can make a mental note to
investigate later.

As for stuff slipping through; In the short term, I'm sure you're
right. However, this is one of those aspects where the crowd brings
the really important stuff forward really quickly. I'm constantly
amazed at how often I mark a ticket as accepted, but then Karen or
SmileyChris or someone else closes it 10 minutes later as a dupe of an
older ticket that I'd forgotten about. On aggregate, I think we're
doing reasonably well on this front.

>> 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'm not sure the RPC interface has all the pieces needed, but I'd
> prefer to get as far as I can with it.

Some of the lists you're describing should be possible with custom
reports; [1] has some details, and I'm sure Trac's docs have more.

[1] http://code.djangoproject.com/wiki/TracReports

> What version of trac are we on?  I'll look to see what
> incompatibilities there are between 0.x and 0.y once I know that to
> try and decide between the options.

I'm not sure; I have a vague feeling it's something on the 0.10
branch, but I could be wrong.

>> 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.
>
> Ah, yes, I was afraid this would come up.  :-)
>
> This quickly veers into the DVCS debate, python-vs-*, etc.  If there
> are trackers that are substantially better, I'm interested in hearing
> about them, but I imagine it'll be more heat than light to try to find
> something that solves our ailments.  :-/

That is a risk. However, we only need a little light to point out the
door. I'm willing to ignore the heat in the hope of getting that
light.

There is one aspect in particular that I would love to see addressed,
and I'm not sure Trac has a way of representing the problem. It's the
"me toos".

There are three stats/lists in particular would be very useful:
1. Number of people that are interested in problem X. We might be
able to get this by counting the size of the CC list or the number of
unique commenters on a patch. Better still would be a specific way for
user X to report "I'm having this problem and would like it to go
away"

2. Number of people that have tried a specific patch, and report that
it works. Trac doesn't currently (to my knowledge) have a way for a
particular user to report that they have tried a patch, and that it is
working for them. If 10 people have independently tried a patch and
say it works, then that's a really good marker that the patch is
probably ready for trunk.

3. (and here's the really hard one) Same as 2, but weighted based on
reputation. For example, if there is a ticket with three people saying
it is ready to go, it makes a difference if those three people are
people like Alex Gaynor, of if they're John Q Public that has made no
other particular contribution. However, if John Q Public recommends a
patch that is committed to trunk, he should get a reputation boost,
and any other ticket that he has recommended should be promoted
slightly.

There's also the potential for something like this to be used as a
qualifier for official roles - you must have a reputation score of X
to be considered a triage team member, or a score of Y to be
considered for commit access.

I appreciate that (3) is a *huge* problem, and it needs to be
considered very carefully to make sure there aren't ways to game the
system, but that's the bit that I think Trac is seriously missing for
our purposes. A "Ready for Checkin" flag works fine if the team doing
that decision making is well controlled, but it just isn't rich enough
to capture the fact that in a crowdsourced review context, RFC isn't
really a boolean state.

>> I'm not a huge fan of Trac - it's
>> got lots of quirks and bugs that annoy the bejezus out of me,
> ...
> Perhaps upgrading would get us some distance?

Possibly. Was that you volunteering to become our Trac jockey? :-)

Yours
Russ Magee %-)

[Stephen Wolff]

>> 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.
>>
> I recognize running tests w/ regressions pass would be useful, but
> it's getting into CI-land -- once we have some CI infrastructure in
> place, I'd be happy to use that.
>
>

In case you missed it, there already is some CI infrastructure.... a
bunch of servers made available to django for testing via Hudson:

http://hudson.djangoproject.com/

Stephen

[yml]

Hello,

On Apr 23, 12:32 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

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
destination. More explanation about the process can be found here :
[4]. It is worth mentioning that the code review process provide a
simple UI to spot the merge proposal that "needs review" [6]. The
"code that failed to merge" is segregated in its own category.
* Anybody who is interested can contribute code to your project, in a
simple way, with full version control. They got offered the same set
of tool than the core developer to cook their proposal (Blueprint,
dvcs, code review, ...) once they think they their code is ready they
can propose it via the code review process.
* it has a web based translation interface [5]

Something which is orthogonal to the development process is that it is
hosted so it might reduce the workload on the Trac admin (disk full,
diff to big, spam, ...). I hope that this will not trigger a flame
war with this kind of assertion: github is better because it supports
git .... I try to keep this post on the macro feature that could
improve the community involvement and I understand that launchpad will
not be the silver bullet that will solve all the issues. From all the
bullet point above IMHO, an integrated code review process would be
one that could have the bigger impact because it could solve several
issues that the community have expressed recently :
* Educate the community : Subscribing to the code review would be an
extraordinary tool to get up to speed, to understand what is required
to get a modification (bug fixes, enhancements) in. The step to start
to becomes active on django-dev is too big, this could help to make it
more accessible.
* Open discussion : On the modification, the advantage there is that
on a single page we have all the information needed to understand the
context the 2 branches, the diff, and the comments
* We could eventually add a bot to that review in order to make sure
that the proposed branch passes all the tests with several
configuration: multiple db backend, multiple OS, ... .

There might be other advantages/inconvenients that I have not listed
so I would be glad to hear them from you.

Regards,
--yml

[Russell Keith-Magee]

I'm glad to hear that Launchpad's UI has been improved recently,
because the last time I played with it... well... I wasn't impressed.

UI issues aside, you raise some interesting features. I can see how
builtin translation and code review interfaces could be very useful; I
would be interested to see how they have implemented their karma
system.

However, the *huge* impediment that you have avoided mentioning is
that moving to Launchpad would require moving Django to using Bazaar
for version control. Moving to a DVCS has been proposed many times in
the past, and rejected. The reasons for this have been well
documented. I don't see the benefits of a bug tracking system
providing a compelling reason to override the existing arguments.

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.

[Dennis Kaarsemaker]

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!

[bur...@gmail.com]

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.

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[yml]

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 <freakboy3...@gmail.com>
wrote:

[Gabriel Hurley]

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

> <freakboy3...@gmail.com> wrote:

> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

[Alex Gaynor]

I can speak to the current status of piano-man. Right now it has
working VCS integration, timeline page, and ticketing system. The
biggest missing components are a) wikis, b) better access control, c)
auth integration (it doesn't feature any login system ATM, you have to
go to the admin to login :P). It's on my long todo list to continue
improving it, if people want to help out please do! Send me
questions, pull requests, whatever. If there's enough interest I'll
set up a mailing list, regardless let's try not to flood
django-developers with message about it.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Gabriel Hurley]

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 <yann.ma...@gmail.com> 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...

> You received...
>
> read more »

[yml]

On Apr 25, 5:21 pm, Gabriel Hurley <gab...@gmail.com> 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

[Russell Keith-Magee]

On Mon, Apr 26, 2010 at 2:34 AM, yml <yann....@gmail.com> 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.

[Russell Keith-Magee]

On Mon, Apr 26, 2010 at 4:48 AM, Gabriel Hurley <gab...@gmail.com> 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.

[Reinout van Rees]

On 04/25/2010 05:15 PM, 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. Moving to a DVCS has been proposed many times in
> the past, and rejected. The reasons for this have been well
> documented. I don't see the benefits of a bug tracking system
> providing a compelling reason to override the existing arguments.

No need to move to bzr in order to use launchpad's bugtracker.

As an example, our friends Zope and Grok have all their code in
subversion, but the individual python packages have their tracker on
launchpad.


Reinout

[yml]

Just to make it clear I am not saying that Launchpad is "The Solution"
to all the problems. I have decided to dig in its documentation and
post the feature that I found interesting and I discover that
launchpad has grown a some very useful features with regards to the
issues we were discussing.

On Apr 26, 1:05 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

> On Mon, Apr 26, 2010 at 2:34 AM, yml <yann.ma...@gmail.com> 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.

Launchpad is an open source bug tracking / community management
platform that you can download / hack / deploy on your own server [1]
here it is a page explaining how to do this [2]. Also I haven't try it
myself and I thought that having an hosted solution was more a
strength rather than a weakness.

>
> As for Drupal using launchpad - are you sure?

This assertion was from launchpad documentation I haven't verify it
further than checking that the import mechanism was in place. I have
used this particular mechanism several times on svn repository so I
know it works.

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

I am not sure to clearly understand this question, on this particular
page I see a couple attribute that help me to understand the nature of
each branch :
* name of the branch
* owner of the branch
* series
* status
and if a click on each branch I can read a longer description.

>
> Yours,
> Russ Magee %-)
>
> --

Regards,
--yml

[1] http://blog.launchpad.net/general/launchpad-is-now-open-source
[2] https://dev.launchpad.net/Getting

[rokcl...@gmail.com]

The timing of this discussion is interesting, because I came to a
similar conclusion last week and decided to start writing a drop-in
replacement for Trac based on Django. Part of my desire was based on
the fact that Trac has such poor support for other VCS and such spotty
support for other databases besides SQLite. Since then, it has been
brought to my attention that .12 has multiple source backend support
and is just a short time away from release. The database issue is
still at large as far as I know.

I pretty much agree with your thoughts on the topic. Adding Django to
the mix would enable a bunch of rich features, such as
internationalization and robust caching (how about stuffing a big diff
into memcache). It could be extended in very interesting ways since
it would just be a collection of Django apps. On the other hand, the
VCS specific bits are pretty much fine if you ask me, and my issues
are mainly with minor things in the ticketing and the underlying
infrastructure. As far as I am aware Trac is open source and the VCS
code could be integrated into such an application.

I would love to hear others' thoughts on that topic and how they would
see Trac's VCS plugins playing a role in such a system.

I have already started work on this project, but it is just a *really*
untested ticketing app at the moment. If anyone is interested, I can
post it on BitBucket.

On Apr 26, 1:54 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

[Jeremy Dunck]

On Sun, Apr 25, 2010 at 1:27 AM, Stephen Wolff <stephe...@gmail.com> wrote:
>> I recognize running tests w/ regressions pass would be useful, but
>> it's getting into CI-land -- once we have some CI infrastructure in
>> place, I'd be happy to use that.
>>
>>
>
> In case you missed it, there already is some CI infrastructure.... a bunch
> of servers made available to django for testing via Hudson:
>
> http://hudson.djangoproject.com/
>

I knew Eric was noodling on it, but didn't know it was up.

Eric, two questions:
1) is there (or could there easily be) a way to run the suite against
uncommitted patches (or a mirror repo with branch-per-patch attempt)?

2) in general, what happens if a malicious patch is run? I'm not
looking for total sandbox here -- but at least the understanding that
putting a machine into the test system means taking the risk that the
machine gets rm -rf'd or similar.

(Does anyone know of a general container for testing untrusted patches safely?)

[Alex Gaynor]

Trying out patches needs separate infrastructure from what Hudson
already provides AFAIK, plus as you point out there are various
sandboxing issues.

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Jeremy Dunck]

On Sun, Apr 25, 2010 at 5:37 PM, yml <yann....@gmail.com> wrote:
...

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

Thanks for this -- I'll be reading it shortly.

[Jeremy Dunck]

On Fri, Apr 23, 2010 at 10:26 PM, Russell Keith-Magee
<freakb...@gmail.com> wrote:
...

>>> I'm not a huge fan of Trac - it's
>>> got lots of quirks and bugs that annoy the bejezus out of me,
>> ...
>> Perhaps upgrading would get us some distance?
>
> Possibly. Was that you volunteering to become our Trac jockey? :-)
>

I've read the TracHacks wiki, it doesn't seem too bad. ;-)

I've just set up trac locally for testing (0.10.5, hoping that's
accurate), auth/xmlrpc working, hooray.

To be clear, I'm not against switching to a better ticket tracker, but
I haven't heard one proposed. I'll take a look at RedMine and/or
steal ideas from launchpad -- but writing a new tracker isn't the
problem I'm trying to solve.

If people want to propose other trackers they've been happy with,
please do. It would save me a lot of time if there was something that
already addresses my concerns. But meantime, I'm doing work against
trac, since it seems the shortest path to solving the problem I'm
seeing.

[Idan Gazit]

FWIW, I spoke with Alex the other week about turning piano-man into a
more finished product.

So long as core guarantees that they'll at least take a look at
whatever is made, I'm +1 on rolling our own, and am willing to
champion this project.

I think having something we can easily shape to meet our process needs
will be a Good Thing. A good ticket tracker helps devs paw through the
pile of tickets and keep kicking the ball forward with a minimum of
effort. Reducing the overhead on core will make those people's lives
more pleasant (and free up their time for dealing with, you know,
code.)

Another benefit: one of the complaints I (anecdotally) hear all the
time is that it is hard to contribute to django. Part of that is the
high bar we set for contribution, and the (necessary) process we
impose in order to prevent oopses, but I posit that a significant part
of the feeling stems from people confusing a lack of activity on their
ticket with a lack of activity. Making it easier for devs to update
tickets will help, and providing some kind of dashboard on project
stats will give us something to point to next time somebody throws
their toys out of the pram because their pony isn't being seen to.

I'll be in Berlin, and plan to sprint on piano-man there. Plan:

1. Figure out a handful of "most useful" tricks that trac doesn't
accomplish, and adding those to piano-man. I particularly like the
idea of baking in some behaviors like timed ticket death and other
things that prevent a buildup of detritus and cut down on ticket
gardening chores.
2. Put up a test instance with a dump of data from trac.
3. Kick the tires and see if it engenders interest.

If people think it's awesome, we'll keep going. :)

-I

[Gabriel Hurley]

On Apr 30, 8:02 am, Jeremy Dunck <jdu...@gmail.com> wrote:
> I haven't heard one proposed.  I'll take a look at RedMine and/or
> steal ideas from launchpad -- but writing a new tracker isn't the
> problem I'm trying to solve.

FWIW, I currently use (and administer) Redmine for my company. I'd say
it's only a marginal improvement over Trac overall. We like it better
because it's more friendly towards non-software project management,
and has easy workflow setup. But the big downside: it's Ruby/Rails.
The thing is a resource hog, and tends to be slower than I'd like
overall. There's a fair plugin community to add cool features, but
having tried a bunch of them I'd say they fall in the "unstable"
category more often than not.

Those are my two cents on Redmine.

- Gabriel

[Gabriel Hurley]

I'd also be interested in working on this, as long as I'm not alone on
it. Have you and/or Alex set up any kind of mailing list for it? Do
you plan to use git's issue tracker or something else? What's the
process plan for getting development kick-started on it?

- Gabriel

[Alex Gaynor]

To keep from bothering everyone on -dev about this I'll setup a
mailing list this evening, I'll put a link in the piano-man readme
when I do.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Luke Plant]

On Friday 30 April 2010 19:22:33 Idan Gazit wrote:
> FWIW, I spoke with Alex the other week about turning piano-man into
> a more finished product.
>
> So long as core guarantees that they'll at least take a look at
> whatever is made, I'm +1 on rolling our own, and am willing to
> champion this project.

Personally it would take quite a lot to persuade me to look at it
(sorry for not responding before, but I was prompted by this message).
I feel similar to Russell about fragmenting the bug tracking
community, but even more so - especially given that Trac is written in
Python, and already has a very active community of supporters. There
are Trac plugins for almost everything you can think of.

I would also be extremely loathe to switch if there is *any* loss of
information in the database conversion. So that includes requiring
identical bug numbers (so that SVN commit messages don't become
outdated) and supporting 100% of the wiki formatting in existing pages
and all bug reports (or being able to convert it losslessly), and
preserving the history of all changes (including flags) to bugs. It
is important to be able to look back at a bug report and see what was
changed by whom etc.

Once you add these requirements, I suspect that you will be doing much
more of a 'Trac clone' than you want to be. And we would still need
to have compelling reasons to switch - bare feature parity wouldn't be
anything like enough, especially given the team and community that are
behind Trac.

I imagine that adding several plugins to Trac would be a much better
route - in particular a code review plugin, of which there are several
on trac-hacks I think, and some plugins to do the auto-mail functions
that Jeremy suggested. If we fail to review the existing plugins to
Trac and see how easy it would be to add our own, it would be nothing
but a massive case of NIH. I have written some small plugins for Trac
in the past and found it fairly painless. While Trac may have it's
problems, we would have to be crazy - not to mention extremely
arrogant - to think that we could do better without a huge amount of
work.

And before anyone starts work on any of these, whichever approach,
please do get some consensus about what features are actually
desirable!

Luke

--
"It is a truth universally acknowledged, that a single man in
possession of a good fortune, must be in want of a wife." (Jane
Austen)

Luke Plant || http://lukeplant.me.uk/