[see also the start of this discussion here: https://sourceforge.net/tracker/index.php?func=detail&aid=1962842&group_id=191105&atid=936036\]
My answer to the Neil's comment (see last paragraph):
it seems that You don't trust me. This can be the only reason why You don't want to include the repository created by me (http://appupdater.svn.sourceforge.net/viewvc/appupdater/server_data/?sortby=date) in Appupdater by default. In such a case why on earth should I trust You?!? My name is one of the two on the SourceForge project summary page. I feel myself responsible for the default repository shipped with Appupdater. But I have no access to it.
The goal of the project cannot be just to write a piece of software but also to be a trustful source and provider for a software repository. I placed my repository in CVS and under GPL and I see it not as my own but as a project's repository. You placed yours on a server where only you have access and the license is also unknown. I don't feel comfortable writing software for a default repository hosted this way.
Wouldn't it be fair to delete the reference to your repository too and ship Appupdater without a default repository? Yes. But it is by far not the best solution. Second best in my opinion is to include both or merge them.
Users will change the default settings if they have a compelling reason to
do so. I refuse to be in the business of deciding who should or should not
have root access on someone else's computer, so we are secure by default.
This isn't just about you but it is also for anyone else that might be
creating a repository in the future. User interaction must be used to
grant this access. Example, debian-multimedia is a Debian repository that
must be added manually and it seems to be plenty busy:
I looked at this other repository... why can't they be merged? seems like apps that could be included in the default one.
I hope you guys can work out the differences.
2 people keeping one repo up to date would be a good thing IMO :)
Do I trust you with root access on my computer? No, I don't. I don't know you or anything about you. And I'm paranoid. :-)
There is a fundamental difference between the code in a repository and the code for the Appupdater application itself. Once you download and install Appupdater, it will do its thing and is predictable in behavior. There is plenty of time for community review. Repositories are constantly being updated and have the potential to change on a daily basis without the user's knowledge, at least not until it has done something bad. Historically, the program author and repository author have been one in the same (me), so it made sense to have it there by default.
My repository is not licensed, it is public domain. I'm pretty sure you can't apply a license to it, not GPL anyway, since it is not copyrightable material, you can't copyright facts/information. You can also add or remove any and all repositories from Appupdater, including mine.
> The goal of the project cannot be just to write a piece of software
Yes it can. The goal of the project is to have the community manage repositories. This can be an individual, like you, or a particular project/corporation or a website like sourceforge.net. This will follow very closely to the Metalink model. The Maemo platform is another good example, basically our goal is to be like this guy, just have a list, the user picks which ones he/she wants:
Now as for a solution, I've thought about not shipping with a default repository. We could make this part of the install process or the first run to select the ones they want. This is the best option I see right now. I don't see any advantage in merging the two, Appupdater does that automagically on the client side already. You know my thoughts on multiple defaults. And of course there is just keeping it how it is. Any other ideas from anyone?
See also Security Concerns: https://sourceforge.net/forum/forum.php?thread_id=1898239&forum_id=673167
I've created a mockup of the dialog that can be shown at the first start: https://sourceforge.net/tracker/download.php?group_id=191105&atid=936036&file_id=278179&aid=1962842
Neil, if you change the Tk GUI, I would do the same for Qt.
Maybe we come up with a better solution for the next release.
although 1.0 is a great step forward, I am really disappointed with it. Neil managed to release a version that does *not* ask upon the first execution about the default repository. Even worse, it just tries to download www.nabber.org-files. Further Neil don't want to change the source and he doesn't even answer to my e-Mails.
Well, this is my last attempt to reach him before I leave this project. I'd really like to hear his answers.
I can dig through the email history and see exactly what happened if you want, but I'm pretty sure you didn't ask any questions, so I didn't respond. I think there were two emails like that. I also would like to see your evidence that I "don't want" to change the source. From my previous comment on this thread:
"Now as for a solution, I've thought about not shipping with a default repository. We could make this part of the install process or the first run to select the ones they want. This is the best option I see right now."
I take great pride in the stability and ease of use of Appupdater, especially for non-technical users. I plan to implement the feature to select your starting repositories in the installer in the next stable release. The bug is still open, I haven't closed it or set it to pending. That said, it didn't go into 1.0 or 1.0 bugfixes because:
1. The code hasn't even been created yet for the installer, command line, and other GUI. This could introduce last minute bugs into a stable release.
2. There is no way to dynamically update the repository list as new repositories pop up (current implementation is hard coded). New or discontinued repositories would require a new release every time.
3. The current implementation is not complete. The user should be to run the installer (and select repositories there) in case they never run the GUI. They should be able to run through the installer and the service will run in the background, update their programs, without further need for configuration.
4. You still have the ability to add your own custom repositories manually.
5. You will still get dynamic suggestions of which repositories to use as they become available.
6. This is the same default repository that has been used since the first release.
I am happy to say that items 1-3 have been included in the 1.2 release!
I'm sorry to say that but I'll stop my contribution to the project until it gets a default repository where everybody can contribute to.
see you after the 1.1 release
In the interest of fairness I've changed the code such that there is no default repository, the user is prompted to choose one or more during install or first run if needed.