As long, as there is something under the old url, I'm fine with it.
Apart from that, I don't really see a real benefit from moving
stuff around. I fear it will create more confusion as it is worth.
Greetings
Janosch
On 29.05.2017 15:27, Sylvain Joyeux wrote:
>> move only the entry in the package set, but leave the repos were they
> are, please.
>
> Why ? GitHub redirects the old URLs to the new ones, and so far all
> packages in rock-core are within the rock-core organization ...
> Starting to randomly have packages spread around wouldn't sound like a
> great idea to me ...
>
> If you're really afraid that the URLs stop working, we could move the
> repo and create a read-only fork of it on the old place.
>
> Sylvain
>
> On Sun, May 28, 2017 at 2:26 PM, Janosch Machowinski
> <janosch.machowin...@dfki.de> wrote:
>> Am 25.05.2017 um 14:57 schrieb Sylvain Joyeux:
>>> Since there is no other comments, I'll start by moving iodrivers_base
>>> to rock-core (package set and github).
>> move only the entry in the package set, but leave the repos were they
>> are, please.
>> Greetings
>> Janosch
>>> Sylvain
>>>
>>> On Thu, May 18, 2017 at 11:31 AM, Sylvain Joyeux <bir.sylv...@gmail.com>
>>> wrote:
>>>> I personally would prefer simply add versioning tags in the
>>>> manifest.xml, and make all packages available all the time.
>>>> Branching/splitting package sets is going to be a horrible mess, as
>>>> each release will become a major change in the git history. We've
>>>> tried that before, it just does not work (or, more accurately,
>>>> requires an amount of effort down the line that we simply don't have).
>>>>
>>>> Basically, a package is supported on a given Rock release if it has
>>>> the corresponding tag. It's up to the maintainer to update the tag.
>>>> The web page/rock-release/an autoproj v2 rock plugin would allow to
>>>> show this tag as "supported on this version or not".
>>>>
>>>> All packages are available all the time (until they are purely and
>>>> simply removed from the package sets because they're truly
>>>> unmaintained). This is actually very close to ROS: you're always
>>>> allowed to check out a package and install it. The only additional
>>>> info you have is whether the package maintainers considers the package
>>>> "maintained on this version of ROS".
>>>>
>>>> Sylvain
>>>>
>>>> On Thu, May 18, 2017 at 10:45 AM, Steffen Planthaber
>>>> <steffen.plantha...@dfki.de> wrote:
>>>>> Hi,
>>>>>
>>>>> At DFKI we were discussing a new release for quite some time and your
>>>>> proposal is very welcome.
>>>>>
>>>>> The result of our discussions was also that we should split rock-core
>>>>> releases from the rest.
>>>>>
>>>>> (Comments on your plan at the end).
>>>>>
>>>>> We also thought about how to "release" the rest of the packages, here is
>>>>> the idea (quite sililar to what ROS does), consider this a RFC:
>>>>>
>>>>> * Split the rock (not core) package_set into two sets:
>>>>> (maintained/unmaintained) both are specific to a single rock release
>>>>> (branch in the package_set?)
>>>>>
>>>>> * When a new rock release is available, all packages from maintained set
>>>>> of the old core version are moved to the unmaintained set of the new
>>>>> one, it gets a new, empty maitained package_set
>>>>>
>>>>> * To move a package from "unmaintained" to "maintained" set for a new
>>>>> release, the ->maintainer<- has to check his package against the new
>>>>> release, and create merge request to the maintained_set.This way, we can
>>>>> keep track of the actual maintainers of packages
>>>>>
>>>>> * Only the packages of the maintained set are checked by the
>>>>> buildserver/listed on the homepage and listed as "maintained there"
>>>>>
>>>>>
>>>>> Still, there is not much "plus" on having a own package in the
>>>>> maintained set, could still be that devs rather stay "unmaintained".
>>>>>
>>>>> We could also completely remove the "unmaintained" set and the package
>>>>> is just not available (commented out) for that release until checked.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 17.05.2017 um 16:16 schrieb Sylvain Joyeux:
>>>>>> I want to prepare a release of rock.core (and only rock.core), "in its
>>>>>> current state"
>>>>> I guess the new release will be based on the master branches as done in
>>>>> the past?
>>>>>
>>>>>> The only change I'd like to make is to add iodrivers_base and
>>>>>> orogen/iodrivers_base in rock.core, as they are quite ubiquitous.
>>>>>> Common core libraries like opencv and pcl should IMO also
>>>>> Sounds fine.
>>>>>
>>>>>> Further down the road, I intend to prepare such a release on a regular
>>>>>> basis (hopefully at most monthly for pure bugfixes and 3 months for
>>>>>> breaking changes). I also want to focus on rock-core passing its own
>>>>>> test suite(s) - which it currently does not. I originally wanted to do
>>>>>> it *before* releasing, but actually getting the tests to pass require
>>>>>> quite a bit of changes in the packages that see little-to-no
>>>>>> maintenance.
>>>>> Noble Goal ;-)
>>>>>
>>>>>> I also intend to gradually assign version numbers (hopefully following
>>>>>> a semantic-versioning like scheme), and provide proper changelogs on
>>>>>> each version.
>>>>> semantic-versioning is a good choice IMO.
>>>>>
>>>>>> Comments are welcome, as usual. Barring showstoppers on this plan,
>>>>>> I'll do the work in the next week(s)
>>>>> Thanks very much.
>>>>>
>>>>> Steffen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Sylvain
>>>>>> _______________________________________________
>>>>>> Rock-dev mailing list
>>>>>> Rock-dev@dfki.de
>>>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>>>>
>>>>> --
>>>>> Steffen Planthaber
>>>>> Weltraumrobotik
>>>>>
>>>>> 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-4125
>>>>> Zentrale: +49 421 178 45-0
>>>>> Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>>>>> E-Mail: steffen.plantha...@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
>>>>>
>>>>> -----------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Rock-dev mailing list
>>>>> Rock-dev@dfki.de
>>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev@dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev@dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
_______________________________________________
Rock-dev mailing list
Rock-dev@dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
