Re: [riot-devel] Fragmentation support in IP

[Martine Lenders]

Hi Adeel,
What do you mean by "lost fragment recovery"? To my knowledge there is no
such thing in 6LoWPAN fragmentation.

Regards,
Martine

Am 19.08.2016 12:59 vorm. schrieb "Adeel Mohammad Malik" <
adeel.mohammad.ma...@ericsson.com>:

> Hi again Thomas,
>
> Do you mean that 6LoWPAN in RIOT does not support lost fragment recovery?
> Assuming it does, what I had in mind was that we could segment data in the
> application to the IP MTU and leverage the lost fragment recovery feature
> in 6LoWPAN to get a decent performance. This way we may not need to
> implement lost segment recovery in the application. But if 6LoWPAN in RIOT
> does not support recovery of lost fragments we might as well run our
> application direclty on link layer (since we dont need IP routing).
>
> /Adeel
>  Original message 
> From: "Thomas C. Schmidt" 
> Date: 8/18/2016 23:27 (GMT+01:00)
> To: RIOT OS kernel developers 
> Cc: Börje Ohlman , Joakim Borgh <
> joakim.bo...@ericsson.com>
> Subject: Re: [riot-devel] Fragmentation support in IP
>
> Hi Adeel,
>
> adding to this: you should keep in mind that in LowPANs you may easily
> trigger multiple layers of fragmentation (loosing one fragment is
> loosing all!) ... and that receivers may not be ready to handle UDP
> datagrams of 'arbitrary' sizes.
>
> So if you really want to stay away from upper layer protocols like CoAP,
> you should process data segmentation in your application (not sure this
> is the best idea, though).
>
> Cheers,
>   Thomas
>
> On 18.08.2016 22:54, Carsten Bormann wrote:
> > Hi Adeel,
> >
> > IP fragmentation is usually a bad idea*), and more so on a constrained
> > network.  If you need to transfer payloads beyond a kilobyte or so,
> > maybe CoAP (RFC 7252) with the block-wise transfer protocol (currently
> > being published as RFC-to-be 7959) solves your problem.
> >
> > Which encryption expands a few bytes of plaintext to kilobytes of
> > ciphertext?  (You may be thinking about signatures; e.g., hash-based
> > signatures can be 3-6 KiB or even more.  These might occur in firmware
> > updates and are covered quite well by CoAP + block-wise.)
> >
> > Grüße, Carsten
> >
> > *)
> > https://tools.ietf.org/html/draft-mathis-frag-harmful-00
> > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
> >
> > Adeel Mohammad Malik wrote:
> >> Hi Thomas,
> >>
> >> I agree that IP fragmentation is not an equivalent for data streaming.
> >> However it still facilitates transporting data that exceeds the MTU. The
> >> use case we are looking at is encryption of IoT data that may result in
> >> a few bytes of plaintext being converted to a few kilobytes of
> >> ciphertext. Had IP supported fragmentation in RIOT it would have been
> >> possible for us to send such data.
> >>
> >> /Adeel
> >>
> >>
> >>  Original message 
> >> From: "Thomas C. Schmidt" 
> >> Date: 8/18/2016 18:11 (GMT+01:00)
> >> To: devel@riot-os.org
> >> Subject: Re: [riot-devel] Fragmentation support in IP
> >>
> >> Hi Adeel,
> >>
> >> GNRC in RIOT supports fragmentation, e.g. in the context of 6LowPAN.
> >>
> >> However, you seem to be interested in sending UDP datagrams that exceed
> >> the MTU payload size. I don't think this is common use ... and I don't
> >> think this is clever, either. IP fragmentation is not an equivalent for
> >> data streaming.
> >>
> >> Cheers,
> >>   Thomas
> >>
> >> On 18.08.2016 18:04, Adeel Mohammad Malik wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> My question is about fragmentation support in IP in RIOT. Does IP in
> >>> RIOT support fragmentation? The use case I am after is transferring a
> >>> large blob of data (let’s say 5 kilobytes) on the UDP/IP stack in RIOT.
> >>> Is that possible?
> >>>
> >>>
> >>>
> >>> I know that 6LoWPAN supports fragmentation but that is below the IP
> >>> layer. I am interested in fragmentation at the IP layer so that
> >>> application running over it in RIOT can send large data.
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Adeel
> >>>
> >>
> >> --
> >>
> >> Prof. Dr. Thomas C. Schmidt
> >> ° Hamburg University of Applied Sciences   Berliner Tor
> 7 °
> >> ° Dept. Informatik, Internet Technologies Group20099 Hamburg,
> Germany °
> >> ° http://www.haw-hamburg.de/inet   Fon:
> +49-40-42875-8452 °
> >> ° http://www.informatik.haw-hamburg.de/~schmidtFax:
> +49-40-42875-8409 °
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> >>
> >> ___
> >> devel mailing list
> >> devel@riot-os.org
> >> https://lists.riot-os.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
>
> --
>
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences   Berliner Tor 7 °
> ° Dept. Informatik, Internet

