El jue, 15-02-2018 a las 17:34 -0500, Matthew Miller escribió: > As shown at https://www.happyassassin.net/nightlies.html, we haven't > had a successful compose for almost two weeks. AIUI this is mostly > worked out now, but it raises the question: who should be keeping > track > of this and coordinating fixes? For the releases, the blocker bug > process basically handles this, so functionally the ownership ends up > with QA (and the various heroes of QA who then track down all the > problems). For rawhide, we don't have any such thing. Is it rel-eng? > Is > it FESCo? Is it the FPgM? Is it QA after all? > > I suspect that right now, the answer is kind of "It's all of us > together", which unfortunately practically speaking often comes down > to > 0.02% per person and rounds down to 0. > > Or if the answer is: "Matthew, you are the FPL. It's you!" … then > fine, > but I'm going to then have to find some way to turn around and > delegate. :) > > I was chatting with Kevin Fenzi and he suggested naming a release > manager for each release — someone who would keep track of stuff > starting at branch, and help coordinate things like this. > > This would help with more than just Rawhide — I'm sure everyone > involved in the blocker bug process would be grateful for more help. > At > least, if it was someone who isn't already deeply involved in that. > I'm > thinking probably someone selected from FESCo — but it also could be > a > way for people with the particular set of skills required here to get > involved in a way that's different from FESCo membership. > > What do you think? I think you are putting the cart before the horse slightly here. We have a few issues that we need to address and that we have to fundamentally step back and rethink how we put Fedora together. I feel that your statement makes an assumption that how we do things today is okay. A fundamental issue we have today is that we have no way to test the changes as they come in. As a result we hit apoint right before branching where people put in a lot of change all at once, with the result being it breaks things, we then get into fire fighting mode. Having a project manager to stay on top of changes and change management and trying to balance the change and get people to submit it ealier may help some, but it would not fully address the issue of making sure that the change is good. I strongly believe that in order to really address the problem we need to take a step back and look at the factory we have for making Fedora. Today in order to make and ship Fedora we have a process that starts by gathering by gathering together all of the rpms we have built, putting them into a place so that we can feed them into making the anaconda run time. Once we have the anaconda runtime we make the distribution repos for the rpms and start the ostree creation. we then create the Cloud images, containers, install dvd's, arm disk images, livecd's etc. The entire process today is configured as a big blob. It requires that the release engineer configuring the compose understand the end to end process on how we build and ship everything. What the inputs for each piece is, the expected outputs, and what pieces are required to make other pieces. The way we have set things up means that the amount of knowledge needed to be effecive is massive. If you compare it to a more traditional process, say a restaurant, you would have to go and pick the fruits and vegetables that have been planted by someone else, plan a extensive menu, answer the phone and take reservations, start cooking the meals, greet the guest and seat them, take drink orders, go make and deliver the drinks, take the meal orders, then go cook and plate the meals, serve them to the guests and refresh drinks, make sure that everyone is happy, once they are done eating clean the tables, and take desert orders, go make plate and deliver desert, make any coffee or tea thats required, deliver to the table, once the table is done, you generate the bill, take it to the table, collect payment, then clean up and do all the dishes after, wash the table linens and get tings ready for the next meal. If anything goes wrong during this process that is run by a single person you get to clean up and start over from the start. That is a little long winded but shows how we have not done the best by ourselves in how we have built and designed the delivery of things today. Restaurants do not work in the way described by a single person, neither does a car get built by having someone design then build the car and get it out the door. It can work for special boutique offerings, it does not scale well for wide spread distribution. I would like to have us look at not only the processes for how we build and ship the distribution. I have some ideas for how we can keep the important pieces of how we build and ship things today, but give us the flexibility to have the peices be more independent and controlled. Some of the work is happening in the CI/CD work that is happening, we need to be able to test the changes as they come in. If you make a change that breaks our ability to create the anaconda runtime, you should know about it within minutes, today you may never know your change broke our ability to compose or deliver Fedora. Adam, Kevin, Patrick or someone else may just go in and fix things or make adjustments to other packages to cater for your changes. We need to build the end user delieverables smarter and more frequently, if we did this right we could then be sure to get proper notifications to the people that care about the various deliverables. A weakness we have today if you care about a piece of Fedora say the Xfce spin we have no way to tell you that changes broke the spin, you have to actively look that it failed to compose. We also build many of the artifacts we deliver every day, not because something changed, but because we do not know if anything changed or not so we err on the side of we need to build it. This is all a very long way of saying that I do not believe that having one person assigned per release is the way to go, but that we need to step back and redesign many organicly grown pieces and reshape the factory that is how we make Fedora. Increase the reliablity of the individual pieces and enable people to specialise in the individual areas that they are interested in. Some of how we work today is better than in the past, there is a long way to go. We may even need to take a time out in order to focus on making fundamental changes to how we manufacture Fedora. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
