All of lore.kernel.org
 help / color / mirror / Atom feed
* Expressing linux-next collateral evolutions in formal grammar
@ 2012-11-02  3:09 Luis R. Rodriguez
  2012-11-02  9:48 ` Julia Lawall
  0 siblings, 1 reply; 2+ messages in thread
From: Luis R. Rodriguez @ 2012-11-02  3:09 UTC (permalink / raw)
  To: linux-kernel
  Cc: Stephen Rothwell, Julia Lawall, Konstantin Ryabitsev, backports

I think by now quite a few amount of folks understand that SmPL can be
used to express collateral evolutions for Linux kernel development.
Obviously some collateral evolutions are not expressed this way though
but Julia and her team have been working on research that would enable
for one to infer such SmPL grammar by analyzing deltas. There is a few
software tools now that start to do this and I think that to help with
reviewing changes it would help us in the community to spread more
education on SmPL grammar and to allow us to become more efficient at
reviewing changes. For a while now Julia has been working on getting
some form of SmPL grammar from linux-next git tag updates, from one
tag to the next. I toyed with Julia the idea recently of perhaps this
being useful to others and if we could point a link to these from lwn
or any other place. My hope would be that collateral evolutions then
would then be easily reviewable folks, in case one did not want to
read a full diff between the tags.

Technically one next tag from the other though are not a linear
evolutions though, so a proper evolution expression for a release
would be from mainline to that day's tag, however being able to
visualize a grammar on the evolutions would still be nice if possible
-- and I think it is. Wanted to review with you all the idea of
possibly linking to collateral evolutions in SmPL grammer from lwn, or
if perhaps kernel.org somewhere.

The way I would envision this to be easier to manage is to break them
down by subsystem and the reviewer can then go and read the grammar
for their own subsystem of preference. The long term benefit of this
is that even if folks don't use SmPL for collateral evolutions we have
a possibility here of being able to backport a collateral evolution by
using the inverse of the SmPL grammar, if we can get to the point of
coming up with formal and proper grammar on each collateral evolution.

Thoughts?

  Luis

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Expressing linux-next collateral evolutions in formal grammar
  2012-11-02  3:09 Expressing linux-next collateral evolutions in formal grammar Luis R. Rodriguez
@ 2012-11-02  9:48 ` Julia Lawall
  0 siblings, 0 replies; 2+ messages in thread
From: Julia Lawall @ 2012-11-02  9:48 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: linux-kernel, Stephen Rothwell, Konstantin Ryabitsev, backports

> The way I would envision this to be easier to manage is to break them
> down by subsystem and the reviewer can then go and read the grammar
> for their own subsystem of preference. The long term benefit of this
> is that even if folks don't use SmPL for collateral evolutions we have
> a possibility here of being able to backport a collateral evolution by
> using the inverse of the SmPL grammar, if we can get to the point of
> coming up with formal and proper grammar on each collateral evolution.
>
> Thoughts?

I had liked the idea of lwn, because that makes it public but doesn't 
bother anyone.  But another option would be to just send an email to the 
relevant maintainer?  Perhaps it would be better to send the email just 
to the specific maintainer for the file, and not all the way up the 
maintainer hierarchy, because these would be just suggestions of things to 
look at, and not actual patch proposals.

thanks,
julia

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-11-02  9:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-02  3:09 Expressing linux-next collateral evolutions in formal grammar Luis R. Rodriguez
2012-11-02  9:48 ` Julia Lawall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.