subject:"Re\: Changes to our Git infrastructure"


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 agree with the importance of getting new 
blood in, but there's also a need to educate these contributors so that 
their skills become better over time.


I'm a bit worried that 
any new patch review system which requires more effort before one can 
submit a patch for review might put some potential new contributors 
off.


That's a valid point, so yeah, I agree that we should evaluate our tool(s) 
in light of being usable by newbies as well as by professionals. Thanks for 
saying that.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 about we take this
offline via email or IRC and then you can walk us 
through the problem you are
trying to fix, its significance and impact and how you 
are going about fixing it…


This has a risk of splitting the discussion about a patch into multiple 
independent streams where people will have hard time keeping track of all 
the results, IMHO.



The polishing (fixing nitpicks, etc.) should come *after* the stone is cut.


That's a good suggestion.


Going straight to that mode is inappropriate because it conveys the message,
The problem you are trying to fix is unimportant to us.  


Would it work for you if there was a bot which pointed out these issues to 
the patch author? That way it would be obvious which part of the review is 
random nitpicking which is indeed not important when one considers the 
general direction of the patch, and in addition it would come from a 
machine so there won't be any bad feelings about people not appreciating 
the contributor's work.


No amount of new technology, neither Gerritt nor the energy of 
cats confined in a
bag, can help.  There are management solutions to technical 
problems, but there
are no technical solutions to management problems, as a 
colleague of mine used to say.


Agreed. So the actual problem is lack of skilled maintainers who just 
aren't around. I agree that tooling cannot fix it -- the tooling can only 
help by a bit by making their job easier. If the maintainer is simply not 
here, then you cannot get a proper review, sure.


This is an interesting discussion, and I think that there is no problem for 
it happening in parallel to the current talk about reshaping the git 
infrastructure -- but maybe in another ML thread.



but the problem is that there's completely unmaintained code where
nobody feels qualified to sign off patches.


Exactly.  And there are simple, technology-free solutions to that problem,
if anybody is interested.


What are these solutions?


  a) There is no encouragement for the reviewer to build and TEST the
   patch, independently of the reviewee.


My personal opinion is that people should not be approving patches unless 
they tested them, or unless they have sufficient reason to believe that the 
change is OK (such as a trivial change with an associated unit test 
pre-approved by a CI run).


How can we motivate people to test these changes without discouraging them 
from doing reviews at all?



  c) Patching encourages incremental, evolutionary development,
   rather than standing back and taking a design view of the way
   things are developing.  BTW, ReviewBoard supports post-commit
   reviews of several patches or commits together, but that feature
   is turned off in the KDE usage [1].


So we need another approach (or tool) to help us perform review of the 
architecture of our software. Got some suggestions? Launchpad blueprints? 
Wiki pages?


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 that this is easy to solve with individual apps, but it's a 
hard problem when it comes to a platform, or indeed to an environment where 
the border between the individual pieces is unclear (e.g. which repo 
contains the plasma clock applet in KDE4, and where is it found in 
plasma5)? I do not have an answer on how to make this more obvious or 
beginner friendly.


The contributors still have to know what a DVCS is, and have to understand 
the concept of a commit and what a push means. But all of that applies to 
GitHub as well.


About the only difference that I can see are GitHub's pull requests. I 
understand that the knowledge of how to create a PR there is pretty 
widespread among our contributors. The fact that ReviewBoard doesn't allow 
actual approval (i.e. where it's approved *and* merged into our SCM) 
doesn't help here at all, that's also true.


I would encourage you to read 
https://techbase.kde.org/Development/Gerrit#Getting_Started . Do you think 
that the workflow proposed there is reasonably beginner-friendly?


We can then discuss ways in which it can be simplified. E.g. the need to 
set up an extra remote can go away easily *if* we agree on directing pushes 
to Gerrit once (and if) it's adopted. A website listing all projects can 
easily show a copy-pasteable link on how to clone and get the change-id 
hook in place during the initial clone, etc. We can add some scripting to 
sync SSH keys from LDAP to Gerrit, so that people only have to register 
with Identity and they'll be all set. That all is possible.


What I'm saying here is that I believe that the feature set supported by 
Gerrit is actually very close to that of GitHub. It's different because 
there's no fork me button and the concepts do not map 1:1 to each other, 
but the general ideas are very similar.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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
- without assuming the required tools/keys/accounts are already set up
- without any further reading
- covering all required steps in sufficient detail
in no more than 2000 words, or (if it's based on a web-wizard) in less
than 20 minutes?


This includes links to other pages which explain how to work with git, but 
I think that it does qualify:


https://techbase.kde.org/Development/Gerrit#Getting_Started

Does it match your requirements?

That page started as an attempt to provide a documentation for existing KDE 
developers, so it does go into depth of how to manualy Cc reviewers. If we 
decide to use Gerrit, then I think it would make a lot of sense to 
intorduce a single-page Submitting Patches Quickstart which would just 
describe the absolute basics on one page, including a git primer.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-06 Thread Boudewijn Rempt


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 newcomer in #krita.

I would encourage you to read 
https://techbase.kde.org/Development/Gerrit#Getting_Started . Do you think 
that the workflow proposed there is reasonably beginner-friendly?




Well, I find the page not very penetrable, to the point that I don't 
get the proposed workflow, but that might just be me, or the prose, which 
certainly needs editing.


But I'm the wrong person to ask in any case. What you should do is hang 
out on #kde-devel and the next time someone comes on the channel who says, 
Hello! I'm new here. I want to develop on KDE. What do I need to do?, 
grab him and ask them to go through this process, and make notes whenever 
they get confused.


Boudewijn

Re: Changes to our Git infrastructure

2015-01-06 Thread Ian Wadham

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 K, but I (or another suggested guy) will try to help.  How about 
 we take this
offline via email or IRC and then you can walk us through the problem 
 you are
trying to fix, its significance and impact and how you are going 
 about fixing it…
 
 This has a risk of splitting the discussion about a patch into multiple 
 independent streams where people will have hard time keeping track of all the 
 results, IMHO.

No, the review would be suspended while a) or b) occurred.  If b) occurs, the 
operative
words are offline via email or IRC (or face-to-face if possible).  When both 
parties
have reached an understanding of the problem and the issues involved, the formal
review can resume.

 The polishing (fixing nitpicks, etc.) should come *after* the stone is cut.
 
 That's a good suggestion.

Thanks.

 Going straight to that mode is inappropriate because it conveys the message,
 The problem you are trying to fix is unimportant to us.  
 
 Would it work for you if there was a bot which pointed out these issues to 
 the patch author?

That might be even worse, like joining a telephone queue…  And what about Krazy?

 That way it would be obvious which part of the review is random nitpicking 
 which is indeed not important when one considers the general direction of the 
 patch, and in addition it would come from a machine so there won't be any bad 
 feelings about people not appreciating the contributor's work.
 
 No amount of new technology, neither Gerritt nor the energy of cats confined 
 in a
 bag, can help.  There are management solutions to technical problems, but 
 there
 are no technical solutions to management problems, as a colleague of mine 
 used to say.
 
 Agreed. So the actual problem is lack of skilled maintainers who just aren't 
 around. I agree that tooling cannot fix it -- the tooling can only help by a 
 bit by making their job easier. If the maintainer is simply not here, then 
 you cannot get a proper review, sure.
 
 This is an interesting discussion, and I think that there is no problem for 
 it happening in parallel to the current talk about reshaping the git 
 infrastructure -- but maybe in another ML thread.

Thank you, Jan.  I am really glad you find it interesting.

 but the problem is that there's completely unmaintained code where
 nobody feels qualified to sign off patches.
 
 Exactly.  And there are simple, technology-free solutions to that problem,
 if anybody is interested.
 
 What are these solutions?

A quote from DOT: 
https://dot.kde.org/2014/06/03/ian-wadham-venerable-kde-programmer

Q. You've gotten the applications into good shape, and are ready to hand them 
off. What type of person would you like to see take over? What will they get 
out of working on these applications?

A. I would like to see KDE set up a maintenance group and standards for 
maintainability of code. Programs that reach a reasonably good standard could 
then be maintained interchangeably by members of the group.

The group could be continually changing. Nobody can stay interested in such 
work for long. Also the group and its stock of programs would be a good source 
of Junior Jobs and a place for newbies to start. It would need to have some 
experienced members, or ready access to such people, because some bugs are too 
hard for trainees to solve.

This is not a new idea. It is roughly what has been happening everywhere I have 
worked since about 1967, when the burden of people quitting jobs and leaving 
behind unmaintainable, half-finished messes became intolerable for most 
organizations.

Albert's Gardening group is a good start in this direction.

Re maintainability: KDE Community code is usually not good in this regard, 
IMHO.

As a result, I was not at all confident about my understanding of Dr Konqi and
how to patch it.  Luckily Bugzilla had quite good documentation, so *what* to
do was fairly clear.  Nevertheless, I completely missed the side-effects (re
cookies) inherent in XML RPC and kio_http.  Those side-effects are not even
visible on my platform, only on Linux.

  a) There is no encouragement for the reviewer to build and TEST the
   patch, independently of the reviewee.
 
 My personal opinion is that people should not be approving patches unless 
 they tested them, or unless they have sufficient reason to believe that the 
 change is OK (such as a trivial change with an associated unit test 
 pre-approved by a CI run).
 
 How can we motivate people to test these changes without discouraging them 
 from doing reviews at all?

Mainly by example and praise, I would say.  Plus maybe a small checklist when
clicking Ship It.

  c) Patching encourages incremental, evolutionary

Re: Changes to our Git infrastructure

