Improving our processes for new contributors.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 15, 2015 at 11:05:40AM -0400, Przemek Klosowski wrote:
> When I looked into packaging, I found extensive documentation but
> very few tutorial-style materials. I like the hands-on approach so I
> wrote a 'user story' about packaging a simple project:
> https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
I made some tweaks to the text. I think it is a reasonable introduction.
 
> I think this is a good approach, and could be extended to describe a
> complete submission process (adding the package in COPR, applying
> for maintainership, reviewing, etc).  Anyone wants to collaborate on
> that?

--

One thing which I find very annoying when creating new packages is the
need to use bare rpmbuild commands. I find the split between
~/rpmbuild/{SPECS,SOURCES} anachronistic (*), and much prefer the
fedpkg / distgit approach of having everything in one directory.
I now usually use the single directory approach from the beginning:
- git init new-package && cd new-pagkage
- emacs new-package.spec &
- spectool -g *spec
- md5sum ... | tee sources
- git add new-package.spec sources && git commit -m 'Initial version'
- git remote add ssh://pkgs.fedoraproject.org/new-package.git
- fedpkg --dist master {srpm,mockbuild,etc}

Without the fake remote fedpkg fails. I am wondering if there is a way
to achieve this in a simpler way, or if not, if it would be possible to
modify fedpkg to support packages which are not part of Fedora out of the
box. IMHO this would make the process easier and more consistent for
new (or existing) contributors.

Zbyszek

(*) Because of the multiple directories it is harder to find stuff.
    It is impossible to use version control on the spec file.
    Tools like 'spectool -g' download stuff to the current directory,
    so it is necessary to move file around afterwards.
    And most importantly, this setup is only used temporarily, before
    the package is reviewed and approved.