25.04.2017 06:16 Globe Trotter <itsme_410(a)yahoo.com> wrote:
[...]
However, if there is going to be an issue with getting it accepted in Fedora
because it has not been around for a while and because it is likely hardly
used by people (because it is at best for WM environments), then I don't know
if I should even proceed.
No, I misunderstood the history of the project because the
GitHub repo says it's been created 23 days ago and has no
releases so far. Having read your more explanations I think
it's probably only a matter of some technical rework.
The project may not be accepted in Fedora because of the
legal reasons. Otherwise I may be wrong but I don't think
there is any threshold of minimum days since being started,
minimum number of users etc.
Ideally, of course, it appears that the best course would be to
version the
software in github itself. I have to figure out how to do this, and would
appreciate any pointers in this regard. I only know very basic commands in
git.
You should choose what is your preferred releasing model
and your spec file must be adapted to the source repo.
It's easier for you because you work on both sides.
I also consider myself as the beginner in git but here
are some links I think may be useful:
* If you'd like to import your project to GitHub again,
now with whole history:
https://help.github.com/articles/importing-a-repository-with-github-impor...
* About releases in GitHub:
https://help.github.com/articles/about-releases/
Also click in this page: Working With Tags and Creating Releases
* Linking to releases - this will be useful when you will access your
release source code from the spec file:
https://help.github.com/articles/linking-to-releases/
* I also recommend reading About branches. When making a release
you should create a release branch which will not be updated unless
you find a bug in an old release and want to make a bugfix release.
Normally your current work should be pushed to master:
https://help.github.com/articles/about-branches/
I hope this helps.
Regards,
Rafal