2015-01-06 Thread Thomas Friedrichsmeier

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 project
  - to someone without prior knowledge of the tools involved
  - without assuming the required tools/keys/accounts are already set
  up
  - without any further reading
  - covering all required steps in sufficient detail
  in no more than 2000 words, or (if it's based on a web-wizard) in
  less than 20 minutes?
 
 This includes links to other pages which explain how to work with
 git, but I think that it does qualify:
 
 https://techbase.kde.org/Development/Gerrit#Getting_Started
 
 Does it match your requirements?

It's great to see there is a starting point, but no, that's not it, yet
(and btw, I was a bit confused when calling 2.000 words the limit.
Something on the order of 500 or 600 would be more like it. So the
length of that page (the first few sections) looks ok to me, but it's
still asking a lot of prior knowledge of a _first time_ contributor.
Things I see missing:

- What exact commands do you have to run to create and enable your SSH
  key? (And will these work cross-platform?)
- What are the commands to configure name and email in git?
- When and where do I do the step of adding the gerrit remote? (And
  just in case, include the initial git clone command)
- What command(s) do I run to create a git branch? What is an example
  of a good branch name, what is bad branch name?
- Explain the basic usage of git commit, and git commit --amend.
  Including some words on what is or is not a useful commit message.
- Also explaining basic usage git diff and git status, of course, for
  verifying the commit is as desired.
- Arguably, some words on undoing undesired changes (before / after
  staging / committing (/ pushing)) would be rather needful, too.
- Might have to explain the Change-Id-thing some more (or does it
  really happen all automagically, esp. for follow-up commits)?
- I am personally unclear on whether I'd need to follow any of the
  steps after Submitting Changes, in order to actually receive
  notifications of what happens to my request. Or how 
- Also, what is the easy / standard way to get the change in, once
  reviewed?

This may sound like nitpicking, but well, all of these are things that
you will have to know for your first review, and while many
contributors will know some of this, none of this should be assumed,
IMO.

 That page started as an attempt to provide a documentation for
 existing KDE developers, so it does go into depth of how to manualy
 Cc reviewers. If we decide to use Gerrit, then I think it would make
 a lot of sense to intorduce a single-page Submitting Patches
 Quickstart which would just describe the absolute basics on one
 page, including a git primer.

Absolutely. My point is: Try writing that page, and you'll get an idea
of what exactly you're asking a first timer to learn (in addition to
the coding) before they can get their first positive feedback.

And well, so I have followed you quite some way into discussing gerrit,
in particular, here. But I'd like not to go any further on this, at
this point. Let's wait for sysadmins to compile their list of
candidates (and I'd be rather sure that gerrit will be among the
candidate, at least). *Then* we can reasonably discuss the pros and cons
of specific alternatives.

Regards
Thomas


signature.asc
Description: PGP signature

Re: Re: Changes to our Git infrastructure

2015-01-06 Thread Martin Gräßlin

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
  
  Dr K, but I (or another suggested guy) will try to
  
  help.  How about we take this
  
  offline via email or IRC and then you can walk us
  
  through the problem you are
  
  trying to fix, its significance and impact and how you
  
  are going about fixing it…
 
 This has a risk of splitting the discussion about a patch into multiple
 independent streams where people will have hard time keeping track of all
 the results, IMHO.
 
  The polishing (fixing nitpicks, etc.) should come *after* the stone is
  cut.
 
 That's a good suggestion.

I have to disagree here. I'm not able to do a good functional review if the 
change is full of unintended nitpick things. Each changed line triggers a 
what is that change for? and if it's just a change like
- if (foo) {
+ if (foo)
+ {

then I have a hard time as a reviewer. For me as a reviewer it's important 
that the change is free of those nitpick things before I start looking at 
the functional things. It's also something I expect from a contributor to 
spend the time to run astyle on the change and configure kate to remove 
trailing white spaces before requiring my time.

For me it's difficult to recognize the true change of a patch if it's full 
of unintended changes. It just makes everything more difficult. If I have to 
review a change with such nitpick items I normally do a nitpick round first, 
then wait for the next patch version to do the proper review. This is 
optimizing my time as a reviewer. (just to get some feeling on my review 
costs: since yesterday I received 20 new mails in my reviewboard mail folder).

Also I do not think that reviewboard makes nitpicking to easy - if it wouldn't 
highlight the trailing whitespaces I would still point them out as I consider 
these things as important.

 
  Going straight to that mode is inappropriate because it conveys the
  message, The problem you are trying to fix is unimportant to us.
 
 Would it work for you if there was a bot which pointed out these issues to
 the patch author? That way it would be obvious which part of the review is
 random nitpicking which is indeed not important when one considers the
 general direction of the patch, and in addition it would come from a
 machine so there won't be any bad feelings about people not appreciating
 the contributor's work.

I would certainly appreciate it. I don't like doing things a computer could 
do. It might also make my life as a reviewer easier as I can see that the 
computer already handled it.

Qt does that and if I hit such a problem the first thing I do is fixing those 
items to upload a clean patch.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Changes to our Git infrastructure

2015-01-06 Thread Boudewijn Rempt


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 big picture first and that isn't easy.

See http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/


Lovely article. I know some people would object that the awful 
indentation makes the patch impossible to read, but apart from that 
specious argument, it's great advice.


I wonder if we can tweak a tool to only allow line-by-line comments after 
two high-level reviews have been written...


Boudewijn

Re: Changes to our Git infrastructure


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, the end 
result is the same.


- 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 it more understandable?

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).


KDE purposefully has a very low barrier to entry. A contributor 
can normally push anywhere.


When I said a contributor, I was referring to somebody who is not a KDE 
developer yet. Please re-read what I wrote again because your understanding 
assumed that a contributor is someone who can push to git. I can see why 
you arrived at what you said in that case, but that's not what I said.



.NET is a framework, not a language. Maybe you meant C#. ...


Thanks for educating me, but I don't think it helps move this 
discussion forward in a productive manner.


I do. Because there are a huge number of languages that have 
compilers to produce .NET CLI. Some of them are indeed 
relatively obscure. Saying .NET doesn't mean anything in terms 
of which languages you are taking issue with. Let's be clear 
what we're talking about.


I was quite obviously referring to any tools which make use of the .NET 
runtime environment. I do think that mandating these for efficient work 
with our code review system is a pretty big no-go.


As other people have added to the list of requirements, patch 
management needs to be able to be done via the web UI. Nobody 
has to install any runtime environment.


The requirement I listed was make the changes available as git refs so 
that I do not use any other tool to work with them. If that is not 
available, then another requirement is have a nice CLI implemented in a 
language that is common on KDE desktop.


The fact that I can fetch and upload patches via a website does not satisfy 
this requirement. It's a bandaid help, not a fully usable solution.


Those that want to contribute will be required to install a 
whole slew of development packages.


Unless they have e.g. done something with Qt already, or unless they're C++ 
developers already, etc.


Especially if it's only needed if they want to do advanced CLI 
stuff.


Fetching patches is not advanced stuff. It's cool to have a manual bypass 
for fetching stuff by hand, but that is a hotfix, not a productive 
solution.


The sysadmins appear to have a strong preference for a unified 
tool to do both.


No, our preference is for well-integrated tools, which is the 
same preference you previously stated.


I'm happy to hear this, but then I don't know how to interpret Ben's 
earlier responses in this thread and our conversations on IRC. Anyway, it's 
cool that we agree on something :).


To put my money where my mouth is, yes, I am willing to 
maintain the extra systems, and I have been doing this with 
Gerrit (and CI) for a couple of months already.


Yes, because Gerrit is not a tool being provided by the 
sysadmin team and as such is not in scope for us to maintain. 
It's great that you're willing to help out, but your offer to 
help maintain Gerrit has no bearing on whether or not it's what 
we end up proposing to the community.


I'm simply stating that any possible argument saying we prefer a single 
tool because we don't have manpower to maintain more of them is moot 
because that manpower is waving its hand and saying I'm gonna do this 
right now.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 concern, so the core question is whether this scenario:

- make changes
- make a commit
- push that commit

is any more complex than:

- make changes
- create a diff
- upload that diff via a browser.

I have to admit I have no idea which one is *really* easier for a total 
newbie, and which one is easier for an average contributor.



Your project's situation may be very different from mine. Personally,
I'm much more worried about keeping the entry barrier as low as
possible, than about reducing the amount of effort that I have to put
into supporting and educating contributors.


That's also a possibility. However, in my experience with Gerrit, GCI 
students (which are kids aged 12-18, IIRC) were able to upload patches 
without substantial problems. That's despite our rudimentary state of 
KDE-specific documentation, and Gerrit having a oh no, let's run away from 
that beast reputation. In short, I think that there's actually a solution 
which can be both a low enough barier to entry *and* help maintainers do 
their job easier.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-05 Thread Ben Cooksley

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 by any other criteria is playing
 pure favouritism to a given set of language(s) and unnecessarily
 limits our options.


 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. It is OK to say that you
 disagree, but it doesn't prove the point to be any less valid. It's fine to
 have people assign varying importance to different evaluation criteria, so
 please do not use your sysadmin hat to unilaterally remove this pure
 favoritism just because you do not see any value in it.

 My impression was that we're gathering a list of possible requirements and
 *then* we, as a community, are going to assign some importance factor to
 each and every item raised. It is therefore acceptable to have mutually
 exclusive criteria at this point, or even bits which some of us might find
 to be totally irrelevant. They are going to be sorted out be community's
 consensus, I suppose.

The list of requirements is first gathered from the community. We then
summarize it with items being weighted based on the level of support
mentioned by various people and send it back. If everyone is broadly
happy we then go ahead and prepare solutions which meet this list of
requirements. There is no community level sorting of the items because
items don't have a priority - it is a best effort basis to meet all of
the requested features and functions.

These proposals are accompanied by the pros and cons each faces, along
with a recommendation for the one we believe best fits the needs of
the community.
You can see an example of this in the initial git.kde.org setup which
Sysadmin did many years ago (2010 I think).



 With kind regards,
 Jan

Cheers,
Ben


 --
 Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 language(s) and unnecessarily
limits our options.


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. It is OK to say that you 
disagree, but it doesn't prove the point to be any less valid. It's fine to 
have people assign varying importance to different evaluation criteria, so 
please do not use your sysadmin hat to unilaterally remove this pure 
favoritism just because you do not see any value in it.


My impression was that we're gathering a list of possible requirements and 
*then* we, as a community, are going to assign some importance factor to 
each and every item raised. It is therefore acceptable to have mutually 
exclusive criteria at this point, or even bits which some of us might find 
to be totally irrelevant. They are going to be sorted out be community's 
consensus, I suppose.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-05 Thread Milian Wolff

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 should be more than
  sufficient criteria here. Limiting it by any other criteria is playing
  pure favouritism to a given set of language(s) and unnecessarily
  limits our options.
  
  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. It is OK to say
  that you disagree, but it doesn't prove the point to be any less valid.
  It's fine to have people assign varying importance to different
  evaluation criteria, so please do not use your sysadmin hat to
  unilaterally remove this pure favoritism just because you do not see
  any value in it.
  
  My impression was that we're gathering a list of possible requirements and
  *then* we, as a community, are going to assign some importance factor to
  each and every item raised. It is therefore acceptable to have mutually
  exclusive criteria at this point, or even bits which some of us might find
  to be totally irrelevant. They are going to be sorted out be community's
  consensus, I suppose.
 
 The list of requirements is first gathered from the community. We then
 summarize it with items being weighted based on the level of support
 mentioned by various people and send it back. If everyone is broadly
 happy we then go ahead and prepare solutions which meet this list of
 requirements. There is no community level sorting of the items because
 items don't have a priority - it is a best effort basis to meet all of
 the requested features and functions.
 
 These proposals are accompanied by the pros and cons each faces, along
 with a recommendation for the one we believe best fits the needs of
 the community.
 You can see an example of this in the initial git.kde.org setup which
 Sysadmin did many years ago (2010 I think).

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 
concentrate on the important aspects first, the admins would have less work 
and most people are still happy.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Changes to our Git infrastructure


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. They're three of the most
popular and widespread languages in the world.


For command-line applications on Linux?


A binary's a binary.

As I stated in my example, I use git-annex, which is coded in Haskell. 
It's not a common language for command-line applications on Linux, but 
it works and is useful. I don't see why it being in an obscure 
language matters.


--Jeff

Re: Changes to our Git infrastructure


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 
concentrate on the important aspects first, the admins would have less work 
and most people are still happy.


+1, this is exactly what I wanted to say.

Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-05 Thread Milian Wolff

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.
 
 Yes, because you are repeatedly assuming that such a tool would be
 required on all developers' and contributors' machines, and are ignoring
 our repeated statements that this is not a requirement to be a developer
 or contributor.

I think you two are misunderstanding each other. Jan is worried about the cli 
tools for developers, i.e. what currently is rbt tools. You, otoh, speak about 
the server-side tools, which of course can be written in any language you are 
willing to install on the server side.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Changes to our Git infrastructure


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-off in some
cases.


That's a valid concern, so the core question is whether this scenario:

- make changes
- make a commit
- push that commit

is any more complex than:

- make changes
- create a diff
- upload that diff via a browser.

I have to admit I have no idea which one is *really* easier for a 
total newbie, and which one is easier for an average contributor.


Obviously, you forgot another workflow that has been discussed:

- make changes
- make a commit
- use a CLI tool to push the change up for review

--Jeff

Re: Changes to our Git infrastructure


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 any whatsoever exotic requirement)


Phabricator has an equivalent of rbtools/rbt called Arcanist which is 
written in PHP. There are AFAIK no other tools for automating working 
with Phabricator's code review subsystem.


No, but it's all API driven so you are free to write whatever tools you 
may like.


I claim that requiring PHP or JVM or .NET for each 
developers'/contributors' productive work is bad.


I claim that apt-get install php5-cli is not any more difficult than 
any other package installations developers may have to perform. Since 
you brought up Java, if we were talking about a Java tool, I would make 
the same claim about apt-get install (your pick of default-jre, 
default-jre-headless, openjdk-7-jre). .NET, apt-get install 
mono-runtime.


Jeff's response is that PHP is not really required because they can 
just juggle patches by hand and paste them to web interfaces or pipe 
to `git am`. While this is technically correct, I find this logic 
misleading


So is your characterization of my claims. For one, I've never said 
anything about juggling patches by hand or piping to git am, only 
about web interfaces.


You have claimed that for the occasional contributor with one to two 
patches a year that installing such a tool is onerous. I disagree with 
that, but regardless, I've said that submitting patches via a web 
interface should be perfectly fine for such occasional contributors and 
that those that will want the power of the CLI tool are likely to be 
more advanced developers/contributors -- who I don't believe would find 
the setup of such a tool to be difficult or onerous.


I do not claim that in a Phabricator world that advanced/regular 
developers would be required to always copy and paste diffs into a web 
UI (and realistically if using the web UI you'd probably save the diff 
to a file and then just upload it). Those that prefer such a workflow 
could use it. Those that don't -- and that don't have unwavering 
language preferences for their tools -- would have command-line options.


and say that in absence of tools which are on-par with Arcanist, PHP 
is effectively required, and I do find this situation a downside of 
Phabricator.


Your hatred of PHP is well noted. I do not feel so strongly as you about 
the languages in which useful tools are written. As I said before, I 
can't speak for the broader KDE development community about that (and I 
doubt you can either).


I also point out that there are other tools which do not require a 
client-side PHP script.


Yes, you've made that abundantly clear.

--Jeff

Re: Changes to our Git infrastructure


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 
requirement to install it for the only purpose of pushing reviews via cli.

Cheers,
Thomas

Re: Changes to our Git infrastructure

2015-01-05 Thread Milian Wolff

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 typical client systems.
  Therefore it's a valid concern that people might very well be pushed
  off by the requirement to install it for the only purpose of pushing
  reviews via cli.
 
 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 and it wants to pull in a bunch of
 (non-daemon) libraries. Whatever you need to do your job, man.
 
 But I recognize that this may be a limitation of my own psyche.

Personally, I also fail to see the issue here. PHP is 15.23MiB on my Arch box. 
Compare that with 34M of karchive build dir when you enable debug symbols (and 
karchive is small!).

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Changes to our Git infrastructure


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 than having just a single 
one.


Does it make it more understandable?


No. What you're saying is having two tools is more complex. It's 
still one workflow.


I feel like you're just language-lawyering here. The workflow I 
propose pushes the burden of producing clean patches to the 
contributor. The workflow you're advocating for appears to center 
around sending patches around


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 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 tool, regardless of how they interact. 
And if yours does, you can't complain about other workflows that do.


GitHub is a notable example showing that people don't seem to have an 
issue with a workflow that uses Git + a web-based tool to manage 
their code reviews. I'm not saying we need to end up with that, I 
just don't think it's credible to claim that it's too difficult or 
complex.


That isn't an example that proves your point, though.


It does if my point was (and it was) that a workflow consisting of 
producing a commit in Git and having the review take place via a web UI 
is a very broadly accepted paradigm in software development, and one 
that is often considered to be friendly to newcomers.


and I believe you were saying that it's fine for a CR tool to work on 
patches and not git trees.


Correct. Although I recognize the merits of such an approach, I do not 
believe that the only acceptable way for a code review tool to work is 
on git trees instead of via patches. And I do not believe that this one 
feature is enough to outright dismiss all other options.


Given your earlier statements I imagine, but this is only supposition, 
that one of the reasons you desire such an approach is so that you can 
have all review actions be performed via SSH commands without requiring 
either a web UI or external tool. While this is certainly nice to have, 
I don't believe that it is very usable for newcomers (we've weathered 
enough complaints over the years about Gitolite SSH commands). Given the 
earlier distinction you made between contributors and developers, it 
also requires those that want to contribute patches to have full KDE 
developer accounts with commit/push access in order to push those diffs 
up for code review...something not required from a web interface 
requiring only an Identity account.


--Jeff

Re: Changes to our Git infrastructure


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 people might very well be pushed 
off by the requirement to install it for the only purpose of pushing 
reviews via cli.


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 and it wants to pull in a bunch of 
(non-daemon) libraries. Whatever you need to do your job, man.


But I recognize that this may be a limitation of my own psyche.

--Jeff

Re: Changes to our Git infrastructure


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 
single workflow cannot include more than one tool.


I believe this discussions heat turned into talking in absolutes.
Your truth - my truth.

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, scale seems a major requirement 
on workflow and tools. Pure CLI access on alinged syntax for efficient pros is as 
relevant as an easy GUI access for starters.


Correct. Although I recognize the merits of such an approach, I 
do not believe that the only acceptable way for a code review 
tool to work is on git trees instead of via patches.


I'd assume operating on git trees is certainly far more important for CI than 
for reviewing patches.


And I do not believe that this one feature is enough to outright dismiss 
all other options.


See? Absolutes ;-)
No feature trumps all others, but it's a matter of ranking and thus all must be 
taken into fair and objective consideration.

distinction you made between contributors and developers, it 
also requires those that want to contribute patches to have full 
KDE developer accounts with commit/push access in order to push 
those diffs up for code review


I don't think this is actually a requirement - the review repo (maybe even 
branches) could easily have other/lower credential requirements than the 
vanilla one.

Cheers,
Thomas

Re: Changes to our Git infrastructure


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 tool, regardless of 
how they interact. And if yours does, you can't complain about 
other workflows that do.


I was complaining about an IMHO artificial split where drive-by people 
submit changes in a different way than core developers. I stated that this 
introduces some needless difference to the way devs and contributors work, 
and that we should check whether there are tools that remove this 
difference. I know that e.g. Gerrit removes that difference, so I am not 
thrilled by the idea of using something without that feature.


It does if my point was (and it was) that a workflow consisting 
of producing a commit in Git and having the review take place 
via a web UI is a very broadly accepted paradigm in software 
development, and one that is often considered to be friendly to 
newcomers.


You're right, and I apologise for not understanding you correctly, we're in 
violent agreement after all.


and I believe you were saying that it's fine for a CR tool to 
work on patches and not git trees.


Correct. Although I recognize the merits of such an approach, I 
do not believe that the only acceptable way for a code review 
tool to work is on git trees instead of via patches. And I do 
not believe that this one feature is enough to outright dismiss 
all other options.


