Feature changed by: Andreas Jaeger (a_jaeger) Feature #306192, revision 6 Title: Make BuildService accessible for anonymous users - Buildservice: Unconfirmed + Buildservice: New Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) + I would mark this as mandatory moving forward. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Michael Löffler (michl19) Feature #306192, revision 10 Title: Make BuildService accessible for anonymous users - Buildservice: New + Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Michael Löffler (michl19) Feature #306192, revision 12 Title: Make BuildService accessible for anonymous users - Buildservice: Unconfirmed + Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Stephen Kellat (skellat) Feature #306192, revision 16 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 + #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) + Making sign-up easier would be more valuable than allowing anonymity in + participation.  Some accountability for actions on the Build Service + would be appropriate even if it is to smooth out any possible blame- + storming sessions.  The system as presently structured promotes + collegiality which can help undergird community. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Peter Poeml (poeml) Feature #306192, revision 18 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. + #7: Peter Poeml (poeml) (2009-07-06 12:45:46) + Here's an example of the pain that people suffer right now, when they + want to share code, and the pain that is suffered on the other end, by + users users trying to access code: + http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, + very hard and costs lots of time. I repeatedly find myself in the same + situation, and need to work around by copying spec files and tarballs + to some private server just to make them accessible. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Peter Poeml (poeml) Feature #306192, revision 20 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. + #9: Peter Poeml (poeml) (2009-07-06 13:29:53) + Here's another aspect to this feature. Once it is implemented, we will + be able to make the generation of source RPMs optional. Right now, the + build service file tree consists to about 50% of source RPMs. Since + source RPMs are built (and kept) per build platform, there is huge + duplication despite of the fact that the RPMs are largely identical. + (It seems not easy to make them identical and store them only once; see + this thread:  [opensuse-buildservice] Extreme waste of space by source + RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) + My hope is that with source RPM generation being optional, once the + sources are directly accessible, we can save lots of disk space. In + addition to local storage requirements, this also is directly relevant + to our mirroring infrastructure. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Karsten König (remur) Feature #306192, revision 22 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 + #11: Karsten König (remur) (2009-07-08 01:21:58) + any update on this? + There was just again somebody from fedora in -kde who wanted to take a + look at our dbus-1 package to investigate a problem. -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Michael Löffler (michl19) Feature #306192, revision 28 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Projectmanager: Mandatory Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). + #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) + Adrian can you give an estimation on a) how much time is needed to + implement this and b) when you or someone else can do it? -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Adrian Schröter (adrianSuSE) Feature #306192, revision 31 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Projectmanager: Mandatory Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 + #16: Adrian Schröter (adriansuse) (2009-10-29 08:30:17) (reply to #4) + Yes, please read #306381 for important implementation details. #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it? #14: Adrian Schröter (adriansuse) (2009-08-25 10:07:57) (reply to #13) I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan. (It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster) -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Juergen Weigert (jnweiger) Feature #306192, revision 33 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Projectmanager: Mandatory Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. + With no login for read access, we can implement a Fedora mock-like + build at the user's machine. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #16: Adrian Schröter (adriansuse) (2009-10-29 08:30:17) (reply to #4) Yes, please read #306381 for important implementation details. #17: Adrian Schröter (adriansuse) (2009-10-29 08:31:12) (reply to #16) This is it: The OBS Web Client shall offer a read only mode for not logged in users. Goals: * The current projects and packages shall become browseable * Search engines shall be able to index our content * Our sources, including the patches should be accessable. * Log files shall be accessable for developers without login. What should not be accessable: Of course no write operations and everything which is causing too much load on our servers. The system must be still usable for packagers as higher goal. This means: * No build result downloads via api * No monitor pages due to the cause load ? #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it? #14: Adrian Schröter (adriansuse) (2009-08-25 10:07:57) (reply to #13) I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan. (It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster) -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Martin Mohring (MartinMohring) Feature #306192, revision 36 Title: Make BuildService accessible for anonymous users Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. With no login for read access, we can implement a Fedora mock-like build at the user's machine. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #16: Adrian Schröter (adriansuse) (2009-10-29 08:30:17) (reply to #4) Yes, please read #306381 for important implementation details. #17: Adrian Schröter (adriansuse) (2009-10-29 08:31:12) (reply to #16) This is it: The OBS Web Client shall offer a read only mode for not logged in users. Goals: * The current projects and packages shall become browseable * Search engines shall be able to index our content * Our sources, including the patches should be accessable. * Log files shall be accessable for developers without login. What should not be accessable: Of course no write operations and everything which is causing too much load on our servers. The system must be still usable for packagers as higher goal. This means: * No build result downloads via api * No monitor pages due to the cause load ? #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it? #14: Adrian Schröter (adriansuse) (2009-08-25 10:07:57) (reply to #13) I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan. (It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster) #18: Adrian Schröter (adriansuse) (2010-02-19 10:53:52) Currently driven by the openSUSE Booster team. important for our next (2.0) OBS release. + #20: Martin Mohring (martinmohring) (2010-02-27 19:42:44) + This all should be seen in conjunction with the proposal for ACL: + http://en.opensuse.org/Build_Service/Concepts/AccessControl -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Juergen Weigert (jnweiger) Feature #306192, revision 38 Title: Make BuildService accessible for anonymous users Buildservice: Done Priority Requester: Important Projectmanager: Important + Info Provider: (Novell) Requested by: Michal Vyskocil (mvyskocil) Developer: (Novell) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. With no login for read access, we can implement a Fedora mock-like build at the user's machine. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #16: Adrian Schröter (adriansuse) (2009-10-29 08:30:17) (reply to #4) Yes, please read #306381 for important implementation details. #17: Adrian Schröter (adriansuse) (2009-10-29 08:31:12) (reply to #16) This is it: The OBS Web Client shall offer a read only mode for not logged in users. Goals: * The current projects and packages shall become browseable * Search engines shall be able to index our content * Our sources, including the patches should be accessable. * Log files shall be accessable for developers without login. What should not be accessable: Of course no write operations and everything which is causing too much load on our servers. The system must be still usable for packagers as higher goal. This means: * No build result downloads via api * No monitor pages due to the cause load ? #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it? #14: Adrian Schröter (adriansuse) (2009-08-25 10:07:57) (reply to #13) I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan. (It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster) #18: Adrian Schröter (adriansuse) (2010-02-19 10:53:52) Currently driven by the openSUSE Booster team. important for our next (2.0) OBS release. #20: Martin Mohring (martinmohring) (2010-02-27 19:42:44) This all should be seen in conjunction with the proposal for ACL: http://en.opensuse.org/Build_Service/Concepts/AccessControl + #21: Juergen Weigert (jnweiger) (2010-03-22 12:48:36) + No changes are visible on software.opensuse.org, when do we expect + deployment? -- openSUSE Feature: https://features.opensuse.org/306192

