On 29 Dec 2014, at 15:20, Thomas Friedrichsmeier wrote:
well, in many but not all cases, this may be true. Here's my example
use case: I am currently considering hosting an "i18n supplement" in a
scratch repo. The idea would be to make it easy for developers or
build-systems to clone translations from this. Not quite sure the idea
will fly, so I'm shy to request a "real" repo for this. But also, a
local repo would be pointless, and using a separate provider would
feel
wrong. Branching is equally out of question, as this is separate data.
Right -- so my suggestion is that we work to get rid of that shyness.
That's a social issue. See below...
I'm not saying that it shouldn't be easy for developers to get
repositories to play around with on KDE infrastructure. I'm just
questioning the idea (as in my original email, which is not part of
your quote) that actually asking a sysadmin for one is too onerous a
burden, so onerous that such projects will simply immediately fail to
thrive, instead of the developer simply waiting an extra X hours to
be able to push up to a central hosted repo from the local system.
Those that feel that this is just too high a price to pay could help
reduce it by handling repo requests.
No, having to ask a sysadmin is not necessarily a show-stopper to me.
But it certainly does create the aura of "don't do this unless you are
sure you know what you are doing". Also note that currently the
wording
on the wiki is:
"Note that we have deliberately decided not to allow the direct
creation of KDE Playground projects; the path to existence for a KDE
Playground repository project always leads through a personal scratch
space first. This is to give you the power to decide whether your
project is ready, and also to force you to deliberate whether it truly
is."
Exactly, so this is the root of the social issue. And for the current
git hosting solution, this is correct. But for the next gen solution, it
doesn't have to be.
Well, that could be changed. And the psychological barrier could
further be lowered by providing a dedicated web form, for instance.
Note that I'm not really attached to the exact process of creating a
scratch repo. But the _concept_ of being able to create a repo
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
seems important to me.
Sure. So I think this is something that can be accommodated except for
the you-do-it-yourselfness. And for what it's worth, it's possible that
the do-it-yourselfness could still be accommodated but would require
custom patching -- currently -- and that is something that we are
somewhat loathe to do to the greatest extent possible. It has been the
root of many a problem, especially in Bugzilla.
Scratch repos are also not just problematic in terms of all of the
out-of-date repositories; they're very much a feature enabled by our
current system (they were enabled because we could do it, so why
not). If we want to move to a new system and the many other benefits
it might provide, the kind of sandboxing that makes scratch a safe
place for developers to create repos at will may be hard to provide
without more of the types of unmaintainable patches and customizing
that cause Ben to describe our system as being held together with
glue and duct tape. (The current scratch area itself is already
entirely custom-coded on top of Gitolite, and that means it must be
maintained.)
I am absolutely not qualified to comment on the pain this is causing
to
you sysadmins. But are we talking about / is the problem inherent to
the
_concept_ of scratch repos, or is it a problem of the implementation
of
how exactly scratch repos are created?
I'm honestly not sure how to answer that; scratch repos are very much an
implementation because we had a solution. It seemed like something that
could be useful, and we had the capability with the current software, so
we did it. In hindsight, it has been problematic.
--Jeff
