On Tue, 2016-06-07 at 22:24 +0200, Sébastien Wilmet wrote:
[...]
> > This of course, requires real thought and engineering, but I wanted
> > to
> > at least offer some technical input, some starting point that could
> > be
> > explored - this wont be solved without real engineering, trial and
> > error.
> It's similar to the "master/master-stable-next/master-stable"
> branches
> concept that I thought about in this previous sub-thread. See those
> two
> mails:
> https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00002
> .html
> https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00008
> .html
>
> It doesn't look like rocket science to me, and it would get us closer
> to
> continuous delivery.
Honestly I hadn't put a huge amount of thought to this, but I did
figure in that once there is API churn, there will be multiple
variations/combinations that are desirable to build - one might want to
build a certain app which has not yet adapted to an API change, in
which case they need an amalgamation of branches which gets them their
app building without the API change in a lower level library/service.
On the other hand someone who wants bleeding edge of the given
library/service will want it with the API change included... but I
admit these considerations are possibly not worthwhile for our basic
goals: improve CI for development cycles and help have a more friendly
starting point for onboarding newcomers.
I also woke up this morning to an interesting conversation on #gnome-
hackers, which I missed due to timezone skew, but made me think of
something cheaper also more inline with what you suggest with master-
stable, master-stable-next etc.
So here it goes, after reading the interesting conversation I think
that we are close to something that is a step forward which will not
cost very much at all, I think that the main point we disagree on is
reverts in *master*, and the idea that *master* is something that can
be forced to be always stable.
I think with a couple of iteration we can work out an agreement. :)
So to wit, let me summarize your points:
* Master is unstable and can be in unbuildable state until we apply a tag making it stable.
* We have a 'integration' branch or something like that which is always in buildable state but lags behind master by some undetermined number of commits.
I'm a little unclear what a maintainer's workflow is, and how can we ascertain that they push to this integration branch when there is no social policy in place to do so. I mean some maintainers can completely ignore that if they wanted to.
I think in general we still need to figure out how to socially have compliance as I can envision some maintainers not wanting extra work for sake of argument.
[snip]
Any thoughts ?
Thanks for taking the time to putting your thoughts and contributing positively to this discussion and making suggestion, well appreciated by the rest of us. I don't think we have gotten any feedback on this and I'm bumping this again to see if people can look at Tristan's proposal as something workable and acceptable as a base of a conversation around doing this.
sri
