On Thu, Oct 28, 2010 at 10:36:40PM +0200, Gianluca Montecchi wrote: > 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).
Some of the dependencies are earlier targets. Perhaps a better
example of would have been:
wk...@thialfi be $ ./be depend --severity target --status all -t 0 /47c
bea/47c blocks:
bea/4fc:ct: patch-52
bea/bd0:ft: 0.2
bea/bd0:ft: 0.2
> 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.
> > 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
If 2.0 is independent, I think the target list would be fine as:
1.2
1.3
2.0
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 ;).
> > > 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?
> 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?
> 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 ;).
> 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`.
--
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
pgpxjrfeC9vPC.pgp
Description: PGP signature
_______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
