On Wed, 1 Apr 2020 at 21:12, Kevin Fenzi <ke...@scrye.com> wrote: > > On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote: > > On Wed, 1 Apr 2020 at 10:54, Vít Ondruch <vondr...@redhat.com> wrote: > > > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :) > > No. > > > This is just hilarious, so after going all pagure for dist-git and > > making it all work, we will now go back to pkgdb, additionally with > > proprietary git backend, lol. > > But pagure doesn't "just work". There's pagure-dist-git that does all > kinds of things to make src.fedoraproject.org have different things than > pagure.io. > > Do you consider pagure-dist-git to be pkgdb 1.5? > > You missed where I said we should adjust our workflow and try and > minimize this layer. I wasn't suggesting we just make another app in > front of the git forge. I was suggesting we move all our "special" stuff > into git or otherwise adjust our workflow to make such a layer > nonexistant or as small as we can. > > How could we do that? > > Well, there was the suggestion from Jermey that we use tags to store > this 'distro metadata'. Or perhaps we have files in each git repo, or a > branch or a seperate repo. This would not only mean we have less to > maintain, but it would mean we could move things much easier, people > could mirror them to another gitforge much easier, etc. > > > I mean if there is some alien race (or a human competitor) watching > > what is happening in one of the leading linux distributions, they must > > laugh hard. Well, we soon won't be leading. > > I think you are misunderstanding me, but sure, laugh away. If you can't > laugh, you have to cry. ;)
I am all for thinning the layer around our base by using git metadata or files where possible but some things cannot be done by it like e.g. links to builds for a given commit, list of actual releases from bodhi, the bugzilla integration etc. But I think it could be suitable e.g. for PDC data. I mean keeping things defined in git is a great goal and it would definitely help to make things minimal. And keeping the tooling footprint minimal can help us to keep our open-source spirit. Anyway, I admit I didn't really understand your email. What you suggested is a good thing to do - a good technological direction but I don't want to be doing this on a proprietary platform that belongs to someone else. That seems to be a huge cut into our identity. pagure is a very well written technology (with a few UI quirks perhaps) and we should be proud of it and continue improving it. A decision like this is likely to make it dead, I mean, guys in the blog post tried to draw some rainbows but we all know what's going to happen. I also think it is sufficient for our needs, whatever the mentioned "stakeholders" wanted I am sure can be done with quite a little effort if the requirements are very well specified. Imho, we should do that instead of immediately switching to some enterprise external hosting that doesn't align with our culture (at least according my view of Fedora, I started to use fedora since around .fc3 and it was a cool and inspiring distribution to me ever since, such feeling can change for new-comers if we don't keep our values). clime > > kevin > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
