So, suppose I am taking the example of you know the first case, case one we are assuming where for the coordination number 4, case one we are taking for all those complexes whose coordination number number is 4. Coordination number 4 for example, the first question we are discussing here is for this, NiCl4 2 minus ok, NiCl4 2 minus is found to be found to be paramagnetic, paramagnetic with two unpaired electron, unpaired electron explain it is hybridization, hybridization and geometry ok. Now you see how to do this question, how to solve this question, solution. First of all the information we should have to solve this question is the nature of the ligand, nature of ligand and ligand here is chlorine which is nothing but chlorine here Cl minus right and Cl minus is a weak ligand. This is the information I am giving now which ligand is weak or is strong that we will understand later on when we do the crystal field splitting right. For the time being I will give you the nature of the ligand whether it is weak or strong ok. We know from the postulates of VBT that in case of strong ligand there will be a pairing of electrons in the atomic orbital against the Hunt's rule right. If the ligand is weak such kind of pairing against the Hunt's rule is not possible correct. So the first thing is this you should know whether the ligand is weak or strong. Second thing is the oxidation state of metal. So oxidation state of metal you see here chlorine is minus 1, minus 4, minus 2 we have already this nickel has plus 2 oxidation state ok. So oxidation state of metal here is plus 2. So what I will do I will just first drop the electronic configuration of nickel. Nickel we know the atomic number is 28 and its configuration is 1S2, 2S2, 2P6, 3S2, 3P6, 4S2, 3D8. Since electronic configuration since the oxidation state is plus 2. So the electronic configuration of Ni plus 2 will be we have to take 2 electron out and that comes out from the outermost shell which is the 4S shell correct. And that is why the electronic configuration of Ni2 plus is 1S2, 2S2, 2P6, 3S2, 3P6 and 3D8 ok. Now when I draw the orbital diagram here ok. So you see the orbital diagram here it is 3D this is 3D 1, 2, 3, 4 this one is 4S and next we have 4P ok. And the number of electron these are 3D shell and this is 4S and this is 4P correct. So now the number of electrons in 3D sub shell is 8. So we will have 1, 2, 3, 4, 5, 6, 7, 8, 4S and 4P orbitals are vacant empty correct. Now how many orbitals these metal require this metal required to bond with 4 chlorine ligands 4 chlorine chloride ion. The number of bonds number of vacant orbital required is nothing but the coordination number of the metal ok. So coordination number of metal is nothing but 4 because it has with 4 monodentate ligand correct. So 4 chlorine atom you can simply understand this one like that we have 4 chlorine atoms so nickel is here in the center and the 4 chlorine atom is trying to donate its electron right to the metal to form a coordinate bond like this ok. So to accept this pair of electron we must need 4 orbitals because 1 chlorine atom donates 1 pair of electron. So 4 pair of electron we nickel has to accept and for that we require 4 vacant orbitals. Now to form 4 vacant orbitals 4 atomic orbitals must go under hybridization right. 4 atomic orbitals must go under hybridization and it forms 4 hybridized orbital 1, 2, 3 and 4 and what kind of hybridization we have here since 1S and 3P orbital goes into hybridization so we call it as SP3 hybridization correct. Now in this SP3 hybridized orbitals the 4 chlorine atom donates its pair of electron and forms coordinate bond with the metal ok. Hence the hybridization of NICL4 the hybridization is hybridization is SP3 and with SP3 hybridization the geometry of the complex is tetrahedral tetrahedral and magnetic property if you think if you think about the magnetic property of this complex since there are 2 unpaired electron so it is paramagnetic in nature ok. Suppose if the electron suppose the ligand is strong then the pairing of electron takes place against the Hans rule ok. So for that also we will do one you know one example for a strong ligand we will try to understand ok. So I hope this example is clear ok. So by with the help of VBT valence bond theory we can actually find out hybridization geometry and magnetic property ok. So the next one you see we are considering the another molecule which is this the question is NICO4 NICO4 NICO4 is diamagnetic it is given is diamagnetic explain its hybridization geometry explain its hybridization and geometry now you see the solution of this molecule of this question ok. The first thing we should know is what the nature of ligand what is the nature of ligand what is the ligand we have here ligand is carbonyl group that is CO CO it is not cobalt take care of this and this is a strong ligand right. Again I am telling you this information I am giving you cobalt CO is a strong ligand generally carbon when the ligand has carbon atom donor or nitrogen atom donor then those ligands are considered as strong ligands in general ok. But how do we know which one is strong or weak that we will discuss in crystal field theory after this ok after this BBT correct. So nature of ligand is strong then the oxidation state of the metal oxidation state is 0 because this ligand is neutral also neutral ligand and to find out this oxidation state of the metal you should know the charge on the ligand that is also important ok last example if you see we have NiCl4 so chloride ion we have Cl minus that is a negative charge ligand ok. So that is why that is you know negative charge ligand so and if you know the charge on the ligand you can find out the oxidation state of the metal to find out oxidation state of the metal you should know the charge on the ligand also this is neutral so no charge oxidation state of the metal is 0. Now the same thing again NiCl has 28 electrons and the oxidation state is 0. So the configuration of this is again 1s2, 2s2, 2p6, 3s2, 3p6, 4s2 and 3d8 orbital diagram if I draw here you see orbital diagram we have 3d sub shell has 8 electrons 4s has 2 and after this 4p which is vacant 1, 2, 3, 4 and 5 number of electrons present you see 3d has 8, 1, 2, 3, 4, 5, 6, 7, 8 and this has 2 electrons like this if you are filling the electrons 1, 2, 3, 1 by 1 it means we are following the Hans rule okay but that Hans rule is not applicable here because the ligand is strong in case of strong ligand there will be pairing against the Hans rule one more thing what you can do that all these electrons you can fill directly 2, 4, 6, 8 like that also you can do okay and another way is what the 2 the unpaired electron present here gets paired why because the ligand is strong so one electron from 4s jumps over here and again the another electron jumps over here and this orbital becomes empty and this orbital becomes completely filled so this converts into this one and then we have 4s and this is 4p right so 1, 2, 4, 6, 8 and 10 and these three orbitals are empty so this is 3d orbital this is 3d this is 4s and this is 4p now again the same thing since the coordination number is 4 coordination number is 4 it means we require 4 hybrid orbitals and to get 4 hybrid orbitals 4 atomic orbitals combines and these atomic orbitals must be vacant so that it can accept the pair of electron which is coming from the ligand correct so ni co4 these three 4 orbitals combines and forms 4 hybrid orbital 1, 2, 3 and 4 this is the hybrid orbital and what kind of hybridization it is it is again 1sn3p so 4sp3 hybridized orbital which is completely vacant and the ligand donates pair of electron to these orbital and forms a coordinate bond hence since the hybridization is sp3 right to summarize this what we can write that hybridization of this now to summarize this hybridization of this molecule is sp3 sp3 geometry is tetrahedral and the magnetic property magnetic property since all electrons are paired you see it is diamagnetic diamagnetic in nature so like this you can understand the magnetic behavior hybridization and geometry one more question we will see here for coordination number 4 suppose suppose we have a molecule say ni cn4 2 minus we need to find out we need to find out the hybridization hybridization next is geometry next is magnetic property these three things we need to find out again you see what all things we should know here the nature of ligand ligand is what cn minus and it is a strong ligand cn minus is a strong ligand you should memorize this it is a negative charged ligand also negative charged and if it is negative charge the oxidation state of nickel if you calculate it is plus 2 so oxidation state of metallis plus 2 nickel atomic number is again 28 configuration is argon 4 s 2 3d 8 electronic configuration of ni plus 2 is argon and 3d 8 there's no electron in 4s uh shell okay so you see next here um orbital diagram if i draw this is 3d 4s and next is 4p 3d has 8 electrons so 1 2 3 4 5 6 7 8 and 4s has zero electron right but since the ligand is a strong right so this electron jumps over here and pairing takes place against the unstroke why because we have strong ligand so in this you see what happens here we have 2 4 6 8 so 1 d orbital is vacant now right again the coordination number is what the coordination number is 4 it means we required 4 vacant orbital 4 atomic orbital combines and forms the hybrid orbital so we have 1d 1s and 2p so we'll get 4 hybrid orbital here 1 2 3 and 4 and what kind of hybridization ds p2 right because 1d 1s and 2p involved so ds p2 hybridization okay so now to write down the answer for this hybridization is what dsp2 and dsp2 hybridization means the geometry is a square planet and magnetic properties since all the electrons are paired so it is diamagnetic it is diamagnetic one type of question also they ask that what is the d which d orbit because there are five d orbitals no so in this geometry in this hybridization dsp2 what like which d orbital is involved over here okay so for that i'll write down just one table here okay and you see this geometry first of all on one side then other side the d orbital involved okay so geometry if it is the geometry if it is a square planet square planet involves dx square y square orbital if it is trigonal bipyramidal tbp trigonal bipyramidal the d orbital involved is dz square if it is a square pyramidal if it is square pyramidal then it is dx square y square if it is octahedral then the orbital involves are dz square and dx square y square okay these few things you must remember this type of question they have asked many times in the exam especially this hybridization magnetic property geometry and all this kind of question they have asked the most important part in this we have for the coordination number six okay so four we have discussed we'll discuss five next and then we'll discuss for the same thing for coordination number six okay so one type of question related to this hybridization geometry magnetic properties the another type is which d orbital involved in this various geometry okay so we are done with the coordination number four next session we'll start with coordination number five and six thank you very much


