<div dir="ltr"><div>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).<br>
</div><div><br></div><div>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)<br>
<div><br></div><div>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 ;-).</div><div>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".</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>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</div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> I arrived at a similar point as Jakob. Repo heads are easy to think</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> about and are what developers work with but the only way to provide any</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> guarantees to a down-stream user is to mark the graph of exact commits</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> that create a "working" system.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px">'stable' is IMO the only practical way it can be done for both the user and developer. </span></div><div><br></div><div>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:</div>
<div> - 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.</div><div> - 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).</div>
<div> - 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.</div>
<div> - 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. </div><div> - 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".</div>
<div><br></div><div>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.</div>
<div>. </div><div>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.</div>
<div><br></div><div>Bottom line:</div><div> - 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.</div>
<div> - 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".</div><div><br></div><div>
Sylvain</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 2:20 PM, Traveler Hauptman <span dir="ltr"><<a href="mailto:traveler.hauptman@iit.it" target="_blank">traveler.hauptman@iit.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I don't really have time to join the discussion properly, but I'd like<br>
to say that I have thought about this topic quite a bit in a non-rock<br>
context (but still robotics). We have a large number of repositories<br>
under development, all with external dependencies. Our build system is<br>
built directly on cmake scripts but tries to solve the same set of<br>
problems as autoproj.<br>
<br>
I arrived at a similar point as Jakob. Repo heads are easy to think<br>
about and are what developers work with but the only way to provide any<br>
guarantees to a down-stream user is to mark the graph of exact commits<br>
that create a "working" system.<br>
<br>
-Traveler<br>
_______________________________________________<br>
Rock-dev mailing list<br>
<a href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a><br>
<a href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev" target="_blank">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a><br>
</blockquote></div><br></div>