No subject
Wed Feb 26 20:00:34 CET 2014
think in most cases his intention is to get his coworkers updates, yet he
receives both the coworkers updates and the updates of the branch he is
tracking. Even if he is tracking next, this might not be want he wants, since
next is also moving.
Another note is that often features are wanted (if they are required remains
another issue) which are in master. Packages are being pulled up to master,
others have to follow because of the implicit dependencies a.s.o. The idea of
the flavours as synchronisation points breaks down here.
- Ok, this is a collection of thoughts, that I can maybe derive some insights
out of...
I have a feeling that tracking branch heads within a project might be wrong in
general. This is for two reasons. 1) the problems with the updates mentioned
above, 2) the inability to go back to a specific version of a project without
taking extra care.
I think that maybe a projects buildconf should be more seen as an index to
specific commits in the packages instead of heads, and the workflow and tools
updated accordingly.
One possible way could be that autoproj takes care of updating the overrides in
the buildconf. It wouldn't be an overrides anymore, but rather a refindex or
something like that. A draft workflow would be:
1) advance head of a packet either through a local commit, or by manually
changing to head to a remote head or specific commit
2) calling autoproj commit <package-name> will record the commit id in the
refindex, could also work for all packages at once
3) commit the buildconf
This puts a bit extra effort on the committing side, but maybe the workflow
could be simplified e.g. by e.g. performing the call automatically for packages
that are marked. I am sure there are ways to make this more streamlined.
The core idea though would be to not track heads in the buildconfs anymore, but
always give explicit commit ids. When combined with a good workflow I have a
feeling this could improve the issues that we have.
Sorry for the rather long mail on this...
cheers,
Jakob
------=_Part_11046_2028452902.1403302879637
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
<style type="text/css">.mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000}
</style></head><body style="">
<div>
Hey,
</div>
<div>
 
</div>
<div>
some of this stuff has been discussed in "The issue with Rock" thread, but I am starting a new thread here to maybe try and focus this a little bit. Lets say this is more a collection of thoughts and maybe I'll come to a conclusion and a proposal in the end. Lets see. I haven't really been thinking or reading on the philosophy of rolling releases before, so forgive me if I state some obvious things.
</div>
<div>
 
</div>
<div>
What we call flavours are really synchronisation points between the different repos. Each of the three flavours is a moving head. Master moves in small steps, next and stable move in larger steps. The contract is that packages that are on the same head work well together and are tested also through the build server. We don't have version numbers and afaik we don't really use any tags or the like to pin down specific versions.
</div>
<div>
 
</div>
<div>
The current way of how project work is performed is that some project specific repos including the buildconf are generated, and the project is started. Lets call this the entry point for that project. We recommend using the next flavour for this, because its supposedly more stable than master. Note that stable means two things in this context. One is that it is less frequently updated, and so less likely to have build errors introduced, and two that the code has been around longer and might be less likely to have bugs.
</div>
<div>
 
</div>
<div>
Once the project gets going a number of things happen. The project specific packages are developed and advance, and the non-project - lets call them rock packages - advance as well. They introduce new features, resolve bugs, create new bugs and incompatibilties. This happens on both the project side, and the rock side. People working on the project will perform frequent autoproj updates, to get what their coworkers have been working on. They will also get the stuff their current flavour is tracking. If its master, it could be a compile error that ruins the checkout just before the demo. This is why we recommend to track next, because its less likely here. 
</div>
<div>
 
</div>
<div>
From the side of the project worker the act of autoproj update is overloaded. I think in most cases his intention is to get his coworkers updates, yet he receives both the coworkers updates and the updates of the branch he is tracking. Even if he is tracking next, this might not be want he wants, since next is also moving. 
</div>
<div>
 
</div>
<div>
Another note is that often features are wanted (if they are required remains another issue) which are in master. Packages are being pulled up to master, others have to follow because of the implicit dependencies a.s.o. The idea of the flavours as synchronisation points breaks down here.
</div>
<div>
 
</div>
<div>
- Ok, this is a collection of thoughts, that I can maybe derive some insights out of...
</div>
<div>
 
</div>
<div>
I have a feeling that tracking branch heads within a project might be wrong in general. This is for two reasons. 1) the problems with the updates mentioned above, 2) the inability to go back to a specific version of a project without taking extra care. 
</div>
<div>
I think that maybe a projects buildconf should be more seen as an index to specific commits in the packages instead of heads, and the workflow and tools updated accordingly. 
</div>
<div>
One possible way could be that autoproj takes care of updating the overrides in the buildconf. It wouldn't be an overrides anymore, but rather a refindex or something like that. A draft workflow would be:
</div>
<div>
 
</div>
<div>
1) advance head of a packet either through a local commit, or by manually changing to head to a remote head or specific commit
</div>
<div>
2) calling autoproj commit <package-name> will record the commit id in the refindex, could also work for all packages at once
</div>
<div>
3) commit the buildconf
</div>
<div>
 
</div>
<div>
This puts a bit extra effort on the committing side, but maybe the workflow could be simplified e.g. by e.g. performing the call automatically for packages that are marked. I am sure there are ways to make this more streamlined. 
</div>
<div>
 
</div>
<div>
The core idea though would be to not track heads in the buildconfs anymore, but always give explicit commit ids. When combined with a good workflow I have a feeling this could improve the issues that we have. 
</div>
<div>
 
</div>
<div>
Sorry for the rather long mail on this... 
</div>
<div>
 
</div>
<div>
cheers,
</div>
<div>
 
</div>
<div>
Jakob
</div>
<div>
 
</div>
<div>
 
</div>
<div>
 
</div>
<div>
 
</div>
<div>
 
</div>
<div>
 
</div>
</body></html>
------=_Part_11046_2028452902.1403302879637--
More information about the Rock-dev
mailing list