DrupalCon Portland 2013

Como implementar con éxito grandes cambios en un proyecto como Drupal

Jess  · 

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

welcome back to Drupal core therapy sorry I mean the core conversation track I'm xjm and I'm that's on drupal.org my name is Jess I'm probably best known in the Drupal community for the core contribution mentoring program but I'm also one

of four co-leads for the views in Drupal core initiative and more recently I work in the office of the CTO at aquia and my job title is codon community strategist so what that means is that raises my boss and I work on core stuff basically full time which

is pretty cool and so the title of this core conversation is making big changes and that's big changes in Drupal core not in your personal life sorry I'm going to really describe four different case studies of big patches in Drupal core and then summarize

some of the lessons I think we learned from them and then after that we can sort of discuss what to do about it but first I'd like to scope this a little bit i'm going to leave aside for now anything about how to run an initiative in general i think

Shannon already covered that and i also want to talk more specifically about individual issues individual patches in core and also issues that are outside the scope of any one initiative I also don't want to talk about tools we don't have yet like

github it like improvements the drew blood or tissue queues because i think that there's been at least one session and one conversation devoted those topics already and finally i don't want to talk about whether our workflow works best with patches

vs cin boxes vs kaur branches vs. unicorns because i don't really think that we like resolve that or even i think if we started that debate would actually be in here until code freeze so i'm going to skip past that for now at least in my portion of

this this conversation is drea it's not calling it a conversations a little bit strange means like I talk at you for half of it and then there's the conversing part so I there's it needs a different label so we have the saying and rupal core that

the drop is always moving and this means that we're willing to innovate and make bold changes that make triple better um at the same time though big changes exposes to risks and they can be difficult to manage they add to our technical debt and even if

our goal is to reduce the technical debt in the long term in the short term they're definitely inducing more and that's a risk they lead to issues with hundreds of comments this this frustrates all of us it leads to people burning out and tuning out

big patches are they break a lot they're they're difficult to reroll and if if the need comes there also very difficult to roll back and a particular problem that's close to my heart they're freaking hard to review and for the retail rings

above they cause contributor burn out whether whether you're reviewing the patch whether you're testing the patch whether you're just someone following the patch who's interested in and especially through the patch author on it it can be really

discouraging even if you're successful in the end it can be a very trying experience so let's talk specifics I can't do that i'm going to describe for examples of big changes in core during the Drupal 8 release cycle and just walk through roughly

what happened in those issues and the first change in the issue is probably my favorite moment in the entire Drupal 8 release cycle when views was merged into core um and I'm going to just describe a little bit help out of EDC worked so we started out

with an 8 X 3x branch of views in the views project repository and gradually worked on removing views external dependencies mostly on ctools and stuff that we thought would be useful in the rest of core on like drop buttons the temporary storage temp store

configure a tease ended up on their own as issues in the normal cork you so those issues went through the normal core process and were adapted to course separately before we went to merge views and decor but once those dependencies were resolved then Tim built

us a sandbox um that had views as a core module and Jeremy Thorson set us up so that test spot could test that which was invaluable because core API changes were breaking our sandbox pretty much on a daily basis and so it was really important to have that

feedback to know whether or not it broke again and we knew going in that we had like seven years of technical debt to resolve so once that we had the sandbox I also spent some time crafting what I hoped was like a bulletproof issue summary this goes back to

what we were talking about in a previous core conversation and I actually like wrote it in a Google Doc and reviewed it with the whole views and core team before i even posted it because i really wanted to make sure that the scope of the issue is clearly defined

we had done a lot of cleanup and where fact but at the same time you know it's like the patch was the patch that we rolled to test views against core was 2.5 megabytes and views has like you know is like a change that involved 500 files so we ended up

merging views in on October 22nd in 2012 and that means I've used as been in cornell for exactly seven months seven months guys whoo i should point out that we did make some exceptions to the normal court process when he merged views in and they're

still core gates issues open for views in in our inner issue summary we listed out the things that that we're not part of the issue like coding standards clean up so we also identified some things that if you had been a normal just core patch should have

been part of it in a particular we knew that there were accessibility problems in views that we weren't going to be able to fix in part because we were blocked on on on some issues in core and in as a matter of fact we still have we still have several

accessibility issues known issues that have been open for a long time because we're blocked on this one particular issue on so if you have if you have any interest in helping with the modal dialogues to make it so that views is usable with a keyboard that

