On 09/19/2015 11:38 PM, Jaroslaw Staniek wrote:
> I am feeling strong enough to trust people and integrate with the
> outside world.
> With any git storages that count in this world.
And it's OK to have that opinion and voice it. The reason we are
having a thread is because our individual opinio
On 19 September 2015 at 23:06, Eike Hein wrote:
>
>
> On 09/19/2015 10:32 PM, Kevin Krammer wrote:
>> I don't see there this github review is coming from.
>
> Review is an interactive process where you ask for changes and
> iterate. Once you open the door to doing it on GitHub, you will:
>
> * Hav
On 09/19/2015 10:32 PM, Kevin Krammer wrote:
> I don't see there this github review is coming from.
Review is an interactive process where you ask for changes and
iterate. Once you open the door to doing it on GitHub, you will:
* Have a hard time making some contributors understand why
they s
On Saturday, 2015-09-19, 22:11:10, Eike Hein wrote:
> On 09/19/2015 09:55 PM, Kevin Krammer wrote:
> > Exactly.
> > So why would one continue to do the prelimiary review in addition to the
> > required one?
> > As soon as there is a stream of patches from a new contributor, that
> > contributor wil
On Saturday 19 September 2015 00:17:00 Boudhayan Gupta wrote:
> When I first thought of Selfie, I thought of the following:
>
> * It makes perfect sense (screen taking a self portrait).
> * While most other applications and projects take an "appropriate" and
> subdued approach to naming their apps
Hey,
so I haven't really organized any sprints myself but have participated
in many, some good, some less good. So here's my personal take
on this speaking from experience:
* always make everyone feel like they belong to the group and to the sprint
* if it's a random group that have never met be
On 09/19/2015 09:55 PM, Kevin Krammer wrote:
> Exactly.
> So why would one continue to do the prelimiary review in addition to the
> required one?
> As soon as there is a stream of patches from a new contributor, that
> contributor will be asked to get an account of their own.
> Need for prelim
On Saturday, 2015-09-19, 20:56:31, Eike Hein wrote:
> On 09/19/2015 08:43 PM, Kevin Krammer wrote:
> > Well, the github side review will make the job of the KDE contributor who
> > brings the patch into KDE a lot easier, because when they put the patch up
> > for review as "their" contribution, mos
On 19 September 2015 at 21:24, Ivan Čukić wrote:
>> Could you mention at least one KDE git repo that belongs to multiple
>
> Eike already mentioned that Plasma has a single repo in which
> different parts are maintained by different people.
But is Plasma a single project or not?
That's the case f
On 09/19/2015 09:36 PM, Kevin Krammer wrote:
> So, right now, a maintainer is expected to check reviewboard even if they are
> content with all holders of commit accounts to push directly.
> But that as soon as there is a second option, then not checking reviewboard
> becomes acceptable?
That'
On Saturday, 2015-09-19, 21:08:27, Eike Hein wrote:
> On 09/19/2015 08:58 PM, Kevin Krammer wrote:
> > Even using a review tool in the first place is something that the
> > maintainer asks people to do.
>
> No. We advertise ReviewBoard (and later Phab) as a general
> interface to throw code at our
> Could you mention at least one KDE git repo that belongs to multiple
Eike already mentioned that Plasma has a single repo in which
different parts are maintained by different people.
Cheerio,
Ivan
Cheerio,
Ivan
--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
On 19 September
On 09/19/2015 09:13 PM, Jaroslaw Staniek wrote:
> Could you mention at least one KDE git repo that belongs to multiple
> projects? And thus maybe multiple even multiple groups of maintainers?
I have previously in the thread: Different subfolders in
plasma-desktop.git have different maintainers,
On 19 September 2015 at 21:08, Eike Hein wrote:
>
>
> On 09/19/2015 08:58 PM, Kevin Krammer wrote:
>> Even using a review tool in the first place is something that the maintainer
>> asks people to do.
>
> No. We advertise ReviewBoard (and later Phab) as a general
> interface to throw code at our m
Selfie is better than Kapture for sure.. :)
On Saturday, September 19, 2015 08:38:41 PM Eike Hein wrote:
> On 09/19/2015 08:32 PM, Rajeev Bhatta wrote:
> > If we can choose the name Selfie and then it is important to have the
> > users
> > relate to it as a product too then it works, if we cannot
On 09/19/2015 08:58 PM, Kevin Krammer wrote:
> Even using a review tool in the first place is something that the maintainer
> asks people to do.
No. We advertise ReviewBoard (and later Phab) as a general
interface to throw code at our maintainers. "I don't look
at ReviewBoard" is not a socially
On Saturday, 2015-09-19, 20:32:43, Eike Hein wrote:
> On 09/19/2015 08:25 PM, Kevin Krammer wrote:
> > Saying "I don't look at the KDE review tool" would be like saying "I am
> > not
> > interested in your patch".
>
> Saying "My personal productivity and efficiency matters more
> to me in the long
You made me giggle with that :
On Sat, Sep 19, 2015 at 3:16 PM, Eike Hein wrote:
>
>
> On 09/19/2015 11:36 AM, rajeev bhatta wrote:
>> Like the name selfie..but it will be nightmare finding the app in google
>> if looking for selfie
>
> No it won't. People aren't too dumb to add an extra
> keywor
On 09/19/2015 08:43 PM, Kevin Krammer wrote:
> Well, the github side review will make the job of the KDE contributor who
> brings the patch into KDE a lot easier, because when they put the patch up
> for
> review as "their" contribution, most of the things that the contributor knew
> about wi
> On the point of code review: I disagree. We mostly only discuss what we
> worked on and send also a summary to the mailing list to not exclude
> anyone.
I think this is a great point that should be reiterated:
[...] send also a summary to the mailing list to not exclude anyone
Cheers,
Ivan
___
On Saturday, 2015-09-19, 20:20:56, Eike Hein wrote:
> On 09/19/2015 08:13 PM, Kevin Krammer wrote:
> > I am afraid my understanding of the technical background of this is still
> > too hazy.
> > How would review "move" from KDE to github?
> > If review on reviewboard is required (per project's unwr
On 09/19/2015 08:32 PM, Rajeev Bhatta wrote:
> If we can choose the name Selfie and then it is important to have the users
> relate to it as a product too then it works, if we cannot target that then we
> should not name it such...
I feel like Selfie is more likely to create an emotional
bond
Though Generic names are more relatable and better for users and program
itself. But the generic name must IMHO should result in self identifying
product. Product branding is very important to define a success of a product.
If we can choose the name Selfie and then it is important to have the
On 09/19/2015 08:25 PM, Kevin Krammer wrote:
> Saying "I don't look at the KDE review tool" would be like saying "I am not
> interested in your patch".
Saying "My personal productivity and efficiency matters more
to me in the long-run than your patch, so please use the tool
I prefer to reach me
On Saturday, 2015-09-19, 19:58:26, Eike Hein wrote:
> On 09/19/2015 07:52 PM, Kevin Krammer wrote:
> > You mean that a KDE project would ignore your review request it it comes
> > from reviewboard/phabricator?
>
> I think that's a realistic, even likely concern. We already
> know that some devs do
On 09/19/2015 08:13 PM, Kevin Krammer wrote:
> I am afraid my understanding of the technical background of this is still too
> hazy.
> How would review "move" from KDE to github?
> If review on reviewboard is required (per project's unwritten social
> contract), it cannot not happen.
> If it is
On 09/19/2015 08:05 PM, Martin Klapetek wrote:
> Patch from 2012 with open questions/issues from a newcomer(?), left
> unattended. Having the same on Phabricator with the source being github
> would be no different, would it? And there _will_ be patches left to rot
> on Phabricator anyway, just l
On Saturday, 2015-09-19, 18:44:24, Martin Graesslin wrote:
> On Saturday, September 19, 2015 6:40:47 PM CEST Kevin Krammer wrote:
> > On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> > > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > > If the problem is somew
On Sat, Sep 19, 2015 at 1:55 PM, Eike Hein wrote:
> On 09/19/2015 07:49 PM, Martin Klapetek wrote:
> > We wouldn't get no lock-in though. Not even remotely. It will simply
> > be another path for an incoming patch. If the patch in question ends
> > up on Phabricator and gets reviewed on Phabricat
Hi Martin,
On Sat, Sep 19, 2015 at 6:49 PM, Martin Klapetek
wrote:
> On Sat, Sep 19, 2015 at 1:42 PM, Laszlo Papp wrote:
>>
>>
>> Sure, but why would increase this situation further on?
>
>
> Sorry, I don't understand this question.
I missed the subject "we" in that sentence, apparently; I apol
On 09/19/2015 08:01 PM, Riccardo Iaconelli wrote:
> The user gets a notifications. We're working on the assumption that this user
> is a github user --> he will see the notification.
Review comments on Phab don't produce GitHub notifications.
Cheers,
Eike
_
On Saturday, September 19, 2015 07:55:08 PM Eike Hein wrote:
> That doesn't address Sune's concern though. If you
> get a patch by email you can reply by email; the
> comm channel stays the same. Ditto IRC. If you file
> a pull req on GitHub and it gets imported into Phab
> which you don't have an
On 2015-09-19, Kevin Krammer wrote:
>> No, I'm afraid of code review slowly moving from KDE to github up to =
> the
>> final point where I need to get a github account because otherwise I =
> cannot
>> contribute code.
>
> You mean that a KDE project would ignore your review request it it come=
>
On 09/19/2015 07:52 PM, Kevin Krammer wrote:
> You mean that a KDE project would ignore your review request it it comes from
> reviewboard/phabricator?
I think that's a realistic, even likely concern. We already
know that some devs don't like using multiple code review
sites concurrently from t
On Sat, Sep 19, 2015 at 7:12 PM, Eike Hein wrote:
>
>
> On 09/19/2015 06:57 PM, Vishesh Handa wrote:
>>> The topology of 'project' is not a match to our repository
>>> topology, which is incidental and an implementation detail.
>>> It's not possible to cleanly turn GitHub on or off along
>>>
On 09/19/2015 07:49 PM, Martin Klapetek wrote:
> We wouldn't get no lock-in though. Not even remotely. It will simply
> be another path for an incoming patch. If the patch in question ends
> up on Phabricator and gets reviewed on Phabricator and merged from
> Phabricator, it is no different than
On Saturday, 2015-09-19, 18:46:24, Martin Graesslin wrote:
> On Saturday, September 19, 2015 6:38:26 PM CEST Kevin Krammer wrote:
> > On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote:
> > > My fear here is that if we allow pull request, people will also start to
> > > use them for code re
On Sat, Sep 19, 2015 at 1:42 PM, Laszlo Papp wrote:
>
> Sure, but why would increase this situation further on?
>
Sorry, I don't understand this question.
> I agree with everything that Sune wrote. Reaching them might be
> particularly important when changing license just for one of those.
> T
On Sat, Sep 19, 2015 at 6:37 PM, Martin Klapetek
wrote:
> On Sat, Sep 19, 2015 at 1:28 PM, Sune Vuorela wrote:
>>
>>
>> What happens if contributor doesn't follows? How do I as a reviewer know
>> why the contributor doesn't follow on? How can I reach them?
>>
>> No. let's just say no to pull requ
On 09/19/2015 07:32 PM, techie.raj...@yahoo.in wrote:
> I search apps on google all the time, some time in youtube to see a demo of
> it.. Searching for selfie will result in all the smartphones, all the
> different
> selfie related stuff which is currently viral among the masses.
Yeah. And
On Sat, Sep 19, 2015 at 1:28 PM, Sune Vuorela wrote:
>
> What happens if contributor doesn't follows? How do I as a reviewer know
> why the contributor doesn't follow on? How can I reach them?
>
> No. let's just say no to pull requests.
>
Same thing as when someone emails you a patch and you rep
People are not dumb.. especially those already familiar with KDE and linux...
however in my opinion we need to think of newbies too.
I search apps on google all the time, some time in youtube to see a demo of
it.. Searching for selfie will result in all the smartphones, all the different
selfi
On Saturday, 2015-09-19, 12:06:18, Michael Pyne wrote:
> On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote:
> > So (a) and (b) workflows differ in that in (a) github mirror and
> > git.kde.org have the same state, while in (b) the mirror is for a period
> > of time not actually a mirror, but
On Saturday, September 19, 2015 01:17:18 PM Martin Klapetek wrote:
> To further expand on the idea, the workflow would be as follows:
>
> * bot looks through our repos
> * bot finds a pull request
> * bot downloads the diff between requested branch and mirror HEAD
> * bot uploads it to phabricator
On 19 September 2015 at 17:36, Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote:
>> But that's not using the pull request. Such workflow would mean that the
>> pull request is not accepted anyway, but the code is pushed through the
>> infrastructure and n
On 2015-09-19, Martin Klapetek wrote:
> To further expand on the idea, the workflow would be as follows:
>
> * bot looks through our repos
> * bot finds a pull request
> * bot downloads the diff between requested branch and mirror HEAD
> * bot uploads it to phabricator as any other patch
> * bot p
To further expand on the idea, the workflow would be as follows:
* bot looks through our repos
* bot finds a pull request
* bot downloads the diff between requested branch and mirror HEAD
* bot uploads it to phabricator as any other patch
* bot posts message to github "Thanks for your patch, in KD
On 09/19/2015 07:04 PM, Martin Klapetek wrote:
> The only limitation I see is the needed Identity account for submitting
> patches on phabricator (right?), but other than that, how hard can it
> be(tm)?
The problem with that is that it's another variant of
"doing GitHub, but badly". It's an impr
On Saturday, September 19, 2015 7:04:46 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 6:58 PM, Martin Graesslin
wrote:
> >> When/If that actually happens, you can bring it up and then we can
> >> deal with it. Dealing in extreme What-Ifs does not help this
> >> discussion.
> >
> > yeah
On 09/19/2015 06:57 PM, Vishesh Handa wrote:
>> The topology of 'project' is not a match to our repository
>> topology, which is incidental and an implementation detail.
>> It's not possible to cleanly turn GitHub on or off along
>> the - ever-shifting - social boundaries involved.
>>
>
On Saturday, September 19, 2015 1:04:22 PM CEST Martin Klapetek wrote:
> Look, if the problem of github pull requests is the concern of KDE
> reviews eventually moving there (and create pressure on others etc),
> why don't we all throw one afternoon of our time and write a bot
> that will automatic
On Sat, Sep 19, 2015 at 7:03 PM, Luca Beltrame wrote:
> Il Sat, 19 Sep 2015 18:49:48 +0200, Vishesh Handa ha scritto:
>
>> When/If that actually happens, you can bring it up and then we can deal
>> with it. Dealing in extreme What-Ifs does not help this discussion.
>
> To be honest I don't want th
On Sat, Sep 19, 2015 at 6:58 PM, Martin Graesslin wrote:
>> When/If that actually happens, you can bring it up and then we can
>> deal with it. Dealing in extreme What-Ifs does not help this
>> discussion.
>
> yeah well, we also said github is only a mirror and pull requests are a non-
> issue. So
Look, if the problem of github pull requests is the concern of KDE
reviews eventually moving there (and create pressure on others etc),
why don't we all throw one afternoon of our time and write a bot
that will automatically import the pull request as a patch into phabricator?
That way, creating a
Il Sat, 19 Sep 2015 18:49:48 +0200, Vishesh Handa ha scritto:
> When/If that actually happens, you can bring it up and then we can deal
> with it. Dealing in extreme What-Ifs does not help this discussion.
To be honest I don't want the "if" to happen, ever.
--
Luca Beltrame - KDE Forums team
KD
On Saturday, September 19, 2015 6:49:48 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 6:46 PM, Martin Graesslin
wrote:
> > No, I'm afraid of code review slowly moving from KDE to github up to the
> > final point where I need to get a github account because otherwise I
> > cannot contribu
On 09/19/2015 06:53 PM, Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 06:44:24 PM Martin Graesslin wrote:
>> No reality would be that it slowly moves code review from KDE to github. And
>> I think we have here quite some people in the discussion who would love to
>> see that
>
> I
On Sat, Sep 19, 2015 at 4:15 PM, Eike Hein wrote:
>
>
> On 09/19/2015 04:04 PM, Vishesh Handa wrote:
>> This is the part of your email I really like. Though this is not what
>> you meant: If projectX choose to also use Github, it is not affecting
>> your project in anyway. Just ignore it and move
On Saturday, September 19, 2015 06:44:24 PM Martin Graesslin wrote:
> No reality would be that it slowly moves code review from KDE to github. And
> I think we have here quite some people in the discussion who would love to
> see that
I don't think anyone ever thought that... o.o
-Riccardo
On Sat, Sep 19, 2015 at 6:46 PM, Martin Graesslin wrote:
> No, I'm afraid of code review slowly moving from KDE to github up to the final
> point where I need to get a github account because otherwise I cannot
> contribute code.
When/If that actually happens, you can bring it up and then we can
d
On Saturday, 2015-09-19, 17:44:35, Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 5:32 PM, Kevin Krammer wrote:
> > Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> > rejected.
> >
> > Is (b) the problem people keep discussing about?
> >
> > Because as far as I can te
On Sat, Sep 19, 2015 at 3:29 PM, Eike Hein wrote:
> You're ignoring the position that says "the long-term
> negatives outweigh the short-term positives on this",
> though.
Well, I clearly think differently. I do not see any long term
negatives which cannot be addressed.
--
Vishesh Handa
On Sat, Sep 19, 2015 at 6:24 PM, Eike Hein wrote:
>
> I expect you'll ignore this as much as my other mail, but
> all of these are ephemeral in nature instead of offering
> a persistent record -- that's why we submit minutes of the
> Hangouts to the plasma-devel mailing list, for example.
>
I ass
On Saturday, September 19, 2015 6:38:26 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:
> > > The patch would still go through review at KDE. Even with no github at
> > > all
> > > a p
On Saturday, September 19, 2015 6:40:47 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > If the problem is somewhere in (a), where is it?
> >
> > I'm afraid of code review happen
On Sat, Sep 19, 2015 at 6:37 PM, Martin Graesslin wrote:
> What's important to realize: the people have already written the patch at the
> point. Some time ago I wrote a patch for a software I hadn't contributed for
> before: figuring out how to submit the patch was more way than writing the
> pat
On Saturday, 2015-09-19, 17:47:38, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > If the problem is somewhere in (a), where is it?
>
> I'm afraid of code review happening through the pull request instead of our
> infrastructure. To me github pull
On Saturday, September 19, 2015 6:29:08 PM CEST Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 06:22:17 PM Martin Graesslin wrote:
> > And how do we do that? Can we enforce this technically or will that be
> > weakened over the time the same way as we just turned the mirror into
> > "l
On Saturday, 2015-09-19, 17:53:17, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:
> > The patch would still go through review at KDE. Even with no github at all
> > a patch could have been through several revisions before being submitted.
> > The rev
On 09/19/2015 06:22 PM, Martin Graesslin wrote:
> And how do we do that? Can we enforce this technically or will that be
> weakened over the time the same way as we just turned the mirror into "let's
> accept pull requests"?
This wishy-washy stuff is nonsense. The sole argument for enabling
Gi
On Saturday, September 19, 2015 12:26:34 PM CEST Martin Klapetek wrote:
> On Sat, Sep 19, 2015 at 12:07 PM, Boudhayan Gupta wrote:
> > On 19 September 2015 at 21:17, Martin Graesslin
> >
> > wrote:
> > > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > >> If the problem i
On Saturday, September 19, 2015 06:22:17 PM Martin Graesslin wrote:
> And how do we do that? Can we enforce this technically or will that be
> weakened over the time the same way as we just turned the mirror into
> "let's accept pull requests"?
There is no way to enforce this technically, it has
On Sat, Sep 19, 2015 at 12:07 PM, Boudhayan Gupta wrote:
> On 19 September 2015 at 21:17, Martin Graesslin
> wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> >> If the problem is somewhere in (a), where is it?
> >
> > I'm afraid of code review happening through t
On 09/19/2015 05:58 PM, Vishesh Handa wrote:
> We already use some other forms of code review -
>
> * IRC
> * Email
> * IM
> * Google+ Hangouts (Just discussed some things related to the Baloo
> KCM a week ago)
> * Knocking on David's door and screaming "I need you to look at some code"
I expec
Hi all,
(hoping to break the thousands of emails currently being written...) we're
having our first sprint at WikiToLearn!!!
It's an exciting news since most of the participants are absolutely newcomers
to FOSS development (let alone to KDE), and to various degrees to WikiToLearn
too. The contr
On Saturday, September 19, 2015 6:11:21 PM CEST you wrote:
> On Saturday, September 19, 2015 05:47:38 PM Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > > If the problem is somewhere in (a), where is it?
> >
> > I'm afraid of code review happeni
On Sat, Sep 19, 2015 at 6:12 PM, Michael Pyne wrote:
>
> Otherwise the corollary to your point would become pertinent: We already
> discuss bugs on IRC, email, IM, etc so why limit bug tickets to Bugzilla?
> Why not a Github issue, or something else? I'm not trying to "slippery slope"
> your a
On Saturday, September 19, 2015 6:08:39 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 6:04 PM, Martin Graesslin
wrote:
> >> * Google+ Hangouts (Just discussed some things related to the Baloo
> >> KCM a week ago)
> >
> > closed
>
> Martin. There are weekly Plasma meetings on Google+! T
On Sat, September 19, 2015 17:58:29 Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 5:53 PM, Martin Graesslin
wrote:
> > My fear here is that if we allow pull request, people will also start to
> > use them for code review at which point we have split the development
> > team in those doing code r
On Saturday, September 19, 2015 05:47:38 PM Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> > If the problem is somewhere in (a), where is it?
>
> I'm afraid of code review happening through the pull request instead of our
> infrastructure. To me g
On Sat, Sep 19, 2015 at 6:04 PM, Martin Graesslin wrote:
>> * Google+ Hangouts (Just discussed some things related to the Baloo
>> KCM a week ago)
> closed
Martin. There are weekly Plasma meetings on Google+! Those are as
essential as code review. They control the direction of the project
and iss
Am Samstag, 19. September 2015, 21:15:41 CEST schrieb Boudhayan Gupta:
> On 19 September 2015 at 20:52, Vishesh Handa wrote:
[…]
> > I think we're talking about different things. The read-only mirror is
> > done, and shipped. I was talking about projects being able to also use
> > github, and the
On 19 September 2015 at 21:17, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
>> If the problem is somewhere in (a), where is it?
>
> I'm afraid of code review happening through the pull request instead of our
> infrastructure. To me github pull requ
On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote:
> So (a) and (b) workflows differ in that in (a) github mirror and git.kde.org
> have the same state, while in (b) the mirror is for a period of time not
> actually a mirror, but "ahead".
>
> Where "ahead" could also mean wrong if "klmn" nee
On Saturday, September 19, 2015 5:57:09 PM CEST Eike Hein wrote:
> On 09/19/2015 05:54 PM, Riccardo Iaconelli wrote:
> > while rejecting them autmatically isjust a great way to drive potential
> > contributors away...
>
> Which is a good reason why the mirror shouldn't have happened
> - regret bei
On Saturday, September 19, 2015 5:58:29 PM CEST Vishesh Handa wrote:
> On Sat, Sep 19, 2015 at 5:53 PM, Martin Graesslin
wrote:
> > My fear here is that if we allow pull request, people will also start to
> > use them for code review at which point we have split the development
> > team in those
Am Samstag, 19. September 2015, 17:22:03 CEST schrieb Vishesh Handa:
> > It is important to note that we're talking about infrastructural
> > consistency here, not code consistency. There is a distinction.
>
> My point over here was to illustrate that there are many parts to
> building a project,
On Sat, Sep 19, 2015 at 5:45 PM, Boudhayan Gupta wrote:
>
>> "governance" is quite a vague word over here.
>>
>> Release cycles, documentation, QA, online infrastructure? what exactly?
>
> All of it. We have clearly defined release cycles that we must abide
> by, documentation standards that we mu
Am Samstag, 19. September 2015, 16:44:54 CEST schrieb Martin Graesslin:
> On Saturday, September 19, 2015 3:28:56 PM CEST Luigi Toscano wrote:
> > Kevin Krammer ha scritto:
> > > On Saturday, 2015-09-19, 14:43:37, Bhushan Shah wrote:
> > >> On Sat, Sep 19, 2015 at 2:06 PM, Sune Vuorela
wrote:
> >
On Sat, Sep 19, 2015 at 5:53 PM, Martin Graesslin wrote:
> My fear here is that if we allow pull request, people will also start to use
> them for code review at which point we have split the development team in
> those doing code review through reviewboard and those through github.
We already u
On 09/19/2015 05:54 PM, Riccardo Iaconelli wrote:
> while rejecting them autmatically isjust a great way to drive potential
> contributors away...
Which is a good reason why the mirror shouldn't have happened
- regret being on vacation during that time.
Cheers,
Eike
__
I understand the takeover concern, it is a valid point. If I become the
maintainer of application X, which was accepting pull requests, and I don't
want to have a github account, I either have to create an account, find
somebody on the team who wants to monitor pull requests, or change the
proj
On Saturday, September 19, 2015 5:46:07 PM CEST Kevin Krammer wrote:
> On Saturday, 2015-09-19, 17:36:09, Martin Graesslin wrote:
> > On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:
> > > I think there was some confusion on that point, so let me state this
> > > again:
> >
On Saturday, September 19, 2015 5:32:33 PM CEST Kevin Krammer wrote:
> If the problem is somewhere in (a), where is it?
I'm afraid of code review happening through the pull request instead of our
infrastructure. To me github pull requests are not just the "here's the
patch", but also the code re
On Saturday, 2015-09-19, 17:36:09, Martin Graesslin wrote:
> On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:
> > I think there was some confusion on that point, so let me state this
> > again:
> > the agreement is that github mirrors ARE going to be kept read-only, so
> >
On 19 September 2015 at 20:52, Vishesh Handa wrote:
> Relevant part - "Online services associated with the project are
> either hosted on KDE infrastructure or have an action plan that
> ensures continuity which is approved by the KDE system administration
> team"
The sysadmin team does *not* hav
On Sat, Sep 19, 2015 at 5:32 PM, Kevin Krammer wrote:
> Where "ahead" could also mean wrong if "klmn" needs to be modified or gets
> rejected.
>
> Is (b) the problem people keep discussing about?
>
> Because as far as I can tell it is not really an option given that it can lead
> to an inconsisten
On Saturday, 2015-09-19, 17:19:16, Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote:
> > Is anyone actually arguing this point in the way you ask? No one's asking
> > to prevent "one offs" entirely, the core of the issue is that KDE
> > development should
On Saturday, September 19, 2015 5:19:16 PM CEST Riccardo Iaconelli wrote:
> On Saturday, September 19, 2015 10:58:09 AM Michael Pyne wrote:
> > Is anyone actually arguing this point in the way you ask? No one's asking
> > to prevent "one offs" entirely, the core of the issue is that KDE
> > develo
On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote:
> But that's not using the pull request. Such workflow would mean that the
> pull request is not accepted anyway, but the code is pushed through the
> infrastructure and not trough Github interface.
>
> Just to be sure, question for
1 - 100 of 176 matches
Mail list logo
