On Tue, Jun 7, 2016 at 9:45 PM Tristan Van Berkom <[email protected]> wrote:
> 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
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
