Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El lun, 26-11-2018 a las 19:44 -0500, Paul Frields escribió:
> On Mon, Nov 26, 2018 at 5:47 PM Dennis Gilmore <dennis@xxxxxxxx>
> wrote:
> > El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió:
> > > Because the people that would be tasked with doing the
> > > development are
> > > also tasked with cranking out the release.  It's a "need more
> > > people problem".
> > 
> > This is no longer entirely true, development of the compose tools
> > is
> > done entirely by PNT DevOps today. Bodhi and other tools in parts
> > of
> > the delivery pipeline are developed by people in Fedora Engineering
> > who
> > also have other tasks to do.
> > 
> > > > ready to go. Ultimately a lot of those sort of ways of
> > > > optimising
> > > > things are things that have been known for some time but no one
> > > > has
> > > > actually stepped up to do the dev work and it it into
> > > > production
> > > > shape. Stopping the standard distro work won't miraculously
> > > > make
> > > > that
> > > > other work happen and appear.
> > > 
> > > Well, I kind of disagree.  Barring magical people that appear out
> > > of
> > > the woodwork that know how the tools work and how they need to be
> > > improved, I don't see an alternative.  Not doing a release to
> > > focus on
> > > our tech debt seems like a good tradeoff.  If there are others
> > > that
> > > really WANT to continue cranking the release with the tools as
> > > they
> > > are today... that might be something that could be pursued.  It
> > > would
> > > still require net new contributors to a critical area.
> > 
> > We would need to engage with the team working on the compose tools
> > and
> > see what time they can dedicate to meeting Fedora's needs.  Likely
> > a
> > end state needs to be defined. then the work can be scoped.
> 
> There are a lot of assumptions wrapped up in these statements. I'm
> not
> sure we should be assuming that delivery mechanisms ought to all be
> tied to internal Red Hat teams. This might be a good opportunity for
> us (meaning people variously assigned in both places) to think about
> whether we should try to decouple more of our delivery side (compose,
> push, etc.), while keeping a tight bond at the build/test side.

There is a lot of assumptions in your assumptions, language is hard :),
I was trying to outline where things are at  not at all how things
should be, sorry I was not clear enough there. My main goal was
pointing out changes from where things were 5 years ago.

> The customers RH serves have specific expectations, and in part that
> dictates how delivery tooling is done. Binding the community to that
> may be counterproductive. This is especially true now that RHEL 8
> Beta
> is out -- it's the perfect time for us to be rethinking at that
> level.
Compose tooling is largely shared, delivery tooling is not, though
there is room for improvement and convergence on both sides.  We should
also consider CentOS and how we can share tooling, process and
resources, they still use something else entirely. Everything used in
Fedora is developed in the open and can be contributed to by anyone. 
We have been talking about making the whole process flexible and
dynamic for years. I know internally they would like to have many of
the same things Fedora wants. 

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux