[PATCH rtems-docs] eng: Add rules for attribution
Christian MAUDERER
christian.mauderer at embedded-brains.de
Tue Sep 28 13:11:59 UTC 2021
Hello Joel,
Am 28.09.21 um 14:48 schrieb Joel Sherrill:
>
>
> On Tue, Sep 28, 2021, 1:40 AM Christian MAUDERER
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> Hello Joel,
>
> Am 28.09.21 um 01:12 schrieb Joel Sherrill:
> > The Microblaze port is interesting for attribution. I did initial
> work
> > on it. Hesham added to that and got Hello on a board. Alex is
> close to
> > submitting the port in a nice state.
> >
> > This is almost seven years across three developers.. The original
> work
> > predates source code reorganisation. Alex deleted the autoconf
> support
> > and created waf. Hesham and I agreed to convert to BSD-2.
> >
> > When submitted, we decided it was best for Alex to submit a Joel
> patch,
> > then Hesham, then Alex to finish it off. This keeps git blame
> working.
> >
> > Not quite the same topic but related to credit due.
>
> But maybe an important extension. Should we replace "sponsored" with
> "sponsored or supported"? That would allow to mention anyone who helps
> in any way, regardless whether it's financial, with information, with
> hobby time or with whatever else.
>
>
> I usually use the word sponsored. Support implies commercial activities
> the way I/we tend to use it.
>
Seems that I picked the wrong word then. Maybe you can help me finding
the correct term:
The one case is clear: Someone pays that someone else develops for
example a driver. I think for that "sponsored" is a good term.
Another similar case could be the following: You get help with writing a
driver for example with information or some other form of help that
doesn't result in a copyright for that person or company. It doesn't
involve money or some other form of payment (T-shirts, pizza, ...) so
it's not really sponsoring. Despite that it might would be nice to
mention them if they want to be mentioned. I think the right location
would be the same place like the one we just discuss for sponsoring.
What would be a good term for that?
Best regards
Christian
>
> >
> >
> > On Mon, Sep 27, 2021, 9:49 AM Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> > <mailto:christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>>> wrote:
> >
> > This adds some rules how an attribution for sponsored
> development should
> > look like.
> > ---
> >
> > Note: This patch is more or less an early draft. See the
> following
> > discussion
> > for more background:
> >
> >
> https://lists.rtems.org/pipermail/devel/2021-September/069465.html
> <https://lists.rtems.org/pipermail/devel/2021-September/069465.html>
> >
> <https://lists.rtems.org/pipermail/devel/2021-September/069465.html <https://lists.rtems.org/pipermail/devel/2021-September/069465.html>>
> >
> > Points that need discussion:
> >
> > * Are there some areas where we don't want to have
> attribution lines
> > (Chris
> > asked about score in the linked discussion). From my point of
> > view: If there
> > is a big contribution and the sponsor wants his name in the
> > (changed) files,
> > that's OK.
> >
> > * Do we want attributions in documentation sources? I'm not sure
> > whether they
> > might end in HTML comments in the distributed documentation.
> >
> >
> > So far, not enough small has been submitted to matter.
> >
> > I'm happy with a master list
>
> So for documentation it would be one SUPPORTERS file that isn't
> processed in any way?
>
> >
> >
> > * What kind of format do we want in the documentation?
> Restructured Text
> > documentation suggests that the two dots should be on a
> separate
> > line to avoid
> > interpreting the comment as directive:
> >
> https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments
> <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments>
> >
> <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#comments>>
> >
> > * Do we need some kind of "signed off" from the sponsor (or
> similar)
> > in the
> > commits that add attribution so that we can later tell who
> said
> > that it is OK
> > that we mention the sponsor?
> >
> >
> > We've done this on trust for a long time but wouldn't git blame
> tell us
> > the same? If it is a manager without git, then what?
> >
>
> Hm. Good questions.
>
> What I wanted to tell is: Do we need to document who allowed us to
> mention the company name?
>
> "git blame" won't tell the same. It would only tell who added the line
> "sponsored by Some Company". In most cases that will be the developer
> working on it and not the one from "Some Company" who said that we can
> add the name.
>
> You are right that a manager without git has problems adding the signed
> off line in the "official" git form. But git comments are free text
> anyway. I think a "signed off" line is based on trust like everything
> else in git. It more or less means: The one who pushes the patch has
> some when asked the person whether the patch is OK. We can also add it
> as a free text comment like "Some Company added with friendly
> permission
> by Some Person".
>
> I'm not sure whether it's an advantage to add something like that or
> whether it's unnecessary bureaucracy.
>
> Best regards
>
> Christian
>
> >
> > I'm sure there are some more points. Please feel free to ask.
> Again:
> > This is a
> > draft.
> >
> > Best regards
> >
> > Christian
> >
> > eng/coding-file-hdr.rst | 48
> +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
> > index 3167670..da6f702 100644
> > --- a/eng/coding-file-hdr.rst
> > +++ b/eng/coding-file-hdr.rst
> > @@ -2,6 +2,7 @@
> >
> > .. Copyright (C) 2018, 2020 embedded brains GmbH
> > (http://www.embedded-brains.de
> <http://www.embedded-brains.de> <http://www.embedded-brains.de
> <http://www.embedded-brains.de>>)
> > .. Copyright (C) 2018, 2020 Sebastian Huber
> > +.. Copyright (C) 2021 Christian Mauderer
> >
> > .. _FileTemplates:
> >
> > @@ -74,6 +75,28 @@ Check the top-level :file:`COPYING` file
> of the
> > repository. If you are a new
> > copyright holder, then add yourself to the top of the list. If
> > your last year
> > of a substantial contribution changed, then please update your
> > copyright line.
> >
> > +.. _FileAttributionSponsor:
> > +
> > +Attribution for Sponsored Development
> > +-------------------------------------
> > +
> > +A lot of development in RTEMS is sponsored by some users. If the
> > sponsor wants
> > +to be mentioned in the code, apply the following rules:
> > +
> > +* The attribution has to be a separate comment block below the
> > copyright block.
> > +
> > +* Only the name of the sponsoring company / person should be
> > mentioned. No
> > + contact details like URLs, email, phone numbers or street
> > addresses should be
> > + added.
> > +
> > +* To avoid unnecessary commits, the name of a sponsor is not
> > updated if (for
> > + example) the name of a company changes. The only reasonable
> > change would be if
> > + a sponsor continues to pay for bigger changes in that file
> anyway.
> > +
> > +* Sponsor names are only added to files which contain relevant
> > amounts of
> > + sponsored work. As a rule of thumb: If the work justifies
> adding
> > a copyright
> > + line, it also justifies adding a sponsor line.
> > +
> > .. _CCXXHeaderFileTemplate:
> >
> > C/C++ Header File Template
> > @@ -96,6 +119,8 @@ Use the following guidelines and template
> for C
> > and C++ header files (here
> > * Separate the Doxygen comment block from the copyright and
> > license, so that
> > the copyright and license information is not included in the
> > Doxygen output.
> >
> > +* If there is a sponsor: Add it as a separate comment block.
> > +
> > * For C++ header files discard the ``extern "C"`` start and end
> > sections.
> >
> > .. code-block:: c
> > @@ -137,6 +162,12 @@ Use the following guidelines and
> template for C
> > and C++ header files (here
> > * POSSIBILITY OF SUCH DAMAGE.
> > */
> >
> > + /*
> > + * Initial foo bar implementation sponsored by Example Inc.
> > + *
> > + * Baz feature sponsored by Some LLC.
> > + */
> > +
> > #ifndef _FOO_BAR_BAZ_H
> > #define _FOO_BAR_BAZ_H
> >
> > @@ -204,6 +235,12 @@ and <COPYRIGHT HOLDER> placeholders see
> > :ref:`FileHeaderCopyright`.
> > * POSSIBILITY OF SUCH DAMAGE.
> > */
> >
> > + /*
> > + * Initial foo bar implementation sponsored by Example Inc.
> > + *
> > + * Baz feature sponsored by Some LLC.
> > + */
> > +
> > #ifdef HAVE_CONFIG_H
> > #include "config.h"
> > #endif
> > @@ -251,6 +288,10 @@ block. RTEMS uses ``"""`` for Python
> docstrings.
> > # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> EVEN IF
> > ADVISED OF THE
> > # POSSIBILITY OF SUCH DAMAGE.
> >
> > + # Initial foo bar implementation sponsored by Example Inc.
> > + #
> > + # Baz feature sponsored by Some LLC.
> > +
> > If the Python source file is a command line command add the
> > following as the
> > first line of the file:
> >
> > @@ -302,6 +343,10 @@ accept a ``#``-style comment block. For the
> > <FIRST YEAR>, <LAST YEAR>, and
> > # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> EVEN IF
> > ADVISED OF THE
> > # POSSIBILITY OF SUCH DAMAGE.
> >
> > + # Initial foo bar implementation sponsored by Example Inc.
> > + #
> > + # Baz feature sponsored by Some LLC.
> > +
> > reStructuredText File Template
> > ------------------------------
> >
> > @@ -314,3 +359,6 @@ Use the following template for
> reStructuredText
> > (reST) source files. For the
> > .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> > .. Copyright (C) <FIRST YEAR>, <LAST YEAR> <COPYRIGHT
> HOLDER>
> > +
> > + ..
> > + Documentation of foo bar feature sponsored by Example
> Inc.
> > --
> > 2.31.1
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org> <mailto:devel at rtems.org
> <mailto:devel at rtems.org>>
> > http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> > <http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>>
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> phone: +49-89-18 94 741 - 18
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> <https://embedded-brains.de/datenschutzerklaerung/>
>
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list