[Rock-dev] Proposal: the next Rock release

[Janosch Machowinski]

On 18.07.2014 22:06, Sylvain Joyeux wrote:
> More thoughts ...
>
> On Thu, Jul 17, 2014 at 11:14 PM, Janosch Machowinski
> <Janosch.Machowinski at dfki.de> wrote:
>> - Create an (example name) 0714_RC1 Branch from Master of all packets
>> - If someone does not want his master commits on the release, he/she
>> reverts them
>>    on the RC Branch
> This is hell. We'll get widely diverging branches or non-fast-forwards
> (i.e. people will have to force-push to their branch)
Hm ? As it is a seperate branch, people can just use git revert...
>
> I personally really would like to think separately about rock.core and
> rock. The way ROS does is have the 'ros core' managed by the ROS
> maintainers, and having the package maintainers in charge of the
> non-core parts. This makes sure that the maintainers are aware about
> what happens to their packages.
I would prefer to have as many packages released together.
The thought here is, that any package that is in the release
is tested (or compiles at least), and should not create any issues.
If we put e.g. the driver package outside of the branch system,
we run in the same problems as now, as their master branch could
depend on changes that are not in the 'core' release.
>
> The same way we have the 'stable' tag, I would prefer having an easy
> way for the package maintainers to tell "yes, this package can go on
> release X" and have an automated mechanism that does so.
The stable tag never had a meaning regarding stability of the package
for me. It was just compile as release, or as debug.
>
>> - Change all packet sets, to have also branches / Remove this
>> in_flavor_stable stuff
> Branching the package sets is problematic (this is why we got the
> flavor system as it is right now, we *were* branching before). The
> problem is that if a new package gets defined, the user *cannot* get
> it.
Yep, this is ok, as this means, it is not tested / integrated with this 
release.
If one really wants this package anyway, he can define his own custom
packageset and add it there.
>
> Again, this should IMO be handled by having a different workflow /
> release system for individual packages vs. for rock.core.
>
>> - Announce new Release and wait for feedback.
>>     - Wait for Bugreports
>>     - Fix the Bugs
>>     - Announce RC2 ...
>> - If no hard bugs occur, any more make RCx 0714
> In order to be more constructive than my previous comment: there
> should be a hard deadline between RC cycles (i.e. the "wait for
> bugreports step" needs to have a timeout).
Agreed
>
> Sylvain
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev


-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  jmachowinski at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik