[pacman-dev] community is active by default
Hi, I don't know if anyone post this before. community is by default activated in the /etc/pacman3.conf In pacman2 it wasn't activate by default. Was this a mistake or should it be active by default? Bye, Daniel
2007/2/13, Isenmann Daniel <daniel.isenmann@gmx.de>:
Hi,
I don't know if anyone post this before. community is by default activated in the /etc/pacman3.conf
In pacman2 it wasn't activate by default. Was this a mistake or should it be active by default?
IMO it should be active by default. Whya not? :-) -- Roman Kyrylych (Роман Кирилич)
2007/2/13, Isenmann Daniel <daniel.isenmann@gmx.de>:
I don't know if anyone post this before. community is by default activated in the /etc/pacman3.conf
In pacman2 it wasn't activate by default. Was this a mistake or should it be active by default?
I'm thinking that's a good choice to activate community repo by default in /etc/pacman3.conf -- Giovanni Scafora Arch Linux Trusted User & Package Maintainer (voidnull) http://www.archlinux.org linuxmania@gmail.com
Am Tue, 13 Feb 2007 21:00:05 +0100 schrieb Isenmann Daniel <daniel.isenmann@gmx.de>:
Hi,
I don't know if anyone post this before. community is by default activated in the /etc/pacman3.conf
In pacman2 it wasn't activate by default. Was this a mistake or should it be active by default?
Bye, Daniel
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
O. Already two votes to have it enabled by default. It should be disabled by default! So it was in the past. Everybody should carefully decide if he wants to trust in the TU's work or not. From a developers view I want to have it strictly apart from what we call "official" packages. For x86_64 we have a special more critical situation. We only have a few packages. They are often outdated (=security risks or not usable at all). I have the feeling the 64bit TUs take only care about their certain "lib32" interests. So our Community packages may add 32bit libraries what is in contrast of the intention the x86_64 port has. I'm very disappointed about the x86_64 community repo situation right now. I'm not going to have that repo enabled by default at this time. I'll cc this mail to the TUs list. I hope the situation will change one day. AndyRTR
2007/2/13, Andreas Radke <a.radke@arcor.de>:
Am Tue, 13 Feb 2007 21:00:05 +0100 schrieb Isenmann Daniel <daniel.isenmann@gmx.de>:
Hi,
I don't know if anyone post this before. community is by default activated in the /etc/pacman3.conf
In pacman2 it wasn't activate by default. Was this a mistake or should it be active by default?
Bye, Daniel
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
O. Already two votes to have it enabled by default.
It should be disabled by default! So it was in the past. Everybody should carefully decide if he wants to trust in the TU's work or not.
From a developers view I want to have it strictly apart from what we call "official" packages.
For x86_64 we have a special more critical situation. We only have a few packages. They are often outdated (=security risks or not usable at all). I have the feeling the 64bit TUs take only care about their certain "lib32" interests. So our Community packages may add 32bit libraries what is in contrast of the intention the x86_64 port has.
I'm very disappointed about the x86_64 community repo situation right now.
I'm not going to have that repo enabled by default at this time.
Ehm, how it will hurt if user doesn't install package from Community? When user does pacman -Ss editor he/she will get a list of packages _and_repos_ where they are. User can choose if he/she want to install some community package. From my point of view enabling community repo by default will just make -Ss searching from larger list. So new Arch users will be quickly aware of packages in community. Most users enable community repo anyway. Anyway IMHO it's not critical question to have community enabled or disabled by dafault. -- Roman Kyrylych (Роман Кирилич)
Man, I recall this conversation somewhere with someone... but gmail fails to find wtf I'm talking about. Basically, here's the reasoning: the community is maintained by "Trusted Users". The packages should be safe because they are "Trusted". A repo disabled by default implies, to a user, that it's unsafe to use. (testing and unstable). Community, however, it not unsafe. We trust the Trusted Users, right? If, for x86_64, you want to disable it by default, that's fine. Disable it. But in CVS and in the i686 package, it should be enabled by default.
Am Dienstag, 13. Februar 2007 21:44:34 schrieb Andreas Radke:
It should be disabled by default! So it was in the past. Everybody should carefully decide if he wants to trust in the TU's work or not.
From a developers view I want to have it strictly apart from what we
call "official" packages.
I think [community] should be disabled by default, too. Useres should use it at their own risk and they should know that those packages are maintained by the community. Another important point is bugreporting. Users should not file bug-reports of community-packages at bugs.archlinux.org; and I think they`ll do if it is enabled by default. -- http://www.archlinux.de
2007/2/13, Pierre Schmitz <pierre@archlinux.de>:
I think [community] should be disabled by default, too. Useres should use it at their own risk and they should know that those packages are maintained by the community. Another important point is bugreporting. Users should not file bug-reports of community-packages at bugs.archlinux.org; and I think they`ll do if it is enabled by default.
I agree with your second point (about bugreporting), but I don't think disabling of community by default solves this issue. I close few bugs in AUR (mostly Community) packages every week. Instead, a big fat warning on bugs.archlinux.org is needed to pay users' attention to this. -- Roman Kyrylych (Роман Кирилич)
Am Dienstag, 13. Februar 2007 22:16:50 schrieb Roman Kyrylych:
I agree with your second point (about bugreporting), but I don't think disabling of community by default solves this issue. I close few bugs in AUR (mostly Community) packages every week. Instead, a big fat warning on bugs.archlinux.org is needed to pay users' attention to this.
But I think we should separate current, extra and community from each other. Otherwise there would be no different in being a TU or Dev. Well, [community] shouldn`t be dangerous but its packages or more unstable. -- http://www.archlinux.de
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Otherwise there would be no different in being a TU or Dev. Well, [community] shouldn`t be dangerous but its packages or more unstable.
That's incorrect. The community repo, in general, has *less important* packages, not *less stable* packages. Think about it this way: If a package goes from community to extra, what makes it magically more stable? The Maintainer: tag in the PKGBUILD?
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> > I think [community] should be disabled by default, too. Useres should use it
at their own risk and they should know that those packages are maintained by the community. Another important point is bugreporting. Users should not file bug-reports of community-packages at bugs.archlinux.org; and I think they`ll do if it is enabled by default.
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
2007/2/13, Aaron Griffin <aaronmgriffin@gmail.com>:
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> > I think [community] should be disabled by default, too. Useres should use it
at their own risk and they should know that those packages are maintained by the community. Another important point is bugreporting. Users should not file bug-reports of community-packages at bugs.archlinux.org; and I think they`ll do if it is enabled by default.
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
Because there are comments in AUR for this task. -- Roman Kyrylych (Роман Кирилич)
Am Dienstag, 13. Februar 2007 22:26:17 schrieb Aaron Griffin:
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-) -- http://www.archlinux.de
2007/2/13, Pierre Schmitz <pierre@archlinux.de>:
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
I think the field comments is sufficient. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania@gmail.com
On 2/13/07, Giovanni Scafora <linuxmania@gmail.com> wrote:
2007/2/13, Pierre Schmitz <pierre@archlinux.de>:
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
I think the field comments is sufficient.
So, what if a package has 20 or so bugs over the course of it's lifetime. Each bug having 2-3 responses from the maintainer and the users. That's a lot of comments with no order to it. One could say "delete the old ones", but then you lose history, which is important sometimes. AUR comments are NOT sufficient to replace a full blown bug tracker. Hell, if it WAS sufficient, why don't we move the AUR comments scheme to the official package list? No more package bugs in the bug tracker, use the package comments. Sounds like a bad idea. For the same reason, deeming AUR comments sufficient for bug tracking is equally as bad.
2007/2/13, Aaron Griffin <aaronmgriffin@gmail.com>:
On 2/13/07, Giovanni Scafora <linuxmania@gmail.com> wrote:
2007/2/13, Pierre Schmitz <pierre@archlinux.de>:
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
I think the field comments is sufficient.
So, what if a package has 20 or so bugs over the course of it's lifetime. Each bug having 2-3 responses from the maintainer and the users. That's a lot of comments with no order to it. One could say "delete the old ones", but then you lose history, which is important sometimes.
AUR comments are NOT sufficient to replace a full blown bug tracker. Hell, if it WAS sufficient, why don't we move the AUR comments scheme to the official package list? No more package bugs in the bug tracker, use the package comments. Sounds like a bad idea. For the same reason, deeming AUR comments sufficient for bug tracking is equally as bad.
Well, there's no strict line between comments and bugtracker. Imagine tons of bugs like "Add license field". ;-) You wanna kill mr.bughunter? :-D -- Roman Kyrylych (Роман Кирилич)
I think we went too far from pacman.conf to reporting of AUR packages bugs in bugtracker. Why not just keep things as they are now? -- Roman Kyrylych (Роман Кирилич)
Back to the point of this conversation. I agree that [community] should be enabled by default. My reasoning is quite simple: all packages in community have been tested by/are maintained by TUs. This should be reason enough to trust the packages in that repo. If you were to use the argument that community packages were less stable or somehow less well maintained, what is the point of having TUs? The very concept of having TUs is to ensure that community packages can be trusted -- hence the name. My $0.02 -- Rob
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Dienstag, 13. Februar 2007 22:26:17 schrieb Aaron Griffin:
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
Tada! <http://bugs.archlinux.org/index.php?tasks=all&project=2> What the heck is the above used for? Why can't it be used for what we are talking about?
2007/2/13, Dan McGee <dpmcgee@gmail.com>:
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Dienstag, 13. Februar 2007 22:26:17 schrieb Aaron Griffin:
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
Tada! <http://bugs.archlinux.org/index.php?tasks=all&project=2>
What the heck is the above used for? Why can't it be used for what we are talking about?
Wrong! Quote: "If you have bugs relating to packages in [community] or unsupported, please do not file bugs here, contact the maintainers directly." ;-) This is used for reporting bugs in AUR scripts, not in packages. -- Roman Kyrylych (Роман Кирилич)
2007/2/13, Roman Kyrylych <roman.kyrylych@gmail.com>:
2007/2/13, Dan McGee <dpmcgee@gmail.com>:
On 2/13/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Dienstag, 13. Februar 2007 22:26:17 schrieb Aaron Griffin:
Hmmm. Why not? What's wrong with reporting bugs there? If we assume we have an "AUR/Community" section in flyspray, and give the TUs accounts and access, what's the problem? Bug reporting is not a bad thing.
Well, at the moment bugs cannot assigned to TUs. Perhaps it might be a good idea to introduce a community-section; but i don`t think we should discuss this at pacman-dev ;-)
Tada! <http://bugs.archlinux.org/index.php?tasks=all&project=2>
What the heck is the above used for? Why can't it be used for what we are talking about?
Wrong! Quote: "If you have bugs relating to packages in [community] or unsupported, please do not file bugs here, contact the maintainers directly." ;-) This is used for reporting bugs in AUR scripts, not in packages.
Did anyone miss my message about bugreporting and AUR comments? Bugs in AUR packages (including Community) were and should be reported by adding a comment to package's page. That's why comments feature exists. -- Roman Kyrylych (Роман Кирилич)
Am Dienstag, 13. Februar 2007 22:42:06 schrieb Dan McGee:
Tada! <http://bugs.archlinux.org/index.php?tasks=all&project=2>
What the heck is the above used for?
It`s used for the webpage aur.archlinux.org and aurtools
Why can't it be used for what we are talking about?
participants (8)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee
-
Giovanni Scafora
-
Isenmann Daniel
-
Pierre Schmitz
-
Robert Howard
-
Roman Kyrylych