Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 306192] Make BuildService accessible for anonymous users
  • From: fate_noreply@xxxxxxx
  • Date: Mon, 22 Mar 2010 12:49:04 +0100 (CET)
  • Message-id: <feature-306192-38@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx#cdbs)
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:00Z)
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

< Previous Next >
This Thread
References