That's another thing where I should have probably worded my responses 
better. The requirements I listed were things which I found valuable for my 
work. I did not mean to say that it's the only possible way of doing 
reviews, or that I found everybody who disagrees with me to be a moron. 
It's just that these features are important for me, so I would like to see 
them and I wanted to make sure they are listed as a requirement in a list 
of points gathered by the community.


Maybe this misunderstanding is caused by sysadmins likely perceiving the 
requrements as hard ones which MUST be provided by any solution, while my 
impression is that we were asked to say what is important for us, and the 
evaluation is to be performed by us all together, not just the sysadmins.


Given your earlier statements I imagine, but this is only 
supposition, that one of the reasons you desire such an approach 
is so that you can have all review actions be performed via SSH 
commands without requiring either a web UI or external tool. 
While this is certainly nice to have, I don't believe that it is 
very usable for newcomers.


I agree that *that* would suck :).

Given the earlier 
distinction you made between contributors and developers, it 
also requires those that want to contribute patches to have full 
KDE developer accounts with commit/push access in order to push 
those diffs up for code review...something not required from a 
web interface requiring only an Identity account.


There is no need for full KDE developer account to upload changes for 
review with Gerrit. All that is needed is a regular Identity account.


Behind the scenes, it works by Gerrit being a special git server which 
intercepts pushes and stores each of these changes in a separate ref. I'll 
be happy to go into more detail in another thread, off-list or on IRC.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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, scale seems a major 
requirement on workflow and tools. Pure CLI access on alinged syntax 
for efficient pros is as relevant as an easy GUI access for starters.


Totally agree.

Correct. Although I recognize the merits of such an approach, I do 
not believe that the only acceptable way for a code review tool to 
work is on git trees instead of via patches.


I'd assume operating on git trees is certainly far more important for 
CI than for reviewing patches.


Yes, that's correct. But then we need to remember that there is a social 
component that is not finalized (and discussed in another thread), which 
is branch policy. Without operating on git trees, a developer could 
still be working on a feature branch and have a review going for the 
commits in that feature branch, and the CI could operate on that branch.


The harder integration (and by no means should be assumed impossible, 
I'm just not sure how easy it would be at the moment since I haven't 
looked) for CI with respect to git trees vs. patches would be for 
one-off patches that aren't keyed to branches. But, if we're talking 
about contributors, not KDE developers with commit access, then they 
can't work with git trees anyways; if someone is already a KDE 
developer, they could work in a feature branch.


Or not. Generally I'm happy providing tools and letting the various 
projects decide on their own preferred method for handling branches and 
patches.


distinction you made between contributors and developers, it also 
requires those that want to contribute patches to have full KDE 
developer accounts with  commit/push access in order to push those 
diffs up for code review


I don't think this is actually a requirement - the review repo (maybe 
even branches) could easily have other/lower credential requirements 
than the vanilla one.


There aren't such things as review repos right now, even on the current 
infrastructure (you could consider clones to be that, but creating 
clones and scratch requires full KDE developer accounts). Yes, you are 
right that highly flexible branch policy may allow something like this, 
but right now there is no such thing as commit access without having a 
full developer account. I think changing that -- assuming tool support 
for this -- would be a deeper policy discussion that is probably best 
had in a different thread.


--Jeff

Re: Changes to our Git infrastructure

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 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 at making it easy to discuss the why,
 wherefore and how of a particular change.

Well, how would you want to have a proper discussion then?
What's your desired workflow/UI for it?
I see what you mean, but to me it seems more a misuse of the tool by the 
community, not a fault of the tool itself.

Cheers,
  Albert

 
 On Mon, 5 Jan 2015, Albert Astals Cid wrote:
  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

Re: Changes to our Git infrastructure


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 fails 
at making it easy to discuss the why, wherefore and how of a 
particular change.


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.
But if nobody feels in charge for the addressed component, you won't get an 
informed response.

Before Ian started the DrKonqui patches I had not seen the drkonqui code even 
one single time and my idea who worked on it was from the git history

Bottom line: things are maintained by an individuum or not at all. If everybody 
is in charge, nobody actually is.

Cheers,
Thomas

Re: Changes to our Git infrastructure

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 have more been around try to not require stuff
 that's not likely around anyway
  We have ruby scripts
 
 Where (wrt code submission?)?

Oh, rbtools is python, somehow i thought it was ruby. Well goes to show it 
doesn't matter the least what a tool is written on, you just install it and 
run it :)

Cheers,
  Albert

Re: Changes to our Git infrastructure

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 don't. What you have to do is accept is this: others don't. The 
rest of the world is fine with accepting that you think it's simple, 
that's not the point of the discussion.


So, yes, you cannot write a git-for-dummies manual, for that we need 
a genius like David Revoy. Just get this: you hope everyone has met a 
DVCS. I regularly meet people for whom git is a magic way of getting new 
features, and who have _no_ idea at all about what version control is, or 
what source code is. And many of them turn out to be awesome contributors, 
and some even, after a year or two, help with git bisecting a particular 
bug.


So all I want to make sure here is that participation in KDE is as 
accessible as possible to the great majority of the world that doesn't 
want to play the 'serious software engineer', qt-project.org-style.


That is why I've given the link to what non-engineers active in #krita 
think about KDE's infrastructure, and that's why I've tried to show you 
how intimidating something you find very simple actually is, how many 
steps that you know are optional, or necessary, you actually forgot to 
mention in your little list.


 On Mon, 5 Jan 2015, Albert Astals Cid wrote:


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 the
right info on techbase, as well as the awareness that techbase exists.

You can always just use the full url.


* figuring out the reponame for a particular project (and that isn't as
easy as just downloading the entire trunk of kde's svn repo -- even if I
never did that myself)

Sure, if you don't know the repo name you're out of luck, not that downloading
the whole trunk would help you much more (you can still grep but it may take
ages)




do coding
git commit


* using the commit template

You don't really need a commit template (though it's nice if you use it)


* with the relevant keywords

You don't really need to use the keywrods (though it's nice if you use it)


* having a grasp of what a git commit is, especially that a commit isn't
visbile to anyone else

Any modern (i.e. DVCS) has that concept, sure it's complicated for cvs/svn
people, i'd like to think most of us has worked with a DVCS at the moment.


git push


But not before you have

* realized that you need to push, i.e. what local and remote is

Same as above, it's DCVS.


* figured out what branches are for, and how different projects handle
those

Right, that's hardly documentable though (and will get old soon most probably)


* got your kde indenity

Every system needs it's own identity system, we use ours.


* posted it on the right reviewboard

Reviewboard is not mandatory (though it's nice)


* to the right reviewers

Yes, you either have to pick the reviewers or let a robot do your job.

That said, i'm not saying contributing is easy, i'm just saying the pure git
part is not that hard, it's all the project overhead (branches, review,
account, etc) that really makes it harder (in my opinion).

Cheers,
 Albert

Re: Changes to our Git infrastructure

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 _enough_. And yes, I know about the whole
reply-to-mangling-is-dangerous lunacy.)

You get them, because you send them. kcd is cc'd by your mails what will in the end make
mail clients reply to all rather than just to the mailing list.

Reviewboard isn't limited to kde-core-devel.

It's not only not limited, it's not even bound to kcd.
The receivers depend on the groups you attach to the RR.

And it doesn't answer my main complaint: reviewboard, by its design, is made
to whine about whitespace, extra white at the end of lines and
other one-line complaints.

a) breaking coding style is bad style anyway. Get a better editor, don't
introduce tabs and trailing spaces and weird indention etc. and there'll be no
complains.

b) You missed my argument.
MANY ppl. can give you an abstract review (whitespace, hot loop, performs crap,
this may crash) but only VERY FEW ppl. can make a feature comment.
If none of the latter ever shows up because the component has vacant maintainance, you
might oc. feel that ppl. only nitpick, but the alternative is that your patch
remains entirely uncommented and if you at some point just push it, you'd introduce
unnecessary style breaks and bad code on top of that.

It gives the reviewer a happy feeling of a job well-done

That's nonsense. It ideally maintains general code quality by many eyes.
If you are in charge of a component and have fundamental comments, you
certainly won't restrict yourself to comment the patch on an abstract level.

and the submitter a cold shower.

Eye of the beholder?
It's a tasklist. Nothing more, nothing less.
If that scares you, you probably would not want to hear fundamental concerns at
all.

There might be a cultural gap between rather polite (lying) and rather direct
(offending) societies, but that won't be fixed by any communcation tool in the near future.

Cheers,
Thomas

Re: Changes to our Git infrastructure

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 handle
   those
  
  Right, that's hardly documentable though (and will get old soon most
  probably)
 
 this is IMO one of the main issues. This really should be documented, and
 ideally should be consistent for all KDE repositories. And this policy
 also shouldn't change often.
 How to deal with branches correctly, i.e. how the project maintainers
 expect it, is a big part what can make using git hard.

But that hasn't changed since svn, no? (Not saying it's good or bad, just 
saying i don't see this is a difference in git)

Cheers,
  Albert

 E.g. using git for cmake is easier, because there the workflow (how to
 branch etc.) is fully documented.
 
 Alex

Re: Changes to our Git infrastructure

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 that people should read Ian's mail, with attention:


Speaking for myself, I find this a huge turnoff in the KDE world and am 
now planning to retire from KDE as soon as I can.  But then I am 76 and 
git is my 10th source-code control system since 1965-66, so I have little 
interest in mastering it.


I have also found ReviewBoard utterly counter-productive this year, either 
because one writes an entry and nobody reviews it, or nobody understands 
it, or because one gets nitpicked about syntax and white space when one is 
really looking for helpful advice about how better to solve the problem at 
hand. I think I must have lost a month or two on ReviewBoard during the 
year, with very little helpful advice gained.


I consider nitpick reviews harmful. If you have nothing better to do than 
nitpick, don't, and reviewboard is a tool which encourages you to do.


On Mon, 5 Jan 2015, Thomas Lübking wrote:


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 _enough_. And yes, I know about the whole 
reply-to-mangling-is-dangerous lunacy.)
You get them, because you send them. kcd is cc'd by your mails what will in 
the end make mail clients reply to all rather than just to the mailing 
list.





Reviewboard isn't limited to kde-core-devel.

It's not only not limited, it's not even bound to kcd.
The receivers depend on the groups you attach to the RR.


And it doesn't answer my main complaint: reviewboard, by its design, is 

made
to whine about whitespace, extra white at the end of lines and 
other one-line complaints.


a) breaking coding style is bad style anyway. Get a better editor, don't 
introduce tabs and trailing spaces and weird indention etc. and there'll be 
no complains.


b) You missed my argument.
MANY ppl. can give you an abstract review (whitespace, hot loop, performs 
crap, this may crash) but only VERY FEW ppl. can make a feature comment.
If none of the latter ever shows up because the component has vacant 
maintainance, you might oc. feel that ppl. only nitpick, but the 
alternative is that your patch remains entirely uncommented and if you at 
some point just push it, you'd introduce unnecessary style breaks and bad 
code on top of that.



It gives the reviewer a happy feeling of a job well-done

That's nonsense. It ideally maintains general code quality by many eyes.
If you are in charge of a component and have fundamental comments, you 
certainly won't restrict yourself to comment the patch on an abstract level.



and the submitter a cold shower.

Eye of the beholder?
It's a tasklist. Nothing more, nothing less.
If that scares you, you probably would not want to hear fundamental concerns 
at all.


There might be a cultural gap between rather polite (lying) and rather 
direct (offending) societies, but that won't be fixed by any communcation 
tool in the near future.


Cheers,
Thomas

Re: Changes to our Git infrastructure

2015-01-05 Thread Alexander Neundorf

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 -- I ain't rude, I'm just honest, it's cultural!), I
 think that people should read Ian's mail, with attention:
 
 Speaking for myself, I find this a huge turnoff in the KDE world and am
 now planning to retire from KDE as soon as I can.  But then I am 76 and
 git is my 10th source-code control system since 1965-66, so I have little
 interest in mastering it.
 
 I have also found ReviewBoard utterly counter-productive this year, either
 because one writes an entry and nobody reviews it, or nobody understands
 it, or because one gets nitpicked about syntax and white space when one is
 really looking for helpful advice about how better to solve the problem at
 hand. I think I must have lost a month or two on ReviewBoard during the
 year, with very little helpful advice gained.
 
 I consider nitpick reviews harmful. If you have nothing better to do than
 nitpick, don't, and reviewboard is a tool which encourages you to do.

I wouldn't blame it on reviewboard, I don't have the impression it differs in 
this regard e.g. from gerrit.

Alex

Re: Changes to our Git infrastructure

2015-01-05 Thread Aaron J. Seigo

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 at making it easy to discuss the why,
 wherefore and how of a particular change.

That is a development culture issue than no tool can fix. Reviewboard is great 
for discussing changes in the hands of people who value that sort of 
interaction. It also can be used to deliver only nitpicking in a non-
constructive manner. The difference in experience comes down to the what the 
people using it value.

Where reviewboard is not good enough is in making it easy to quickly try the 
patch (bi-directional scm integration) ... but the commenting and discussion 
features are pretty much as good as it gets.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Changes to our Git infrastructure


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 feeling he's
done his job, while it fails at making it easy to discuss the why,
wherefore and how of a particular change.


That is a development culture issue than no tool can fix.


Not fix, but a tool can encourage one way or another.


Reviewboard is great
for discussing changes in the hands of people who value that sort of
interaction. It also can be used to deliver only nitpicking in a non-
constructive manner. The difference in experience comes down to the what the
people using it value.

Where reviewboard is not good enough is in making it easy to quickly try the
patch (bi-directional scm integration) ... but the commenting and discussion
features are pretty much as good as it gets.

--
Aaron J. Seigo

Re: Changes to our Git infrastructure


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 should ideally go along w/ the functional reviews.
That you believe it's the only kind of review you get implies that you would 
simply not have gotten any other review otherwise. Not ideal, but rather 
unrelated.

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!)


Sorry, I was just trying to understand what could get anyone scared about a very simple 
and direct please fix this, this and that list - it would have to be fixed 
anyway at some point.

I'm sorry if you or anyone feels offended by the way it's presented, but to 
change that, one would first need to have a remote idea, what's so driving away 
about it. And sorry again, but I really cannot even imagine - wheter you may 
call that rude or dumb.



Ian and the DrKonqui bug:
---

I think that people should read Ian's mail, with attention:

I have read Ian's mail and I do recall his review requests on DrKonqi.

I agree that the process was anything but fluid - though ultimately successful.

Apparently nobody actually felt in charge of DrKonqi then (and now, since Ian 
will apparently be sadly lost, again), so other developers, unfamiliar w/ 
DrKonqi commented on the patches - the first two of them actually focussing on 
OSX specific (or rather triggered) issues.


The last one addressed DrKonqi being broken due to bugzilla changes.

