Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
alright alright catch us here which means you can get started hey you're on time alright so this is our final core conversation of the conference hope it is a good one we're going to be talking about the Drupal 8 release cycle and how we can make it
more future friendly so first off let's talk about what our release cycle is now at least the story we like to tell ourselves so it works like this some version of Drupal comes out and it's wonderful and we all party and things are good and we open
up development on the next version of Drupal and you know we try to make everything better and we can improve anything in the sky's the limit and we can break api's we need to in order to improve things and this is what core developer sees that we
can improve anything and this is what everyone else sees we can just change stuff and that's scary and we have this idea that we allow ourselves to break ap is in order to enervate that we make Drupal better by changing things and that's true to an
extent but we eventually hit this API freeze phase which is actually sometimes more of an API slush and okay maybe yogurt I don't know some kind of sort of frozen it chills eventually and we could go to the face of just fixing bugs we're fixing bugs
all along and adding features now we're just fixing bugs and time passes while we do that and eventually we get down to zero criticals and we release and everything is happy and we start all over again and this is how core development works those of you
who have actually been involved in core development how realistic is this the yogurt is spot on here's more what it actually is like speaking of someone who's now lived through three as a major contributor here's what happens we released a major
version of Drupal and everyone falls asleep for a while because we're exhausted and burned out and we and then the court team just kind of ignores that stable because there's a new stable to start working on we've got the next version let's
go work on that now and we just keep on doing it stuff we were doing before that now we can do again because we can break api's again wonderful and we start designing new stuff and add new features and you know improve the UI do all this wonderful stuff
and we don't necessarily know that it's right because the new old version has only been out for a day and a half and we're already designing new stuff does the old stuff actually work well we can our guesses are sometimes pretty good but they're
still guesses we are not actually operating on data to determine if we actually need to change something and we have no idea how long it's going to be until the next release because grace doesn't tell us and so we're all in a panic trying to figure
out okay can I do something big do i do something small if I do something small doesn't mean I won't be able to justify the big thing figure the big thing well I not get it in time which means that nothing's gotten done I can't plan when I
have no idea how long it's going to be so I'm just gonna panic and then try and get stuff is done as much as I can and we try to fix everything we possibly can in as spastic a method as possible because that's all we can do which means that we
change everything and break it for everybody as usual and then eventually eventually drees announces a feature freeze date and it's usually way closer than we want it to be given wherever we are at that point and so we panic them again and keep on panicking
throat I'm into it work on weekends and evenings and stay up late at night and we finally hit Freese by which I mean slush by which I mean I don't know whatever API freeze is such a loose term and at this point a lot of people wander off because we're
not adding cool stuff we're just fixing bugs fixing bugs isn't sexy so we're gonna leave or I've already been working for the past year and a half i'm exhausted so I mean to go take a nap and let someone else fix the bugs and this phase
of Drupal 7 lasted way too long and I see some people here in the front row who are nodding in pain and really only this the only the few stubborn gets from incorp at this point to finally clean things up and get it released because everyone else is just kind
of burned out and tired and finally we stumble into a one point zero point zero release of the next version barely awake so you know carrying each other over our arms because that's all the energy we have left and we get this release out and then we try
and do it all over again this is actually how core development works for those of you who haven't been in it yes all software products used to work so how did that change exactly agile hmm so why are we panicking this is a quote from Chris Vander water
clips GC who's the initiative lead for scotch the blocks and layout this is about six months ago that he said this yeah I'm burned out I'm losing sleep but I too stubborn to care about my own feelings because I know I have to live with us the next
three years because we expect at this point our core releases are going to last a long time programming is like sex make one mistake and support for the rest of your life and when you don't know if it's a mistake or not for three years it's kind
of worrisome another problem it would be nice to get companies involved in core development and we talked about this at every conference how do we get more companies involved in core development in supporting Drupal large companies like long release cycles
you know I largely anything you know like salon release cycle large nonprofits large for profits governments anyone who has large investments they like this idea of a long stable release cycle but it also means that why am I going to bother contributing when
if I put an engineer on something to work on core I'm not actually gonna be able to use it for three years and I'm just talking about core say nothing of contributing up and so a lot of companies don't because you know it wouldn't be of any
value to them the turnaround time is too long sometimes these api breaks we do are necessary to evolve that is completely true if you don't ever break api's you turned into windows millennium edition and I see some people nodding in pain on that one
too there's actually code in windows millennium that special cased SimCity 2000 the game and retained a bug from windows 95 to support just that one game because they couldn't break that we don't want to do that believe me we don't want to
do that we go to the other extreme however if the only way you can innovate is breaking api's I've got news for you you don't actually have an API you have a pile of code a pile of code does not qualify as an API api's let you evolve and innovate
without breaking things by sneezing Drupal 8 breaks a lot of things it was a necessary shift we are catching up with eight years of development in the PHP world with Drupal 8 we are fast forwarding through eight years of evolution in two years that's a
big break it's necessary that should not be the normal case drupal 8 should be an exceptional release both is in exceptional really cool and exceptional is in not normal I'm seeing a lot of people nodding with that one especially people who have worked
on core so what do we actually need here you want the picture okay and what we actually need to be doing is we need more stability we need ability to rely on something both of ourselves and for our clients that is not going to change all the time without having
less development we don't need less you know fewer changes because you're fewer people working that's not what we need at all we need to be able to develop with better stability as we go forward we need to be able to iterate rapidly we need to
be able to improve in smaller chunks in bits and pieces we need to have a shorter roi we need to be able to say i'm going to put time into this task into this improvement and i'm going to be able to use it in four months in six months not in three
years because if i can't use it for three years why am i going to bother in us and they're completely crazy natick who is going to do this just for fun because these are sick and twisted human being I admit it we need to be able to improve without
breaking things this is something that core has been very bad at can't really has been better at than core in many ways so how do we get there how do we have a system that lets us do that you need to have loosely coupled components loosely coupled components
let you evolve individual pieces without breaking each other we need to have a clear separation of concerns we need to be able to have this piece of code deals with the database this piece of code deals with display this piece of code deals with HTTP this
piece of code deals with validation and they deal with just those one that one piece just their piece which means changes to the other pieces don't affect them that's how you get stability we need clear boundaries between our api's when you have
a big gigantic blob of arrays is not an API because you don't know what side of it you're on you don't have that separation concerns you don't have that clear boundary behind which you can make changes we need swappable components if you can
take a component rip it out and replace it with something else that follows the same interface that means you can improve that that system the thing you rip it out with and replace it with can be just the same thing only iteratively better and as long as you
don't change that interface nothing else breaks your code is still stable your API is still stable that's a feature for backward compatibility for forward compatibility for supporting alternate systems for testability this is just good code in general
basically we need clear interface interfaces and real honest-to-god api's that's how we get to the point of being able to improve without breaking things by improving guess what we've been doing for the last two years in Drupal 8 we've been
refactoring the system heavily for exactly this reason all of those things are have been the guiding principles for Drupal 8 sarka tech all of those things we need that are prerequisites for being able to evolve our system without massive API breaks are exactly
why we've been breaking so many api's in Drupal 8 to get to that point things like dependency injection get us disability interface driven development it gets us this ability putting you know separating out code into the Drupal component library gets
us this ability because this forces us to have loosely coupled systems that are not dependent on the application layer Drupal 8 makes this possible for the first time in the history of Drupal so let's do it how exactly would that work what well how would
we be able to evolve our code now for example here's a small example this is the class book manager it's in the book module Mark Sullivan has argued that it's a terribly named class and which should be called a book repository maybe he's right
maybe he's wrong I'm not going to debate that let's assume for the moment he's right how do we may make that fix without breaking api's you simply extend the class and then anything the type hints on the old class it's still going to
work core uses the new one it gets the new capabilities with a new object anything using the old one it's not going to use the new capabilities anyway that's fine it can still you know use the old code even call it by the old name that's fine use
the old tools and core can do the new cool stuff and contributes after we make that change can use it to know API has been broken we've added functionality there's some cases where it's not quite that simple you need to actually you know branch
[ ... ]
Nota: se han omitido las otras 5.960 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.