[Rock-dev] Draft of Github-based development process [IMPORTANT]

Discussion:

Sylvain Joyeux

2014-05-15 08:41:31 UTC

Since we were talking about setting up actual push permissions when moving
to github, I've drafted a "process with github" document.

PLEASE REVIEW

It will of course need to be updated as we go with it, but it is important
to have a consensus on at least the first version ...

http://rock.opendfki.de/wiki/WikiStart/Standards/RG9

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140515/76da3b49/attachment.htm

Alexander Duda

2014-05-15 09:31:30 UTC

Permalink

Sounds good to me.

Greets Alex

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140515/3becfecb/attachment.htm

Sylvain Joyeux

2014-05-15 10:18:47 UTC

Permalink

On Thu, May 15, 2014 at 11:53 AM, Jakob Schwendner <jakob.schwendner at dfki.de

Hi Sylvain,
in principle ok. I am not sure on the wording of the "owners" team. Maybe
management?

"Owners" is a default team in Github with all admin rights on an
organization ... Unfortunate name, but I would really not create a second
team with the same role.

This pulls up the question on the management of rock as a whole, not just
repo rights (but I guess its somehow mirrored).

Obviously. Now, I would do it "the open source way" and let those who code
speak for themselves, at least for now. This is why I personally want to
favor pull requests and the MLs for discussion *before* code gets merged,
in order to include as many interested parties as possible.

Also, I don't agree with the last section. I would not want to rule who
has committed the most in the dicision on who gets the rights.

I don't understand your last sentence ... Can you explain ?

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140515/ad3beae4/attachment.htm

Sylvain Joyeux

2014-05-15 11:04:24 UTC

Permalink

Hi

(Note: be careful, you reply only to me and not to the ML)