It was presented first on 30/9/2014, saw an immediate coding style and function 
design review, resolved 3/10/2014.
Followed up by a minor nitpick to not use fprintf, but kdebug and a call for 
someone w/ experience on the codebase to review on 5/10/2014

On 6/10/2014 Ian worried that he's perhaps the person most familiar with the 
codebase of Dr Konqi, having worked on it for a few months now and sugested to push 
the patch within the next 24h.

This raised immediate concerns from the release team about the size of the patch, 
discouraging to submit it to 4.14 what caused a hyperactive 7/10/2014 with the discussion 
leading to the consensus that a vastly simplified version of the patch would still be the 
best option for 4.14 (and suggestions on how to simplify things) with the result being 
finally presented 9/10/2014 and submitted and submitted in time 23h later.

I would fully agree that 7/10/2014 should have been 30/9/2014, but the most 
important thing is:

  IT TOOK A VETO FROM THE RELEASE TEAM 
   and thus

  THE THREAT OF A BROKEN DR KONQI FOR KDE SC4

to cause major interest in the patch, what is, given the DrKonqi bug was 
reported long before, a clear sign that nobody actually had a special interest.
In the end, blind ppl. were supposed to guide the one-eyed.

AND NO TOOL ON EARTH WILL EVER FIX SUCH A SITUATION.

Tools are as good or bad as the ppl. that use them. The problem is *not* that 
RB encourages nitpicks, but the problem is that there's completely unmaintained 
code where nobody feels qualified to sign off patches.

Ian is certainly the one person permitted to retire whenever he feels like, but 
/actually/, now that the worst time is passed, he would be the one to fix 
*this* problem for DrKonqi, ie. become the person to sign off patches.

Cheers,
Thomas

Re: Changes to our Git infrastructure


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 master the beginnings. Heck, I myself 
haven't used rbtools, even though the reviewboard site urges it 
strongly. Let the real experts use cli tools, and they can handle a 
bit of obscurity.


So I don't think obscure cli tools matter even one whit -- what 
matters is having the nicest possible web tools that make life for 
people as easy as possible. Ideally, people shouldn't need a kde 
identity to submit something (patch, bug report, idea, screenshot, 
plea for help), and reviewers should be able to drop into a private 
conversation with only very little effort.


Agreed. We've been looking for more friendly, better-integrated, and 
more usable tools for a long time. Not just for newcomers, but 
especially for newcomers. When you're an old hand at development, 
minimal setup of a useful tool is just not a huge burden.


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 and all sorts of other nastiness. 
Possibly allowing non-Identity account providers for non-developers is a 
good middle ground (Google, Twitter, Facebook, GitHub).


--Jeff

Re: Changes to our Git infrastructure


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 and all sorts of other nastiness. Possibly allowing 
non-Identity account providers for non-developers is a good middle ground 
(Google, Twitter, Facebook, GitHub).



Yes, that should be totally fine. The intersection of people who don't 
want a kde identity (or find it too much bother) and those people who feel 
g, t, f, gh are too invasive is really small, and, honestly, likely too 
individual to be helpful.


Boudewijn

Re: Changes to our Git infrastructure


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 own preferred 
workflow involves more than one tool, regardless of how they 
interact. And if yours does, you can't complain about other workflows 
that do.


I was complaining about an IMHO artificial split where drive-by people 
submit changes in a different way than core developers. I stated that 
this introduces some needless difference to the way devs and 
contributors work, and that we should check whether there are tools 
that remove this difference. I know that e.g. Gerrit removes that 
difference, so I am not thrilled by the idea of using something 
without that feature.


Understandable, although I think that as our policy currently stands 
over who can commit to repos, this is necessary anyways (since you need 
a developer account to commit, and once you have that you could work on 
a topic branch). It's also pretty common -- e.g. most GitHub repos don't 
allow people to commit directly, but rather go through a merge request 
workflow. But I understand why you feel that this would be a regression.


That's another thing where I should have probably worded my responses 
better. The requirements I listed were things which I found valuable 
for my work. I did not mean to say that it's the only possible way of 
doing reviews, or that I found everybody who disagrees with me to be a 
moron. It's just that these features are important for me, so I would 
like to see them and I wanted to make sure they are listed as a 
requirement in a list of points gathered by the community.


OK, sorry for misunderstanding.

Maybe this misunderstanding is caused by sysadmins likely perceiving 
the requrements as hard ones which MUST be provided by any solution, 
while my impression is that we were asked to say what is important for 
us, and the evaluation is to be performed by us all together, not just 
the sysadmins.


It's definitely why Ben put out a call for people to list requirements. 
We want to make sure that we understand what people are looking for. But 
it did seem like some people (not just you) were essentially saying if 
it doesn't have X we must not use it, regardless of whether a solution 
has A, B, C, ...


Given the earlier distinction you made between contributors and 
developers, it also requires those that want to contribute patches to 
have full KDE developer accounts with commit/push access in order to 
push those diffs up for code review...something not required from a 
web interface requiring only an Identity account.


There is no need for full KDE developer account to upload changes for 
review with Gerrit. All that is needed is a regular Identity account.


OK. I was unaware of that since (normally speaking) Gerrit intercepts 
pushed refs and then pushes them into g.k.o.


--Jeff

Re: Changes to our Git infrastructure

2015-01-05 Thread Frank Reininghaus

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 something they can be rightly
 proud of when they master the beginnings. Heck, I myself haven't used
 rbtools, even though the reviewboard site urges it strongly. Let the real
 experts use cli tools, and they can handle a bit of obscurity.

 So I don't think obscure cli tools matter even one whit -- what matters is
 having the nicest possible web tools that make life for people as easy as
 possible. Ideally, people shouldn't need a kde identity to submit something
 (patch, bug report, idea, screenshot, plea for help), and reviewers should
 be able to drop into a private conversation with only very little effort.

 Agreed. We've been looking for more friendly, better-integrated, and more
 usable tools for a long time. Not just for newcomers, but especially for
 newcomers.

yes, I fully agree. It certainly makes sense to improve our tools such
that they are more convenient for maintainers and others who
contribute very frequently, but taking the needs of newcomers into
account is also very important. Ultimately, a constant stream of
newcomers is the only thing that keeps a free software project alive
in the long term.

I have read a large number of bug reports during the past few years,
and I have very often seen first-time contributions which consisted of
a patch which was generated by redirecting the output of git diff to
a file and then attached to the bug report. In my experience, thanking
the new contributor for their efforts and asking them to upload their
patch file to http://reviewboard.kde.org/ via the web interface has a
success rate of close to 100%, and often, the contributors will then
continue to fix bugs and submit more patches. I'm a bit worried that
any new patch review system which requires more effort before one can
submit a patch for review might put some potential new contributors
off. And I'm not talking about the requirement to not introduce unit
test regressions or follow the coding style or fix white space issues
here - that certainly makes sense! - but the effort that is required
before one can even use the patch review system.

Having said that, I do acknowledge that tools which are best suited
for newcomers may not be the most efficient to use for frequent
contributors and maintainers (and I appreciate all efforts that try to
improve the situation for the latter). I just wanted to highlight that
as little setup effort as possible may be a desirable property of a
patch review system if attracting many newcomers is considered an
important goal.

Cheers,
Frank

Re: Changes to our Git infrastructure

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. Therefore it's a valid concern that
 people might very well be pushed off by the requirement to install it for
 the only purpose of pushing reviews via cli.

Is there any logical reason people would people be pushed off? Or is it just 
irrational?

Cheers,
  Albert

 
 Cheers,
 Thomas

Re: Changes to our Git infrastructure


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 put window-oriented tools in a different class than CLI tools, 
because the tool using gtk3 may have a very different look and feel, 
which many users can find legitimately jarring.



Whatever you need to do your job, man.
Erheemmm i doubt need to do your job holds for potential new 
contributors in any aspect :-P


This was a comment to package X wanting to pull in a bunch of non-daemon 
libraries...not to people. :-)


--Jeff

Re: Changes to our Git infrastructure


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* tools 
written on any whatsoever exotic requirement)

Is that correct?

In case and as this does not imply a real disagreement, the issue necessarily 
/is/ a simple misunderstanding - and apparent ambiguity on the other side :-P

Cheers,
Thomas

Re: Changes to our Git infrastructure


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 want to. I can't speak for the entire developer community.

- Nobody remotely intends to *require* this (but one can oc. *offer* 
tools written on any whatsoever exotic requirement)


Correct.

--Jeff

Re: Changes to our Git infrastructure


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 it more understandable?


No. What you're saying is having two tools is more complex. 
It's still one workflow.


I feel like you're just language-lawyering here. The workflow I propose 
pushes the burden of producing clean patches to the contributor. The 
workflow you're advocating for appears to center around sending patches 
around, so by definition in your workflow there's a big difference in the 
way 3rd party contributors work as opposed to what KDE developers do. My 
proposal aims at closing this gap.


GitHub is a notable example showing that people don't seem to 
have an issue with a workflow that uses Git + a web-based tool 
to manage their code reviews. I'm not saying we need to end up 
with that, I just don't think it's credible to claim that it's 
too difficult or complex.


That isn't an example that proves your point, though. The GitHub workflow 
actually involves a `git push` to be done by the contributor. That means 
that the GitHub workflow relies on contributors to curate git trees, and as 
such I like that workflow [1] because both core developers and contributors 
produce the same sort of artefacts. It's a different workflow from 
uploading patches via browser or via some client-side tool, though, and I 
believe you were saying that it's fine for a CR tool to work on patches and 
not git trees.


[1] GitHub manages to screwup things when one does a rebase, but that's an 
implementation detail for the purposes of this discussion. Yes, it does 
make the workflow hardly usable for me.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

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

Re: Changes to our Git infrastructure

2015-01-05 Thread Alexander Neundorf

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 walk away, but the move from svn to git has made contributing 
to KDE for me harder/less fun. Just svn up in trunk/ was really nice.
Now we have hundreds of repositories, and as far as I know there is still no 
using-git-for-KDE-development-for-dummies documentation (maybe because there 
is no common workflow for all of these many repositories).

Having said that, the mail flood I get from Qt gerrit also isn't fun. After 
every comment a new review is requested... I don't have that time.

Having a system where every repository (project) automatically has its own 
wiki and bug tracker is something I would really like to have. I think this is 
especially useful with the frameworks effort. I'd really like to see a 
homepage for each of the frameworks, and such a wiki page would be a natural 
place to put it.

Alex

Re: Changes to our Git infrastructure

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
  feeling.  Where *did* all those people go in the last few years?  And why?
 
 I didn't really walk away, but the move from svn to git has made
 contributing to KDE for me harder/less fun. Just svn up in trunk/ was
 really nice. Now we have hundreds of repositories, and as far as I know
 there is still no using-git-for-KDE-development-for-dummies documentation
 (maybe because there is no common workflow for all of these many
 repositories).

I think this is due to the fact that it's quite simple
git clone kde:repo
do coding
git commit
git push

Obviously i think it is simple but you think it's not, i can't write a guide 
for dummies because i think it's simple and you can't write it because you 
don't know how to write it, it'd need to people to collaborate on it.

If you can write somewhere your questions I'm sure we can find people to write 
the answers :)

Cheers,
  Albert

 Having said that, the mail flood I get from Qt gerrit also isn't fun. After
 every comment a new review is requested... I don't have that time.
 
 Having a system where every repository (project) automatically has its own
 wiki and bug tracker is something I would really like to have. I think this
 is especially useful with the frameworks effort. I'd really like to see a
 homepage for each of the frameworks, and such a wiki page would be a
 natural place to put it.
 
 Alex

Re: Changes to our Git infrastructure

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 that Phabricator seems to be owned/maintained by Facebook Inc.
 (what alone may cause significant, though irrational, veto...) this is sth.
 that needed to be accounted.

You should check your facts before calling for an irrational veto :)

http://phabricator.org - Phabricator's development is lead by Phacility, Inc.

Cheers,
  Albert

 
 How much of a problem it is is imo. atm out of scope, but eg. it would be
 less a problem on a fork/pullrequest driven workflow (esp. if a smart git
 hook would eg. support a PULLTHIS! keyword) but pretty much a showstopper
 for a RB/gerrit like approach.
 
 == The only relevant question to be answered in the current discussion is
 whether Just install php!
 is an acceptable answer to such concerns.
 
 I'd say no (because php /is/ uncommon on client systems...) - but there's
 also phc which *might* cure this particular problem for Phabricator.
 
 Cheers,
 Thomas

Re: Changes to our Git infrastructure


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 the reponame for a particular project (and that isn't as 
easy as just downloading the entire trunk of kde's svn repo -- even if I 
never did that myself)



do coding
git commit


* using the commit template
* with the relevant keywords
* having a grasp of what a git commit is, especially that a commit isn't 
visbile to anyone else



git push


But not before you have

* realized that you need to push, i.e. what local and remote is
* figured out what branches are for, and how different projects handle 
those

* got your kde indenity
* posted it on the right reviewboard
* to the right reviewers

Of course it's doable, but even with cats just getting source and building 
it poses hurdles that need articles like 
http://www.davidrevoy.com/article193/building-krita-on-linux-for-cats to 
help people jump them.


I am a very fortunate and happy person: there is hardly a week when I 
don't have to guide someone through the process. Usually, half-way through 
they ask me, why doesn't KDE use github (or, less often) phabricator. Then 
I point them at the manifesto, and we usually spend another half hour 
discussing that -- most often with good results! Our story about not using 
github is not hard, but our contribution process often is.





Obviously i think it is simple but you think it's not, i can't write a guide
for dummies because i think it's simple and you can't write it because you
don't know how to write it, it'd need to people to collaborate on it.

If you can write somewhere your questions I'm sure we can find people to write
the answers :)

Cheers,
 Albert


Having said that, the mail flood I get from Qt gerrit also isn't fun. After
every comment a new review is requested... I don't have that time.

Having a system where every repository (project) automatically has its own
wiki and bug tracker is something I would really like to have. I think this
is especially useful with the frameworks effort. I'd really like to see a
homepage for each of the frameworks, and such a wiki page would be a
natural place to put it.

Alex

Re: Changes to our Git infrastructure



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 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 at making it easy to discuss the why, 
wherefore and how of a particular change.


On Mon, 5 Jan 2015, Albert Astals Cid wrote:


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

Re: Changes to our Git infrastructure

2015-01-04 Thread Thomas Friedrichsmeier

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, then the following happens:
 
 - contributors learn to master the same tools as the maintainers,
 - there's one less thing for a maintainer to do on a contributor's
 behalf,
 - maintainers have more time to process more incoming reviews,
 - contributors can eventually transition to maintainers more easily
 because they already know the tools.

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 different from mine. Personally,
I'm much more worried about keeping the entry barrier as low as
possible, than about reducing the amount of effort that I have to put
into supporting and educating contributors.

Regards
Thomas


signature.asc
Description: PGP signature

Re: Changes to our Git infrastructure