Re: [riot-devel] Fragmentation support in IP

[Thomas C. Schmidt]

Hi Martine, Adeel,

there had been proposals in 6LowPan + Roll by Pascal Thubert for adding 
reliability to 6LowPan (recovering fragments) ... but if I see things 
correctly, they have never gotten anywhere -> Carsten?


In any case, the design discussion seems a bit out of focus: Whether to 
design a L2 protocol or an application layer (on top of CoAP) should be 
sorted out first. I guess these things depend on the problem scope and 
the objectives.


Cheers,
  Thomas

On 19.08.2016 09:56, Martine Lenders wrote:

Hi Adeel,
What do you mean by "lost fragment recovery"? To my knowledge there is
no such thing in 6LoWPAN fragmentation.

Regards,
Martine


Am 19.08.2016 12:59 vorm. schrieb "Adeel Mohammad Malik"
mailto:adeel.mohammad.ma...@ericsson.com>>:

Hi again Thomas,

Do you mean that 6LoWPAN in RIOT does not support lost fragment
recovery? Assuming it does, what I had in mind was that we could
segment data in the application to the IP MTU and leverage the lost
fragment recovery feature in 6LoWPAN to get a decent performance.
This way we may not need to implement lost segment recovery in the
application. But if 6LoWPAN in RIOT does not support recovery of
lost fragments we might as well run our application direclty on link
layer (since we dont need IP routing).

/Adeel
 Original message 
From: "Thomas C. Schmidt" mailto:t.schm...@haw-hamburg.de>>
Date: 8/18/2016 23:27 (GMT+01:00)
To: RIOT OS kernel developers mailto:devel@riot-os.org>>
Cc: Börje Ohlman mailto:borje.ohl...@ericsson.com>>, Joakim Borgh
mailto:joakim.bo...@ericsson.com>>
Subject: Re: [riot-devel] Fragmentation support in IP

Hi Adeel,

adding to this: you should keep in mind that in LowPANs you may easily
trigger multiple layers of fragmentation (loosing one fragment is
loosing all!) ... and that receivers may not be ready to handle UDP
datagrams of 'arbitrary' sizes.

So if you really want to stay away from upper layer protocols like
CoAP,
you should process data segmentation in your application (not sure this
is the best idea, though).

Cheers,
  Thomas

On 18.08.2016 22:54, Carsten Bormann wrote:
> Hi Adeel,
>
> IP fragmentation is usually a bad idea*), and more so on a constrained
> network.  If you need to transfer payloads beyond a kilobyte or so,
> maybe CoAP (RFC 7252) with the block-wise transfer protocol (currently
> being published as RFC-to-be 7959) solves your problem.
>
> Which encryption expands a few bytes of plaintext to kilobytes of
> ciphertext?  (You may be thinking about signatures; e.g., hash-based
> signatures can be 3-6 KiB or even more.  These might occur in firmware
> updates and are covered quite well by CoAP + block-wise.)
>
> Grüße, Carsten
>
> *)
> https://tools.ietf.org/html/draft-mathis-frag-harmful-00

> http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf

>
> Adeel Mohammad Malik wrote:
>> Hi Thomas,
>>
>> I agree that IP fragmentation is not an equivalent for data streaming.
>> However it still facilitates transporting data that exceeds the MTU. The
>> use case we are looking at is encryption of IoT data that may result in
>> a few bytes of plaintext being converted to a few kilobytes of
>> ciphertext. Had IP supported fragmentation in RIOT it would have been
>> possible for us to send such data.
>>
>> /Adeel
>>
>>
>>  Original message 
>> From: "Thomas C. Schmidt" mailto:t.schm...@haw-hamburg.de>>
>> Date: 8/18/2016 18:11 (GMT+01:00)
>> To: devel@riot-os.org 
>> Subject: Re: [riot-devel] Fragmentation support in IP
>>
>> Hi Adeel,
>>
>> GNRC in RIOT supports fragmentation, e.g. in the context of 6LowPAN.
>>
>> However, you seem to be interested in sending UDP datagrams that exceed
>> the MTU payload size. I don't think this is common use ... and I don't
>> think this is clever, either. IP fragmentation is not an equivalent for
>> data streaming.
>>
>> Cheers,
>>   Thomas
>>
>> On 18.08.2016 18:04, Adeel Mohammad Malik wrote:
>>> Hi all,
>>>
>>>
>>>
>>> My question is about fragmentation support in IP in RIOT. Does IP in
>>> RIOT support fragmentation? The use case I am after is transferring a
>>> large blob of data (let’s say 5 kilobytes) on the UDP/IP stack in RIOT.
>>> Is that possible?
>>>
>>>
>>>
>>> I know that 6LoWPAN supports fragmentation but that is below the IP
>>> layer. I am interested in fragmentation at the IP layer so that
>>> application running over it in RIOT can send large data.
>>>
>>>
>>>
>>> Regards,
>>>
>>> 

Re: [riot-devel] Fragmentation support in IP

[Oleg Hahm]

Hi Adeel,

On Thu, Aug 18, 2016 at 10:45:40PM +, Adeel Mohammad Malik wrote:
> We don't want to use CoAP as we are working with ICN (Information Centric
> Networking) protocols.

have you checked if fragmentation in CCN-lite works and would serve your
needs?

Cheers,
Oleg
-- 
printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good luck!\n",...);
linux-2.6.6/drivers/net/wan/lmc/lmc_main.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Fragmentation support in IP

[Adeel Mohammad Malik]

Hi Martine and Thomas,

Martine, actually when I wrote the question I did not mean to imply that the 
6LoWPAN standard has "lost fragment recovery". I did a quick search on it and I 
see no RFCs. Thanks for pointing it out.

Thomas, I agree that whether we do it on L2 or on the application layer depends 
on the problem scope. We are working on a prototype and would like to get 
things running with a decent performance in time. Hence the questions about 
what RIOT supports and what not. Perhaps we need to do some loss recovery 
implementation at the application layer to not have a poorly performing 
prototype.

/Adeel