- I don't want to give the power to a few people to do this selection. It
will lead to bikeshed bitter arguments (why am I not included ? Why is Y
included I don't think he should ? It can get very personal very quickly).
Rock is not big enough to already start having an overseeing team. Let the
coding decide.
- people that have committed a lot are the ones that know the codebase, so
that is IMO the best people as a starting point
- this is an INITIAL list. Obviously, it will be updated over time. Now, I
would NOT add anybody in there that did not already contribute a
significant amount of code, simply because they are probably not familiar
with the codebase (and therefore is not suited to decide what to push or
not push there).

Sylvain

On Thu, May 15, 2014 at 12:37 PM, Jakob Schwendner <jakob.schwendner at dfki.de

Also, I don't agree with the last section. I would not want to

rule who

has committed the most in the dicision on who gets the rights.
I don't understand your last sentence ... Can you explain ?

In the text you suggest using the numbers on who commited the most to give
out commit rights.
Quantity is not quality, and I would argue its better to select these
people. These decisions should come from a management team.
Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140515/cac54be6/attachment.htm

Sylvain Joyeux

2014-05-15 12:22:02 UTC

Permalink

OK ... Maybe I got the confusion.

I wrote it down as if it was how the team was going to be maintained, while
in my mind it was the way to create the initial list. I've updated the page
in this direction.

However, I do stand against the idea of having a dedicated management team.
We are way too small to have some kind of a steering comittee.

Post by Sylvain Joyeux
Hi
(Note: be careful, you reply only to me and not to the ML)
- I don't want to give the power to a few people to do this selection. It
will lead to bikeshed bitter arguments (why am I not included ? Why is Y
included I don't think he should ? It can get very personal very quickly).
Rock is not big enough to already start having an overseeing team. Let the
coding decide.
- people that have committed a lot are the ones that know the codebase,
so that is IMO the best people as a starting point
- this is an INITIAL list. Obviously, it will be updated over time. Now,
I would NOT add anybody in there that did not already contribute a
significant amount of code, simply because they are probably not familiar
with the codebase (and therefore is not suited to decide what to push or
not push there).
Sylvain
On Thu, May 15, 2014 at 12:37 PM, Jakob Schwendner <

Also, I don't agree with the last section. I would not want to

rule who

has committed the most in the dicision on who gets the rights.
I don't understand your last sentence ... Can you explain ?

In the text you suggest using the numbers on who commited the most to
give out commit rights.
Quantity is not quality, and I would argue its better to select these
people. These decisions should come from a management team.
Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140515/7399ff7f/attachment.htm

Sylvain Joyeux

2014-05-16 12:43:45 UTC

Permalink

Hi Jakob.

Does the updated document look better to you ?

Sylvain

Post by Sylvain Joyeux
OK ... Maybe I got the confusion.
I wrote it down as if it was how the team was going to be maintained,
while in my mind it was the way to create the initial list. I've updated
the page in this direction.
However, I do stand against the idea of having a dedicated management
team. We are way too small to have some kind of a steering comittee.

Post by Sylvain Joyeux
Hi
(Note: be careful, you reply only to me and not to the ML)
- I don't want to give the power to a few people to do this selection.
It will lead to bikeshed bitter arguments (why am I not included ? Why is Y
included I don't think he should ? It can get very personal very quickly).
Rock is not big enough to already start having an overseeing team. Let the
coding decide.
- people that have committed a lot are the ones that know the codebase,
so that is IMO the best people as a starting point
- this is an INITIAL list. Obviously, it will be updated over time. Now,
I would NOT add anybody in there that did not already contribute a
significant amount of code, simply because they are probably not familiar
with the codebase (and therefore is not suited to decide what to push or
not push there).
Sylvain
On Thu, May 15, 2014 at 12:37 PM, Jakob Schwendner <

Also, I don't agree with the last section. I would not want to

rule who

has committed the most in the dicision on who gets the rights.
I don't understand your last sentence ... Can you explain ?

In the text you suggest using the numbers on who commited the most to
give out commit rights.
Quantity is not quality, and I would argue its better to select these
people. These decisions should come from a management team.
Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140516/563d32bf/attachment.htm

Javier Hidalgo Carrió

2014-05-19 07:16:05 UTC

Permalink

Post by Sylvain Joyeux
Since we were talking about setting up actual push permissions when
moving to github, I've drafted a "process with github" document.
PLEASE REVIEW
It will of course need to be updated as we go with it, but it is
important to have a consensus on at least the first version ...
http://rock.opendfki.de/wiki/WikiStart/Standards/RG9

It looks nice to me!

Javier.

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140519/252bb7d9/attachment.htm

Sylvain Joyeux

2014-05-22 12:33:29 UTC

Permalink

One other idea:

Instead of keeping rock-base and rock-toolchain separated, I would like to
keep the "core" packages into a single rock-core organization. I think it
would really make a lot more sense from an organization point of view. The
core packages that are currently not in rock-toolchain (aggregator,
transformer, vizkit*) could be moved there as well.

In addition, I would like to merge the two package sets. We would then have
a rock.core package set that defines a rock.base and rock.toolchain
metapackages so that people can build without the toolchain.

Thoughts ?

Post by Sylvain Joyeux
Since we were talking about setting up actual push permissions when moving
to github, I've drafted a "process with github" document.
PLEASE REVIEW
It will of course need to be updated as we go with it, but it is important
to have a consensus on at least the first version ...
http://rock.opendfki.de/wiki/WikiStart/Standards/RG9
Sylvain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140522/449824a3/attachment.htm

Alexander Duda

2014-05-22 13:34:17 UTC

Permalink

Post by Sylvain Joyeux
Instead of keeping rock-base and rock-toolchain separated, I would
like to keep the "core" packages into a single rock-core organization.
I think it would really make a lot more sense from an organization
point of view. The core packages that are currently not in
rock-toolchain (aggregator, transformer, vizkit*) could be moved there
as well.
In addition, I would like to merge the two package sets. We would then
have a rock.core package set that defines a rock.base and
rock.toolchain metapackages so that people can build without the
toolchain.
Thoughts ?

Is there a real use case for using rock.base without rock.toolchain? I
guess if someone only wants to build a driver library he is not going to
use autoproj in the first place. Or do we need the separation to build
Debian packages?

Alex

Post by Sylvain Joyeux
On Thu, May 15, 2014 at 10:41 AM, Sylvain Joyeux
Since we were talking about setting up actual push permissions
when moving to github, I've drafted a "process with github" document.
PLEASE REVIEW
It will of course need to be updated as we go with it, but it is
important to have a consensus on at least the first version ...
http://rock.opendfki.de/wiki/WikiStart/Standards/RG9
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140522/a065d0dc/attachment.htm

Sylvain Joyeux

2014-05-22 18:54:12 UTC

Permalink

I sometimes bootstrap only a rock.base when I don't need the toolchain. The
toolchain takes long to build ... So I would definitely keep it around.

The new scheme would add rock.core for base+toolchain

Sylvain

Post by Sylvain Joyeux
Instead of keeping rock-base and rock-toolchain separated, I would like to
keep the "core" packages into a single rock-core organization. I think it
would really make a lot more sense from an organization point of view. The
core packages that are currently not in rock-toolchain (aggregator,
transformer, vizkit*) could be moved there as well.
In addition, I would like to merge the two package sets. We would then
have a rock.core package set that defines a rock.base and rock.toolchain
metapackages so that people can build without the toolchain.
Thoughts ?
Is there a real use case for using rock.base without rock.toolchain? I
guess if someone only wants to build a driver library he is not going to
use autoproj in the first place. Or do we need the separation to build
Debian packages?
Alex

_______________________________________________
Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140522/4769e02e/attachment-0001.htm

Thomas Roehr

2014-05-23 10:43:10 UTC

Permalink

Thx for drafting. Looks good to me.

Thomas

--
Thomas R?hr (M.Sc.)
Space Robotics

Besuchsadresse der Nebengesch?ftstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Postadresse der Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4151
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: thomas.roehr at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/619b0758/attachment.htm