Feature changed by: Juergen Weigert (jnweiger) Feature #306192, revision 40 Title: Make BuildService accessible for anonymous users Buildservice: Done Priority Requester: Important Projectmanager: Important Info Provider: (Novell) Requested by: Michal Vyskocil (mvyskocil) Developer: (Novell) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debia...) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57:...) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. Use Case: With no login for read access we lower the hurdle for interested people, we enable external linking to "my" project and the OBS is visible for search engines. With no login for read access, we can implement a Fedora mock-like build at the user's machine. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-03-18 15:12:14) I would mark this as mandatory moving forward. #2: Stephan Kleine (bitshuffler) (2009-03-24 19:05:51) The only objection I have is that the email addresses shouldn't be shown to random unidentified users because I already get enough spam. Besides that it would be a nice addition. #3: Juergen Weigert (jnweiger) (2009-06-05 09:33:36) (reply to #2) Valid comment. We need to asure privacy according to data protection standards; With openFATE, we show initials only to anonymous users, and show full names & email addresses after you log in. I'd recommend doing the same here. Also, I suggest that every opensuse user should be able to choose, if and under what circumstances she wants her email/fullname exposed. #4: Juergen Weigert (jnweiger) (2009-06-05 09:35:05) See also fate#306381 #16: Adrian Schröter (adriansuse) (2009-10-29 08:30:17) (reply to #4) Yes, please read #306381 for important implementation details. #17: Adrian Schröter (adriansuse) (2009-10-29 08:31:12) (reply to #16) This is it: The OBS Web Client shall offer a read only mode for not logged in users. Goals: * The current projects and packages shall become browseable * Search engines shall be able to index our content * Our sources, including the patches should be accessable. * Log files shall be accessable for developers without login. What should not be accessable: Of course no write operations and everything which is causing too much load on our servers. The system must be still usable for packagers as higher goal. This means: * No build result downloads via api * No monitor pages due to the cause load ? #5: Stephen Kellat (skellat) (2009-06-14 23:24:39) Making sign-up easier would be more valuable than allowing anonymity in participation.  Some accountability for actions on the Build Service would be appropriate even if it is to smooth out any possible blame- storming sessions.  The system as presently structured promotes collegiality which can help undergird community. #6: Juergen Weigert (jnweiger) (2009-06-16 10:59:19) (reply to #5) The anonymous user shall be allowed read-only access. Nothing more.What I miss most, is the ability to forward the URL of a spec file or patch or build-log to upstream. Let us asks Michal Vyskocil if he really wanted to request read+write access without login. #8: Peter Poeml (poeml) (2009-07-06 12:54:29) (reply to #5) Making sources easily accessible instead of hiding them helps productivity immensely. Note that it also helps users with an account. It is faster and more efficient to access content if you don't need to login first, because often you are not already logged in. In addition, you can automate things easily, where with a protection with logins system is in place, you'll have more work to overcome it. (Read about the poor situation I cited in comment #7 for further ideas.) And you want to foster collaboration with other communities as well, not only within a "closed" community. #7: Peter Poeml (poeml) (2009-07-06 12:45:46) Here's an example of the pain that people suffer right now, when they want to share code, and the pain that is suffered on the other end, by users users trying to access code: http://lists.opensuse.org/zypp-devel/2009-07/msg00008.html It is very, very hard and costs lots of time. I repeatedly find myself in the same situation, and need to work around by copying spec files and tarballs to some private server just to make them accessible. #9: Peter Poeml (poeml) (2009-07-06 13:29:53) Here's another aspect to this feature. Once it is implemented, we will be able to make the generation of source RPMs optional. Right now, the build service file tree consists to about 50% of source RPMs. Since source RPMs are built (and kept) per build platform, there is huge duplication despite of the fact that the RPMs are largely identical. (It seems not easy to make them identical and store them only once; see this thread:  [opensuse-buildservice] Extreme waste of space by source RPMs (http://lists.opensuse.org/opensuse-buildservice/2009-06/msg00169.html)  .) My hope is that with source RPM generation being optional, once the sources are directly accessible, we can save lots of disk space. In addition to local storage requirements, this also is directly relevant to our mirroring infrastructure. #10: Juergen Weigert (jnweiger) (2009-07-06 13:42:30) (reply to #9) Peter, I'd like to invite you to https://fate.novell.com/306656 #11: Karsten König (remur) (2009-07-08 01:21:58) any update on this? There was just again somebody from fedora in -kde who wanted to take a look at our dbus-1 package to investigate a problem. #12: Adrian Schröter (adriansuse) (2009-07-08 10:41:03) This has atm 2nd priority, first we need to finish the attribute system (we need it after removal of PDB to create products with all informations and in a secure way again). #13: Michael Löffler (michl19) (2009-08-24 19:39:07) (reply to #12) Adrian can you give an estimation on a) how much time is needed to implement this and b) when you or someone else can do it? #14: Adrian Schröter (adriansuse) (2009-08-25 10:07:57) (reply to #13) I roughly estimate 2 weeks to implement this. However, there is currently no forseable free resource to work on this. It is anyway targeted in our Milestone 2.0 feature plan. (It is not enough to remove the access control, we need also implement a positive white list or we become a content provider via the api (or worse a warez and porn hoster) #18: Adrian Schröter (adriansuse) (2010-02-19 10:53:52) Currently driven by the openSUSE Booster team. important for our next (2.0) OBS release. #20: Martin Mohring (martinmohring) (2010-02-27 19:42:44) This all should be seen in conjunction with the proposal for ACL: http://en.opensuse.org/Build_Service/Concepts/AccessControl #21: Juergen Weigert (jnweiger) (2010-03-22 12:48:36) No changes are visible on software.opensuse.org, when do we expect deployment? #22: Adrian Schröter (adriansuse) (2010-03-22 13:28:45) (reply to #21) Erm, what do you exepect on software.o.o to happen ? This will happen on build.o.o when we release 2.0 to it (planned in June) + #23: Juergen Weigert (jnweiger) (2010-03-22 18:00:35) (reply to #22) + Thanks for the timeline. + On the results page of software.opensuse.org/search we have links + called 'Go to OBS Project' pointing to + https://build.opensuse.org/project/show?project=... + Currently strangers are blocked with this message: Please login to + access the requested page. + I'd expect to see anonymous access as an alternative here. -- openSUSE Feature: https://features.opensuse.org/306192