> -Original Message-
> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Thomas C.
> Schmidt
> Sent: Friday, August 19, 2016 10:16 AM
> To: RIOT OS kernel developers
> Cc: Börje Ohlman; Joakim Borgh
> Subject: Re: [riot-devel] Fragmentation support in IP
> 
> Hi Martine, Adeel,
> 
> there had been proposals in 6LowPan + Roll by Pascal Thubert for adding
> reliability to 6LowPan (recovering fragments) ... but if I see things 
> correctly,
> they have never gotten anywhere -> Carsten?
> 
> In any case, the design discussion seems a bit out of focus: Whether to
> design a L2 protocol or an application layer (on top of CoAP) should be sorted
> out first. I guess these things depend on the problem scope and the
> objectives.
> 
> Cheers,
>Thomas
> 
> On 19.08.2016 09:56, Martine Lenders wrote:
> > Hi Adeel,
> > What do you mean by "lost fragment recovery"? To my knowledge there is
> > no such thing in 6LoWPAN fragmentation.
> >
> > Regards,
> > Martine
> >
> >
> > Am 19.08.2016 12:59 vorm. schrieb "Adeel Mohammad Malik"
> >  > >:
> >
> > Hi again Thomas,
> >
> > Do you mean that 6LoWPAN in RIOT does not support lost fragment
> > recovery? Assuming it does, what I had in mind was that we could
> > segment data in the application to the IP MTU and leverage the lost
> > fragment recovery feature in 6LoWPAN to get a decent performance.
> > This way we may not need to implement lost segment recovery in the
> > application. But if 6LoWPAN in RIOT does not support recovery of
> > lost fragments we might as well run our application direclty on link
> > layer (since we dont need IP routing).
> >
> > /Adeel
> >  Original message 
> > From: "Thomas C. Schmidt"  > >
> > Date: 8/18/2016 23:27 (GMT+01:00)
> > To: RIOT OS kernel developers  > >
> > Cc: Börje Ohlman  > >, Joakim Borgh
> > mailto:joakim.bo...@ericsson.com>>
> > Subject: Re: [riot-devel] Fragmentation support in IP
> >
> > Hi Adeel,
> >
> > adding to this: you should keep in mind that in LowPANs you may easily
> > trigger multiple layers of fragmentation (loosing one fragment is
> > loosing all!) ... and that receivers may not be ready to handle UDP
> > datagrams of 'arbitrary' sizes.
> >
> > So if you really want to stay away from upper layer protocols like
> > CoAP,
> > you should process data segmentation in your application (not sure this
> > is the best idea, though).
> >
> > Cheers,
> >   Thomas
> >
> > On 18.08.2016 22:54, Carsten Bormann wrote:
> > > Hi Adeel,
> > >
> > > IP fragmentation is usually a bad idea*), and more so on a constrained
> > > network.  If you need to transfer payloads beyond a kilobyte or so,
> > > maybe CoAP (RFC 7252) with the block-wise transfer protocol (currently
> > > being published as RFC-to-be 7959) solves your problem.
> > >
> > > Which encryption expands a few bytes of plaintext to kilobytes of
> > > ciphertext?  (You may be thinking about signatures; e.g., hash-based
> > > signatures can be 3-6 KiB or even more.  These might occur in firmware
> > > updates and are covered quite well by CoAP + block-wise.)
> > >
> > > Grüße, Carsten
> > >
> > > *)
> > > https://tools.ietf.org/html/draft-mathis-frag-harmful-00
> > 
> > > http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
> > 
> > >
> > > Adeel Mohammad Malik wrote:
> > >> Hi Thomas,
> > >>
> > >> I agree that IP fragmentation is not an equivalent for data 
> > streaming.
> > >> However it still facilitates transporting data that exceeds the MTU. 
> > The
> > >> use case we are looking at is encryption of IoT data that may result 
> > in
> > >> a few bytes of plaintext being converted to a few kilobytes of
> > >> ciphertext. Had IP supported fragmentation in RIOT it would have
> been
> > >> possible for us to send such data.
> > >>
> > >> /Adeel
> > >>
> > >>
> > >>  Original message 
> > >

Re: [riot-devel] Fragmentation support in IP

[Adeel Mohammad Malik]

Hi Oleg,

Yes I looked into it. It did not seem to work right away. Seems like we will 
have to dig deeper into it. With the time constraints we have, we have a 
decision to make whether to rely on chunking in CCN-lite or rely on 
fragmentation in CCN-lite. The fragmentation approach implemented in CCN-lite 
is the "Begin-End" Hop by Hop Fragmentation scheme 
(draft-mosko-icnrg-beginendfragment-01) which if I understand correctly does 
not support recovery of lost fragments. So it seems like a more riskier option 
in terms of how our prototype will perform compared to using chunking in 
CCN-lite. With chunking we can retransmit only the lost chunk unlike 
fragmentation where a lost fragment will mean retransmitting the whole CCN 
object.

/Adeel

> -Original Message-
> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Oleg Hahm
> Sent: Friday, August 19, 2016 10:35 AM
> To: RIOT OS kernel developers
> Cc: Börje Ohlman; Joakim Borgh
> Subject: Re: [riot-devel] Fragmentation support in IP
> 
> Hi Adeel,
> 
> On Thu, Aug 18, 2016 at 10:45:40PM +, Adeel Mohammad Malik wrote:
> > We don't want to use CoAP as we are working with ICN (Information
> > Centric
> > Networking) protocols.
> 
> have you checked if fragmentation in CCN-lite works and would serve your
> needs?
> 
> Cheers,
> Oleg
> --
> printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good
> luck!\n",...);
> linux-2.6.6/drivers/net/wan/lmc/lmc_main.c
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Thread stack size in RIOT

[Adeel Mohammad Malik]

Hi,

I would like to know if there is a way in RIOT to define different thread stack 
sizes in RIOT for different threads. The thread size is defined here 
https://github.com/RIOT-OS/RIOT/blob/master/cpu/cortexm_common/include/cpu_conf_common.h#L44.

Regards,
Adeel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Thread stack size in RIOT

[Kaspar Schleiser]

Hi,

On 08/19/2016 10:54 AM, Adeel Mohammad Malik wrote:
> I would like to know if there is a way in RIOT to define different thread 
> stack sizes in RIOT for different threads. The thread size is defined here 
> https://github.com/RIOT-OS/RIOT/blob/master/cpu/cortexm_common/include/cpu_conf_common.h#L44.