Are we doing everybody forced here? I got a diamond icons box for Tom see 2023 diamond icons hobby Let's go. Let's go. I'm ready. I'm ready to pull the roof. I'm ready to pull a One-of-one othony Something like that What better time than 2 30 a.m? What better time? All right. Well hell of a start Each row red ink 6 of 15 on the auto That is a great start each year. Oh red ink 6 of 15 sick to do it Buster Posey 7 of 15 Gold ink Buster. We're just going through all the different colors of ink here Joey Vado green to 15 5 of 15 Vado auto Vado Matic We literally have four different autos now four different colors silver ink Barry Larkin auto to a 15 Who's a al-tube on the red ink auto 4 of 10 Tom loves al-tube? I know that Well, probably actually love this one. We've got King Felix red ink auto one of one Beautiful King King Felix Red ink one of one That guy was a good pitcher. These guys are pretty good pitchers Dole Jersey auto Nolan Ryan show hey othony Yeah, buddy. Here we go 7 to 10 Ryan Express in show time Tom see Mr. Tom Yeah We're not done We're not done. We got rookie five of five uncut diamond relic auto of Gabriel Moreno Gabi Moreno uncut diamond rookie auto. We're not done Cut signature three or four Ron Santo Ron Santo on the cut What a box dude, what is this what a box this is a classic Tom see right here My dude Vladdie jr. Two of ten on the green ink auto Such an awesome box That was awesome. That was Well worth staying up for yeah, man, that's just crazy.


