[Rock-dev] Flavours, freezes, updates

[Sylvain Joyeux]

The major issue with making the "snapshot" workflow is the one of
maintenance. It is IMO a great workflow when you are trying to reach either
a ready-to-deploy state (for a customer) or a demo-ready state, as it
ensures that one controls the state of the global system *and* can
reproduce its installation. At this stage, I personally *also* includes the
repositories from the project developers. I've used that workflow for a
previous project (snapshot each version of the 'demo' code so that I can
reproduce it as-is). One can already do this to a certain level with
existing Rock tooling (more on that later).

During development, the problem is the one of bug reporting / interaction
with the developers. It is simply impractical to assume that the developers
can help you if you might be in any state. Updating to newer code is hell
as well as we really can't make release notes from any state to any state
(i.e. people won't know what they might or might not get if they update)

However, I have the impression that Jakob carefully decided to omit the
word "stable" in his text. Whether it is conscious or not is another
question ;-).
I also want to forget about the broader "Rock" and focus on the Rock core
for now. This is IMO implicitly what Jakob does by separating the "coworker
stuff" from the "rock stuff".

Stable *is* a consistent, released, snapshot of the Rock core code.
Moreover, the release notes are meant to give broad information about
backward compatibility issues. Finally, stable releases are the only point
in time where one can check that e.g. documentation got updated.

What I wanted to acknowledge in the original thread is that 'stable' is a
failure. Everyone is using a mixture of next and master. What I personally
want to achieve is that this stops and that 'stable' becomes the rule
instead of the exception /because/ it is the only place where the core
developers can offer some guarantee to the Rock users. And that I
personally don't want someone come to me with "I have bug X on commit Y".
You use half-released stuff ? It should be your problem. Traveler's last
paragraph

> I arrived at a similar point as Jakob. Repo heads are easy to think
> about and are what developers work with but the only way to provide any
> guarantees to a down-stream user is to mark the graph of exact commits
> that create a "working" system.
'stable' is IMO the only practical way it can be done for both the user and
developer.

That's why I started to talk about separating the development workflow of
rock.core. During the weekend, I started thinking about also dropping
'next' altogether. If noone is using stable, then let's just remove the
intermediary:
 - separate rock.core and rock release cycles. Maybe make the non-core Rock
code each maintainer's responsibility. If he does not want to release, then
so be it.
 - ensure that any stable version of rock.core can be re-bootstrapped. We
already tag the releases, so it just means that we should also generate an
overrides file that allows someone to get back to any stable version.
Bootstrapping stable would "pin" you to the current release (i.e. you would
not automatically update to the 'new' stable).
 - guarantee some backward compatibility in rock.core. This means that
updating to the N+1 stable release of rock.core will not break your code. I
would even go as far as having 6 months to a year without breaking
compatibility or two releases, whichever lasts longer.
 - schedule the releases long in advance, and nominate one release manager
(also long in advance) to ensure that we release "often enough", thus
removing being drawn to using master.
 - finally acknowledge that master can break your stuff. Meaning that if
you pin master versions, good luck with updating later on (you'll have to
find the "consistent set of commits that allow you to not break your code
while still getting the new features / bugfixes you are looking for".

In order to avoid breakage while we release, an *ephemeral* rc branch will
appear to prepare the release code, run the unit tests and let "edgy"
people try the soon-to-be-released code on their codebase. That would be
part of the release cycle and should not last more than say 3 weeks.
.
Now, from the point of view of project development, I personally really
like the idea of having autoproj automatically maintain a history of the
system's state. This is useful *no matter what* because my coworkers can
also break a demo. I know that Steffen already did some scripts that could
do it in Virgo.

Bottom line:
 - we need to have the tooling that supports the "snapshot" workflow Jakob
talks about, if only for RTM or demo situations, so the people that feel so
inclined will be able to test this workflow.
 - what we need to do however is to provide an improved "standard" workflow
for new users. I personally think that requiring new users to select
commits is ... "suboptimal".

Sylvain


On Sat, Jun 21, 2014 at 2:20 PM, Traveler Hauptman <traveler.hauptman at iit.it
> wrote:

>
> I don't really have time to join the discussion properly, but I'd like
> to say that I have thought about this topic quite a bit in a non-rock
> context (but still robotics). We have a large number of repositories
> under development, all with external dependencies. Our build system is
> built directly on cmake scripts but tries to solve the same set of
> problems as autoproj.
>
> I arrived at a similar point as Jakob. Repo heads are easy to think
> about and are what developers work with but the only way to provide any
> guarantees to a down-stream user is to mark the graph of exact commits
> that create a "working" system.
>
> -Traveler
> _______________________________________________
> 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/20140623/e90a57b7/attachment.htm