Pirut: Edit -> Repositories mock-up.

[Jeremy Katz]

On Mon, 2007-07-09 at 23:15 +0530, Debarshi 'Rishi' Ray wrote:
> > 1) Jim is getting more involved in Fedora and wants to enable the
> > updates-testing repository so that he can be involved in testing
> > updates.  Also the disable case here.
> 
> I think this is already taken care of. Click the checkbutton beside
> every repository.

You're missing my point here... the idea _ISN'T_ "how does the UI mock
up match with the use cases".  It's more "determine the set of use
cases.  Based on them, work on the actual interface".  You _start_ with
the use cases, not the mockup.

> > 2) John has a local mirror that he prefers to use for getting his Fedora
> > updates and would like to point directly at it rather than the mirror
> > list.
> 
> This can be done by either adding a 'New' repository, or by 'Editing'
> an exiting repository.

Again...

> > 3) Sue read about some new software that's available from $vendor and
> > would like to add their repo so that she can install and try it out.
> > 4) $vendor provides a repo file on their website and would like to have
> > it be easy for end-users to add that to their configs
> 
> Do you want a way one can select a RPM which offers repository
> configuration for $vendor, rather than manually entering the relevant
> information?

If the vendor is providing it via an RPM, then the user just installs
the RPM.  They can even do so right from the browser.  This is more the
case where they say "the repo is at http://some.site.com/path/to/repo"
and you then have to go configure it yourself.

> > Of these, the first three are all things that are going to be pretty
> > sensible and fit in with the target audience of pirut.  The fourth

^^^ erm, the last should be the fifth.  And the fourth is valid as well.
> > really isn't and so it's probably not worth trying to look at Sally's
> > needs.
> 
> What is the target audience of Pirut? If we can offer most of the
> functionality of the CLI through the GUI, and at the same time use
> reasonable default values and ensure that the advanced settings do not
> clutter the GUI and intimidate the beginners, we would have a good
> solution.

The idea with pirut has never been to provide "the functionality of the
CLI wrapped up in a GUI".  Rather, we want to expose the things which
are good for the majority of users.  If you need every bit of
functionality of the CLI, then really, you're probably a better target
user for the CLI not pirut.

> > * As Rahul said, what's the real use case for making changes but not
> > saving them?  I think that ends up being a bit more of a power-user
> > thing and probably more confusing than not for pirut
> 
> First of all the checkbutton is set to 'on' by default, which is what
> most people would want. However a --enablerepo/--disablerepo like
> thing can be quite useful at times.
> 
> Say X has temporarily migrated from his network and can not access any
> of the upstream mirrors. Now he wants to use Pirut to remove package
> P. Currently Pirut will simply fail to contact any of the configured
> repositories and fail. Instead we can give him an oppurtunity to turn
> off all the upstream repositories on a one-off basis, so that he can
> start Pirut and remove P.
> 
> True this feature might be a bit advanced, and we can hide it away
> under some drop-box called "advanced settings", or something like
> that.

So, why do this in the repository editor?  I'd argue the _better_ way to
handle this is:
a) Use with what's installed should be fixed to be okay if you don't
have any repos set up/accessible.  This is pretty straight-forward to do
b) If a single repo fails to set up (or multiple, where n < total number
of repos), allow a way to do a temporary disable then.

_Not_ to shoe-horn it in as something associated with repository
editing.

> > * The authentication tab seems likely to be a bit of micro-management.
> > Also, even if there's a good case for the user to want to care, why is
> > it separate and global rather than per-repo?  Especially as the gpgkey
> > bits are all generally set on a per-repo basis
> 
> Okay. I took this from Synaptic. Do you want to handle the key
> management from the 'Edit' dialog? eg., user selects a repository and
> clicks 'Edit', and then gets an oppurtunity to disable gpgcheck or
> permanently delete the key.

I don't know if that's interesting or not.  Maybe.  Maybe not.
Definitely more reasonable that way than as its own high level thing

> > * What's the difference between Add and Add CDROM?  A repo is a repo,
> > and distinguishing between where they come from is going to be a little
> > painful.  Especially as a repo can have both URLs and a way to access it
> > via media (add mediaid= to the repo config)
> 
> True, but since we already know the layout of the Fedora DVD, we can
> relieve an entry level user from entering the details of the DVD
> manually.

But why should it be separate at the top level there?  Adding a
repository can be an easy thing to do.  Hell, the Fedora DVD should be
set up _by default_ to be accessed as the core repo, but that requires
someone to write some code so that we can do a reasonable job of writing
out repos at install time.

> Now that you say so we can also provide a feature in the 'Edit'
> dialog, whereby the user can chose whether to access a repository
> through a URL or media. However I need to learn about this mediaid=
> thing. Don't know much about it. :-)

It's part of how yum at the API level now can really handle media.

> > * What's a channel?  It says it's a repository manager but then seems to
> > be dealing with something that's channels?
> 
> I took most of the strings from Synaptic. Please suggest something
> else. "Repositories" would be alright?

Probably.  

> What I want to convey is that although a GUI tool will be most often
> used by newbies, we can also make it attractive for non-newbies (say
> intermediate level) users too. eg., Synaptic does provide a wide range
> of configuration options, which on hearing may sound intimidating.
> However the GUI is so designed and the default values are such that it
> simply works out of the box in most cases, making it an attractive
> tool for newbies and non-newbies alike.

Lots of options is _not_ the answer to making a tool attractive to
"non-newbies". 

Jeremy