2015-01-04 Thread Boudewijn Rempt


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 different from mine. Personally,
I'm much more worried about keeping the entry barrier as low as
possible, than about reducing the amount of effort that I have to put
into supporting and educating contributors.



Getting first-timers and non-coders to even create a patch and post it to 
a bug is often already a challenge. But I managed to make someone do a 
proper and succesful git bisect!


Anyway, and coincidentally, Here's something artists and other 
interested people wrote up for Krita, some time ago:


https://notes.kde.org/p/YWlSAP98tl

(Needs a KDE identity to access...)

Boudewijn

Re: Changes to our Git infrastructure

2015-01-04 Thread Boudewijn Rempt

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 Rempt wrote:


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 different from mine. Personally,
I'm much more worried about keeping the entry barrier as low as
possible, than about reducing the amount of effort that I have to put
into supporting and educating contributors.



Getting first-timers and non-coders to even create a patch and post it to a 
bug is often already a challenge. But I managed to make someone do a proper 
and succesful git bisect!


Anyway, and coincidentally, Here's something artists and other interested 
people wrote up for Krita, some time ago:


https://notes.kde.org/p/YWlSAP98tl

(Needs a KDE identity to access...)

Boudewijn

Re: Changes to our Git infrastructure

2015-01-04 Thread Cornelius Schumacher

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 decision.

The first question is: Who do we want to address? We obviously want to address 
existing contributors and for that the list represents the needs quite well. 
But to what degree do we want to address new contributors? Collecting 
requirements on kde-core-devel won't give us the input we need, if we want to 
address people who are not already part of our community.

The second question is: What are our requirements for hosting? Do we want to 
host it ourselves, or would we be ok with a third party hosting the 
infrastructure as well, and under which conditions?

Both questions are related to GitHub, which has been mentioned in the 
discussion quite a bit. It would address a lot of our requirements and it is 
something especially new contributors are familiar with.

I'm not saying we should simply move to GitHub, but as it is brought up so 
often, we maybe should review our position, and make sure that we know why we 
are not going with the flow, and why we are paying the price of a higher 
barrier of entry and the additional effort of hosting our own infrastructure.

-- 
Cornelius Schumacher schumac...@kde.org

Re: Changes to our Git infrastructure

2015-01-04 Thread Jeff Mitchell


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 them immersed into what we're doing and helping bridge the 
gap between maintainers and contributors.


I agree that this is missing from the list of things people brought 
up but I'd appreciate an explanation as to how this is directly 
translates into our workflow. As far as I can tell our workflow is 
what we make it; if contributions from outside a core team are done 
through a patch-based review instead of a git tree-based review, then 
patch-based review is our workflow.


Because what we together produce is software stored in git trees, not 
series of patches.


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, the end result is the same.


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).


KDE purposefully has a very low barrier to entry. A contributor can 
normally push anywhere. Unless you set access permissions otherwise, 
there's no reason that a contributor, after having a patch reviewed, 
can't be the one to push it into the main repo. The difference is a 
social one; until you've been given the say so, usually new contributors 
do the right thing and run their changes by the maintainers.


If we can offload the management of git trees to the contributors, 
then the following happens:


- contributors learn to master the same tools as the maintainers,


This will happen regardless of which tools are chosen.

- there's one less thing for a maintainer to do on a contributor's 
behalf,


This is only something the maintainer needs to do if you restrict access 
in the first place, which is not our normal way.



- maintainers have more time to process more incoming reviews,


Same as above.

- contributors can eventually transition to maintainers more easily 
because they already know the tools.


Same as above.

- Not needing a CLI tool in an obscure language (PHP, Java, 
.NET,...).


.NET is a framework, not a language. Maybe you meant C#.


Thanks for educating me, but I don't think it helps move this 
discussion forward in a productive manner.


I do. Because there are a huge number of languages that have compilers 
to produce .NET CLI. Some of them are indeed relatively obscure. Saying 
.NET doesn't mean anything in terms of which languages you are taking 
issue with. Let's be clear what we're talking about.



Regardless, I fail to see how any of those are obscure.


I sincerely believe that pushing Yet Another Runtime Environment to 
our contributors is something which reduces chances of them 
contributing. Would I install e.g. PHP to contribute to Qt? I probably 
would because Qt is an excellent and high profile software project. I 
don't think I would do this just to e.g. send a patch to a random KDE 
app that I use twice a year, though, and I also can't imagine people 
doing this to contribute to Trojita.


As other people have added to the list of requirements, patch management 
needs to be able to be done via the web UI. Nobody has to install any 
runtime environment. Even if you wanted to stick to command-line only, 
it's too bad that you think that sending a patch to a part of KDE is not 
worth the same amount of effort as sending a patch to Qt, but I suppose 
we can't all consider KDE to be an excellent and high profile software 
project.


They're three of the most popular and widespread languages in the 
world.


The popularity has to be judged with our target audience in mind


Yes...

because we still haven't achieved dominance even on Linux, and 
absolutely not on other OSes.


Which has what to do with it?

I think that most of our contributors don't come from the pool of PHP 
programmers, Java programmers, or those who use the .NET framework or 
the most popular desktop OSes.


Me neither. I still fail to see how that's relevant.

These languages/frameworks/environments have historically been alien 
to us, and we are talking about tools that need to be on each 
contributor's machine in order to participate in the development.


I have used git-annex successfully despite not knowing how to program in 
Haskell.


You are free to disagree with my impression that e.g. requiring to 
install PHP or Mono on a dev machine provides an extra step for 
contributors to pass, though.


Those that want to contribute will be required to install a whole slew 
of development packages. I absolutely disagree that adding one more to 
the list of packages they copy and paste from the wiki will be the straw

Re: Changes to our Git infrastructure

2015-01-04 Thread Jeff Mitchell


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 to have good answers for before we can take a 
decision.


The first question is: Who do we want to address? We obviously want to 
address
existing contributors and for that the list represents the needs quite 
well.

But to what degree do we want to address new contributors? Collecting
requirements on kde-core-devel won't give us the input we need, if we 
want to

address people who are not already part of our community.

The second question is: What are our requirements for hosting? Do we 
want to

host it ourselves, or would we be ok with a third party hosting the
infrastructure as well, and under which conditions?

Both questions are related to GitHub, which has been mentioned in the
discussion quite a bit. It would address a lot of our requirements and 
it is

something especially new contributors are familiar with.

I'm not saying we should simply move to GitHub, but as it is brought 
up so
often, we maybe should review our position, and make sure that we know 
why we
are not going with the flow, and why we are paying the price of a 
higher
barrier of entry and the additional effort of hosting our own 
infrastructure.


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 direction and feedback to the sysadmins has always 
been FOSS-only. If GitHub *is* on the table, then we need to consider 
other non-FOSS possibilities as well.


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 developers might find to be most useful to 
them personally. Finding the best balance is a difficult task.


--Jeff

Re: Changes to our Git infrastructure

2015-01-04 Thread Ben Cooksley

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 which I
 think are important to have good answers for before we can take a decision.

 The first question is: Who do we want to address? We obviously want to address
 existing contributors and for that the list represents the needs quite well.
 But to what degree do we want to address new contributors? Collecting
 requirements on kde-core-devel won't give us the input we need, if we want to
 address people who are not already part of our community.

Good point. Traditionally we've addressed the requirements of new
contributors by keeping the barrier to entry low.
Considering we have all passed the barrier though it is a bit hard to
see potential trip points ourselves I think.

May I suggest we look at the pad Boud posted as a starting point for that?


 The second question is: What are our requirements for hosting? Do we want to
 host it ourselves, or would we be ok with a third party hosting the
 infrastructure as well, and under which conditions?

 Both questions are related to GitHub, which has been mentioned in the
 discussion quite a bit. It would address a lot of our requirements and it is
 something especially new contributors are familiar with.

 I'm not saying we should simply move to GitHub, but as it is brought up so
 often, we maybe should review our position, and make sure that we know why we
 are not going with the flow, and why we are paying the price of a higher
 barrier of entry and the additional effort of hosting our own infrastructure.

 --
 Cornelius Schumacher schumac...@kde.org

Cheers,
Ben

Re: Changes to our Git infrastructure

2015-01-04 Thread Cornelius Schumacher

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 direction and feedback to the sysadmins has always
 been FOSS-only. If GitHub *is* on the table, then we need to consider
 other non-FOSS possibilities as well.

FOSS-only is a too simple requirement for a hosted service. It might be 
perfectly possible and fine to use a service which is not running free 
software as long as it doesn't force you to run non-free software. The issues 
are elsewhere (recommeded reading is Richard Stallman's text about this 
problem [1]). That's why I'm asking what exactly are our requirement there, 
and do the arguments we had last time we took a decision still hold? And yes, 
while GitHub is the poster child here, that doesn't mean we shouldn't look at 
other service providers, if we generally consider this to be an option.

 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 developers might find to be most useful to
 them personally. Finding the best balance is a difficult task.

That's true, and that's exactly the reason why we should consciously decide 
what our target is. It might be perfectly valid to focus on current 
contributors and go with something like a gerrit-based solution, but if we 
want to focus on new people there might be better solutions.

[1]: https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html

-- 
Cornelius Schumacher schumac...@kde.org

Re: Changes to our Git infrastructure

2015-01-04 Thread Ben Cooksley

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 the industry is. I'm not stating my personal preferences on
 the matter, but the direction and feedback to the sysadmins has always
 been FOSS-only. If GitHub *is* on the table, then we need to consider
 other non-FOSS possibilities as well.

 FOSS-only is a too simple requirement for a hosted service. It might be
 perfectly possible and fine to use a service which is not running free
 software as long as it doesn't force you to run non-free software. The issues
 are elsewhere (recommeded reading is Richard Stallman's text about this
 problem [1]). That's why I'm asking what exactly are our requirement there,
 and do the arguments we had last time we took a decision still hold? And yes,
 while GitHub is the poster child here, that doesn't mean we shouldn't look at
 other service providers, if we generally consider this to be an option.

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.

The messaging around things we're willing to adopt has certainly
always been FOSS only.
Otherwise we would probably have some Atlassian products deployed already...


 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 developers might find to be most useful to
 them personally. Finding the best balance is a difficult task.

 That's true, and that's exactly the reason why we should consciously decide
 what our target is. It might be perfectly valid to focus on current
 contributors and go with something like a gerrit-based solution, but if we
 want to focus on new people there might be better solutions.

There is of course a difference in preferences within our contributors
as well, which we have to take into account as well.


 [1]: 
 https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html

 --
 Cornelius Schumacher schumac...@kde.org

Re: Changes to our Git infrastructure

2015-01-04 Thread Thiago Macieira

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 widespread languages in the world.

For command-line applications on Linux?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Changes to our Git infrastructure

2015-01-04 Thread Ben Cooksley

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 of those are obscure. They're three of the most
 popular and widespread languages in the world.

 For command-line applications on Linux?

We're now extremely far off topic. Let's get it back on topic here please.

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 language(s) and unnecessarily
limits our options.


 --
 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
   PGP/GPG: 0x6EF45358; fingerprint:
   E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


Regards,
Ben

Re: Changes to our Git infrastructure

2015-01-04 Thread Ian Wadham


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 developers might find to be most useful to
 them personally. Finding the best balance is a difficult task.
 
 That's true, and that's exactly the reason why we should consciously decide 
 what our target is. It might be perfectly valid to focus on current 
 contributors and go with something like a gerrit-based solution, but if we 
 want to focus on new people there might be better solutions.

And what about *current* developers who are NOT more or very experienced?
What is the cost to them (and the KDE Community) of having to learn new tools,
not to mention new libraries and porting to new libraries?

Speaking for myself, I find this a huge turnoff in the KDE world and am now
planning to retire from KDE as soon as I can.  But then I am 76 and git is my
10th source-code control system since 1965-66, so I have little interest in
mastering it.

I have also found ReviewBoard utterly counter-productive this year, either
because one writes an entry and nobody reviews it, or nobody understands
it, or because one gets nitpicked about syntax and white space when one is
really looking for helpful advice about how better to solve the problem at hand.
I think I must have lost a month or two on ReviewBoard during the year, with
very little helpful advice gained.

So how will a new tool change that?  As we used to say when I was working,
New technology is the answer, but what is the question?  Are the reviewers
going to change their style?  Nevertheless, it is refreshing to see Jeff and
Ben conducting what looks like a proper requirements analysis.  Good on you!

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?

All the best, Ian W.

Re: Changes to our Git infrastructure

2015-01-03 Thread Ben Cooksley

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 opt-out for this. I receive a large number of
 emails from gerrit for reviews which I have been automatically subscribed to
 which I have absolutely zero interest in.

I'd imagine that you would only be subscribed to reviews automatically
if you had requested it.
Auto subscribing you to reviews when you have no interest is wrong
(and i'd consider it to be spam).


 --
 Aaron J. Seigo

Cheers,
Ben

Re: Changes to our Git infrastructure

2015-01-03 Thread Aaron J. Seigo

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 reviews which I have been automatically subscribed to 
which I have absolutely zero interest in.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Changes to our Git infrastructure

2015-01-03 Thread Jan Kundrát


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. However, I was hoping that the result from 
this first phase would include every mentioned feature (perhaps on a wiki 
page?), so that we can then discuss how many people find each of these 
features valuable. I did not include some of the bits which others already 
expressed when I wrote my reply.


Things I miss from the list you just gathered:

- 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.


- Being able to tweak small bits of the review request straight from the 
web application (in the nice-to-have category; this is different from 
Developers can tweak proposed changes easily before they are landed 
without the involvement of the submitter.).


- Retaining proper autorship (git author) of the original author without 
extra work.


I think it's also reasonable to add:

- Not needing a CLI tool in an obscure language (PHP, Java, .NET,...).

- Not needing a CLI tool or an explicit authorization at all for operations 
such as download patch.



- Project Management:
  - Coherent and Performant
  - One canonical place to get the desired information (no more duplication)
  - Can either be links to elsewhere or directly hosted by the system
  - Covers items like documentation (wiki, api), bug tracking, task
boards, CI, code browsing and reviews, etc.


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 and task boards. I do not 
think that we should be looking for a single tool to do everything (and the 
kitchen sink), so I would appreciate a bit more information on what exactly 
your opinion is here, and why so.



  - A weaker case exists for clone repositories - making them more
nice to have than critical.


I believe that people requested a place to store their changes which for 
some reason cannot be easily upstreamed, but at the same time they do not 
want to bother other folks by having a visible branch in your face in 
the main repo. If that is indeed the case, we should focus on this 
*concept* and put away the fact that it's right now implemented as 
GitHub-style repository clones. Other tools might very well support such 
a scenario by something entirely different from clone repos.



- Integrated:
  A single application which handles everything will always be able to
offer a better and more coherent experience than several applications
we have connected to each other.


I do not agree with that. Well-integrated applications which work well 
together while doing one thing well are superior to a single tool which 
tries to do everything.



  There is also a lower maintenance burden from an integrated
application, as it is one piece of software to update - not 3 or 4.


I am volunteering to get my hands dirty, and I believe others have 
expressed their willing to join the sysadmin team as well. In particular, 
I'll be happy to take care of the Gerrit deployment and help others perform 
day-to-day maintenance of Gerrit. This includes participating in the rest 
of the Git-hosting business, anongit, repo hooks, etc. I'm also interested 
in CI, which is another area in which I can help.


I've worked as a sysadmin for a couple of years and am pretty familiar with 
treating the physical infrastructure of servers and gear as code.



- Scalable:
  The applications which make up our infrastructure need to be able to
handle the demands we place on them without consuming resources
unnecessarily.


That's a good goal, but seems very vague to me. When we move to next 
phases, it is important to spell out what these demands are to prevent 
possible misunderstandings.



As this is quite an extensive list of requirements, we won't be able
to get everyone what they're after. We'll have to do things on a best
effort basis - depending on what is available, what features are
missing, etc. Unfortunately there is no perfect solution here - it
just does not exist.


I can see all of the above fulfiled with Gerrit, but I'm OK with waiting 
with a proper evaluation when we call for one.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-03 Thread Thiago Macieira

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 / etc for a
 review rather than the submitter needing to know who to set.

Check.

Also, from experience with Tizen's Gerrit: if the automatic list has more than 
3 people, all reviews stop getting done since everyone will be overwhelmed by 
reviews and they will thinki it's someone else's problem on this one.

   - Changes should be shown per-commit.

Check.

   - Updates to reviews should leave prior reviews intact.

Check.

   - Patches should be readable, commentable on line by line.

Check.

   - Proposed changes are vetted by the CI system (compilability, tests,
 etc).

Check. The most common use is to run before merging into the official tree; Qt 
is the only project I know that does it after.

  - Ability to accept the changes through the code review system

Check.

   - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it
 going in) / Good (Ship It)

