On Sun, Jul 8, 2012 at 7:43 PM, Alec Leamas <leamas.alec(a)gmail.com
<mailto:leamas.alec@gmail.com>> wrote:
On 07/08/2012 07:08 PM, Tim Lauridsen wrote:
> On Wed, Jul 4, 2012 at 3:41 PM, Alec Leamas
> <leamas.alec(a)gmail.com <mailto:leamas.alec@gmail.com>> wrote:
>
> On 07/04/2012 03:06 PM, Stanislav Ochotnicky wrote:
>
> Quoting Alec Leamas (2012-07-04 14:48:45)
>
> I have looked into the f-r functions to assign,
> comment and login· From
> my perspective, they seem "odd" and not really
> focused on f-r's main
> task. Furtjhermore, they clog the CLI interface and
> are hard to test
> requiring some kind of bugzilla test account with
> unclear implications.
>
> As stated in #67, the already existing dependency
> python-bugzilla have a
> bugzilla tool which can do all this (assign, comment
> etc) and much, much
> more. I find it reasonable to point users to this
> tool rather than
> keeping overlapping functionality in f-r.
>
> Ergo: remove the function assign, login and comment
> from f-r. However,
> removing functionaltiy is not to be taken lightly.
> So: has anyone strong
> feelings about these functions, please speak up,
> either here or in the
> bug #67 :)
>
> A feature branch 'rm-bugz' is in git repo for review.
>
> Truth be told, I don't mind removing the code from f-r.
> However...how
> about we provide a wrapper for python-bugzilla? Just a
> simple shell
> script mind you (which would directly call "bugzilla").
> This way we
> would still provide users with simplified way to assign
> bugzilla and
> perhaps do the approval part as well.
>
> If anything, I'd like to keep the commandline options
> there and when
> invoked they should print out suggested workaround so
> people who were
> using them won't be (too) surprised.
>
> This is not fair - I know you are going on holiday. Don't
> worry, I''l wait until you're back to complete this discussion
:)
>
> With this said, one of the objectives is to get rid of the
> command line options. They are simply too many, and it's
> hard to read the help page. One idea could be to have to old
> options 'assign', 'login' etc as invisible options, just
> spitting out some "use bugzilla instead" text. And of course,
> the manpage could have some transition text on this.
>
> However, expanding the interface with the obvious 'approve'
> part is going in the wrong direction IMHO.
>
> Also, I'm not really fond of the wrapper idea. The complexity
> if the CLI is not a technical problem, the python
> code is not that hard. The problem is the user interface,
> and a wrapper doesn't change that. It's just more complicated
> code.
>
> BTW, my gut feeling is that this part is not that heavily
> used. Might be wrong, but...
>
> --alec
>
>
> _______________________________________________
> fedorareview mailing list
> fedorareview(a)lists.fedorahosted.org
> <mailto:fedorareview@lists.fedorahosted.org>
>
https://fedorahosted.org/mailman/listinfo/fedorareview
>
>
> removing '--assign' would be very bad in IMO, it is a very useful
> functionality and very good related to a review tool
>
> Tim
>
Hi Tim!
Thanks for speaking up!
With this said: f-r has currently 15 options, and 47 lines of
help. All but three bz opts are related to the same task: to
create a review template. This makes the bz options sort of 'out
of scope'. Also note the testing problems for these, since they
require a test account which might not be easily distributed.
OTOH, if we should support the complete life cycle there should
not just be 'assign', but also 'approve' and perhaps also
'comment'. Together with 'login' and 'user id' this makes up
to
five options, none of which related to what I think most users
perceive as f-r's core task.
And there is this tool bugzilla, which actually is maintained sw
which does all this, although requiring more options even for
simple cases like 'assign'.
Current code (rm-bugz) branch contains some text written when
--assign et. al. are invoked. This must be the case for first
release making this move IMHO
Maybe we should provide another tool like 'fedora-bz' which
provides a complete life-cycle support (assign, deassign, approve,
comment...) implemented as a wrapper to the bugzilla tool. Thus we
could give users this complete functionality without expanding
the user interface and complexity of f-r.
Would this be acceptable?
--alec
--aelc
Splitting the bugzila functionality into a separate tool could be a
way to go, but telling people to use the bugzilla tool from python
bugzilla is not, we what to help people doing review related tasks in
a easy way not hurt them :)
Another way could be using commands in fedora-review, like
fedora-review assign <bz report no> will assign the bugzilla report
fedora-review review <bz report no> will make the review
fedora-review upload <bz report no> will upload the repost to the
bugzilla report.
it will make it easier group the help and show only options there
relates to a give command.
and we can do stuff like
fedora-review help <command> to get help about a given command
And we could add a bash-completion profile to reduce the typing.
and it will make the tool work more like ex. the fed-pkg tool.
Tim
I think it makes sense to split. For many (most?) users f-r is used to
make the review template - everything else is done through the browser:
assigning, pasting the report, approving etc. For these, commands like
above adds nothing but added complexity. OTOH, the functionality they
use is available whether they use a bugzilla bug #, an e. g. rpmfusion
url local packages.
OTOH, there is another group of users who wants to make the assign,
approve etc using the CLI interface. They need to talk to a bugzilla
instance, and has a specific set of capabilities and semantics.
All this is best handled by removing the 'bugzilla' stuff from f-r, and
creating a separate tool for them.
Or?!
-.-alec
PS: I think we should be careful about writing things like f-r will
"make the review". We all know it doesn't, it makes a review template.
But not everyone out there knows that we know :)