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
