[Numpy-discussion] YouTrack testbed
Thu Apr 12 11:04:26 CDT 2012
On Thu, Apr 12, 2012 at 5:37 PM, Bryan Van de Ven <email@example.com>wrote:
> On 4/10/12 2:40 PM, Ralf Gommers wrote:
> On Mon, Apr 9, 2012 at 10:32 PM, Bryan Van de Ven <firstname.lastname@example.org>wrote:
>> On 4/3/12 4:18 PM, Ralf Gommers wrote:
>> > Here some first impressions.
>> > The good:
>> > - It's responsive!
>> > - It remembers my preferences (view type, # of issues per page, etc.)
>> > - Editing multiple issues with the command window is easy.
>> > - Search and filter functionality is powerful
>> > The bad:
>> > - Multiple projects are supported, but issues are then really mixed.
>> > The way this works doesn't look very useful for combined admin of
>> > numpy/scipy trackers.
>> > - I haven't found a way yet to make versions and subsystems appear in
>> > the one-line issue overview.
>> > - Fixed issues are still shown by default. There are several open
>> > issues filed against youtrack about this, with no reasonable answers.
>> > - Plain text attachments (.txt, .diff, .patch) can't be viewed, only
>> > downloaded.
>> > - No direct VCS integration, only via Teamcity (not set up, so can't
>> > evaluate).
>> > - No useful default views as in Trac
>> > (http://projects.scipy.org/scipy/report).
>> Ralf, regarding some of the issues:
> Hi Bryan, thanks for looking into this.
>> I think for numpy/scipy trackers, we could simply run separate instances
>> of YouTrack for each.
> That would work. It does mean that there's no maintenance advantage over
> using Trac here.
> Also we can certainly create some standard
>> queries. It's a small pain not to have useful defaults, but it's only a
>> one-time pain. :)
> That should help.
>> Also, what kind of integration are you looking for with github? There
>> does appear to be the ability to issue commands to youtrack through git
>> commits, which does not depend on TeamCity, as best I can tell:
>> I'm not sure this is what you were thinking about though.
> That does help. The other thing that's useful is to reference commits
> (like commit:abcd123 in current Trac) and have them turned into links to
> commits on Github. This is not a showstopper for me though.
>> For the other issues, Maggie or I can try and see what we can find out
>> about implementing them, or working around them, this week.
> I'd say that from the issues I mentioned, the biggest one is the one-line
> view. So these two:
> - I haven't found a way yet to make versions and subsystems appear in
> the one-line issue overview.
> - Fixed issues are still shown by default. There are several open
> issues filed against youtrack about this, with no reasonable answers.
> I don't believe there is a solution for the first issue. There are tickets
> on YouTrack filed specifically asking for this feature, but it does not
> seem clear they want to implement it.
> For the second, I created a saved search called "open" that I think should
> show up for all users (let me know if it does not). The nice thing is, this
> save search can be referenced in other searches, so you can do:
> saved search: open Subsystem: test3 sort by: updated
> and get all the open tickets for that subsystem. I think basically it's
> just a different type of workflow, fixed tickets show up "by default"
> because everything shows up by default, there is no search criteria to
> exclude them. But it seems easy enough to combine searches to get what you
Well, not that easy. For example, if I want to go through all open tickets
and get an overview of how many open tickets there are for each scipy
module. In Trac I can just sort by "component" and see the (approximate)
answer. In Youtrack I'd have to execute "saved search: open Subsystem:xxx"
once for each module.
Of course a tracker with a useful REST API where you could get the exact
answer with a few lines of Python code would be even better....
Another trac feature that I did realize is missing is a "group by"
> functionality. So you can sort by subsytem, but there is no notion of
> nicely grouping by them as in trac. There's a feature request for this,
> too, but who knows if or when it will get put in.
> Travis mentioned he had created a code.google.com site for numpy a long
> time ago that never got used. I think Maggie is going to create a few dozen
> test tickets on its issue tracker today and then we can also have that to
> evaluate as well.
Is that necessary? I think there's a reason no one has suggested it so far
- it has very few features. Plus it's blocked in China (and probably other
countries too), which is enough of a problem in my opinion to immediately
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion