On Tue, Jun 6, 2017 at 4:47 AM, Michal Sekletar <msekleta@xxxxxxxxxx> wrote: > On Tue, Jun 6, 2017 at 7:14 AM, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > >> So what would be your workflow here? You would start update of the >> package by "fedpkg upload" to upload the new tarball and let dist-git to >> explode it? And what would be next? > > My ideal workflow would be to use pagure (repo with exploded source) > just like I use github/gitlab/bitbucket these days. Hence if I am > owner I commit directly or perhaps I file pull-request against the > package source. Then once commit is merged, package maintainer tells > koji to build the package. Note that Koji *has* support to build > directly from git repo referenced in your spec. We just don't use this > feature in Fedora, because up until pagure came along there was no > suitable code hosting/collaboration platform available to Fedora > package maintainers. > >> >> I thought that the exploded tree would be more passive, i.e. it would >> mirror just the basic tarball, possibly each Koji build would result in >> some release branch containing also the applied patches, but it seems >> you want to use it more actively .... > > Not only more actively, I would like to use it almost exclusively. > > In my opinion move into this direction would be hands down the best > change for package maintainers in years. Also I personally think such > possibility is also necessary if Fedora wants to attract new > contributors in era of Github. Because let's be honest, plain dist-git > (spec+patches) is just terrible experience compared to what people are > used to upstream. > I'd really rather not see this become a thing. There are five big reasons why I don't want this to become a thing with Fedora packages: 1. It encourages monkey patching and desynchronization from upstream. Given our philosophy, I'd rather it be more explicit and obvious that something is patched and altered, because the mere *burden* of patching should encourage us to track upstreams in general and fix things there. If you *are* the upstream, then you should not be making downstream forks of your own project. That's just dumb and can create all kinds of weird issues down the line. I have this problem with my software packaged by Debian people and it's very aggravating. They do fixes and don't bother to talk to me until they literally break everything, and by that point I don't feel particularly charitable anymore. They made their mess. I don't want us to become like that. 2. We actually have decent tooling for tracking more than one VCS repo in parallel now. Tools like tito and rdopkg (which sadly isn't in Fedora and doesn't support Python 3, boo!) can concurrently track and enable better management of the code and packaging when they are in separate repositories. 3. Pagure is already a huge disfavor for people who prefer non-Git VCSes (I personally prefer Mercurial whenever I can use it, and I've heard of people jumping onto VCSes like pijul, which has an interesting and different model of source control that doesn't map to Git at all). 4. I don't particularly want to have the same kind of terrible squawking that goes on in Debian about "how to structure code + packaging" for a package that often leads to nothing getting done for months. The fact we use Git for packaging is irrelevant and immaterial to upstreams, and they can use whatever they want. If we want the "user experience" to look like an exploded tree (like what "dpkg-source -x <file.dsc>" does), we could make tooling to support that, but I would not want us to go down the road of actually maintaining that merged tree ourselves in Pagure. 5. It makes things worse when we have to scrub code. Debian has the lovely option of fancifully ignoring software patents because they make no money and there's no point suing them. We don't have that. Red Hat essentially owns Fedora for all legal purposes and they inherit the packages we have for Red Hat Enterprise Linux. That means we scrub code *before* uploading (freetype, chromium/qtwebengine, gst plugins, etc.). With the current model, this is easy to do and maintain. Merged trees make this much harder. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