The only compile-time stack sizes are for ISRs, the main and the idle
thread. All other stack sizes get defined by passing parameters to
thread_create().

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Radio Modul Drivers - Initialization of Chip-Select-, Reset-, Sleep-, Interrupt-Pin of the MCU

[Neo]

Hello all together,
just a question for a better understanding of the initialization process:

I thought that the correct way to set up the MCU interface is to implement
an auto_init-function for the radio module. The MCU interface pins 
should be

setup during the auto-initialization. Is this correct?

I found the _init(netdev2_t *netdev) function in the _netdev.c
file and for me it looks like this is exactly the place where the 
initialization of

the pins are done. Is this correct?

While debugging a driver I set a breakpoint onto this function, but the 
breakpoint

is never reached.

Now my question: From where ist the _init function invoked? What is 
necessary

to force this initialization?

Best regards,
Neo


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] RFC: development procedures

[Oleg Hahm]

Dear reviewing IoTlers,

looking at https://github.com/RIOT-OS/RIOT/pull/5758, I just realized that our
convention to add squash commits while a PR is under review may need an
amendment. If all commits that addresses a certain comment and are meant for
squashing have a non-speaking commit message (see linked PR), then it gets
more time-consuming for the reviewer to map a commit to a certain
review-reaction. Hence, I would propose to somehow reference the addressed
comment in the commit message. What do you think?

Cheers,
Oleg
-- 
printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n");
linux-2.6.6/drivers/message/fusion/mptctl.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Kaspar Schleiser]

Hey,

On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> Hence, I would propose to somehow reference the addressed
> comment in the commit message. What do you think?

That would rule out --fixup commits (and thus automatic rebasing). "git
commit --squash" allows adding to the commit message, but the commit
subject stays the same, so in order to improve things, one would have to
unfold the whole message in git's PR overview.

(+1 in general...)

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi!

On Fri, Aug 19, 2016 at 05:25:32PM +0200, Kaspar Schleiser wrote:
> On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> > Hence, I would propose to somehow reference the addressed
> > comment in the commit message. What do you think?
> 
> That would rule out --fixup commits (and thus automatic rebasing). "git
> commit --squash" allows adding to the commit message, but the commit
> subject stays the same, so in order to improve things, one would have to
> unfold the whole message in git's PR overview.

Actually, I've never found a big advantage in automatic rebasing. If you
specify both, the addressed comment and the corresponding commit in the commit
message, interactive rebasing can be done in no time.

A potential other solution would be to use something like Gerrit, but I guess
no one here wants this. ;-)

Cheers,
Oleg
-- 
The best thing about script jokes is that they start with a bang.


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Martine Lenders]

Hi,

2016-08-19 17:25 GMT+02:00 Kaspar Schleiser :

> Hey,
>
> On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> > Hence, I would propose to somehow reference the addressed
> > comment in the commit message. What do you think?
>
> That would rule out --fixup commits (and thus automatic rebasing). "git
> commit --squash" allows adding to the commit message, but the commit
> subject stays the same, so in order to improve things, one would have to
> unfold the whole message in git's PR overview
>

Not necessarily. I would put such links to comments in the commit body
anyway and that is ignored by --autosquash.


> (+1 in general...)
>

+1 from my side too.

2016-08-19 17:39 GMT+02:00 Oleg Hahm :

> Actually, I've never found a big advantage in automatic rebasing. If you
> specify both, the addressed comment and the corresponding commit in the
> commit
> message, interactive rebasing can be done in no time.
>

Well you still have to read and compare every single commit, which
--autosquash just takes a way. So you still need way more time. ;-)

Regards,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Kaspar Schleiser]

Hey,

On 08/19/2016 05:54 PM, Martine Lenders wrote:
> Not necessarily. I would put such links to comments in the commit body
> anyway and that is ignored by --autosquash.

Not necessarily what?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Martine Lenders]

Hi,

Am 19.08.2016 7:51 nachm. schrieb "Kaspar Schleiser" :
>
> Hey,
>
> On 08/19/2016 05:54 PM, Martine Lenders wrote:
> > Not necessarily. I would put such links to comments in the commit body
> > anyway and that is ignored by --autosquash.
>
> Not necessarily what?

Rule out --fixup commits
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Kaspar Schleiser]

how do you put a link in the body of a --fixup-commi?

-Original Message-
From: Martine Lenders 
To: RIOT OS kernel developers 
Sent: Fr., 19 Aug. 2016 20:06
Subject: Re: [riot-devel] RFC: development procedures

Hi,

Am 19.08.2016 7:51 nachm. schrieb "Kaspar Schleiser" :
>
> Hey,
>
> On 08/19/2016 05:54 PM, Martine Lenders wrote:
> > Not necessarily. I would put such links to comments in the commit body
> > anyway and that is ignored by --autosquash.
>
> Not necessarily what?

Rule out --fixup commits
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi,

On Fri, Aug 19, 2016 at 05:54:07PM +0200, Martine Lenders wrote:
> 2016-08-19 17:25 GMT+02:00 Kaspar Schleiser :
> > On 08/19/2016 05:15 PM, Oleg Hahm wrote:
> > > Hence, I would propose to somehow reference the addressed
> > > comment in the commit message. What do you think?
> >
> > That would rule out --fixup commits (and thus automatic rebasing). "git
> > commit --squash" allows adding to the commit message, but the commit
> > subject stays the same, so in order to improve things, one would have to
> > unfold the whole message in git's PR overview
> >
> 
> Not necessarily. I would put such links to comments in the commit body
> anyway and that is ignored by --autosquash.

hm, that makes it rather inconvenient to review - particular with the "new"
shitty GitHub UI.
 
> > Actually, I've never found a big advantage in automatic rebasing. If you
> > specify both, the addressed comment and the corresponding commit in the
> > commit
> > message, interactive rebasing can be done in no time.
> >
> 
> Well you still have to read and compare every single commit, which
> --autosquash just takes a way. So you still need way more time. ;-)

Yes, it takes more time, but just a few seconds if the commit messages are
sensible. I never use autosquashing.

Cheers,
Oleg
-- 
panic("bad_user_access_length executed (not cool, dude)");
linux-2.0.38/kernel/panic.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Kaspar Schleiser]

Hi,

On 08/19/2016 08:05 PM, Martine Lenders wrote:
>>> Not necessarily. I would put such links to comments in the commit body
>>> anyway and that is ignored by --autosquash.
>>
>> Not necessarily what?
> 
> Rule out --fixup commits

Did you read my email? You cannot change the commit message of --fixup
commits - it is always "!fixup "
without body. You can add a body when using "--squash" (the subject will
always be "!squash ", but that body would always get
folded away by the github interface. If anyone would like to see a
comment you've added to such a commit, you have to press the little
"..." icon.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Martine Lenders]

Hi Kaspar,

2016-08-19 22:34 GMT+02:00 Kaspar Schleiser :

> Hi,
>
> On 08/19/2016 08:05 PM, Martine Lenders wrote:
> >>> Not necessarily. I would put such links to comments in the commit body
> >>> anyway and that is ignored by --autosquash.
> >>
> >> Not necessarily what?
> >
> > Rule out --fixup commits
>
> Did you read my email? You cannot change the commit message of --fixup
> commits - it is always "!fixup "
> without body. You can add a body when using "--squash" (the subject will
> always be "!squash ", but that body would always get
> folded away by the github interface. If anyone would like to see a
> comment you've added to such a commit, you have to press the little
> "..." icon.
>

Yes, that's true (somehow I overread that important part O_o)... But I
don't really see it as an inconvenience as long as the information is there.

Oleg Hahm wrote:
> Yes, it takes more time, but just a few seconds if the commit messages are
sensible. I never use autosquashing.

You should try it, its REEAAALLY convenient.

Hm, ... maybe there is a way to provide some hooks that can do all this
(edit --fixup message, use hash instead of message of original commit,
change rebase -i --autosquash so it greps commit hashes instead of commit
messages). If I find time I will look into it after the weekend.

Cheers,
Martine
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RFC: development procedures

[Oleg Hahm]

Hi Martine!

On Fri, Aug 19, 2016 at 10:53:49PM +0200, Martine Lenders wrote:
> Oleg Hahm wrote:
> > Yes, it takes more time, but just a few seconds if the commit messages are
> sensible. I never use autosquashing.
> 
> You should try it, its REEAAALLY convenient.

I did some time ago and couldn't see a big advantage and prefer meaningful
commit messages.

Cheers,
Oleg
-- 
panic("Halt failed!");
linux-2.6.6/arch/sparc/kernel/process.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel