Git Scratch-Pads for every identity.kde.org account (not only developers)

[Milian Wolff]

Eike Hein, 02.01.2011:
> On 1/2/2011 12:21 AM, Milian Wolff wrote:
> > See above, this is nothing I ever wanted to change. I only speak about
> > scratchpad (or what was playground).
> > 
> > Hope this makes it clear that most of your email is just not relevant.
> 
> I'm referring to this paragraph:
> 
> "It's also a mechanism to ensure that stuff served up under a
> *.kde.org domain name isn't random crap (this issue is relevant
> to your proposal, btw; if you want to see anything like it done,
> please come up with a solid plan in this area that can be im-
> plemented with the available manpower)."

Doh, now I finally understand you. I first thought you meant the content of 
the kde websites, i.e. http://websvn.kde.org/trunk/www/ with *.kde.org...

> Basically, the system that I described (and did so intentionally
> because it (a) answered your question and (b) is really relevant
> to your proposal) exists to try and make sure a couple of things
> come true, among other things:
> 
> - Stuff in KDE SVN (and now git) is relevant to KDE.
> 
> - Stuff in KDE SVN (and now git) is of a respectable nature that
>    won't get us sued.
> 
> This is done by screening the people who get to upload the data.
> 
> Your proposal, without additions, removes that screening step
> and allows random persons to upload random data to a kde.org
> machine and domain name.

Right, now this makes sense.

> I'm asking you to come up with a plan that:
> 
> - Makes sure that the data that will be uploaded will be rele-
>    vant to KDE, so our infrastructure is not unnecessarily taxed.
> 
> - Finds a way to be reasonably confident that the data that
>    will be uploaded will not make us liable in some way.

What about a license agreement? Something like "I won't upload stuff that will 
get KDE sueued nor anything unrelated to KDE. If in doubt, I'll ask the holy 
sysadmins whether what I intend to upload is OK."

Or alternatively something like a two-stage development account, where the 
initial padawan status only allows for comitting in the personal scratch pad 
but also needs the OK by an existing person.

The whole "I as an existing Dev vouche for new contributor XYZ" is fraud 
anyways. If he's about to do new work, how am I supposed to know what he does 
or not. And "only clones allowed" is also not safe, he could simply upload 
fraud stuff in those clones if he wants to.

Really, onle a license agreement would make sense (and imo would be a good 
thing anyways, just to make sure).

> Additionally depending on the timeframe you had in mind I'd also
> ask you to be prepared to do the work (including the systems that
> deal with the above two concerns) necessary to implement your pro-
> posal or organizing the needed manpower, because after discussing
> it on IRC the sysadmin team believes that it should focus on com-
> pleting work on git.kde.org as per the original feature scope for
> now (e.g. there are still various issues to fix in the hooks and
> around providing various consumers with the data necessary for
> auto-discoverring repositories, plus more work on projects.kde.org, etc.).

Since I'm already swamped with work for KDevelop/Kate/... I doubt I'll find 
the time to do this *and* maintain it. Esp. considering that I'll need to 
learn and understand your existing setup to begin with.

So this is essentially a "CLOSED/WONTFIX" from your side then - too bad. Any 
other takers? Esp. considering how others (rekonq) already voiced themself in 
support of my request.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110102/ee2addcc/attachment.sig>