> 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 com
---
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 d
> 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 com
> 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 com
---
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 A
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 yo
On Tue, Dec 30, 2014 at 11:42 AM, 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
---
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, David
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
its
---
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
http:/
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 sitting
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
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 -- http:/
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 about / is the pr
> 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
> > remo
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 about / is the problem inherent
> > to the
> > _concept_ of scra
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 Tue, Dec 30, 2014 at 6:08 AM, Jan Kundrát 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 pl
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 beca
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 cha
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 ups
---
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 J
Hi,
On Mon, 29 Dec 2014 14:41:03 -0500
"Jeff Mitchell" 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 the beginning
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
Hi,
On Mon, 29 Dec 2014 12:13:38 -0500
"Jeff Mitchell" 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.
>
> Out of
Ben,
I've been having two of the three SoK students I'm helping this winter use
clones so far (the other one hasn't gotten to that point yet) for the
following reasons.
1. A scratch repo isn't available to push to since the original repo had
audit hook exceptions, so pushing to a scratch repo req
On Mon, Dec 29, 2014 at 12:13 PM, Jeff Mitchell 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 IRC. Del
On Mon, Dec 29, 2014 at 11:36 AM, Jan Kundrát 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 thei
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 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 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. Wh
On Sun, Dec 28, 2014 at 5:23 PM, Ben Cooksley 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 to let y
---
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 m
> 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
On Sat, Dec 27, 2014 at 9:09 AM, Matthew Dawson 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
>> > "reserved
36 matches
Mail list logo