would be amazing and come to the cold spring on Friday and talk to Daniel I didn't even look up okay and they're also usability issues we did a usability study on views on at bad camp and I say we like I planned it all I did was sit there and go oh

my goodness um but the the sum of the usability contributors in the Drupal community set up a usability study and did that there were also performance concerns going in we knew that our test coverage wasn't perfect but at the same time it was probably

the right decision to make to Mars using at that point in the release cycle because there was no way we were going to be able to finish all of those things by the December first code freeze and it did a lot of good for the rest of core for views to be in that

early because we were really able to to have use cases to test some api's that wouldn't have been available without a module with like views there on the second change I'd like to talk about is the blocks is plugins conversion and this is the one

that led to a big retrospective with all of the initiative owners and then in turn to this core conversation being proposed so if it seems like I'm picking on this issue that's the reason for it and it a pretty important learning experience for all

of us so in April of 2012 Chris Vander water Eclipse GC posted a 144 k patch that added a new plug-in API on you block system and a conditions module and it also converted every single block in core to this new API and it also converted the configured block

instances to the then xml-based configuration management system for those of you are familiar with cmi that's how long ago we're talking about here so once the plugins system went in separately in August August you just we just jump from april to august

on chris posted an updated patch and then he also added a UI overhaul into the mix to make the new user interface a new user interface to support a new model for placing blocks so while the patch converted all of the blocks it didn't actually at that point

update any of the test coverage in fact the issue was marked active until August until catch came and said its knees review and was like what's going on here um and of course you know there were like hundreds of test failures because all these tests were

using a block system that wasn't there anymore so a small group of dedicated superheroes nacho alchemilla anderson i think is our last name and several developers from zip tech spent a bunch of time fixing those tests just to convert them to the new api

there were entire Sprint's dedicated to just getting the test the old tests to pass for this one patch whole sprints and by the time the patch was passing it was 400 k ah so that's that's when I came into the issue and it took me 80 hours to read

and review the entire patch and I spent spent the better part of a transatlantic flight writing of a comprehensive 3,000 word summary of my other reviews on this issue I documented the remaining tasks file follow-up sport I thought this issue was really important

you know it was it was doing something that was laid in architectural foundation for actually views in the future as well I tested it manually I helped with some minor architectural issues and then I invested another 30 hours of work or so in that part of

it and meanwhile merging had for this particular patch because it was so big was also failing on other core API changes daily so Tim Plunkett and I spent a lot of time just fixing those merge conflicts over and over and over again so on December twentieth

and now we're from april to December twentieth we had this big call with threes and several people from the blocks and Lance initiative and we came to conclusion of the only way the only way the Scotch initiative was going to make any progress in its release

cycle was to commit this patch now and just do the rest as follows because it was there was so much overhead in rerolling this patch in maintaining it um so the idea was that after that happened we would start crowdsourcing this follow-up issues because it

was some things we're no longer condensed in this one 300 comment 440 k patch we would be able to get other people to make just one specific change and you'd be easier to find people to do that um and so we committed the patch on January fourth with

over 50 follow-ups already filed i filed most of those myself even though i'm not part of the blocks and layouts initiative and we bent the rules pretty dramatically for that patch on it did not provide an upgrade path for blocks at all um it introduced

a 15-percent performance regression in one particular case that we profiled it had numerous you I usability issues and the test coverage and documentation were also incomplete now those two issues still aren't resolved so what we have is fairly significant

architectural debt in court right now we made a significant improvement but at the same time the trade-off has been a persistent risk to the release of Drupal 8 um now I want to pause out for a second here and talk about the similarities and differences between

these in core and the blocks as plugins patch now note that both both patches added a new api's decor um and both had some exceptions granted to our normal policies in order to save them from this reroll hell that we were stuck in where we couldn't

make progress because we were spending so much time chasing head both had concerns about usability and accessibility and performance and test coverage and both spawned a lot of follow-up issues and issues that still persist in all these areas in some cases

so that's important to note you know it's it's not that views you know was magic and wonderful and blocks did a horrible thing there's definitely some similarities there but there's also some key differences that have sort of affect how

this is played out over the course of the release cycle and the first thing is that the views API which you know it's not perfect it has been battle tested for seven years as a contributed module its installed on seventy percent of Drupal sites so there's

[ ... ]

Nota: se han omitido las otras 6.221 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.