Just my humble half-cent:
regarding cli-tools:
I feel very uncomfortable on needing to install php on a Windows machine
(just as if it were Mono on a Linux machine) just to send patches to review
(maybe it's just prejudice of mine, but others may refrain from it too).
I'd prefer using a compiled p
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
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 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
On Tue, 06 Jan 2015 13:19:45 +0100
Jan Kundrát 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 project
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 b
On Monday 05 January 2015 22:59:51 Boudewijn Rempt wrote:
> 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, wh
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
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
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
- withou
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 th
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 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 a
First of all, Thomas, I forgive you (and others) for nit-picking, etc. but
please
don't do it again.
And I thank you, Thomas, for two positive suggestions re fixing the Dr Konqi
reporting failure, both before 10 October and during its resurgence, in a new
guise, in November and December (see thre
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 sho
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 German
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 pr
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 tha
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 handle
> > those
>
> Right, that's hardly documentable though (and will get old soon
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 _en
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 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 fe
On Mon, 5 Jan 2015, Thomas Lübking wrote:
I don't think this is a problem w/ RB.
When RRs get on k-c-d, many devs who can provide an abstract review are
addressed. They can take /this/ load from the actual maintainer/main
developer.
For me, personally, RB's mails are even worse. They are unr
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 fail
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
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 fai
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 m
El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure:
> 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 th
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 have more been around "try to not require stuff that's
not likely around anyway"
W
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 fa
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 t
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.
>
> Leavi
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
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 reall
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
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. The
El Dilluns, 5 de gener de 2015, a les 16:23:15, Thomas Lübking va escriure:
> 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
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
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 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 a
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 ow
On Montag, 5. Januar 2015 18:06:57 CEST, Jeff Mitchell wrote:
I really, really don't understand this concern. We're not in
the days of 500MB hard drives and nobody is asking anyone to
install constantly-running daemons with open ports. I don't
shiver with fear when I apt-get install a package
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 range,
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 master the beginnings. Heck, I myself haven't
used rbt
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 t
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 remains an und
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 lit
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
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 p
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 complex
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
requi
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 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 that Phabricator seems to be owned/maintained by Facebook Inc.
(what alone may c
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 make
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 any whatsoever exotic requirement)
Phabri
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 wan
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. *offer
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
contributors' ma
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 then accepted
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 discoura
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 those are "obscure
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
Hi,
On Mon, 05 Jan 2015 10:37:24 +0100
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_ contribut
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 we
On Monday 05 January 2015 23:57:40 Ben Cooksley wrote:
> On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát 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 shoul
On Mon, Jan 5, 2015 at 10:05 PM, Jan Kundrát 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 by a
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 conc
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 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 l
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 dev
On Mon, Jan 5, 2015 at 2:41 PM, 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
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
On Mon, Jan 5, 2015 at 12:45 PM, Cornelius Schumacher
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 the industry
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 t
On Mon, Jan 5, 2015 at 4:15 AM, 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
> thi
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 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 decisi
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 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 diffe
On Sun, 04 Jan 2015 00:37:49 +0100
Jan Kundrát 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, then the f
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
hel
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 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 Saturday, 3 January 2015 03:31:26 CEST, Ben Cooksley wrote:
Regrettably there were one or two items which conflicted. I sided with
the option which kept the barrier to entry as low
as possible as that seemed to be the greater consensus within the thread.
Hi Ben,
thanks for compiling a list.
On Saturday 03 January 2015 12:39:42 Lydia Pintscher wrote:
> On Sat, Jan 3, 2015 at 12:07 PM, Thiago Macieira 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 impor
On January 3, 2015 03:31:26 PM Ben Cooksley wrote:
> 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
On Sat, Jan 3, 2015 at 12:07 PM, Thiago Macieira 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? :)
Cheers
Lydia
--
L
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
> Client should have good documentation.
> - System should automatically set the CC / Reviewers / etc
On Sat, Jan 3, 2015 at 8:57 PM, Aaron J. Seigo 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 opt-out for t
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 revie
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 k
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
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 sysadm
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 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 Mon, Dec 29, 2014 at 11:13 PM, Thomas Lübking
wrote:
>
> IMO, a scratch repo should be hyperactive by concept and if it isn't, it
> probably settled and is good for deletion unless explicit veto.
>
Not necessarily, some projects may just be finished and don't need more
commits.
Then the quest
1 - 100 of 143 matches
Mail list logo
