Improving our processes for new contributors.

[Vít Ondruch]

Dne 17.7.2015 v 00:28 Mikolaj Izdebski napsal(a):
> On 07/16/2015 07:53 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> 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.
> I use simillar workflow of creating new packages, but I have a shell
> function which I use to init git repos for new packages.
>
> # Usage: newpkg <name>
> newpkg()
> {
>     cd ~/newpkg
>     git clone git at github.com:mizdebsk/newpkg.git $1
>     cd ./$1
>     git push -u origin master:$1
>     touch $1.spec
>     git add $1.spec
> }
>
> After initializing new git repo this way all important fedpkg commands
> should work, except for uploading sources. I simply don't bother
> creating "sources" files as sources will need to be uploaded later
> during import.
>
> So my workflow is as simple as:
>
> newpkg foo
> emacs foo.spec
> spectool -g *.spec
> fedpkg --dist master srpm
> mock ... foo*.src.rpm
> fedpkg commit -c
> git push
>
> Pros:
> 1) workflow uses fedpkg, without rpmbuild or manual md5sum
> 2) no need to upload spec/srpm to fedorapeople for review - you can use
> github and koji URLs, respectively, as seen in [1].

Using FPo instead of GH, but I don't like the koji SRPM link, since the
build will get garbage collected soon and it might become invalid even
prior the reviewer starts the review.

Vít


> 3) future co-maintainers can easily collaborate (open pull requests)
> before the package is accepted
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1242328
>