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:
> On Sun, Apr 25, 2010 at 10:54 PM, yml <yann.ma...@gmail.com> wrote:
>> Hello,
>>
>> On Apr 23, 12:32 pm, Russell Keith-Magee <freakboy3...@gmail.com>
>> wrote:
>>> 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.
>>>
>> 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.
>
> 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.
>
> 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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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.
