On Thursday 28 October 2010 21:11:26 W. Trevor King wrote: > On Thu, Oct 28, 2010 at 03:13:21PM +0200, Gianluca Montecchi wrote: > > I have not a way to sort the targets in the order I want, since when > > I read the bug list, they are reported in creation order, with the > > newer first. > > Cheap answer: > > I think targets can be ordered by with dependency trees, and sorted by > $ ./be depend -t 0 /773 > bea/773 blocked by: > bea/275:fm: Fix Unicode handling. > Although of course you'd want to reformat the output for HTML.
Ok, but this order all the bugs of this target, that is interesting but it is not what I need (for this time). 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 ? > Mid-range answer: > > I suggest people just pick a sane target naming scheme that can be > sorted correctly by distutils.version.LooseVersion (see PEP 386 [1]), > and we add a LooseVersion-based summary sorter. Right, but still, no way of saying that v2.1 will be released before release 1.3 and after 1.2. There is always the possibility that I miss something... PEP 386 is usefull if you have only one tree, not it you have two tree because you have a stable tree and a devel tree. > Luxury answer: > > Also the depend field it is not usefull in this occasion, since while it > > is still true that a 1.1 version will be released after a 1.0 version, > > it is not always true that a 1.2 version will be released before a 2.0 > > version, so > > If the order of 1.2 vs 2.0 is not defined, we can list them in > whatever order we want. 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 > > 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. > If you want a dependency-ordered list, you could traverse the > dependency tree à la libbe.command.depend.DependencyTree, which would > break your list of targets into disjoint trees. Then you'd have to > develop a way to sort disjoint trees (e.g. by root, or "greatest" tip, > or ...). A step in this direction would be generalizing > libbe.command.depend.DependencyTree to libbe.command.depend.DiGraph. I already have a way to extract only the bugs of a certaint target. What I miss is the order between the targets. 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. 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) > > 1) add a field "deadline" to the bug > > I think the "targets as bugs" treatment is worthwhile because it keeps > the base system simple while allowing people to use targets if they > want. I agree on this > We should try to restrict feature extensions to things that > work nicely in libbe.commands.*, and not go delving into the base > system in libbe.* itself. Again, I agree but, I don't see as totally useless the fact to add a deadline in the bug properties, also if I agree that such change should be done very carefully. 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 ?" I will send another way with a proposal to solve this. bye Gianluca _______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
