14 Aug
2014
14 Aug
'14
12:25 p.m.
Hi! First appeareance after a long lurking time :-)
On 08/13/2014 01:43 AM, Gui Iribarren wrote:
the objective is to have a "snapshot" of
everything, so that cloning
lime-build release and running make, will produce the same binary, at
any future time, no matter what happens with 3rd party repos.
[...]
i know this means a loooot of repos that we have to
"maintain" on our
own (in a way), but:
* it's the only method to have something that we control completely
* normally they will be just mirrors of the original repo, and pulling
changes from upstream should be as easy as "git pull upstream ; git push
github-lime"
Yes it's good also if there are patches to be applied and yet not
available in the upstream repo.
In the nvie branching model releases are made via tags applied to the
master branch while "release branches" are created to do the latest
refinements before releasing. That's true for the main project repo, but
the model doesn't hold for dependencies because the other project could
not use the nvie model and because it's not lime's duty to prepare
releases for openwrt.
So... can't the immortal branches be replaced by tags?
I don't know much of the build system of lime, yet, so it may not be
feasible.
also, i changed the "default" branch of
lime-packages to *develop*, to
make development progress more visible.
while this deviates just a little bit from nvie
"gitflow" branching
model, i think it is aligned with what people expect when looking at a
github repo.
Agree 100% on that. People don't want to look at the github repo and see
"last commit months ago" and then discover after a while that all the
work is happening "behind the scenes" in another branch. Also because
the obvious question when you see a hundred branches is "and now? what's
the correct branch?"
David