Hi JP,
On 01/13/2018 01:12 AM, JP wrote:
> So I've asked some questions in the PR but receive few answers and it
> usually takes weeks for an answer. Should I be asking in the PR or
> here? In any case here's some questions.
I'll answer in the PR.
Kaspar
_
So I've asked some questions in the PR but receive few answers and it
usually takes weeks for an answer. Should I be asking in the PR or
here? In any case here's some questions.
For the SiFive license is there someone who could review it? I assuming
there's some RIOT licensing guru who chec
Hi JP,
First of all, welcome to the RIOT community and thank you for your
contribution!
There are two steps to our CI at the moment. The first one is Travis, which
provides you with some preliminary static check regarding our coding
conventions, documentation and also some static code analysis. W
I just created a pull request for merging support for the SiFive HiFive1
board. I've never used the pull request mechanism before so hopefully
nothing is too buggered. What need to be done for the CI integration?
Those checks are failing.
JP
___
de
Hi,
just added the guideline to the Wiki.
> I suppose it is intended as an update to Development-procedures?
Actually, I decided to add a link to the main page _and_ to the development
procedures.
Cheers,
Oleg
--
die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs);
linux-2.2
Am 24.08.2015 um 17:42 schrieb Oleg Hahm:
[...]
> So, are there any objections about putting the following into the Wiki?
I suppose it is intended as an update to Development-procedures?
> =
> ## Guidelines for creating a good Pull Request
>
[...]
> =
Agreed.
greetings
Paul
_
+1
minor remark:
I would prefer writing `pull request` with lowercase letters. I couldn't
find any significant occurences on google, where `pull request` is
written with capital letters. It's fine for the subject, though. But
then again, I would insist on also capitalizing `Creating` and `Good
+1
On Aug 24, 2015 9:13 PM, "Oleg Hahm" wrote:
> Hi again!
>
> So, are there any objections about putting the following into the Wiki?
> =
> ## Guidelines for creating a good Pull Request
>
> * The title and initial description of a Pull request should describe its
> basic idea and what goa
+1
On Mon, Aug 24, 2015 at 5:50 PM, rakendra thapa
wrote:
> +1
> On Aug 24, 2015 9:13 PM, "Oleg Hahm" wrote:
>
>> Hi again!
>>
>> So, are there any objections about putting the following into the Wiki?
>> =
>> ## Guidelines for creating a good Pull Request
>>
>> * The title and initial desc
Hi again!
So, are there any objections about putting the following into the Wiki?
=
## Guidelines for creating a good Pull Request
* The title and initial description of a Pull request should describe its
basic idea and what goal is intended to be achieved in a brief and
comprehensible ma
Moin,
Am 21.08.2015 um 09:52 schrieb Kaspar Schleiser:
This might speed up PR reviewing, but it slows PR creation. Let's not
So what.
(Less PRs into the pipe) - (more PRs out) = (less open PRs)
Just kidding... :-)
lose focus, we want to streamline RIOT development, not PR reviewing.
This
Hey,
On 08/21/15 11:35, Oleg Hahm wrote:
> Am I mistaken or do you react somehow allergic to the word "rule" here?
You might have nailed it.
Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Hey!
> Say I write a complex piece of code, add comments where I find them
> necessary. As I wrote the complex beast, I find everything "very clear".
> So I open the PR, and someone says "sorry I don't understand and
> documentation is missing".
>
> So I improve documentation and try to clarify
Hey,
On 08/21/15 11:01, Emmanuel Baccelli wrote:
> One argument for decently documented/explained code is
Do I sound like I want to write complex, undocumented code?
I just don't agree with a "rule" requiring a PR to have perfect
documentation before even opening it.
Documented code (might be s
One argument for decently documented/explained code is that it is not only
for the reviewer(s) before merging, but for ALL the people who will look at
the code and try to understand/modify/extend it AFTER it's been merged...
That's potentially a LOT of people... and a lot of problems down the road,
Hey,
On 08/21/15 10:37, Oleg Hahm wrote:
> If the code is complex and poorly documented, it sucks. Full stop!
I agree 100%.
But as there are no simple metrics for "well documented" or even "easy
to understand" code, and we can't even agree on "goto vs do() while
(0)", I find it difficult to have
Hey,
On 08/21/15 10:55, Oleg Hahm wrote:
>> @Oleg: Maybe we should continue discussing offline. I choose a baseball bat.
>
> I choose a wasp's nest!
Aaah! That's the problem of pissing off good friends: they know you
too well...
Kaspar
___
devel m
> @Oleg: Maybe we should continue discussing offline. I choose a baseball bat.
I choose a wasp's nest!
--
You can already run chrome with --enable-quic switch to enable it and go to
chrome://net-internals/#quic to see nothing.
signature.asc
Description: PGP signature
___
Hey,
On 08/21/15 10:37, Oleg Hahm wrote:
> Now it's up to me to ask: are you trying to piss me off?
For the record, Oleg and I are very good friends and usually spend
awesome time together and we like discussing, so if the tone between us
seems to get rude, we know each other well enough to handl
Hi!
> This seems like a huge burden to developers writing non-trivial code.
> What does "very clear" mean?
>
> Proper reviewing includes reading and understanding the actual code. If
> code is unclear, reviewers ask for clarification. Now, apart from a
> concept that has been approved, perfect do
Hi Cenk again!
> Out of curiosity (and maybe to state the obvious):
> The rules you proposed would forbid WIP pull requests, right?
No, as Martine stated, I don't see a reason why this should prevent WIP PRs.
However, in my personal work flow I handle WIP PRs similar to Martine: mostly
ignore the
Hi Cenk!
> I like your proposed guideline.
Thanks!
> What's your opinion on adding some words about logically splitting a PR
> across several commits. I always like it when a PR contains 1 commit for the
> new feature / bugfix and 1 commit for new/modified (unit)tests. This way I
> can review t
Hey,
On 08/20/15 16:46, Oleg Hahm wrote:
> * The provided code and its documentation should make it very clear how this
> goal is intended to be solved.
This seems like a huge burden to developers writing non-trivial code.
What does "very clear" mean?
Proper reviewing includes reading and unde
Hi Cenk,
2015-08-20 21:18 GMT+02:00 Cenk Gündogan :
> Hi Oleg,
>
> Out of curiosity (and maybe to state the obvious):
> The rules you proposed would forbid WIP pull requests, right?
How did you come to this implication? If one marks a PR as WIP (either by
label because they are able to, or by s
Hi,
+1 for your guideline (though I really need to put some work into point s 1
and 3 ^^).
On the somewhat-positive-feedback-side for the maintainers and reviewers in
general: If I saw and remember correctly we, brought the number of open PRs
of ~170 in the last few weeks finally down to ~140 aga
Hi Oleg,
Out of curiosity (and maybe to state the obvious):
The rules you proposed would forbid WIP pull requests, right?
On 20.08.2015 19:10, Cenk Gündogan wrote:
Hey Oleg,
I like your proposed guideline.
What's your opinion on adding some words about logically splitting a
PR across several
Hey Oleg,
I like your proposed guideline.
What's your opinion on adding some words about logically splitting a PR
across several commits. I always like it when a PR contains 1 commit for
the new feature / bugfix and 1 commit for new/modified (unit)tests. This
way I can review them separately
Dear requesting IoTlers,
in order to improve and hopefully speed up the Pull request/review process, I
think it would be beneficial to describe in a better defined way how a Pull
request should be created and maintained. Therefore, I plan to put the
following rules into the wiki:
* The title and
28 matches
Mail list logo