Check. And you can change at will, add more categories, roles, etc.

   - Can determine whether the review was by someone with commit rights.

Check. Not obvious, but it is doable, since you can look up people's group 
memberships. Might make a nicer feature to list the group(s) they're member of 
in the UI.

   - Can produce a list of review requests given a certain set of
 criteria easily (preferrably savable)

Vague requirement without knowing what criteria were in mind here. So I'm 
going to go and say check since it can look up the criteria I want.

   - Developers can tweak proposed changes easily before they are
 landed without the involvement of the submitter.

Check, you can push a new commit with the same Change-Id.

 - Post Commit Review:
   - Be able to comment on reviews, other than by replying to a mail on
 kde-commits

Check.

 - Project Management:
   - Coherent and Performant

It's Java, but unlike Jenkins, we don't seem to have had problems with it for 
Qt.

   - One canonical place to get the desired information (no more duplication)

Vague requirement.

 - Can either be links to elsewhere or directly hosted by the system 

Check.

 -
 Covers items like documentation (wiki, api), bug tracking, task boards, CI,
 code browsing and reviews, etc.

Vague. Assuming items like documentation ... are in Git, everything works.

 - Repository Hosting:
   - Strong case has been made for retaining scratch repositories.

Out of scope, needs separate website and tools.

   - A weaker case exists for clone repositories - making them more
 nice to have than critical.

Out of scope, needs separate website and tools.

Though it might be possible with the command-line, just not the web UI. I need 
to investigate.

   - Anongit propagation should be within 1 minute.

Totally out of scope.

 - Overall: Sensible email notifications

Check, requires modifications from the Qt Project, since the default email 
notifications are not sensible.

 - Overall: Capable web APIs for the system as a whole

Check.

 There are also a couple of items which come from sysadmin, to make
 things easier for us in the long run:
 
 - Supported well:
   Upstream should be stable with a viable future.
   We should also be able to build a relationship with one or more
 developers who authored/maintain the application.
   This is helpful in obtaining assistance should it be necessary and
 assists us in getting additions upstreamed.

Check. Dozens of projects use Gerrit.

 - Integrated:
   A single application which handles everything will always be able to
 offer a better and more coherent experience than several applications
 we have connected to each other.
   There is also a lower maintenance burden from an integrated
 application, as it is one piece of software to update - not 3 or 4.

Not check, since Gerrit alone will not correspond to KDE's desires (project 
creation, scratch clones, etc.)

 - Care about compatibility:
   Upstream should have an interest in stable interfaces, both
 externally facing (Web APIs) and internal (application plugins, etc)
   As the recent Dr Konqi problems have demonstrated, upstreams which
 act without regard for backwards compatibility can introduce
 significant problems for us.

Check.

 - Scalable:
   The applications which make up our infrastructure need to be able to
 handle the demands we place on them without consuming resources
 unnecessarily.

I understand it is, but you'll have to speak to other sysadmins.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Changes to our Git infrastructure

2015-01-03 Thread Thiago Macieira

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 an important decision so let's do this step-by-step? :)

I was only going to comment on the request to automatically add reviewers but 
then I thought I might as well give more information instead of a single 
paragraph.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Changes to our Git infrastructure

2015-01-03 Thread Lydia Pintscher

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? :)


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
KDE e.V. Board of Directors / KDE Community Working Group
http://kde.org - http://open-advice.org

Re: Changes to our Git infrastructure

2015-01-03 Thread Jeff Mitchell


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 agree that this is missing from the list of things people brought up 
but I'd appreciate an explanation as to how this is directly translates 
into our workflow. As far as I can tell our workflow is what we make 
it; if contributions from outside a core team are done through a 
patch-based review instead of a git tree-based review, then patch-based 
review is our workflow.


- 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 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 and task 
boards. I do not think that we should be looking for a single tool to 
do everything (and the kitchen sink), so I would appreciate a bit more 
information on what exactly your opinion is here, and why so.


The subject line is unfortunately a bit narrow, but since code ties into 
everything, changes to our hosting necessarily affects all of our other 
systems. Changing our git infrastructure is a reasonable time to look at 
changing other things as well. There are a number of capabilities we'd 
like to provide and a number of systems we'd like to be able to 
consolidate.



- A weaker case exists for clone repositories - making them more
nice to have than critical.


I believe that people requested a place to store their changes which 
for some reason cannot be easily upstreamed, but at the same time they 
do not want to bother other folks by having a visible branch in 
your face in the main repo. If that is indeed the case, we should 
focus on this *concept* and put away the fact that it's right now 
implemented as GitHub-style repository clones. Other tools might 
very well support such a scenario by something entirely different from 
clone repos.


In this example it's the same as a scratch repo concept. The clones were 
meant for GH-style forks, as Gitolite eventually got the capability to 
do merge requests.



A single application which handles everything will always be able to
offer a better and more coherent experience than several applications
we have connected to each other.


I do not agree with that. Well-integrated applications which work well 
together while doing one thing well are superior to a single tool 
which tries to do everything.


I don't think this broad generalization is any more valid than a broad 
generalization that single applications are always better. Regardless, 
we have never found a single application that handles everything 
acceptably, so I think this point is moot.


I am volunteering to get my hands dirty, and I believe others have 
expressed their willing to join the sysadmin team as well. In 
particular, I'll be happy to take care of the Gerrit deployment


I believe you are on the hook for this regardless :-)


As this is quite an extensive list of requirements, we won't be able
to get everyone what they're after. We'll have to do things on a best
effort basis - depending on what is available, what features are
missing, etc. Unfortunately there is no perfect solution here - it
just does not exist.


I can see all of the above fulfiled with Gerrit, but I'm OK with 
waiting with a proper evaluation when we call for one.


I can see the above fulfilled with many tools. Gerrit is not 
automatically the choice simply because it checks many boxes.


--Jeff

Re: Changes to our Git infrastructure

2015-01-03 Thread Albert Astals Cid

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.
 
 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.
 
 - Code Reviews:
   - CLI client to make changes to the code review system and to manage
 the review (including retrieving the commits/patches)
 Client should have good documentation.
   - System should automatically set the CC / Reviewers / etc for a
 review rather than the submitter needing to know who to set.
   - Changes should be shown per-commit.
   - Updates to reviews should leave prior reviews intact.
   - Patches should be readable, commentable on line by line.
   - Proposed changes are vetted by the CI system (compilability, tests,
 etc). - Ability to accept the changes through the code review system
   - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it
 going in) / Good (Ship It)
   - Can determine whether the review was by someone with commit rights.
   - Can produce a list of review requests given a certain set of
 criteria easily (preferrably savable)
   - Developers can tweak proposed changes easily before they are
 landed without the involvement of the submitter.

I'm missing a 
   - Can upload patches without a CLI (i.e. via web) 
in the list.

Cheers,
  Albert

Re: Changes to our Git infrastructure

2015-01-03 Thread Jan Kundrát


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 
helping bridge the gap between maintainers and contributors.


I agree that this is missing from the list of things people 
brought up but I'd appreciate an explanation as to how this is 
directly translates into our workflow. As far as I can tell 
our workflow is what we make it; if contributions from outside a 
core team are done through a patch-based review instead of a git 
tree-based review, then patch-based review is our workflow.


Because what we together produce is software stored in git trees, not 
series of patches.


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 following happens:


- contributors learn to master the same tools as the maintainers,
- there's one less thing for a maintainer to do on a contributor's behalf,
- maintainers have more time to process more incoming reviews,
- contributors can eventually transition to maintainers more easily because 
they already know the tools.



- Not needing a CLI tool in an obscure language (PHP, Java, .NET,...).


.NET is a framework, not a language. Maybe you meant C#.


Thanks for educating me, but I don't think it helps move this discussion 
forward in a productive manner.



Regardless, I fail to see how any of those are obscure.


I sincerely believe that pushing Yet Another Runtime Environment to our 
contributors is something which reduces chances of them contributing. Would 
I install e.g. PHP to contribute to Qt? I probably would because Qt is an 
excellent and high profile software project. I don't think I would do this 
just to e.g. send a patch to a random KDE app that I use twice a year, 
though, and I also can't imagine people doing this to contribute to 
Trojita.



They're three of the most popular and widespread languages in the world.


The popularity has to be judged with our target audience in mind because we 
still haven't achieved dominance even on Linux, and absolutely not on other 
OSes. I think that most of our contributors don't come from the pool of PHP 
programmers, Java programmers, or those who use the .NET framework or the 
most popular desktop OSes. These languages/frameworks/environments have 
historically been alien to us, and we are talking about tools that need to 
be on each contributor's machine in order to participate in the 
development.


You are free to disagree with my impression that e.g. requiring to install 
PHP or Mono on a dev machine provides an extra step for contributors to 
pass, though.


The subject line is unfortunately a bit narrow, but since code 
ties into everything, changes to our hosting necessarily affects 
all of our other systems. Changing our git infrastructure is a 
reasonable time to look at changing other things as well. There 
are a number of capabilities we'd like to provide and a number 
of systems we'd like to be able to consolidate.


It isn't clear to me what exactly is being reconsidered at this point. I 
was told that CI is specifically not in scope, and now I read that wiki 
pages and issue tracking is being considered. I don't understand where the 
line was drawn and why.


My impression is that the goals for a code review tool are very different 
from needs for a project management tool. The sysadmins appear to have a 
strong preference for a unified tool to do both. As a (non-KDE) sysadmin, I 
understand the general reasoning, but at the same time, as a developer I do 
not really care about that, and am strongly against using an inferior tool 
just because it was easier to install and takes less effort to maintain. To 
put my money where my mouth is, yes, I am willing to maintain the extra 
systems, and I have been doing this with Gerrit (and CI) for a couple of 
months already.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2015-01-02 Thread Ben Cooksley

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 kept the barrier to entry as low
as possible as that seemed to be the greater consensus within the thread.

- Code Reviews:
  - CLI client to make changes to the code review system and to manage
the review (including retrieving the commits/patches)
Client should have good documentation.
  - System should automatically set the CC / Reviewers / etc for a
review rather than the submitter needing to know who to set.
  - Changes should be shown per-commit.
  - Updates to reviews should leave prior reviews intact.
  - Patches should be readable, commentable on line by line.
  - Proposed changes are vetted by the CI system (compilability, tests, etc).
  - Ability to accept the changes through the code review system
  - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it
going in) / Good (Ship It)
  - Can determine whether the review was by someone with commit rights.
  - Can produce a list of review requests given a certain set of
criteria easily (preferrably savable)
  - Developers can tweak proposed changes easily before they are
landed without the involvement of the submitter.

- Post Commit Review:
  - Be able to comment on reviews, other than by replying to a mail on
kde-commits

- Project Management:
  - Coherent and Performant
  - One canonical place to get the desired information (no more duplication)
  - Can either be links to elsewhere or directly hosted by the system
  - Covers items like documentation (wiki, api), bug tracking, task
boards, CI, code browsing and reviews, etc.

- Repository Hosting:
  - Strong case has been made for retaining scratch repositories.
  - A weaker case exists for clone repositories - making them more
nice to have than critical.
  - Anongit propagation should be within 1 minute.

- Overall: Sensible email notifications
- Overall: Capable web APIs for the system as a whole

There are also a couple of items which come from sysadmin, to make
things easier for us in the long run:

- Supported well:
  Upstream should be stable with a viable future.
  We should also be able to build a relationship with one or more
developers who authored/maintain the application.
  This is helpful in obtaining assistance should it be necessary and
assists us in getting additions upstreamed.

- Integrated:
  A single application which handles everything will always be able to
offer a better and more coherent experience than several applications
we have connected to each other.
  There is also a lower maintenance burden from an integrated
application, as it is one piece of software to update - not 3 or 4.

- Care about compatibility:
  Upstream should have an interest in stable interfaces, both
externally facing (Web APIs) and internal (application plugins, etc)
  As the recent Dr Konqi problems have demonstrated, upstreams which
act without regard for backwards compatibility can introduce
significant problems for us.

- Scalable:
  The applications which make up our infrastructure need to be able to
handle the demands we place on them without consuming resources
unnecessarily.

Commentary on the above would be appreciated.

As this is quite an extensive list of requirements, we won't be able
to get everyone what they're after. We'll have to do things on a best
effort basis - depending on what is available, what features are
missing, etc. Unfortunately there is no perfect solution here - it
just does not exist.

Thanks,
Ben

Re: Changes to our Git infrastructure

2015-01-02 Thread Christian Mollekopf

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.
  
  Our current one was constructed when KDE first seriously migrated to
  Git following the Gitorious experiments, and it shows. (As a sysadmin
  I can attest that parts of it are held together by digital glue and
  tape).
  
  Before we go ahead and jump to a new platform though - we need to know
  what we want.
  Can everyone please suggest what they think are the things they'd like
  to see feature wise?
  
  In doing so, please refrain from mentioning any existing solutions -
  all we want to do at this point is construct a wishlist of what people
  would like to see the system be capable of.
  
  Items that we (sysadmin) would like to see community comment on
  include the code review system, clone and scratch repositories and how
  they function, and whether people would be bothered by repository
  locations changing as they move around. Also useful would be comment
  on how anongit and other systems that rely on the Git infastructure
  work.
 
 Here's a list of things that I'd like to have for my workflow, which is
 basically two folded: On one hand, I actively develop new software and new
 features. On the other hand, I spent a considerable amount of KDE time
 reviewing other peoples work.
 
 ## The Developer
 
 For productivity, I'd love to have the ability to push changes directly from
 the command line to somewhere others can then review the code. This should
 support both, individual commits as well as feature branches. I.e. when
 pushing a merge request for review, I still want others to see individual
 commits. Updating such reviews should be trivial and keeps the review
 history intact. I can just continue hacking and push new changes as they
 come without influencing the previous patches sent for review.
 
 Optimally, I'm never forced to go to a website to manipulate the review.
 I.e. to add reviewers, or select branches or other metadata. Nor do I want
 to be forced to manually publish a review, I just pushed it for review
 after all.
 
 ## The Reviewer
 
 Here, my biggest wish reflects that of the developer: I want to be able to
 see the developers intent, i.e. individual commits that make up one bigger
 mergeable hunk. I want to comment directly on lines of code in the patch.
 The patch should be displayed as easily readable as possible, with syntax
 highlighting and side-by-side diff view. As much as possible should be
 shown on a single page, I do not want to be forced to navigate between
 different files or the like, I need to see the big picture.
 
 Optimally, I could apply hotfixes, such as whitespace changes, directly when
 doing the review. Finally, once the review is good to go, I want to click a
 button (or better: hotkey) to merge the patch into the upstream branch.
 
 Furthermore, I'd like to use the same review mechanism for post-review. When
 a patch is triggering problems, I'd like to start a discussion in the
 context of the commit that was merged. Again, I want to annotate source
 lines. So rather than sending mails to kde-commits which are then lost, I
 want to have that tracked on a website for others to see.
 

Excellent summary, I fully agree.

Cheers,
Christian

Re: Changes to our Git infrastructure

2015-01-02 Thread Christian Mollekopf

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 proposes that both clone and scratch repositories
 be eliminated as a concept with the next iteration of our Git
 infrastructure.

Having some mechanism where a developer can just create his own repositories 
that may or may not be shared with others is IMO essential. With the current 
infrastructure scratch repositories provide this mechanism and if not replaced 
with something similar I don't think it would be a good idea to remove this 
functionality.

I find clones useful to publish my private branches somewhere, either as 
backup, or to share with someone. I also use force-pushes sometimes on those 
to i.e. cleanup a patch queue, and to avoid proliferation of branches by using 
$branchv1, $branchv2, ...
If we established that everyone pushes his branches into a prefix 
(cmollekopf/lksjflsjdf), and we can force-push and delete branches, then 
clones become IMO less important.

Cheers,
Christian

Re: Changes to our Git infrastructure

2014-12-30 Thread Jeff Mitchell


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* want that code that they 
pushed up and left sitting there.  :-)


Maybe I'm stupid, but one could just send a mail

WARNING:
your scratch repo foobar will be automatically deleted due to 
inactivity within 1 month / 2 weeks / 1 week / 5/3/2/1 days (Saturday, 
May 16th)


See https://www.kde.org/dontspamourgit.html on scratch repo policy 
details.


Of course we could do that and we've thought of doing so but have not 
implemented such a policy so far.


--Jeff

Re: Changes to our Git infrastructure

2014-12-30 Thread Thomas Lübking


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 didn't commit yesterday, gone is your stuff, but 
starting to ping the user after half a year of inactivity, opting in for prolongation click 
here - the idea should be to get bit rot out, not to destroy anyones work.

Cheers,
Thomas

Re: Changes to our Git infrastructure

2014-12-30 Thread Jeff Mitchell


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/whatever then?


Also I did not mean to imply you didn't commit yesterday, gone is 
your stuff, but starting to ping the user after half a year of 
inactivity, opting in for prolongation click here - the idea should 
be to get bit rot out, not to destroy anyones work.


This is all a sidebar anyways, as the current problems with scratch 
repos are not really relevant. The solutions we're looking at to replace 
our current infrastructure do not have the necessary bits to support 
this kind of workflow *right now*. This does not mean that they could 
not in the future, even the near future. But in the *short term* they 
would require a manual step by sysadmins or by those that want to help 
out the sysadmins with this and are given privs to do so.


There's a useful metric, which is that if you take the number of current 
scratch repos and divide them by the number of days we've had the 
current infrastructure, you end up with something close enough to 0.5. 
As in, on average, someone creates a new scratch repo once every two 
days. If you then look at the length of time since last commit for the 
vast majority of the repositories, you'll see that within the last 
couple of years, that number is way, way lower.


The point being that having a manual step in some near term doesn't mean 
that dozens of scratch repos a day are going to be sitting waiting on 
someone to create them. Yes, it's useful to be able to have a repo 
*right now*, but up until such a thing could be automated again, I'd 
like to try to take advantage of our international nature and get some 
interested parties to simply help try to ensure that there is 24/7 
coverage so turnaround time is short. In addition, once a solution is 
finalized, someone could take on the task of working with sysadmins and 
upstream to get such a solution implemented.


Most people are using scratch to have a place to store a new experiment, 
where pushing code from their local repo to the new scratch repo in a 
few hours instead of right now isn't that big a deal. I've seen the mail 
about how someone needed a repo that they could get distributed to 
multiple boxes *this very second* and complained about the anongits 
taking a while to get that new repo distributed, so they ended up using 
GitHub (presumably, in the short term). I'd prefer to avoid that needing 
to be necessary, but this is really not a widespread problem. The 
numbers just don't back it up.


--Jeff

Re: Changes to our Git infrastructure

2014-12-29 Thread Sven Brauch

 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 than proper repositories - mostly because they don't
 require manual sysadmin actions (and fileing tickets by the developer),
 it's a personal git space readily available.
+1, I also think scratch repos are useful and shouldn't be removed
mostly for the reasons Martin quoted.

Re: Changes to our Git infrastructure

2014-12-29 Thread argonel

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 to let you put a
private branch in their repo for sharing that patch set. I'm sure I'm not
the only one carrying patches that are arguably sharable but not
upstreamable.

I've also used clones to share an experiment that may not belong in the
proper repo now or ever. Making everyone who uses the main repo pay to
carry an experimental branch is somewhat unfriendly, especially if you're
not normally involved with the project. You may also wish to avoid the
scrutiny of the others involved in the main project until you're ready,
which the sudden appearance of a new branch during checkout would certainly
invite.

2) Little commentary has been made on the merits of scratch
 repositories, with some dismissing them as pointless.


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, or already exists elsewhere.

Therefore sysadmin proposes that both clone and scratch repositories
 be eliminated as a concept with the next iteration of our Git
 infrastructure.

 We've now begun the process of shortlisting candidate software for
 evaluation, so those who haven't yet responded are urged to do so
 soon.


There are probably still quite a few people away for the holiday season,
perhaps this decision can be deferred for a couple of weeks until its more
likely that everyone is back and paying attention?


 Thanks,
 Ben

Re: Changes to our Git infrastructure


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 yuo describe makes sense -- if a patch 
is extremely dirty, for example, I can imagine a project maintainer not 
willing to carry it as a visible branch in their repo.


However, the personal prefixes appear to solve this problem semi-neatly. A 
perfect solution would be refs that aren't getting included in clones (and 
guess what, there's one review system which works exactly like that).



I'm sure I'm not
the only one carrying patches that are arguably sharable but not
upstreamable.


Got an example so that I know what you're describing?


I've also used clones to share an experiment that may not belong in the
proper repo now or ever. Making everyone who uses the main repo pay to
carry an experimental branch is somewhat unfriendly, especially if you're
not normally involved with the project. You may also wish to avoid the
scrutiny of the others involved in the main project until you're ready,
which the sudden appearance of a new branch during checkout would certainly
invite.


That's a valid concern. On the other hand, it's a pretty simple way of 
enforcing collaboration. There were keynotes during the last Akademy 
where people mentioned their worrying about development moving into 
isolated silos. Disabling clones leads directly to sort of an enforced 
collaboration (or, failing that, to people pushing stuff to GitHub).



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, or already exists elsewhere.


I agree with scratch repos being useful as a first step.


There are probably still quite a few people away for the holiday season,
perhaps this decision can be deferred for a couple of weeks until its more
likely that everyone is back and paying attention?


+1, and sending a mail to kde-cvs-announce to make sure all KDE account 
holders are aware of both this and the other thread is a good idea.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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, or already exists elsewhere.


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 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 largest piece of our Git hosting. There are more 
scratch repos than normal repos. If clone repos were excluded, scratch 
repos would actually be a majority of all repos -- and again, most of 
them haven't been touched in years. People complain about propagation 
delay of repos to anongits -- syncing all these totally outdated repos 
is a major reason.


I understand the reason people like them -- as a place to test out early 
concepts before making them official projects -- but I think that a 
combination of social changes and technical changes can address losing 
them.


One social change would be divesting ourselves of the idea that getting 
a Git repo from sysadmins is onerous. You can start a git repo locally 
and push it up later; the extra few hours or even a day it might take to 
get a hosted version should really not be the reason that your project 
simply cannot see the light of day.


Another social change, in combination with a technical change, would be 
to get interested people who would like to see this kind of thing happen 
faster and have them take on specific sysadmin tasks -- for instance, 
creating repos on request as soon as possible, spreading the workload 
out so that any given request is likely to be handled faster (your 
standard task queue). The reason it's semi-onerous now (but we should 
stop thinking that it is, see above) is due to lack of manpower. But 
volunteers can be given rights to handle specific ticket types without 
having to become full sysadmins. Like anything else, if people think it 
takes too long, get involved.


Clones (336 of them) are also nice in concept but with better code 
review and/or auditing capabilities (especially pre-commit 
capabilities), I think they will become less important, and remarks on 
this thread seem to back that idea up. On GitHub they're mostly used to 
prepare branches for merge requests because random user X can't commit 
to a branch in repo Y, but KDE's open-to-all-by-default policy, and 
generally decent project communication (IRC, mailing lists, and other 
means), makes that less necessary. Approved developers discussing 
improvements with developers are more likely to get approved to have a 
branch in the main repo; tiny fixes can be approved via a pre-commit 
audit. IOW, I think losing clones can be dealt with by some reasonable 
workflow rejiggering and social engineering.


Remember, we don't have the resources of GitHub or Bitbucket. No 
solution will be 100%. We're trying to decide what solution will, on 
balance, be closest to that 100%. But this also needs to factor in 
actual sysadmin time constraints/availability.


Sorry to be the sad-sack voice in this conversation. Ben and I have been 
having many conversations about alternate hosting mechanisms over the 
past few days, weeks, months, and (yes, really) years, and he's 
definitely Good Cop and I'm definitely Bad Cop when it comes to meeting 
every single desire of every single community member. We'd both love to 
do it (again, really), but I'm trying to be pragmatic, not the least 
because my availability is very hit and miss now and so even more burden 
falls on Ben. I don't want the minimal sysadmin staff we have getting 
crushed by the weight of requirements. Again -- I'd like to see us get 
as close to 100% as possible, and I think that some features that a few 
people find very useful -- but that can fairly effectively be addressed 
through other means -- and that cause amazing amounts of sysadmin and 
system burden should be up on the chopping block unless there are truly 
compelling arguments against.


--Jeff

Re: Changes to our Git infrastructure

2014-12-29 Thread argonel

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 repo for sharing that patch set.


 This is a social issue, then. What yuo describe makes sense -- if a patch
 is extremely dirty, for example, I can imagine a project maintainer not
 willing to carry it as a visible branch in their repo.


In one case, *I* am technically that maintainer. I have a personal clone
that has a very invasive patch set, that I rebase just about every time I
touch it. Once the design is entirely hammered out I'll share the changes,
but I think if it were a branch in the main repo it would be quite annoying
for others - and maybe for me if someone decided to help. As a personal
clone I can disclaim liability for being annoying with the rebasing, and it
comes with a sense of privacy in that maybe I don't want any help.

I also have a patch set that requires a forked KMessageWidget. (This was
from before it was moved to KWidgetsAddons). If I hadn't been the only
developer interested in experimenting with my changes to KMW, I could have
created a scratch repo for a lib containing only the modified KMW, and a
personal clone of Konversation that used it.

In KDE3 times, I had a fork of QTextEdit. Since we had qt-copy, I could
have used a personal clone to house that fork instead of importing it into
Konversation. I think I still could, since we have qt.git.

However, the personal prefixes appear to solve this problem semi-neatly. A
 perfect solution would be refs that aren't getting included in clones (and
 guess what, there's one review system which works exactly like that).

  I'm sure I'm not
 the only one carrying patches that are arguably sharable but not
 upstreamable.


 Got an example so that I know what you're describing?


Well, to avoid any undesirable discussion, lets use something contrived
instead of.. fraught.. as an example:

Konversation uses a treeview that acts exactly like a tab view. Which means
that when you scroll the treelist via the mouse scrollwheel, it moves the
selection instead of scrolling the list. Upstream disagrees with mixing
the metaphors and therefore has rejected my patch. (In truth, I didn't
feel strongly enough about the idea to even create a patch)

With enough activity around said personal clone, an argument to the
maintainer might be made for a configuration option, maybe even one that's
visible in the config dialog.

I have a couple of other UI patches of similar nature, that have bitrotted
since I moved to Fedora. In theory, had I shared them in personal clones,
someone else might have continued to keep the patches up to date.

In the first example above, in time those of us using the forked
KMessageWidget might have been able to finally win our case with the
KMessageWidget maintainer to cause my changes to be included. (In reality
though, my changes are probably useless and have never been shared except
as screenshots)

 I've also used clones to share an experiment that may not belong in the
 proper repo now or ever. Making everyone who uses the main repo pay to
 carry an experimental branch is somewhat unfriendly, especially if you're
 not normally involved with the project. You may also wish to avoid the
 scrutiny of the others involved in the main project until you're ready,
 which the sudden appearance of a new branch during checkout would
 certainly
 invite.


 That's a valid concern. On the other hand, it's a pretty simple way of
 enforcing collaboration. There were keynotes during the last Akademy
 where people mentioned their worrying about development moving into
 isolated silos. Disabling clones leads directly to sort of an enforced
 collaboration (or, failing that, to people pushing stuff to GitHub).


I wasn't there so I don't have any context for this.

 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, or already exists elsewhere.


 I agree with scratch repos being useful as a first step.

  There are probably still quite a few people away for the holiday season,
 perhaps this decision can be deferred for a couple of weeks until its more
 likely that everyone is back and paying attention?


 +1, and sending a mail to kde-cvs-announce to make sure all KDE account
 holders are aware of both this and the other thread is a good idea.


 With kind regards,
 Jan

 --
 Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure

2014-12-29 Thread argonel

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 IRC. Deleting it is painless when you discover
 that your idea is terrible, or already exists elsewhere.


 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.


I thought they expired automatically, perhaps others are under that
impression as well?


 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 largest piece of our Git hosting. There are more scratch
 repos than normal repos. If clone repos were excluded, scratch repos would
 actually be a majority of all repos -- and again, most of them haven't been
 touched in years. People complain about propagation delay of repos to
 anongits -- syncing all these totally outdated repos is a major reason.

 I understand the reason people like them -- as a place to test out early
 concepts before making them official projects -- but I think that a
 combination of social changes and technical changes can address losing them.

 One social change would be divesting ourselves of the idea that getting a
 Git repo from sysadmins is onerous. You can start a git repo locally and
 push it up later; the extra few hours or even a day it might take to get a
 hosted version should really not be the reason that your project simply
 cannot see the light of day.

 Another social change, in combination with a technical change, would be to
 get interested people who would like to see this kind of thing happen
 faster and have them take on specific sysadmin tasks -- for instance,
 creating repos on request as soon as possible, spreading the workload out
 so that any given request is likely to be handled faster (your standard
 task queue). The reason it's semi-onerous now (but we should stop thinking
 that it is, see above) is due to lack of manpower. But volunteers can be
 given rights to handle specific ticket types without having to become full
 sysadmins. Like anything else, if people think it takes too long, get
 involved.


Sign me up, I'll do this. I'd also be willing to chase down the owners of
old scratch repos and personal clones, similar to Albert's maintenance of
stale open reviews. My availability isn't perfect, but I am in UTC-5:00
which might come in handy.


 Clones (336 of them) are also nice in concept but with better code review
 and/or auditing capabilities (especially pre-commit capabilities), I think
 they will become less important, and remarks on this thread seem to back
 that idea up. On GitHub they're mostly used to prepare branches for merge
 requests because random user X can't commit to a branch in repo Y, but
 KDE's open-to-all-by-default policy, and generally decent project
 communication (IRC, mailing lists, and other means), makes that less
 necessary. Approved developers discussing improvements with developers are
 more likely to get approved to have a branch in the main repo; tiny fixes
 can be approved via a pre-commit audit. IOW, I think losing clones can be
 dealt with by some reasonable workflow rejiggering and social engineering.

 Remember, we don't have the resources of GitHub or Bitbucket. No solution
 will be 100%. We're trying to decide what solution will, on balance, be
 closest to that 100%. But this also needs to factor in actual sysadmin time
 constraints/availability.

 Sorry to be the sad-sack voice in this conversation. Ben and I have been
 having many conversations about alternate hosting mechanisms over the past
 few days, weeks, months, and (yes, really) years, and he's definitely Good
 Cop and I'm definitely Bad Cop when it comes to meeting every single desire
 of every single community member. We'd both love to do it (again, really),
 but I'm trying to be pragmatic, not the least because my availability is
 very hit and miss now and so even more burden falls on Ben. I don't want
 the minimal sysadmin staff we have getting crushed by the weight of
 requirements. Again -- I'd like to see us get as close to 100% as possible,
 and I think that some features that a few people find very useful -- but
 that can fairly effectively be addressed through other means -- and that
 cause amazing amounts of sysadmin and system burden should be up on the
 chopping block unless there are truly compelling arguments against.

 --Jeff

Re: Changes to our Git infrastructure

2014-12-29 Thread Thomas Friedrichsmeier

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.
 
 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 largest piece of our Git hosting.
 There are more scratch repos than normal repos. If clone repos were
 excluded, scratch repos would actually be a majority of all repos --
 and again, most of them haven't been touched in years. People
 complain about propagation delay of repos to anongits -- syncing all
 these totally outdated repos is a major reason.

ok, I can see your point. But, personally, I was absolutely unaware of
that problem, so far. And, while it's absolutely possible that I've
simply missed the relevant discussions(*), I tend to think that I
may not be the only one. In fact, at a cursory glance, I cannot even
find any relevant words of caution on either
- https://sysadmin.kde.org/services/code-repositories/ or
- https://community.kde.org/Sysadmin/GitKdeOrgManual
.

So lets not abandon a very useful concept without giving some soft
measures a try, first:
- Call for deletion of obsolete scratch repositories every once in a
  while. In fact, as a reaction to your mail, I will go ahead and
  delete my current (obsolete) scratch repo, right away.
- Clearly state in the docs that scratch repos should be used with
  resource consumption in mind.
- Every once in a while (fully automated or not), identify repositories
  that have not seen a commit in a year (most of them, as you say), and
  send mail to their owners requesting to do some sort of ping. Delete /
  archive repositories that have not seen a ping or other activity
  after a sensible grace period.

Regards
Thomas

(*) I'm only just moving my main project to kde.org; but I have been
contributing on-and-off, and following kde-core-devel on-and-off, for years.


signature.asc
Description: PGP signature

Re: Changes to our Git infrastructure


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 largest piece of our Git hosting.
There are more scratch repos than normal repos. If clone repos were
excluded, scratch repos would actually be a majority of all repos --
and again, most of them haven't been touched in years. People
complain about propagation delay of repos to anongits -- syncing all
these totally outdated repos is a major reason.


ok, I can see your point. But, personally, I was absolutely unaware of
that problem, so far. And, while it's absolutely possible that I've
simply missed the relevant discussions(*), I tend to think that I
may not be the only one. In fact, at a cursory glance, I cannot even
find any relevant words of caution on either
- https://sysadmin.kde.org/services/code-repositories/ or
- https://community.kde.org/Sysadmin/GitKdeOrgManual
.

So lets not abandon a very useful concept without giving some soft
measures a try, first:


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 -- it turned our Git hosting into a generic 
repository hosting system, even if only for confirmed developers. Yes, 
it's nice to have remote backup, but you can also get this from many 
other providers, your own server, your own laptop, or more.


I'm not saying that it shouldn't be easy for developers to get 
repositories to play around with on KDE infrastructure. I'm just 
questioning the idea (as in my original email, which is not part of your 
quote) that actually asking a sysadmin for one is too onerous a burden, 
so onerous that such projects will simply immediately fail to thrive, 
instead of the developer simply waiting an extra X hours to be able to 
push up to a central hosted repo from the local system. Those that feel 
that this is just too high a price to pay could help reduce it by 
handling repo requests.


Scratch repos are also not just problematic in terms of all of the 
out-of-date repositories; they're very much a feature enabled by our 
current system (they were enabled because we could do it, so why not). 
If we want to move to a new system and the many other benefits it might 
provide, the kind of sandboxing that makes scratch a safe place for 
developers to create repos at will may be hard to provide without more 
of the types of unmaintainable patches and customizing that cause Ben to 
describe our system as being held together with glue and duct tape. (The 
current scratch area itself is already entirely custom-coded on top of 
Gitolite, and that means it must be maintained.)


--Jeff

Re: Changes to our Git infrastructure

2014-12-29 Thread Thomas Friedrichsmeier

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 the beginning -- it turned our Git hosting into a
 generic repository hosting system, even if only for confirmed
 developers. Yes, it's nice to have remote backup, but you can also
 get this from many other providers, your own server, your own laptop,
 or more.

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 from this. Not quite sure the idea
will fly, so I'm shy to request a real repo for this. But also, a
local repo would be pointless, and using a separate provider would feel
wrong. Branching is equally out of question, as this is separate data.
 
 I'm not saying that it shouldn't be easy for developers to get 
 repositories to play around with on KDE infrastructure. I'm just 
 questioning the idea (as in my original email, which is not part of
 your quote) that actually asking a sysadmin for one is too onerous a
 burden, so onerous that such projects will simply immediately fail to
 thrive, instead of the developer simply waiting an extra X hours to
 be able to push up to a central hosted repo from the local system.
 Those that feel that this is just too high a price to pay could help
 reduce it by handling repo requests.

No, having to ask a sysadmin is not necessarily a show-stopper to me.
But it certainly does create the aura of don't do this unless you are
sure you know what you are doing. Also note that currently the wording
on the wiki is:

Note that we have deliberately decided not to allow the direct
creation of KDE Playground projects; the path to existence for a KDE
Playground repository project always leads through a personal scratch
space first. This is to give you the power to decide whether your
project is ready, and also to force you to deliberate whether it truly
is.

Well, that could be changed. And the psychological barrier could
further be lowered by providing a dedicated web form, for instance.
Note that I'm not really attached to the exact process of creating a
scratch repo. But the _concept_ of being able to create a repo
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
seems important to me.

 Scratch repos are also not just problematic in terms of all of the 
 out-of-date repositories; they're very much a feature enabled by our 
 current system (they were enabled because we could do it, so why
 not). If we want to move to a new system and the many other benefits
 it might provide, the kind of sandboxing that makes scratch a safe
 place for developers to create repos at will may be hard to provide
 without more of the types of unmaintainable patches and customizing
 that cause Ben to describe our system as being held together with
 glue and duct tape. (The current scratch area itself is already
 entirely custom-coded on top of Gitolite, and that means it must be
 maintained.)

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 scratch repos, or is it a problem of the implementation of
how exactly scratch repos are created?

Regards
Thomas


signature.asc
Description: PGP signature

Re: Changes to our Git infrastructure


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 upstream's manual at [1]. What are the 
KDE-specific additions?


With kind regards,
Jan

[1] http://gitolite.com/gitolite/wild.html#deleting-a-wild-repo

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 changing the
commits though.


In my personal opinion. the moment we adjust our workflow from a good one 
(rebase locally, force push) to a worse one (with commits such as fix 
missing semicolon) just to work around an ACL setup of a git hosting, 
we're doing things very wrong.


With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Re: Changes to our Git infrastructure


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 because I see 
this exact feature described at upstream's manual at [1]. What are the 
KDE-specific additions?


In sysadmin/repo-management as always.

The custom stuff is not the ability to delete. It's keying scratch and 
clone commands to specific users to ensure that users can a) only put 
these in proper locations and b) only access and perform commands on the 
right repos.


Also, some of our stuff got upstreamed to Gitolite over time.

--Jeff

Re: Changes to our Git infrastructure


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 from this. Not quite sure the idea
will fly, so I'm shy to request a real repo for this. But also, a
local repo would be pointless, and using a separate provider would 
feel

wrong. Branching is equally out of question, as this is separate data.


Right -- so my suggestion is that we work to get rid of that shyness. 
That's a social issue. See below...





I'm not saying that it shouldn't be easy for developers to get
repositories to play around with on KDE infrastructure. I'm just
questioning the idea (as in my original email, which is not part of
your quote) that actually asking a sysadmin for one is too onerous a
burden, so onerous that such projects will simply immediately fail to
thrive, instead of the developer simply waiting an extra X hours to
be able to push up to a central hosted repo from the local system.
Those that feel that this is just too high a price to pay could help
reduce it by handling repo requests.


No, having to ask a sysadmin is not necessarily a show-stopper to me.
But it certainly does create the aura of don't do this unless you are
sure you know what you are doing. Also note that currently the 
wording

on the wiki is:

Note that we have deliberately decided not to allow the direct
creation of KDE Playground projects; the path to existence for a KDE
Playground repository project always leads through a personal scratch
space first. This is to give you the power to decide whether your
project is ready, and also to force you to deliberate whether it truly
is.


Exactly, so this is the root of the social issue. And for the current 
git hosting solution, this is correct. But for the next gen solution, it 
doesn't have to be.



Well, that could be changed. And the psychological barrier could
further be lowered by providing a dedicated web form, for instance.
Note that I'm not really attached to the exact process of creating a
scratch repo. But the _concept_ of being able to create a repo
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
seems important to me.


Sure. So I think this is something that can be accommodated except for 
the you-do-it-yourselfness. And for what it's worth, it's possible that 
the do-it-yourselfness could still be accommodated but would require 
custom patching -- currently -- and that is something that we are 
somewhat loathe to do to the greatest extent possible. It has been the 
root of many a problem, especially in Bugzilla.



Scratch repos are also not just problematic in terms of all of the
out-of-date repositories; they're very much a feature enabled by our
current system (they were enabled because we could do it, so why
not). If we want to move to a new system and the many other benefits
it might provide, the kind of sandboxing that makes scratch a safe
place for developers to create repos at will may be hard to provide
without more of the types of unmaintainable patches and customizing
that cause Ben to describe our system as being held together with
glue and duct tape. (The current scratch area itself is already
entirely custom-coded on top of Gitolite, and that means it must be
maintained.)


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 scratch repos, or is it a problem of the implementation 
of

how exactly scratch repos are created?


I'm honestly not sure how to answer that; scratch repos are very much an 
implementation because we had a solution. It seemed like something that 
could be useful, and we had the capability with the current software, so 
we did it. In hindsight, it has been problematic.


--Jeff

Re: Changes to our Git infrastructure


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 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 there.  :-)


--Jeff

Re: Changes to our Git infrastructure

2014-12-29 Thread Thomas Friedrichsmeier

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 scratch repos, or is it a problem of the
  implementation of
  how exactly scratch repos are created?
 
 I'm honestly not sure how to answer that; scratch repos are very much
 an implementation because we had a solution. It seemed like something
 that could be useful, and we had the capability with the current
 software, so we did it. In hindsight, it has been problematic.

What I mean is, it seems somewhat unclear what aspects exactly of
scratch repos are the problem. So I'll try to clarify:

To me, the essence of the concept of a scratch repo is the three
points, I listed, i.e. (reiterating), creating a repo 
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
A different aspect, that is not so important to me, is that scratch
repos can be created instantly via certain SSH commands without any
interaction with sysadmins. This is what I referred to as
implementation.

In these terms, concept is what I care about. And if this concept
can be preserved, consider me happy with any implementation.

Regards
Thomas


signature.asc
Description: PGP signature

Re: Changes to our Git infrastructure


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 about / is the problem inherent
to the
_concept_ of scratch repos, or is it a problem of the
implementation of
how exactly scratch repos are created?


I'm honestly not sure how to answer that; scratch repos are very much
an implementation because we had a solution. It seemed like something
that could be useful, and we had the capability with the current
software, so we did it. In hindsight, it has been problematic.


What I mean is, it seems somewhat unclear what aspects exactly of
scratch repos are the problem. So I'll try to clarify:

To me, the essence of the concept of a scratch repo is the three
points, I listed, i.e. (reiterating), creating a repo
- without _any_ questions asked (other than the name)
- in a not-quite-as-visible area / prefix
- following more liberal rules, e.g. about force pushing
A different aspect, that is not so important to me, is that scratch
repos can be created instantly via certain SSH commands without any
interaction with sysadmins. This is what I referred to as
implementation.

In these terms, concept is what I care about. And if this concept
can be preserved, consider me happy with any implementation.


Concept can be preserved. Implementation may or may not be able to be 
preserved. Or, implementation may not be preserved initially, and will 
be fully preserved eventually (as in, when new custom patches are 
written).


--Jeff

Re: Changes to our Git infrastructure

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://trojita.flaska.net/

Re: Changes to our Git infrastructure