Re: Pirut: Edit -> Repositories mock-up.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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?

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
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.

* 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.

* 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.

* 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.

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. :-)

* 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?

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.

Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux