On Tuesday 06 January 2015 08:19:20 Thiago Macieira wrote:
Unfortunately, as long as the tool permits line-by-line commenting, you're
going to get nitpicking. My experience is that people are linear and will
start reading the patch, calling out what they see when they see it.
I made some
On Wednesday, January 07, 2015 08:03:06 Martin Gräßlin wrote:
On Tuesday 06 January 2015 12:48:41 Jan Kundrát wrote:
On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
...
This has a risk of splitting the discussion about a patch into multiple
independent streams where people will
On Monday, 5 January 2015 20:57:47 CEST, Frank Reininghaus wrote:
Ultimately, a constant stream of
newcomers is the only thing that keeps a free software project alive
in the long term.
Yes, as long as these newcomers eventually get enough interest and enough
skills to become maintainers. I
On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
a) I do not know anything about Dr K, but I will try and
find someone who does.
b) Unfortunately there is nobody available any more who
knows anything about
Dr K, but I (or another suggested guy) will try to
help. How
On Monday, 5 January 2015 22:22:19 CEST, Boudewijn Rempt wrote:
Usually, half-way through they ask me, why doesn't KDE use github
I do not understand how stuff would change if we used GitHub, though. There
would still be that huge gap of not understanding which of the repos to
use. I think
On Monday, 5 January 2015 14:03:13 CEST, Thomas Friedrichsmeier wrote:
I think there is an easy test for this (well, not a real test, but a
useful initial heuristic): Can you explain exactly how to submit a
patch for your project
- to someone without prior knowledge of the tools involved
-
On Tue, 6 Jan 2015, Jan Kundrát wrote:
On Monday, 5 January 2015 22:22:19 CEST, Boudewijn Rempt wrote:
Usually, half-way through they ask me, why doesn't KDE use github
I do not understand how stuff would change if we used GitHub, though.
I'm just relaying what usually happens when I get a
Hello Jan,
On 06/01/2015, at 10:48 PM, Jan Kundrát wrote:
On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
a) I do not know anything about Dr K, but I will try and find someone who
does.
b) Unfortunately there is nobody available any more who knows anything
about
Dr
On Tue, 06 Jan 2015 13:19:45 +0100
Jan Kundrát j...@kde.org wrote:
On Monday, 5 January 2015 14:03:13 CEST, Thomas Friedrichsmeier wrote:
I think there is an easy test for this (well, not a real test, but a
useful initial heuristic): Can you explain exactly how to submit a
patch for your
On Tuesday 06 January 2015 12:48:41 Jan Kundrát wrote:
On Tuesday, 6 January 2015 07:40:01 CEST, Ian Wadham wrote:
a) I do not know anything about Dr K, but I will try and
find someone who does.
b) Unfortunately there is nobody available any more who
knows anything about
On Tue, 6 Jan 2015, Thiago Macieira wrote:
Unfortunately, as long as the tool permits line-by-line commenting, you're
going to get nitpicking. My experience is that people are linear and will
start reading the patch, calling out what they see when they see it.
They should instead look at the
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 then
accepted and merged, or direct merging of branches,
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-off in some
cases.
That's a valid
On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát j...@kde.org wrote:
On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote:
Ease of installation and it's the availability of the necessary
interpreters within mainstream distributions should be more than
sufficient criteria here. Limiting it
On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote:
Ease of installation and it's the availability of the necessary
interpreters within mainstream distributions should be more than
sufficient criteria here. Limiting it by any other criteria is playing
pure favouritism to a given set of
On Monday 05 January 2015 23:57:40 Ben Cooksley wrote:
On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát j...@kde.org wrote:
On Monday, 5 January 2015 06:05:33 CEST, Ben Cooksley wrote:
Ease of installation and it's the availability of the necessary
interpreters within mainstream distributions
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 those are obscure.
On Monday, 5 January 2015 12:43:06 CEST, Milian Wolff wrote:
Hm, why don't we do a prioritization poll? Quite some items
raised by others
are totally unimportant to me, and probably vice versa. While I
agree that it
would be nice to make everyone happy, I doubt that's going to
work out. If
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
contributors' machine might be a little bit discouraging.
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
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
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 a valid concern that people might very well be pushed off by the
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 remains an undeniable fact that it's
of little use on
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 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 a valid concern that
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
Sending patches around? That's quite the stretch from
submitting a diff to a web interface and recalls the KDE 1.0
days. And you're accusing me of language-lawyering?
The problem here is that you believe -- incorrectly -- that a
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 own
preferred workflow involves more than one
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
El Dilluns, 5 de gener de 2015, a les 22:26:24, Boudewijn Rempt va escriure:
Well, _obviously_ reviewboard supports raising issues and adding comments
, but neither facilitates actual conversation, i.e. discussion on what's
up with a particular patch at a deeper level.
In short, what I meant
On Montag, 5. Januar 2015 22:26:24 CEST, Boudewijn Rempt wrote:
In short, what I meant is that as a tool to dicuss code
changes, Reviewboard is a poor thing. It facilitates
nit-picking, which is off-putting and useless, but at least
gives the reviewer the feeling he's done his job, while it
El Dilluns, 5 de gener de 2015, a les 22:29:36, Thomas Lübking va escriure:
On Montag, 5. Januar 2015 21:36:54 CEST, Albert Astals Cid wrote:
What's the problem with php?
Dynamic typing ;-)
I don't think there's a particular issue with php in this context.
To me the concern seemed to
Well, this getting to a pretty useless discussion. You set out to prove
that you find it all very simple, and I am sure you find it simple.
You don't have to rebut everything I say point by point to prove whatever
you think you are proving because the point is this: you find it simple,
others
On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote:
For me, personally, RB's mails are even worse.
Ok, but that's pretty much OT, isn't?
(Same problem with this thread, or rather mailing list. Why the
heck do I need to get two copies of every reply to a mail of
mine... One is
El Dilluns, 5 de gener de 2015, a les 23:46:18, Alexander Neundorf va
escriure:
On Monday, January 05, 2015 22:35:23 Albert Astals Cid wrote:
El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va
escriure:
...
* figured out what branches are for, and how different projects
I'm just trying to make clear that reviewboard is a crappy tool inciting
people to write crappy reviews that drive people away. Apart from any
other nonsense about cultural differences (the standard cop-out from
Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!), I
think
On Monday, January 05, 2015 23:53:02 Boudewijn Rempt wrote:
I'm just trying to make clear that reviewboard is a crappy tool inciting
people to write crappy reviews that drive people away. Apart from any
other nonsense about cultural differences (the standard cop-out from
Dutchmen and Germans
On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote:
In short, what I meant is that as a tool to dicuss code changes,
Reviewboard is a poor thing. It facilitates nit-picking, which is
off-putting and useless, but at least gives the reviewer the feeling he's
done his job, while it fails
On Mon, 5 Jan 2015, Aaron J. Seigo wrote:
On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote:
In short, what I meant is that as a tool to dicuss code changes,
Reviewboard is a poor thing. It facilitates nit-picking, which is
off-putting and useless, but at least gives the reviewer the
On Montag, 5. Januar 2015 23:53:02 CEST, Boudewijn Rempt wrote:
I'm just trying to make clear that reviewboard is a crappy tool
inciting people to write crappy reviews that drive people away.
And I was trying to make clear that those crappy reviews are just the house
cleaning stuff that
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
On Mon, 5 Jan 2015, Jeff Mitchell wrote:
I do disagree about needing a KDE identity to submit things like bug reports;
it is not useful to be unable to follow-up with someone, and if they don't
have an email address they're much less likely to remember to check back. Not
to mention link spam
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
Hi,
2015-01-05 19:03 GMT+01:00 Jeff Mitchell:
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
El Dilluns, 5 de gener de 2015, a les 17:57:19, Thomas Lübking va escriure:
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.
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.
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.
- Nobody remotely intends to *require* this (but one can oc.
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't
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 complex than having just a single one.
Does it
El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure:
I do agree, btw, with Ian, that the current reviewboard workflow is badly
broken and can be very discouraging. It doesn't support conversation
What do you mean it doesn't support conversation?
Cheers,
Albert
On Monday, January 05, 2015 16:15:09 Ian Wadham wrote:
...
I wonder also how many people have just tiptoed quietly away from the KDE
Community rather than speak out about frustrations they may have been
feeling. Where *did* all those people go in the last few years? And why?
I didn't really
El Dilluns, 5 de gener de 2015, a les 21:51:34, Alexander Neundorf va
escriure:
On Monday, January 05, 2015 16:15:09 Ian Wadham wrote:
...
I wonder also how many people have just tiptoed quietly away from the KDE
Community rather than speak out about frustrations they may have been
El Dilluns, 5 de gener de 2015, a les 17:25:48, Thomas Lübking va escriure:
On Montag, 5. Januar 2015 16:40:52 CEST, Jan Kundrát wrote:
Phabricator has an equivalent of rbtools/rbt called Arcanist
which is written in PHP.
So this is actually a concern on a particular tool.
Leaving aside
On Mon, 5 Jan 2015, Albert Astals Cid wrote:
I think this is due to the fact that it's quite simple
git clone kde:repo
This requires:
* setting up gitconfig with the kde: alias. That requires finding the
right info on techbase, as well as the awareness that techbase exists.
* figuring out
Well, _obviously_ reviewboard supports raising issues and adding comments
, but neither facilitates actual conversation, i.e. discussion on what's
up with a particular patch at a deeper level.
In short, what I meant is that as a tool to dicuss code changes,
Reviewboard is a poor thing. It
On Sun, 04 Jan 2015 00:37:49 +0100
Jan Kundrát j...@kde.org wrote:
My goal is to help bridge the gap between the existing project
maintainers (who produce software in git trees) and the new
contributors (who produce patches). If we can offload the management
of git trees to the contributors,
On Sun, 4 Jan 2015, 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-off in some
cases.
Your project's situation may be very
Just to make sure -- I didn't write any of this, this is stuff that
committed users of Krita were coming up with some time ago when the
question arose of why is krita not on github (which got answered
satisfactorily, but then sequed in what people are missing).
On Sun, 4 Jan 2015, Boudewijn
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 to have good answers for before we can take a
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 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 Mon, Jan 5, 2015 at 4:15 AM, Cornelius Schumacher schumac...@kde.org 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
On Sunday 04 January 2015 13:38:09 Jeff Mitchell wrote:
GitHub has been mentioned as a comparison point, but I can't credibly
believe that we're willing to migrate to GitHub en masse, no matter what
the flow of the industry is. I'm not stating my personal preferences on
the matter, but the
On Mon, Jan 5, 2015 at 12:45 PM, Cornelius Schumacher
schumac...@kde.org wrote:
On Sunday 04 January 2015 13:38:09 Jeff Mitchell wrote:
GitHub has been mentioned as a comparison point, but I can't credibly
believe that we're willing to migrate to GitHub en masse, no matter what
the flow of
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 those are obscure. They're three of the most
popular and
On Mon, Jan 5, 2015 at 2:41 PM, Thiago Macieira thi...@kde.org 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
On 05/01/2015, at 10:45 AM, Cornelius Schumacher wrote:
On Sunday 04 January 2015 13:38:09 Jeff Mitchell wrote:
I do agree that we want the barrier to entry to be as low as possible.
As is often the case, I think that may conflict somewhat with what some
of the more/very experienced
On Sat, Jan 3, 2015 at 8:57 PM, Aaron J. Seigo ase...@kde.org wrote:
On Saturday, January 3, 2015 15.31:26 Ben Cooksley wrote:
- System should automatically set the CC / Reviewers / etc for a
review rather than the submitter needing to know who to set.
It would be nice if there was an
On Saturday, January 3, 2015 15.31:26 Ben Cooksley wrote:
- System should automatically set the CC / Reviewers / etc for a
review rather than the submitter needing to know who to set.
It would be nice if there was an opt-out for this. I receive a large number of
emails from gerrit for
. This thread is called Changes to our Git
infrastructure. I see that code review is very relevant to that because
some efficient tools do extend Git, but I don't understand why this list
contains information about wikis, bug tracking and task boards. I do not
think that we should be looking
For Gerrit:
- Code Reviews:
- CLI client to make changes to the code review system and to manage
the review (including retrieving the commits/patches)
Check. It's ssh host gerrit subcommand
Client should have good documentation.
- System should automatically set the CC / Reviewers
On Saturday 03 January 2015 12:39:42 Lydia Pintscher wrote:
On Sat, Jan 3, 2015 at 12:07 PM, Thiago Macieira thi...@kde.org wrote:
For Gerrit:
I think before checking Ben's list against specific implementations we
should make sure the list is actually correct and complete. It's the
basis for
On Sat, Jan 3, 2015 at 12:07 PM, Thiago Macieira thi...@kde.org wrote:
For Gerrit:
I think before checking Ben's list against specific implementations we
should make sure the list is actually correct and complete. It's the
basis for an important decision so let's do this step-by-step? :)
and widespread languages in the world.
I'm confused by this part. This thread is called Changes to our Git
infrastructure. I see that code review is very relevant to that
because some efficient tools do extend Git, but I don't understand why
this list contains information about wikis, bug tracking
El Dissabte, 3 de gener de 2015, a les 15:31:26, Ben Cooksley va escriure:
Hi all,
I've gone over the comments everyone has made thus far and came up
with the following community wishlist as it were.
It represents a combination of what everyone has said, in a fairly
distilled form.
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 them immersed into what we're doing and
Hi all,
I've gone over the comments everyone has made thus far and came up
with the following community wishlist as it were.
It represents a combination of what everyone has said, in a fairly
distilled form.
Regrettably there were one or two items which conflicted. I sided with
the option which
On Tuesday 23 December 2014 13.21:37 Milian Wolff wrote:
On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote:
Hi all,
As has been made evident in the prior thread there are quite a few
interesting ideas floating around about what our Git infrastructure
should be capable of.
On Monday 29 December 2014 11.23:19 Ben Cooksley wrote:
Hi all,
Based on the current feedback:
1) It seems people see no use in clone repositories.
2) Little commentary has been made on the merits of scratch
repositories, with some dismissing them as pointless.
Therefore sysadmin
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 they *did*
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/whatever then?
Also I did not mean to imply you
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
N not scratch repos. I can see clones being useless as branches
in the actual repos should be used instead, but I personally consider
scratch repos a very useful thing, for example to host simple projects
that shouldn't be part of any main/big module - they are much more
easier to set up
On Sun, Dec 28, 2014 at 5:23 PM, Ben Cooksley bcooks...@kde.org wrote:
Hi all,
Based on the current feedback:
1) It seems people see no use in clone repositories.
Personal clones are for forks. If you can't get a patch set accepted by
upstream, its equally unlikely that upstream are going
On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:
Personal clones are for forks. If you can't get a patch set accepted by
upstream, its equally unlikely that upstream are going to let you put a
private branch in their repo for sharing that patch set.
This is a social issue, then. What
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 Mon, Dec 29, 2014 at 11:36 AM, Jan Kundrát j...@kde.org wrote:
On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:
Personal clones are for forks. If you can't get a patch set accepted by
upstream, its equally unlikely that upstream are going to let you put
a
private branch in their
On Mon, Dec 29, 2014 at 12:13 PM, Jeff Mitchell mitch...@kde.org wrote:
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
Hi,
On Mon, 29 Dec 2014 12:13:38 -0500
Jeff Mitchell mitch...@kde.org wrote:
On 29 Dec 2014, at 11:36, Jan Kundrát wrote:
I agree with scratch repos being useful as a first step.
Except nobody deletes it. That's a large problem. Scratch is nice in
concept but it's a sysadmin nightmare.
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
Hi,
On Mon, 29 Dec 2014 14:41:03 -0500
Jeff Mitchell mitch...@kde.org wrote:
I just want to point out that scratch repos may be useful to some
people, but are also the easiest repo type for anyone to host
anywhere, including on their own local filesystem. The concept was a
bit flawed from
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 asking because I see this
exact feature described at
On Monday, 29 December 2014 19:44:21 CEST, Jeremy Whiting wrote:
2. The students typically change their commits quite often after review
(sometimes many times to finally get it right) and force pushing isn't
permitted, but is on clones.
I guess 2 could be solved with more commits rather than
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 asking
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 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
On Mon, 29 Dec 2014 16:19:37 -0500
Jeff Mitchell mitch...@kde.org 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 about / is the problem inherent
to the
_concept_ of
On 29 Dec 2014, at 16:40, Thomas Friedrichsmeier wrote:
On Mon, 29 Dec 2014 16:19:37 -0500
Jeff Mitchell mitch...@kde.org 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
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.
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client --
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 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 they *did* want
that code that they pushed up and left
1 - 100 of 121 matches
Mail list logo
