On Tue, 12 May 2020 at 09:47, Tomas Tomecek <ttomecek@xxxxxxxxxx> wrote: > > I haven't responded here for a few days - that doesn't mean I stopped > caring, quite the opposite, I've read every single response but the > thread grew so big that I wasn't able to keep up replying. > > Given all your valuable feedback, we are aiming to come with a plan, > how to provide repositories with unpacked sources ( = source-git) > within Fedora. The next steps for our team are to write the plan down > and then submit it as a Fedora 33 change. While we'll be working on > the plan, we'd review this thread in-depth and reach out to specific > comments ad-hoc. > I would like to put some constraints on trying to make this a Fedora 33 change. You are going to need to retool parts of koji and other build tools to work with these repositories. You are going to need additional disk space which needs to be spec'd out to exist and how it is going to do. You are possibly going to need other changes to PDC (dead software), bodhi, builders and such. The majority of Fedora infrastructure will be moving from one datacenter to another in June and I do not expect us to be back to 'normal' until mid to late August to add new items. This means the work to do this has to either land in the next 30 days or in September before the checkmark that all changes are done. Infrastructure is already going to be implementing items for the ELN and upgrading various other dead software to newer versions to try and get past the EL6 deadline. With this in mind, I think this would make a better Fedora 34 change versus something you can get done in 2-3 months. > Thank you for taking your time, > Tomas > > On Mon, May 4, 2020 at 5:05 PM Tomas Tomecek <ttomecek@xxxxxxxxxx> wrote: > > > > Let’s talk about dist-git, as a place where we work. For us, > > packagers, it’s a well-known place. Yet for newcomers, it may take a > > while to learn all the details. Even though we operate with projects > > in a dist-git repository, the layout doesn’t resemble the respective > > upstream project. > > > > There is a multitude of tasks we tend to perform in a dist-git repo: > > * Bumping a release field for sake of a rebuild. > > * Updating to the latest upstream release. > > * Resolving CVEs. > > * Fixing bugs by… > > * Changing a spec file. > > * Pulling a commit from upstream. > > * Or even backporting a commit. > > * And more... > > > > For some tasks, the workflow is just fine and pretty straightforward. > > But for the other, it’s very gruesome - the moment you need to touch > > patch files, the horror comes in. The fact that we operate with patch > > files, in a git repository, is just mind-boggling to me. > > > > Luckily, we have tooling which supports the repository layout - > > `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can > > easily inspect the source tree or make sure your local change builds. > > > > Where am I getting with this? > > > > Over the years there have been multiple tools created to improve the > > development experience: > > rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g. > > the way Fedora kernel developers work on kernel [k]). > > > > In the packit project, we work in source-git repositories. These are > > pretty much upstream repositories combined with Fedora downstream > > packaging files. An example: I recently added a project called nyancat > > [n] to Fedora. I have worked [w] on packaging the project in the > > GitHub repo and then just pushed the changes to dist-git using packit > > tooling. These source-git repositories can live anywhere: we have > > support for GitHub right now and are working on supporting pagure. > > > > Would there be an interest within the community, as opt-in, to have > > such source-git repositories created for respective dist-git > > repositories? The idea is that you would work in the source-git repo > > and then let packit handle synchronization with a respective dist-git > > repo. Our aim is to provide the contribution experience you have in > > GitHub when working on your packages. Dist-git would still be the > > authoritative source and a place where official builds are done - the > > source-git repo would work as a way to collaborate. We also don’t have > > plans right now to integrate packit into fedpkg. > > > > The main reason I am sending this is to gather feedback from all of > > you whether there is an interest in such a workflow. We don’t have > > concrete plans for Fedora right now but based on your feedback we > > could. > > > > > > [r] https://github.com/softwarefactory-project/rdopkg > > [ru] https://pagure.io/rpkg-util > > [t] https://github.com/rpm-software-management/tito > > [k] https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/thread/JW4P7FINXXXTOEAHMDTZBVGYZUZMVTWX/#3MLMOTUG5B4F32XIM2YRL3FKVUJNYVRF > > [n] https://github.com/TomasTomecek/nyancat > > [w] https://github.com/TomasTomecek/nyancat/pull/2 > > > > > > Cheers, > > Tomas > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
