On Thu, Oct 28, 2010 at 07:26:12PM -0400, W. Trevor King wrote:
> On Thu, Oct 28, 2010 at 10:36:40PM +0200, Gianluca Montecchi wrote:
> > Bonus question: why 'be depend /773' output
> >
> > bea/773 blocked by:
> > bea/275
> >
> > while 'be depend -t 0 /773' output
> >
> > bea/773 blocked by:
> > bea/275:fm: Fix Unicode handling.
> >
> > ?
> >
> > Should not be the output coherent ?
>
> Good point. Fixed in my branch.
Thanks.
> > Right, but add a 1.3.
> > The output should be
> > 1.2
> > 2.0
> > 1.3
> >
> > since 1.3 depend on 1.2, but 2.0 is indipendent from any 1.x version
>
> If 2.0 is independent, I think the target list would be fine as:
> 1.2
> 1.3
> 2.0
Not always.
But anyway, as I already said, it is more important to know what is/are the
next target to reach.
> Also, if they were independent, they would probably be in independent
> VCS branches so the 1.3 target would not exist in the .be/ repository
> of the 2.0 branch ;).
Good point.
> > > > I cannot set that V2 depend on V1.2, but even if I do it, I still get
> > > > that V2 will be showed before V1.2 since it is newer.
> > >
> > > This is because of the default sort (libbe.bug.cmp_full) sorts by
> > > time. The list sorting code (libbe.command.list.List._sort_bugs)
> > > shows how you can sort a list of bugs by any parameter you like.
> >
> > I find it, but it seems that it does not work.
>
> Can you post an example of it not working?
I already send a mail on Oct. 28 about this...
anyway:
this is the traceback:
grys:~/Devel/BulbCalculator> be list -S time
Traceback (most recent call last):
File "/usr/local/bin/be", line 26, in <module>
sys.exit(libbe.ui.command_line.main())
File "/usr/local/lib/python2.6/dist-packages/libbe/ui/command_line.py", line
332, in main
ret = dispatch(ui, command, args)
File "/usr/local/lib/python2.6/dist-packages/libbe/ui/command_line.py", line
264, in dispatch
ret = ui.run(command, options, args)
File "/usr/local/lib/python2.6/dist-packages/libbe/command/base.py", line
534, in run
return command.run(options, args)
File "/usr/local/lib/python2.6/dist-packages/libbe/command/base.py", line
262, in run
self.status = self._run(**params)
File "/usr/local/lib/python2.6/dist-packages/libbe/command/list.py", line
168, in _run
self._parse_params(bugdir, params)
File "/usr/local/lib/python2.6/dist-packages/libbe/command/list.py", line
192, in _parse_params
for cmp in params['sort'].sort_by.split(','):
AttributeError: 'str' object has no attribute 'sort_by'
grys:~/Devel/BulbCalculator> be --version
fe99ef2f6148790ef792ecf47ca3629a4d367890
> > Of course I can develop some way to force a order in the "be html" command,
> > like a reverse order or something else, at least passing explicitally a
> > string
> > to the html command that specify the order.
>
> Again, I think LooseVersion will do a good enough job. How many open
> targets do we expect to be dealing with here?
In my project now I have 3 open target:
- V2_0
- Next_version
- Undefined
but of course you can think about a more complex development path with about
10 open target planned in a year.
> > I think that also for the command "be list" can be usefull to display the
> > bugs
> > sorted by target (and sort the target reflecting the programmed release
> > plan)
>
> From the command line, I would do that with:
> for bug in $(be list --severity target --ids); do
> echo $bug;
> be depend --show-status --show-summary $bug;
> done
> If you have a nice interface bundle that into a single `be list`
> call, go ahead ;).
Nice script. But I think that is better to integrate it in a single
'be list'. I will think about it (and the target command expasion) after I
finish the rework on the html command
> > Anyway, thinking about it a little more, actually, what I need is more
> > something like "what is the next target I should complete ?" than "what is
> > order of the tags ?"
>
> That sounds like libbe.bugdir.BugDir.target. Perhaps it needs a
> better interface than `be set` and `be target --resolve`.
I have a plan (I posted it). As soon as I get some free time, I will try to
implement all the two options I proposed. Maybe one of them will be a good
solution.
bye
Gianluca
_______________________________________________
Be-devel mailing list
[email protected]
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
