On 07/09/2012 08:00 AM, Tim Lauridsen wrote:


On Sun, Jul 8, 2012 at 7:43 PM, Alec Leamas <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@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@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 :)