On Sat, Dec 27, 2014 at 9:09 AM, Matthew Dawson matt...@mjdsystems.ca wrote:
On December 25, 2014 08:21:05 PM Ben Cooksley wrote:
The way I see it, there are two reasonable alternatives with the current
setup:
1) Everybody can create, delete and force-push to all branches except the
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
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121248/
---
(Updated Dec. 29, 2014, 11:57 a.m.)
Status
--
This change has been
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 Monday, 29 December 2014 09:50:06 CEST, Ben Cooksley wrote:
Unfortunately allowing force pushes is an extremely messy business
with the hooks - so we're unable to do this (for maintenance reasons
among others).
Could you please elaborate on this one?
The only reason I remember ever hearing
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
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121717/
---
(Updated Dec. 29, 2014, 8:21 p.m.)
Review request for KDE Base Apps and
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 Tue, Dec 30, 2014 at 6:08 AM, Jan Kundrát j...@kde.org wrote:
On Monday, 29 December 2014 09:50:06 CEST, Ben Cooksley wrote:
Unfortunately allowing force pushes is an extremely messy business
with the hooks - so we're unable to do this (for maintenance reasons
among others).
Could you
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 June 14, 2014, 8:54 a.m., David Faure wrote:
What if the file isn't local?
Sounds to me like the bug is elsewhere.
Of course for local files, showing a local path looks better than a
file:/// URL, so this could be improved, but in a way that doesn't break
remote files.
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
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121746/
---
Review request for KDE Runtime and Tobias Koenig.
Bugs: 245482
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 relevant because you mentioned that the current scratch area
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121746/
---
(Updated Dec. 29, 2014, 10:43 p.m.)
Review request for KDE Runtime,
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 relevant because you
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121746/#review72751
---
I'm confused. Are you patching old code?
kde-runtime branch
On Dec. 29, 2014, 10:49 p.m., David Faure wrote:
I'm confused. Are you patching old code?
kde-runtime branch Applications/14.12 has my rewrite of this code to use
the cache as per the trash spec v1.0, replacing the KConfig-based code.
It solves that issue.
See commit
On Dec. 29, 2014, 10:49 p.m., David Faure wrote:
I'm confused. Are you patching old code?
kde-runtime branch Applications/14.12 has my rewrite of this code to use
the cache as per the trash spec v1.0, replacing the KConfig-based code.
It solves that issue.
See commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121746/
---
(Updated Dec. 29, 2014, 11:08 p.m.)
Status
--
This change has been
On Dec. 29, 2014, 10:49 p.m., David Faure wrote:
I'm confused. Are you patching old code?
kde-runtime branch Applications/14.12 has my rewrite of this code to use
the cache as per the trash spec v1.0, replacing the KConfig-based code.
It solves that issue.
See commit
34 matches
Mail list logo
