On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Thu, Nov 29, 2018 at 10:22 AM Paul Frields <stickster(a)gmail.com> wrote:
>
> On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý <msuchy(a)redhat.com> wrote:
> >
> > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a):
> > >> In other words, the "technical debt" we are trying to solve
here is
> > >> not project wide and doesn't justify slowing down the whole
project
> > >> permanently.
> > > I completely disagree. Our release process and tooling is built on
> > > heroism and tech debt.
> >
> > People working on release and people working on packages maintenance are
different group - they are not disjunct, but it
> > is not the same group.
> > For example *I* am a maintainer of lots of packages, but the additional works
because of the fedora release is about one
> > working day per year - and it is mostly because of fedora-upgrade package.
Other packages do not need so much work. I am
> > more affected by upstream releases.
> >
> > Do not forget that annual releases will mean that N-1 release will implicate 24
months support for packages which will
> > mean a much more significant impact on us-the maintaners.
I'll echo what Paul says below with a +1, but I wanted to touch on
this point a bit because it implies an assumption that the maintenance
model remains the same even if lifecycle options change. I don't
think that needs to be the case, nor do I think it would even be good.
Of the large number of packages that you maintain, how many of them
are critical to freeze at a specific version for a given Fedora
release? Possibly some, but I would think across the distribution it
would not be a huge number. So if there is no essential need to
freeze them at a specific version, why would you want to maintain the
packages *separately* for each release? That sounds like extra work
for no benefit. If we instead take a maintenance approach that you
maintain package foo and it is built for all releases, then you only
really need to maintain it in a singular instance.
Today that is something that can be accomplished with modularity, but
I would suggest that we look at stream branching as a solution even
for regular packages. So you wouldn't have fc22-fc32 branches under
package foo. You'd have foo/stream-<version> and you could build that
wherever you'd like. Couple that with automated CI testing and I
believe you actually decrease your maintenance burden while increasing
your quality.
There are many details that would need to be worked out and I don't
want to trivialize them, but I do want to at least get people thinking
about it in the long term. If we are going to improve the way we
build and deliver our operating system, we shouldn't assume we can do
that without changing the way we maintain it either.
We can change this _today_, actually. fedpkg supports an in-repo
config file to specify distro targets to push whenever running `fedpkg
build`. So you could do a repo with only a master branch and have it
push to all distro targets enabled for the repo at once. This is
probably a useful optimization for the overwhelming majority of
packages held by packagers.
It's just not documented or available as an option for setup when you
file a repo creation request.
--
真実はいつも一つ!/ Always, there's only one truth!