On this week's edition of Titans All Access, excitement from Amy Adams strunk on the Titans New Stadium project. Check, talking ball with General Manager John Robinson. Check, a conversation with not only one, but two rising defensive leaders. Check, that's a hit. Dave McGinnis breaking down Austin Hooper's big day against the Colts. Check, we've got all of that and plenty more right now on Titans All Access. It's not even November and the Titans already have two wins over the Indianapolis Colts. Welcome to Titans All Access. She's Amy Wells. I'm Mike Keith. And the Tennessee Titans beat the Indianapolis Colts last Sunday for the second time in October. Final score 19-10. Amy Wells was on the sidelines for Titans Radio. When did you know the Titans had this one? Well, Mike, I knew it all along. Had them all the way? I had them all the way. No, probably somewhere in the middle of the second half. I knew the Titans were going to get it done.  Ryan Tannehill led the way along with Derek Henry as you would expect. But tight end Austin Hooper had not one, not two, but three big plays in the second half. Let's talk to Coach Dave McGinnis and go beneath the surface as we look at Austin Hooper's big second half performance. Hey guys, Coach Mack here with this week's Beneath the Surface powered by Microsoft Surface beginning now. Today we're going to look at three outstanding catches, very pivotal catches in this last ballgame against the Colts by tight end Austin Hooper. The empty set three by two, it's a five up defensive scheme. A three man game on top linebacker fires the A gap. Ben Jones does an outstanding job coming back on the wrapper in this stunt. Zaire Franklin, the leading NFL tackler, not this time. Excellent move by Hooper for a critical first down. Nick Westbrook Akina also helping with the block. This was a critical third down conversion at this point in the ballgame to begin Austin Hooper's record setting day for himself as a Titan receiving the ball. Now we are in 12 personnel, two tights, two wides, one back and forms a three by one. Indy's in a four man rush, now they are playing man to man. Bobby Ocaracay is the low hole rat. Tannehill has great location throw right by Ocaracay's ear right here. Outstanding adjustment and a combat catch meaning he's going to be contacted as soon as he catches the ball by Hooper for another critical first down. Now they're in a two by two formation, we're in a four man front. Indy goes to a zone cover two scheme. Offensive line does an excellent job picking up the three man game to the quarterbacks left side. Tannehill now sidesteps the pressure right up the middle in the cylinder. Again, another great job by Hooper settling down between the two safeties that are the two high safeties in this cover two scheme who both converge on the ball. If you'll watch closely, this ball is moved five times before Hooper secures it with outstanding concentration on the sixth time. This is not only a pivotal catch. It also forces Frank right to challenge the catch losing a timeout which proves very, very vital at the end of this ball game. And that was an outstanding win by the Titans 19 to 10 over the Indianapolis Colts and a really nice day by Austin Hooper. The Titans are going to need more big plays for Austin Hooper and the offense as they go to Houston this Sunday and some big plays for the defense. Speaking of the defense, Amy Wells, they had some big plays, a lot of big plays in the win over Indianapolis. Oh my gosh, it was beautiful. The interceptions, the force, fumbles, I could go on and on. And we're going to talk to some of the leaders on the Titans defense later in the program. But on the other side of this break, the Titans released some renderings of their new stadium and it might have made some noise. We're going to show you that in a lot more. So stick around. Speaking of a big play. Well done. Welcome back to Titans All Access. It is time for the Hughes and Coleman decision of the week. Mike Keith, last week the Titans announced that they reached an agreement with Mayor Cooper to build a new stadium and start looking into what that process is going to look like. So the question is the decision to build a new stadium, a good one. Yeah, absolutely. It's a great decision. When you've seen the renderings and you feel the excitement and you know what it's going to do for the Tennessee Titans, for Nashville, for Middle Tennessee, for the Mid-South, it's a great decision. And we're all extremely excited. The person who's probably most excited, Titan's owner, Amy Adams, trunk. I had a chance to visit with her to discuss this big news, a new stadium on its way to downtown Nashville. What is it to start with that you're specifically most excited about? Oh my gosh. Well, I'm excited for the city of Nashville and the state of Tennessee because I think this is going to be a real game changer with these big events that will come to town and I'm excited for our fans. You are one of the most fan-centric owners in all of sports anywhere. Why are the fans so important to you and have you kept them in mind so much through this entire process leading to this moment? Well, thank you for that. But you know what, I always have the fans in my thoughts. Whenever I make a decision whether it's something to do with football or something to do with the stadium or something to do with the new stadium, I'm always thinking about what are they going to like? From their experience, what are you hoping that the first thing that really jumps out to them about the new stadium is all about? What do you want for the fans first and foremost? It was so important as the last two years, this journey that we've been on, that this stadium looks like Nashville. We didn't want it to look like a stadium in another city. It has to have that Nashville feel, which I think is going to be great and going to be different than what's around the country. But when you get inside the stadium, it was important to us that every single seat is perfect. It's just going to be a great seat. Berkney Hill has been talking about the stadium and referring to it as the People's House. Meaning that he wants everybody in the community to feel like there's something in it for them and to feel like they have that sort of ownership. When that's said, what does that mean to you as the owner? Our mission statement is when serve, entertain. And we just don't say that. We believe it. And we don't want it to be just a Sunday football stadium. We're saving 12,000 square feet for a community center inside the stadium, which we hope will host job fairs, metro students, let them come have classrooms there, nonprofits. We hope it will be all things. So you could have a Super Bowl on Sunday and host a job fair, students, whatever on Friday. I want to wrap up with this one. Your dad took a chance on this city over a quarter century ago. I'd say it's worked out okay. If he were here right now, and he saw the renderings we're going to take a look at in just a minute, and he knew what the plan was and how people have come together to make this happen, what in the world would he say? Oh my gosh, he'd be so excited. You know, I'm going to tell you a little story about my dad when he was making the move from Houston. Nashville was the only city he would look at. And the people that were helping him tried to getting, go to LA, Mr. Adams, you need to at least see these other spots. And he wasn't having it. He was like, I'm going to Nashville. Mayor Bredesen and I are going to get this done. He loved Tennessee, and he loved Nashville. And there was going to be no other home for him. So he would be so proud. Mike, keep one thing is for sure, you can feel the excitement not only throughout the Titans organization, but throughout all of Nashville. All of Nashville people are fired up. People also fired up right now about the Titans defense, and the young leaders that are emerging like, for example, Christian Fulton and David Long. Guess who's next on The Nissan Insider, Christian Fulton and David Long. David Long, stay tuned. Welcome back to Titans All Access coming to you from the Bet MGM Studio. David Long and Christian Fulton are two guys who are making an impact on the Titans defense in a lot of different ways. So Mike Keith had the opportunity to sit down with both of them to talk about not being the young guys anymore and their increased roles on the defense. Wentz takes the snap, looking, throwing. Intercepted! Intercepted, David Long! And the Titans have shut down the commanders at the two. Yes! Yes! Yes!  That was the big play, and it came on the last play. Alright, so if David doesn't intercept the pass at Washington, what's going to happen, Christian? You're not getting that in zone. That's one thing. Either way, he made the play, but just having each other's back, playing the defense, just trying to make a play to make sure that they don't score, so just doing my job. Who is your teammate that you would say you have emulated the most to realize what it's like to be a leader on defense? I would say probably KB, off the rip. Jeff, both vocal guys, something that I want to be more like, you know, just to have that easy flowing. Come out and motivate the team and stuff like that. Also Wesley Williams, what I got here, he was in my room, a guy that I looked and see how he does stuff. Take care of his body and preparation and all that. I said KB and Amani, guys that I came in and they pretty much already had their role figured out. Like I said, KB is a vocal guy for our back end, for our defense, really. He's also vocal, but he's more chill, you know, more so how I am. So I kind of take things from both of those guys. I feel like they're great leaders. When did you know that you were going to have to be a leader on this defense? That you just weren't one of the 11 guys that you got to step up and be David Long, one of the leaders of the Titans defense? I think that just came with my play, you know, seeing how my play affected other players and how my energy affected in the green dot, you know, that makes it more, you know, I'm calling it a huddle, so you know, I feel like I might have to set the tone, you know, regardless. You know, so it just came to me. I really wasn't trying to press to be a leader, like trying to speak up, but it just came to me, you know, I just ran with it. When did you know you weren't just a starting corner? You had to be one of the dudes.  You know, I made sure we talked every play. I made that communication go across the board. Yeah! Here we go! Let's go out to film. Show me something. Hey, set the tone, man. Hey, set the tone. I gotta come see you. That's what I want to see. It's Kevin's defense. It's Jeff's defense. And now it's your defense. I mean, the fans are looking to you to make it happen. Your teammates are looking to you to make it happen. Stepping into that role earlier, you know, like I said, it's allowed me to get out of my comfort zone and not only make me a better player, but my teammates around me. So I see the impact, you know, that I can have. And I mean, it's been fun stepping into that role for me, to be honest. So I just look to continue to thrive in that role. Me personally, I think that was just always a mission on what's getting to the league. You know, this is the highest level of our profession. You know, so we don't want to get here just to get here. You know, we want to make the most out of it.  So I think, you know, we were dealing with it as up and downs, you know, as wins and losses, you know. But all in all, I think it's good for us. Coming up next, Titans General Manager John Robinson stops by the Bet MGM Studios and we're talking a little ball. So stick around. Time to talk ball presented by Duncan with Titans General Manager John Robinson. Titans, of course, come off a 19 to 10 win over the Colts. And I want to go back to that for just a moment. When you became the general manager here nearly seven years ago, you said you wanted guys who were tough, dependable team first and it was repeated over and over again. So a lot of that toughness on Sunday in the win. So I want to ask, where did the toughness stand out the most to you in Sunday's victory over the Colts? Yeah, I mean, I think you could see elements of it in all three phases of the game, Mike. I think on the kickoff cover we saw guys run down there, whether it was Dylan Cole with the big tackle, Monty Ryder with the big, you know, physical tough hit. Defensively with the way we were able to stop the run and continue to get pressure. We had 10 hits on the quarterback. But I think the best example was the first play of the last drive in the fourth quarter where we ran it up the middle. Derrick kind of got stymied around five yards and then you see this sea of light blue jerseys just throw themselves into the pile without regard for anything and move him another five or six yards to get the first down. To me, that was toughness exemplified in that play right there. What does the element of having Bud Dupree in the lineup add to the defense? Well, I think his size and power and length and the intensity with which he plays the game. When he can get knocked back on those tackles in the run game and really kind of, you know, force everything to funnel back one way or bounce out to the outside, that's impactful. And then in the pass game, whether it's coming around the edge with speed or coming inside with power and violence and collapsing that pocket, it's good to have a big, long physical player like Bud back out there to really impact the game. The Titans head to Houston on Sunday last season. Quarterback Davis Mills played well against the Titans. What have you seen from him in his second season? Well, I think he's more confident in his play, the players around him. He plays with toughness. He's not afraid to turn his back to the defense and then went back around there on the play-action pass and rip it. He throws a good ball. He's got good command of the offense. You can see that he's improved from his first year. Houston has a new weapon in running back Damian Pierce. What has the rookie from Florida really added to this offense that you can see? Yeah, he's really running well, Mike. I mean, he runs behind his pads well. He's got good stature for a back. He's got a good balance of patience and instincts in that he lets the blocks develop. He gives them time for the play to get going and he'll run it the way it's supposed to be ran. But then if he sees a hole on the other side one way or the other, he's just got great vision to find it and gets in the hole and he makes positive yards. He's a really good football player and off the fast start as a rookie. Lovey Smith is known for his defenses. What do the Titans need to do against Houston's defense? I think we've got to handle their disruptive play style.  They've got a lot of speed at linebacker. So we've got to do a good job of handling the movement that they do up front with the line and getting on these linebackers that play with speed, covering them up so we can get the run game going. Don, thanks so much for your time. Always enjoy, Mike. Titans General Manager John Robinson talking ball with us, presented by Duncan. Coming up, we've got your Titans game ticket for Houston and a great memory from 15 years ago when an NFL record was set. That's next on Titans All Accidents. It was 15 years ago this month when the Tennessee Titans beat the Texans in Houston, 38 to 36. The final score says the game was wild, but it barely tells the story of that day, especially the story of Titans kicker Rob Baronis. The Titans starting the game with a field goal attempt. Baronis from 52 yards away and the Titans grab an early 3-0 lead. By halftime, Baronis had kicked five field goals and the Titans led 22-7. More of the same for the Titans in the third quarter as Baronis kicked a sixth field goal and Chris Henry ran for the touchdown. Tennessee led after 3 quarters, 32-7. And then things got crazy, really crazy. The Texans scored 29 points in the fourth quarter, capped by a 53-yard touchdown pass from Sage Rosenfels to Andre Davis to take a 36-35 lead with 57 seconds to play. Tennessee had blown a 25-point lead. They had one last chance. After back-to-back incompletions, the Titans faced a third and 10 at their 37. Collins with a blitz coming. It's picked up. He throws deep downfield for Roydale Williams. He caught it at the 30, at the 25 and out about near the 20-yard line.  They're going to put the football down at the 17. On third and 10, Collins burns him for 46. It's all on number two. The kicker who hails from Louisville, Kentucky who has tied an NFL record today. And can vault himself past four others with a make here. Snap, set, kick on the way. Good! Boiled Titans 4-2. Rob Baronis with an NFL record. Eighth made field goal. And the Titans send the remaining crowd here at Reliant Stadium home stunned and disheartened. It was a crazy, amazing day in Houston. One for the ages. One that is still recognized in the pro football hall of fame. Rob Baronis became a legend that October day in Houston, Texas. That was 15 years ago in Houston. What about this weekend as the Titans return to Texas? Here's more of this week's Titans All Access. That was a good memory in Houston. The Titans hope to make more good memories in Houston this Sunday. As they take on the Texans, Amy Wells has your Titans game ticket to fully get you ready. Well, Mike Keith, it starts off with an alert. Alert! Because Titans fans need to be aware, Sunday's game at NRG Stadium kicks off at 3-0-5. That's right. Titans, Texans, this Sunday, 3-0-5. The Texans are 1-4 and 1 in 2022. Quarterback Davis Mills has thrown for 1,350 yards, 7 touchdowns, and 5 interceptions. Rookie running back Damien Pierce has carried the ball 106 times for 504 yards and 3 touchdowns. On defense, Rookie safety Jalen Petrie has 24 solo tackles, 1 sack, 2 interceptions, and 3 1⁄2 stuff. As a team, the Texans have tallied 12 sacks, 6 interceptions, and 2 stumble recoveries. Again, game time is 3-0-5. 3-0-5 Central Titans Radio Coverage is on the air with Amy Wells and our good friend Rhett Bryan. Titans countdown at 2 o'clock. There's stations all over the region. Find the one nearest you and tune in. For Amy Wells, I'm Mike Keith. Thanks for being with us for Titans All Access, and we'll see you next time.


