On Mon, Oct 07, 2019 at 05:38:51PM +0200, Aleksandra Fedorova wrote: > On Mon, Oct 7, 2019 at 5:21 PM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > > > > On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha <sanjay.ankur@xxxxxxxxx> > > wrote: > > > So I guess I am arguing that while the "new package for existing > > > maintainers" remain at the `fedpkg` level of doing things, the "join > > > the > > > package collection maintainer" page for newbies, who should not be > > > assumed to have prior knowledge about rpm, should start at the > > > `rpmbuild` level and promote them to `fedpkg` when they reach the > > > "import to SCM" steps. > > > > I don't agree. I can probably count on one hand the number of times > > I've used rpmbuild directly in the past five years. fedpkg is much > > simpler, and simple is what we should be promoting to new packagers. > > > > We can all have our own preferred workflow, nothing wrong with that. > > But the newcomers guide should be as simple as possible. Learning > > packaging is complex and the fewer tools that new packagers need to > > learn, the better. > > I strongly disagree with your take on what simplicity is. There > various kinds of simplicity: simple to execute, and simple to > understand. > > Rpmbuild is verbose, it provides more details and information without > wrapping it all in helpers, isolation layers and so on. Thus with > rpmbuild you can easily get, what is going on. I think there's an analogy here to git: git has low-level commands, and it _is_ useful to understand them, particularly when one wants to learn how git internals work. But it is not useful to teach people to use them. Instead, beginners need to learn about git commit, git pull, git push, and so on. We hide the lower-level details because the higher-level picture is more important. Also, the replies in this thread show another issue: we teach people to use rpmbuild, and even long-time packagers keep using such workflows, because they are accustomed to them. This just confirms that teaching a bad workflows early, just because it's "easier", is doing a disservice to packagers. > I'd argue you don't want newcomers to copy-paste three cryptic > commands and leave forever, you want to educate people on what they > are doing. And cutting corners doesn't help in teaching. Right. So we should show the big picture (dist-git for sources, mock for a pristine environment, koji for official builds, reproducibility, reliability of builds, and how this all ties into a general philosophy). If people need to figure out the details of some low-level command, they will do it. Zbyszek _______________________________________________ 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
