Re: Fedora Lifecycles: imagine longer-term possibilities

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

 



On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny <clime@xxxxxxxxxx> wrote:
> >
> > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny <clime@xxxxxxxxxx> wrote:
> >>
> >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek <ttomecek@xxxxxxxxxx> wrote:
> >>>
> >>> > * Matthew Miller:
> >>> >
> >>> >
> >>> > Make it cheap to maintain branches.  I expect that one what to achieve
> >>> > this would be to build directly out of Git, with synthesized release
> >>> > numbers and changelogs.  This way, you can apply a lot of fixes to
> >>> > multiple branches without encountering mandatory conflicts.
> >>>
> >>> We are aiming for something similar what you just described. I created this wiki page to describe the work briefly:
> >>>
> >>> https://fedoraproject.org/wiki/CI/source-git
> >>>
> >>> The actualy work is happening here now:
> >>>
> >>> https://github.com/user-cont/source-git
> >>>
> >>> We would love to take development off dist-git (but keep dist-git!) and move it to git repos with real source code which match upstream repositories. In such repo you have branches which track respective Fedora versions -- you can easily cherry pick fixes. We would validate every pull request in such repo and stuff would get merged only when it passes testing. Right now we are trying to write minimal code to make such thing work, evaluate it and present at devconf.cz to get some more feedback.
> >>>
> >>> Hopefully we would utilize clime's work to help with changelogs and release numbers: https://pagure.io/rpkg-util/pull-request/15
> >>
> >>
> >> So that would be cool if my work is actually used. I recommend looking at https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could use that.
> >>
> >> I planned to open a PR for python-rpkg do enable this functionality in Fedora but I am being delayed by work on rpkg-3.0, which is yet another *pkg client.
> >>
> >> Anyway, if there is some interest in making this available in Fedora soon, I can happily do it first. Just kick (contact) me.
> >> To be clear, the macros can only do the second point from "What and why?" at https://github.com/user-cont/source-git.
> >
> >
> > The README was changed meawhile so the second point from here: https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md
> >
> 
> The problem with merged source trees (aka source-git) is that it
> implies forking projects. It's an easy trap to start having vendor
> trees and maintain your own functionality independent from upstream.
> Fundamentally, I don't want having patches to be too easy, because
> then people _will_ do that. Fedora should strive to remain close to
> upstream projects and interact with them to make things better[1].
> 
> And the thing is, it's not like I'm unfamiliar with merged source
> models. I've worked in distributions that operated that way, and the
> consequence is almost always that things are patched and changed
> without ever interacting with upstream. Of course, that's their choice
> to do so, but most distributions do not have "upstream-first" as a
> specific goal.

IMHO this is an overly negative view. It is making a presumption
that package maintainers are in general bad at what they do and
must be made to jump through hoops to "force" them to do the
right thing, no matter what the cost to good maintainers.

I think we should design our systems around a positive viewpoint,
where package maintainers are in general good at what they do
and make life as easy as possible for those people.

No matter what we do there will always be maintainers who don't
do a good job at sending stuff back upstream. We see that today
in places but they are a minority. Most people learn pretty quickly
that updating downstream-only patches to work with new versions
is painfull and so it is in their own interests to get stuff
upstream.

Even today though, we could  & should do more to identify where
we have problems. ie something that looks at patches applied in
Fedora, and reports on how long they have existed for, and across
how many version rebases they've existed. This could show places
where extra help / push is needed to get stuff back upstream.

> In addition, it may seem like it makes things easier (and maybe
> faster), but it actually makes things much harder and slower for
> everyone else. Merged source trees make it so that it's stupid easy to
> have light forks of everything, which means people will just patch and
> change things without consequence. That makes it much harder to
> identify changes for rebasing to newer versions, what's safe to drop,
> and so on.
> 
> I know this because it was a problem where I work before I banished
> merged source trees where I work, and it remains an issue for Linux
> distributions that operate this way too.

You can't actually "banish" merged source trees in practice. At most
you end up pushing them behind the curtain where you won't see them,
but they still very much exist. There are already packages maintained
this way with dist-git merely getting automated imports of patches
from the merged source tree. I maintain my own packages this way
whenever I need to pull bug fixes back to Fedora from upstream.

> When patches are a burden, you will only do it when needed, and you
> feel more compelled to try to avoid it. Ironically, that makes it
> easier to move faster and update more frequently.

This is assuming the main use of patches is to add non-upstream
changes to Fedora. The more common use of patches is likely to be
backporting of fixes already existing upstream.

IOW, when patches are a burden, the maintainers are less likely
to fix bugs present in Fedora, even if the fix is available
upstream. This is counter to what our users want/expect.

> I have not yet seen a practical example of merged source trees
> improving the quality of package maintenance.

I'll have to disagree on this. I've found merged source trees to make
it significantly quicker and more reliable for me to get fixes from
upstream pulled back into Fedora packages. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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