T reading the topic of this buff is pure part and we would like to know what sucks. Envel wants to start. As mentioned in the description of the talk, what I find most most difficult is parsing the output. What I would really like is please tell me if there are any errors and nothing else. Pure part output looks like it has debug enabled at level 2. It has two levels of debugging-output enabled. One is a very custom level that I invented myself called Dump. I've recently sent to the BNDeval mailing list a proposal for a new format, which basically to summarize, it would have three forms of output. One would be to standard output, a summary of the test that are being run, and for each test, whether it succeeded or failed. And since there are a fairly limited number of tests, this would be a fairly short bit of output. And the style of the output would be very similar to what Lintian produces. So hopefully this would fix the problem of finding out whether this thing worked or not. The other output would be the current log file, but it would not go to the screen, it would go to a file. And it's a useful thing to have just in case something does go wrong. And some of the things that go wrong are things in the environment. Something runs out of memory, for example. And this can be hard to detect, except from the log file. And the third thing would be, in case there is a test failure, to optionally produce a snapshot of the virtual environment, the CH-shoot, so that it's easier to debug. This would be optional because such a snapshot will be somewhat large, and it would be a bad idea to produce it always. But for the people who want to debug the problem, then this would provide some additional help. Last, anyone think this is a good idea? Definitely. Does anyone think it's a bad idea? I look at it differently, because I don't look at one single package being tested, but all 25,000 in Debian. So I definitely want to have flags, so I can say this test failed because the test environment didn't have network, which would be not a failure in the package.  And also to be able to categorize different kinds of bugs, like files owned after Perch or something. Yeah. And the Lintian style output should make your work as well easier. It will not just say that something went wrong. It will be slightly more specific. Any other issues anyone has ever had with view parts? No. That would be a very short both. Well, I'll try again. I should have reported this as a bug, probably. I find sometimes that even if I tell view parts, I hope my memory doesn't fail. I tell view parts to ignore some files, but it still changes its exit code, or it sees as failed because there were files ignored. But that would be a bug. Yeah, that should be a bug. So I'll try again. How many of you use view parts regularly? I don't.  So I don't use view parts. James. So I'm not sure if this is a problem with the package itself, or the way that it's run on lintian.debian.org. I'm not sure quite where it happens, but I saw a failure the other day where the package failed to install because it depended on a new binary in that new version of the package. So that wasn't available in the base repository. Is it to do with the way that the packages are supplied to view parts for the run? Or does my explanation make sense? Could be that when the binary is built, or the package to be installed is architecture all, and depends on a AMD64 binary, which is not yet built on AMD64, which the machine runs on, then the test will fail. But it will be detected and automatically redone seven days later. Ideally, of course, it would be detected before running the test, but someone who wrote the code didn't think of all the cases. All the things that are wrong in view parts are my fault. All the things that people enjoy are his achievements. Do you get contributions? Yeah. So just looking at the way, sorry, view parts builds its truth right here, and apologies if this is a well-known thing. I see that it does a full debut strap and then pulls stuff out until it gets back down to only priority required. True it. Firstly, is it intentional that that means that every run of a package through view parts will detect any errors that are present when perching priority-important packages? And secondly, have you thought about just using a debut strap variant that only installs required in first place? To the second question. No, I haven't thought of that.  I shall file a bug then. To the first problem, it's fairly endemic to view parts at the moment that it's very hard for it to detect problems in, well, in this case it would be in the preparation stage, which could be dealt with. But in the actual testing phase, it's very hard to detect the problem, difference between a problem in the package itself or a package that it depends on. And I would love to find a way to fix this. I spent several minutes thinking about this in 2005. I didn't come up with anything. Presumably, well, presumably you could, you'd have to find out what sequence of operations was going to be and intercept after each one. So do each of the duplicate operations in sequence and then test the cleanliness of the truth. But presumably at early stages you'd find a lot of crap left over deliberately. The other thing that is that I currently recommend that people use the dash dash keep minimize option, which doesn't minimize the CHQ, because frankly these days this doesn't actually find any real problems. Well, it finds them very, very rarely. And it uses a lot of time, so there's no point in doing this every time. I have been thinking of the possibility of using Python apps instead of running updates manually as a separate process, well, automatically run updates as a separate process, which might give me more granularity as far as catching errors. My experiences with Python apps elsewhere have been excellent nowadays. In former times you had to do rather more messing about than perhaps you might want. You do find yourself having to re-implement bits of the app get front end, but often that's what you want if you're doing this kind of thing. Problem with dependency resolution are the or depends, because there it's not deterministic what gets installed and what gets tested before. Normally packages only tested if all depends have been tested, but if they are all depends then it is enough if one depends is satisfied. That should be improved. The correct solution, that would be to test every permutation of dependency if that is possible. And we would love to have some more hardware to do this. A few data centers would be sufficient. But yeah, given the complexity of the dependency tree in Debian, it's never going to be complete the testing we do. But it would be good to at least cover all the usual cases that users actually encounter. I don't think users really encounter a problem where they removed an important package, for example. The initial versions of few parts didn't do a threshold minimization. And I only added that after I had gotten the basics of the tester to work. Because when I went overboard and decided that I will find all the bugs ever done in Debian, thereby introducing a lot of problems. So I'm planning on writing few parts from scratch because every time I touch the current code I break it. The few parts being an automated testing tool has no testing suite whatsoever. There used to be one, but then I formatted my hard disk. So I started collecting back packages. So we started collecting back packages. So we have something to test few parts against. I don't want to stand up. You could sit on the table. No, that will break. Okay. After I've rewritten few parts I will try to keep the command line interface compatible with what currently exists, because this will make things easier. Skipping this minimization phase is one of the things I want to make the default. Because it's not useful enough to have everyone run it by default. And if you want to run it on the few parts.debian.org machine then it's easier for us to add an option than to have everyone else add an option when they use it. So I will deciphering my handwriting. But I think I have written MBF. And I have no idea what that means. Mess buck filing. Oh yes, you wanted to talk about that. Yeah, that's basic. There's some bugs which are more frequent than others. And there was the release goal for Lenny so it starts clean archive. And that has not been reached. There are still packages which are not clean, but I'm not testing Lenny anymore, so I don't really know how many it are. And I would like to discuss which bugs should be fixed and filed with either important or serious severity and then do mass NMU campaigns to fix them. And to discuss this properly I would need a list of those bugs that don't happen in my head. Own files are not removed after Perch. I think it's annoying, but it's really just cosmetical. There's other stuff which is files in user local which I think is so ugly that I really want them gone, but maybe still it's better to file them still, which is important. And other bugs like this. But I think this should be really discussed on Debian Devil on the list. Mass bug filing should be discussed on Debian Devil. And then it's easy to write. I added quite some functionality to PU parts by writing small best scripts which mostly grab in the lock files because there is no flex indicating it. And it's easy to extend these scripts to really then file 50 bugs at one time because it's just the same lock file to grab for the error. And I think it would be good to have functionality in the system that we have that will have a semi-automatic bug reporting facility for certain kinds of stuff. So that the system generates a bug submission email but doesn't actually send it a human needs to look at it and confirm that it's worthwhile sending. Hello Ian. Can you tell me what's wrong with PU parts? Yeah. Something I would like to do at some point in the future would be to add support for other kinds of virtualization than CSU. For example KVM and Xen. Because one of the things that makes me nervous about PU parts and running it across the entire archive is that since the devices in a CSU are shared with the host and if there happens to be something that writes to slash dev slash sda then my host is slightly screwed. Anyone else feeling this would be a good idea? Good. Once that is done I would also like to do things like allow the packages to start services because at the moment it's not saying to allow the packages to start services in the CSU. There's all sorts of things that can go wrong that way. And this means that many code paths don't actually get tested in postings for example or pre-inst or pre-room and so on. I just wanted to say that also I see another use case for using virtualization. If your package in any way depends on a kernel and I've just run it and it says oh cannot install the kernel because bootloader and so on and so on. So even if it's not a problem of security in running the host system it's just not flexible enough just in a CHL. So I totally agree with that proposal. Then something that has suggested to me is that if we are running inside a KVM anyway would it not be worthwhile to run test that test the functionality of the package. Ian. I have a system which is able to do this and it's been running in my cupboard for the last year or so. But there's nothing really useful being done with the output. Firstly because I don't have a huge amount of time to read the reports that it emails me. And secondly because I haven't really what I've decided to do very recently is that I'm going to put it up on a web page and see if I can get it on the packages QA page for your package. And that might get the more motivated people to write some actual tests. Because at the moment there are no tests as far as I'm aware in pretty much well there's probably like a couple of test packages where the tests haven't been removed but there are basically no functional tests that are wired into my system. So what tests do you run? Well I run tests that are provided by the package and if the package doesn't provide any tests then I don't run any tests. I do build it. In the WN Roots fire the tests are provided. No there's a separate spec for how to provide the tests. So as a background these tests are tests that test the installed package if I remember correctly. And the question I have is this something that would be worthwhile integrating with view parts? Well yes there's a good deal of shared stuff. It may or may not be useful to completely merge the two things but I've got some pretty funky virtualization stuff and I think it basically runs all the time on Zen. And I think there's probably the functionality there what you need to do is get the interface usable to a state where view parts can use it and then anybody who's got a Zen install and it's reasonably there's a sort of reasonably flexible sort of plugable virtualization thing. So if you just want to run it locally you don't have Zen, you can use a churrut or you can use Zen if you've got a Zen or whatever. So I think that's probably in terms of a detailed discussion is more of a case of us both sitting down and reading each other's code and documentation than a thing for this boff. Okay, fair enough. So as regards functional tests I've looked at Ian's framework before and agree that it's necessary to test the installed package rather than some build time thing that may or may not completely fail later. But as a matter of, as a pragmatic matter of getting lots of tests running I was struck recently by the general usefulness of DH Auto Test which is a fairly new thing in Dev Helper 7 and I wonder if that would be useful to wire in. It's anything that uses Dev Helper 7 will be using it probably by default but the test output will only really wind up in the build log and it might be useful to have it somewhere a little bit more central. How does that work? I mean DH Auto Test, what does it do? It looks around for various tests that are provided by upstream that it might be able to run. At build time. It's heuristic. At build time. At build time. Save. All of the DH Auto commands are, they're called that because they're heuristic in some way. Yeah. The problem here, integrating this with few parts would be difficult because few parts but certainly there's a lot to be found somewhere and acted upon. I've been missing functional tests because any test at build time test the upstream software and what we are interested in here in testing actually the packaging of the upstream software I mean presuming already that the upstream software works so I'm surprised to find out there's a framework and I'm really interested in that. Right, so it's called Auto Bookage Test. Auto PKG Test and I'm not entirely sure whether the version that's in the archive or my public tree is exactly the same one as I'm running but you can email me about it. The big problem with it is precisely that if you've got some functional tests that you want to hook in it'll provide you with a framework for running them and if you upload the package with the tests in I'll even run them for you occasionally but nothing really very useful will happen with the output at the moment. Could we perhaps find a situation where if there is a problem running those tests that the maintainers and uploaders are automatically emailed about them. I asked about this on Debian Develop and there was some hostility to well it wasn't exactly clear what the hostility was towards. Well perhaps, yes. Another thing to do might be to use the PTS email preferences system and I'm not sure whether we should this would be a thing that people will be described to by default but certainly I could already very easily just email the PTS. I think if you put it on the PTS page like PU-parts is now integrated there that people either can pull from there or get an email if they want to but PU-parts also doesn't mail failure to the maintainers because I think that would be possibly if there's a bug that will be 100 of mails sent and 100 of people annoyed so I would rather not do it. Right, so if you break some lower level package that does, you do really notice this right if Lipsy is broken then I see this in my logs and I get a whole pile of emails saying well you know this is broken and that is broken and the other is broken and you know actually I'm not entirely sure that would be too bad a thing because you know you firstly the person who broke it would suddenly get lots of attention and secondly the bug would suddenly get lots of attention. On the other hand the other package tests are added to the package by the maintainers so I would expect them to want to know about failure. That's true however at the moment because it actually does a build it builds and installs the resulting package before it discovers that there are no tests just I mean I did that deliberately so I am doing build and installability testing already and if you want to do functional testing as well there's a whole framework for defining that. I don't think email should be sent just email, I think bug should be filed and that will result in emails then I'm fine with emails and to file this bug there need to be tools to analyze the output and then humans to validate it because then we are automatic bug filing which is probably... Well at the moment I don't have the effort to deal with that kind of output I mean essentially what's happening at the moment is the emails going into my mailbox and I'm ignoring them because there's too many of them and I can do better stuff than I should fix the program to make these emails available to other people and that should be higher on my list than going and chasing up individual bugs. At PU-parts it has at the moment 300 bucks in SID or 350 or something so if I file them manually and I file one a day I'm done in a year which is not so good but on the other hand when Lukas started doing PU-parts mess runs on the archive two years ago he really filed several hundred of bugs which were all the same and those got fixed and the archive became cleaner and I think filing bugs is the way to go and dealing with these log files is why I'm at the moment not working on making the performance of PU-parts Debian org better by using AVM containers or whatnot but because I rather need to spend time to deal with the output which is there with the current speed and the solution I see there is to get the log files analyzed by more people than me. So can one currently just browse the output of PU-parts and go rather than hunting through for each of the 50 packages I maintain here Yeah there's PU-parts.debian.org which has all the log files and there are pages for each source package and there are also pages for each maintainer or uploader so there's somewhere Colin Watson page with all your packages. I mean this may sound very lazy but if anybody fancies getting on the CC for these emails that I'm currently getting and ignoring and thinks that they have time and effort to look them up so it's very formulaic and it may only take 10-15 minutes each one but if you're getting 10 a day that's rather too many to deal with and some days it's none and some days it's 50 Perhaps a mailing list for the time being Yeah having them public would be good I agree. Debian develop is a mailing list Debian develop announce On the whole I think emailing the package tracking system would make the most sense because it's an existing mechanism and people already know how to subscribe and unsubscribe or people know where to find the documentation how to do this because it's weird but it's there and it's worthwhile using and in fact this makes more sense than emailing the maintainers directly because then other people interested in that package can also subscribe easily How easy would it be to extend your stuff to support say KVM? Pretty damn easy I would say The thing that is the functionality that I don't know how to provide in KVM that's not because I think KVM will find it difficult is essentially snapshotting and resuming a VM Now this is something that QM you can do so I imagine KVM can do it but No I've done it So you need to be able to because you don't want to have to boot the VM every time you run a test so you want to snapshot in a kind of booted running state and then resume it That's an interesting speed of my session I will have to copy Yeah so I'm able to instantiate you know wipe all output of the previous test and instantiate a new VM and it takes a couple of seconds Sure A couple of seconds is about as fast as it takes the Piatti machine to unpack a pre-made tarvol for a C-shoot So in fact on Piatti it makes no sense to keep using C-shoots I learn new things every week When I was younger it was every day but I'm older now Right and because of this approach what the tests run in a they don't run in a churrut they run in a properly normal booted system that's got you know it's good enough to run an SSH server because that's how the test machinery talks to the test bed Sure and I'd like to have that as well Well actually I want to have I also want to test the case where we don't allow services to be started within the virtual environment because when I first started doing that it brought up a number of issues in a number of packages Every time you start doing some kind of systematic testing on a large code base you find new stuff Yeah some of that stuff is quite exciting Running it with a properly booted system does seem to help a lot I do have problems with kernels though Anything that attempts to install a kernel I can't really cope with because the way that the Zen guest boots doesn't really I don't have it set up to use Pygrub In terms of wiring this into PU parts it's just a question of what interface do you have an internal interface to how your Chiru works or is it all just like scattered through the code Let's assume that PU parts doesn't exist yet because I am going to be rewriting it Right Yeah in that case you should probably look at the interface I've defined which is basically you run this program and then you sort of talk to it to tell it what to you have a child process which acts like a server for the testbed and you can send it commands like open the testbed and grab it for me and throw it away again and tell me how to SSH into it I looked at auto package test years ago then I was still actively working on PU parts and I thought it was very impressive and definitely defined by you in a very good way but I didn't have time to actually look at integrating it which I probably should have but time goes Fair enough So maybe you and I could sit down today Sure, I'm not here tomorrow so today We've had a lot of talk between Ian and Colin and do you anyone else want to say anything What's the one thing you've always wanted to have from an automated package tester That's not entirely a silly an idea as it could be This is slightly facetious but always that other people are running it as in, you know, I've tested testing its own packages is one thing but what you really want is that Debian as a whole is using it effectively and so the most important thing seems to me to be odd reach and making sure that it's in a state that people are running it as a matter of routine or at least looking at the output as a matter of routine I would really love to see everyone run all the available automated testing on their packages before an upload Before an upload is good but at all It's better than nothing Even at all it's fairly hard to achieve right now One of the problems is that Xen and KBM and PEOPART tend to be fairly rough on a net book and a number of people are still relying on low end machinery to run things, that's why we have I intend to do that really to file those bugs which are there now, these are 300 and then there will be whatever 5 new bugs a month and I can easily file those and if there are 30 then it's a mass bug filing But it would be, sorry it would be a really good thing to have some kind of bay of not making sure not tracking that everyone does this but having a culture where doing this is natural of what you do anyway should be integrated into PEE builder PEE builder and PEE builder runs PEOPARTs automatically after it They build long runs lintien after building a package you could perhaps have that happen 8s I will not have to file 5 bugs a month but suddenly it will become 10 and 20 Something else I wanted to say is that the faster a test method is the more likely I am to run it Lintien is just about on the edge Debuild runs it so I put up a bit of it and it's sufficiently useful that I put up with it if it were if it took 5 times as long then I would probably control C at most of the time Yeah, I know that feeling Auto package test is really rather on the slow side for that because typically what it does is it takes some version of the package and builds it and maybe not necessarily the package that you are testing if you have got functional tests often you find that you have bugs in the tests so you need to be able to update the tests and still test the old package and that means that sometimes you end up building two versions of the package and it's all a bit slow really Something that we perhaps could do is have Debuild not run via parts but check whether there is an existing problem and check the change log whether it has been fixed So yeah, I do have a sort of slightly sophisticated because it takes so long but my expected time to scan the whole archive is months I've got a thing that tries to guess what would be a good package to do next based on does it have a bug open that was related to auto package test and if so, well why bother since the bug hasn't been closed or what version was it the last time we tested it and has it been updated, that kind of question Yeah What's our estimated time for running of an entire archive? A month So yeah, all of these things are slow But I'm sure on that hardware it can be with AVM snapshots can be improved by factor 3 or something because it's untas the base system all day Yeah, that seems like a thing that should be possible to optimize away possibly using the virtual machine snapshotting Right, the time consuming part is entirely the build and that means I haven't really optimized very much the sort of infrastructure but if all you want to do is install the package then the total overhead is 5-10 seconds maybe in terms of selecting a package instantiating the VM, SSH copy the package across install it, throw the VM away Very little of Yeah, you could basically do that in the time it takes to install the package Yeah, if we assume 10 seconds per package then that would be 8000, 8500 per day which is very impressive I think I want to do some coding now So, any other blue sky kind of suggestions for automated testing of packages Has anybody looked at integrating any of the desktop testing approaches into, perhaps more into auto package test than into pure parts because you'd be talking about functional testing at that point I have no idea if anyone has looked at it but it definitely should be done Things like, you know, start the start the program up, press a couple of buttons see if it explodes, entertainingly It's amazing that See if it starts up, in fact, just come to that It's amazing how many times you find problems even if the only thing you do is start up firefox because that tests an entire stack of things that can go wrong and back when I was slightly younger the stack on an MS-DOS machine was there was a bias there was sort of MS-DOS on the side and then there was your code These days we have slightly higher stacks of abstractions and code and stuff that gets foggy all the time And many of them are wobbly and fall over at the slightest provocation I was not referring the compass here But yeah abstractions and libraries, as I said, are really good but there is a problem with making sure that everything works together And sometimes you have problems where I had one case, I forget what package it was early on in PewParts testing where package true would work when installed and gone through the entire testing and package bar itself would work but it depends on foo and foo breaks if bar is installed resulting in viernas And this is the kind of things that would be nice to catch before user's catch it in a release But that's what I was saying even if people aren't running it before upload which obviously helps anybody running unstable and avoids slowing down developers and so on But even if people don't do that dealing with trying to catch things before they get into a release is hopefully the ultimate I would like to catch before they go into testing and then automatically or semi-automatically file a bug saying that there is a serious kind of problem that PewParts or other package test has found Please don't let this package go into testing until it has been fixed You mentioned the expected time to run over the whole archive Seems to me that perhaps a slightly more interesting question is can you keep up with flow and unstable Easily We can do about a thousand packages per day It's fairly rare day when a thousand packages get uploaded Excuse me while I go and make some uploads Please do Auto package test is more in the order of a hundred packages a day depending on whether today's list of packages includes open office Yeah, so that's a bit iffy But basically often you upload something and then it won't quite get around to testing it again and then somebody will upload it again so it's a bit one version and that it degrades relatively gracefully I think Out of interest What kind of hardware do you run it on? At the moment it's a dual processor P3 866 How much memory? A gig I think and nearly all of that is assigned to the testing guest obviously So on the order of the same as as the Piatti machine I think No Piatti has 4 gigs now I think and 2 gigahertz to a core or something Okay, what do I remember? And then the memory really makes a difference Yeah But Piatti does It puts us huge amounts of IO so memory helps Yeah, if somebody wants to give me access to a nice fast machine then I can stop having this thing wearing away and my under stairs cover making the house warm We might be able to point at someone who has access to a machine Yeah, but loading the machine was that then we cannot be rebuild the archive so fast every rebuild test Yeah, well, we'll see But Debian has more hardware access It would be actually nice to have this test run on more architecture because, for example I know like right now it doesn't work on alpha because I got bug report but I cannot test it myself beforehand That is certainly true The way the package are tested by PewParts is that I wrote well I wrote PewParts then I wrote PewParts master and PewParts slave and the PewParts master tells the slave which package is to test and we could run these either a pair of these master and slaves either per archive or have a setup where which would be slightly faster where only architecture specific packages get tested by this but if you already have a bug where an architecture old package or sorry architecture any package fails on alpha but not on some other architecture then it might be worthwhile to look into having more of this architecture supported by this The question is then where do we get the hardware Well Debian has a lot of money But where do we get the hardware to test very slow architectures or packages that is really the issue The binary packages should be the same on all architectures and I see the greater risk of difference there that there are still manually built packages accepted into the archive the uploaded packages are not rebuilt on auto builders and I think that should be changed to make archives more similar and sure of course it would be great to test all packages on all architectures but I think for the first step should be to test the architecture specific packages only on the other archive architectures But if we can get that then we could also add things like if you get such a bug report that you can request testing of that package on all architectures Buying alpha hardware is slightly hard these days unfortunately because they make very great heaters I admit once a machine that had an alpha CPU that burned for hard disk because ventilation wasn't good enough So in terms of other architectures I mean if we've managed to get something auto package test like working with KVM like it's the sort of Zen booted system snapshot thing if we get that working with KVM KVM is essentially just an accelerator for QMU and this means that in principle we could boot the entire system an alpha system or M68K whatever under QMU and do all of the tests whole build everything and obviously be a bit slow but maybe useful That's a very good point I haven't thought of that and slowness is irritating but having it work slowly is better than not having it at all and again if we do only test architecture specific packages on that plus by request something else then hopefully no one wants to build open office under QMU instead of M68K Possibly It is faster See, I've learned two things this week But anyway, yeah Sure, that sounds like a good idea Is there anyone here who would like to be spammed by all the test results of their own packages every time something happens If there's a failure, absolutely But not successes Or something that looks odd But yeah, if it's just everything is peachy well, it's not that exciting I mean, at least for me Okay, I would find it very exciting to know that my package installs I would assume that if it didn't I would get a mail Oh yeah, your packages actually have users Yeah, exactly what Lars said I do sometimes wonder Is anybody with me actually using this and then sometimes you discover bugs and you think either everybody who uses this program hasn't upgraded to this version yet or nobody is using it and so getting a mail saying I tested this package and it installs that would actually be useful Maybe it would just be enough to send them by default with some easily prockmailable out filter to packages Before you came, we actually discussed sending them to the BTS which has a filtering system Right, exactly, and that's the optimal way to do it Yeah, now that you're here and you know everything about the bugs is there if we wanted to start doing automated bug reporting from pure parts and auto packages and possibly lintien and rep and other things is there any advice you can give? Is that varying as best as underwear? Yeah, the main things that would be useful is to set up a set of user tags and a user that you guys use that's common to you that identifies these bug reports so that way it's possible for somebody who is interested in them like you guys are because you want to see what's going on with them whether they've been fixed what people are doing with them that way you can select this whole set of bugs so once you submit them include a user header for whatever makes sense for pure parts and then user tags that are appropriate so like if it was an example it failed an installation or something like that totally up to you of course and that way you can select this whole set of bugs very easily and you can discern between the different types of errors and see whether people are fixing them and everything and that's the only advice that I could give I mean people are going to respond and say I assume if you're finding these sorts of bugs they're actual real bugs and that users would be finding them and filing them and at least in this case it's a comprehensible report as opposed to a user telling you some random failure that doesn't tell you why it failed and it failed actually for a different package Yeah, like deep package Yeah Something I once thought about was whether it would be worthwhile to have a non-user tag indicating a automatically filed bug I mean I wouldn't have a real problem with it my general method of dealing with proposed new user tags is to require that they first be implemented with user tags and that basically sort of forces the impetus onto other people but if you have a set of bugs that are filed with an appropriate user tag that have cohesive existence and there's a rationale behind it then generally I'm open to adding new tags I just generally won't add new tags until somebody is proven to me at least that they're going to use them because otherwise it just makes it more complicated and it's a waste of time and that can be implemented as a user tag automatically filed bug Yeah, it's at least a start I mean if a bunch of people use it then it's definitely something that we could think about The reason I'm thinking about that is that filing even semi-automated bug reports is a fairly large amount of manual work and manual work tends to be things that we do too much in the BN Yeah, it doesn't scale So yeah, maybe that's something that could definitely be done I mean if it ends up being useful so I mean I wouldn't have a problem with it Okay, I guess we are done one minute early possibly 90 seconds Thank you everyone