On 5 Jan 2015, at 12:47, Thomas Lübking wrote:
Stuff that relies on present and known libraries/executables has a
lower barrier. I've no gtk3 installation atm. and when I need to pick
among different tools, the one that doesn't require gtk3 wins.
That may be irrational, but still happens.
I'd
On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote:
All this back-and-forth about cli tools actually sounds weird to me. I
know that the beginners who start hacking on Krita would never use any
of them. Git on the command line is often already something they can
be rightly proud of when they maste
On 5 Jan 2015, at 12:39, Jan Kundrát wrote:
On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote:
The problem here is that you believe -- incorrectly -- that a single
workflow cannot include more than one tool. The reason I can
definitively say that you are incorrect is because your
On 5 Jan 2015, at 12:15, Thomas Lübking wrote:
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
It's not a matter of what is possible, but of preferences (while we
probably all prefer to not return to send patches on mailing lists ;-)
Since they may obviously cover a large
On 5 Jan 2015, at 12:21, Milian Wolff wrote:
On Monday 05 January 2015 12:06:57 Jeff Mitchell wrote:
On 5 Jan 2015, at 11:57, Thomas Lübking wrote:
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
Your hatred of PHP is well noted.
I don't think it's hate - but it
On 5 Jan 2015, at 11:57, Thomas Lübking wrote:
On Montag, 5. Januar 2015 17:46:51 CEST, Jeff Mitchell wrote:
Your hatred of PHP is well noted.
I don't think it's hate - but it remains an undeniable fact that it's
of little use on typical client systems.
Therefore it's
On 5 Jan 2015, at 11:06, Jan Kundrát wrote:
On Monday, 5 January 2015 16:05:07 CEST, Jeff Mitchell wrote:
- Existing KDE account holders can and do use git for their
workflow.
- Using non-git workflow for others introduces a different workflow
to the mix.
- Having two workflows is more
On 5 Jan 2015, at 10:40, Jan Kundrát wrote:
On Monday, 5 January 2015 16:23:15 CEST, Thomas Lübking wrote:
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a
client.
- Nobody remotely intends to *require* this (but one can oc. *offer*
tools written
On 5 Jan 2015, at 10:23, Thomas Lübking wrote:
On Montag, 5. Januar 2015 16:10:51 CEST, Jeff Mitchell wrote:
Not at all. I perfectly understand what Jan is talking about.
To sum up my understanding:
- Nobody wants to install/use PHP (or, good god, .NET/Mono ;-) on a
client.
Jan doesn&#
On 5 Jan 2015, at 9:41, Milian Wolff wrote:
On Monday 05 January 2015 09:14:36 Jeff Mitchell wrote:
On 5 Jan 2015, at 4:05, Jan Kundrát wrote:
Ben, you and Jeff appear to disagree with my point that e.g.
requiring
a PHP tool to be installed client-side on each developers' and
contrib
On 5 Jan 2015, at 4:37, Jan Kundrát wrote:
On Sunday, 4 January 2015 13:21:12 CEST, Thomas Friedrichsmeier wrote:
True, but don't forget about the other side of the story:
- potential contributors will have to learn more stuff, before they
can even _start_ contributing, which may be a real turn
On 5 Jan 2015, at 4:27, Jan Kundrát wrote:
On Sunday, 4 January 2015 19:32:28 CEST, Jeff Mitchell wrote:
I don't follow this line of logic. The end result is software stored
in git trees, but how it gets there is a totally different concern.
Whether it comes from patches that are
On 5 Jan 2015, at 4:05, Jan Kundrát wrote:
Ben, you and Jeff appear to disagree with my point that e.g. requiring
a PHP tool to be installed client-side on each developers' and
contributors' machine might be a little bit discouraging.
Yes, because you are repeatedly assuming that such a tool w
On 4 Jan 2015, at 20:41, Thiago Macieira wrote:
On Saturday 03 January 2015 15:35:12 Jeff Mitchell wrote:
- Not needing a CLI tool in an "obscure language" (PHP, Java,
.NET,...).
.NET is a framework, not a language. Maybe you meant C#. Regardless,
I
fail to see how any of
On 4 Jan 2015, at 19:07, Ben Cooksley wrote:
> At least as far as I know the only hosted service we have looked at is
> Gitorious, and that was undertaken in part by the Board.
> Others have been around longer than me and may be able to comment on
> more though.
And Gitorious was looked at over Gi
On 4 Jan 2015, at 10:15, Cornelius Schumacher wrote:
On Saturday 03 January 2015 15:31:26 Ben Cooksley wrote:
(...excellent summary of discussion...)
Commentary on the above would be appreciated.
There are two questions which aren't addressed int he summary, but
which I
think are important
On 3 Jan 2015, at 18:37, Jan Kundrát wrote:
On Saturday, 3 January 2015 21:35:12 CEST, Jeff Mitchell wrote:
On 3 Jan 2015, at 14:00, Jan Kundrát wrote:
- Working on git trees, not patches. This directly translates into
making the contributors familiar with our workflow, and therefore
getting
On 3 Jan 2015, at 14:00, Jan Kundrát wrote:
- Working on git trees, not patches. This directly translates into
making the contributors familiar with our workflow, and therefore
getting them "immersed" into what we're doing and helping bridge the
gap between maintainers and contributors.
I agr
On 30 Dec 2014, at 10:56, Thomas Lübking wrote:
On Dienstag, 30. Dezember 2014 16:31:20 CEST, Martin Klapetek wrote:
Not necessarily, some projects may just be finished and don't need
more
commits.
Yes, of course - but I'd assume they'd be transferred from "scratch"
to playground/extragear
On 29 Dec 2014, at 17:13, Thomas Lübking wrote:
On Montag, 29. Dezember 2014 22:25:33 CEST, Jeff Mitchell wrote:
They don't. If I remember conversations of four years ago correctly,
it's partly out of the fear of horrible rants from users that decide
two years later that in fact
On 29 Dec 2014, at 17:42, Jan Kundrát wrote:
On Monday, 29 December 2014 23:05:48 CEST, Jeff Mitchell wrote:
...what does that have to do with anything?
It means that there is no problem with having scratch repos ("self
service repo creation") with Gitolite.
I find that releva
On 29 Dec 2014, at 16:56, Jan Kundrát wrote:
We agreed on IRC that these patches are used for personal clones. The
support for scratch space, i.e. self-service repo creation, is
implemented by upstream Gitolite, and no custom patches for that are
in production now.
...what does that have to
On 29 Dec 2014, at 16:40, Thomas Friedrichsmeier wrote:
On Mon, 29 Dec 2014 16:19:37 -0500
"Jeff Mitchell" wrote:
On 29 Dec 2014, at 15:20, Thomas Friedrichsmeier wrote:
I am absolutely not qualified to comment on the pain this is
causing to
you sysadmins. But are we talking abou
On 29 Dec 2014, at 13:38, argonel wrote:
Except nobody deletes it. That's a large problem. Scratch is nice in
concept but it's a sysadmin nightmare.
I thought they expired automatically, perhaps others are under that
impression as well?
They don't. If I remember conversations of four years a
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
On 29 Dec 2014, at 15:23, Jan Kundrát wrote:
On Monday, 29 December 2014 20:41:03 CEST, Jeff Mitchell wrote:
(The current scratch area itself is already entirely custom-coded on
top of Gitolite, and that means it must be maintained.)
Can we take a look at these custom patches? I'm a
On 29 Dec 2014, at 14:00, Thomas Friedrichsmeier wrote:
Out of the 846 repos I currently count in scratch/, nearly all of
them haven't seen a commit in years. Meanwhile that's an extra 846
repos that have to be hosted, distributed to anongits, and backed up.
That's not just a lot; that's the larg
On 29 Dec 2014, at 11:36, Jan Kundrát wrote:
As I see it, scratch repos are the first stage in a project's life
cycle.
Before playground, you might fiddle with something, drop it in a
scratch
repo and share the link on IRC. Deleting it is painless when you
discover
that your idea is terrible,
On 18 Dec 2014, at 8:52, Sebastian Kügler wrote:
On Wednesday, December 17, 2014 08:47:09 Jeff Mitchell wrote:
I understood that to be the case -- I'm really meaning for a general,
KDE-wide solution.
Personally I don't have an issue with volunteers taking care of
non-official sys
On 17 Dec 2014, at 6:01, Jan Kundrát wrote:
Hi Jeff, thanks for a very reasonable mail, I don't have much to add
to it in general, except for one item:
But it's not reasonable to expect the sysadmins to support multiple
parallel systems
Maybe there is a misunderstanding of some kind -- I do
Don't want to weigh in on Gerrit as I don't know it well enough, but as
for Phabricator, Ben may have forgotten but we did evaluate it a while
back. It was neat but had a very serious problem: you needed an account
to even view anything (no public access), and once you got into it
everything wa
On 12 Dec 2014, at 17:25, Luca Beltrame wrote:
Albert Astals Cid wrote:
So what do you suggest, because we already tried gitlab and didn't
work,
is there any more github clones out there that may work for us? I
don't
There are at least a couple:
- Gitbucket (written in Scala, mimics the Gi
Hello,
If you are receiving this email, you're either on kde-core-devel or you
have an account on the current KDE Etherpad system (possibly from being
a KDE developer, possibly from Desktop Summit 2010).
If you (a) no longer wish to use the Etherpad system, and/or (b) you
don't care about ke
Can anyone who feels comfortable handling the above class please get in
touch with secur...@kde.org?
Richard Moore worked on an initial (but as it turns out incomplete) fix
for this problem, but for a month now I've been unable to get him to
look at the second part of it, so if anyone else is comf
34 matches
Mail list logo
