El jue, 15-02-2018 a las 17:34 -0500, Matthew Miller escribió:
As shown at https://www.happyassassin.net/nightlies.html
had a successful compose for almost two weeks. AIUI this is mostly
worked out now, but it raises the question: who should be keeping
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?
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
0.02% per person and rounds down to 0.
Or if the answer is: "Matthew, you are the FPL. It's you!" … then
but I'm going to then have to find some way to turn around and
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.
least, if it was someone who isn't already deeply involved in that.
thinking probably someone selected from FESCo — but it also could be
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
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,
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
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
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