Devan Goodwin wrote:
1. Make it installable via setup.py:
Why would I want it to install? How I manage the updates if I install
it? Should I then manualy track the changes in rel-eng/bin and when file
change, then reinstall it?
- - re-run when you need to get the latest code.
How would I know when to re-run it?
- - Doing this because tracking the code in specific branches is
going to bite someone sooner or later. (something's fixed in master
that you need when building in another branch or repo)
Jan had ionce idea for Makefile, that the Makefile will do as first
think checkout of rel-eng/ from master and then will call the Makefile
from this checkout. This way you will have always fresh code even if you
are building from some old branch.
But this idea never been implemented.
- - Was thinking 'tito', our magical rel-eng helper.
+1
3. Restructure the CLI into modules like yum or cobbler:
Instead of refactoring cli can you instead change the behavior to be
more friendly?
My dislikes with build.py:
Have to specify path for each run (sometimes it can be dot hell):
$ ../rel-eng/bin/build.py --srpm
compared to
$ make srpm
And - no, I do not want to modify PATH since I have more then one
checkout and I want to use the script from that checkout I'm currently
using.
$ cat build.py.props
[buildconfig]
builder = spacewalk.releng.builder.Builder
tagger = spacewalk.releng.tagger.VersionTagger
Compare to:
$ cat Makefile
include ../../rel-eng/Makefile
Why should I care about some classes? Why can not I use some simple
switch like:
KEEP_VERSION=1
I really do not want to study code of build.py when I create build.py.props
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
