On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: > > Yes, we do all development on SUSE Manager and then rebase against > master what we want to upstream. It makes total sense.
It may make sense from SUSE's point of view. Not sure it makes sense from upstream project health point of view. > - Spacewalk code is very "distro" oriented. In what way? In the way that the team tries hard to release binary signed rpms with each release to allow the administrators just upgrade the software without having to compile it? > It is not possible right now > to "run" it from the source tree. What are the patches to make it possible? > It needs packaging and "productizing" > in order to run it. We figured that's exactly how our users would want to use it. > Spacewalk is very tied to Fedora in this regard. Not really -- all recent Spacewalk releases were done both on Fedoras *and* on RHEL 5 and 6. > Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in > the spec files (like they are in our tree. /srv/www vs /var/www anyone) Why didn't you send those %ifdefs for review? If this is the only thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm sure the Spacewalk team will be happy to consider those patches for master. > - If you do a feature in Spacewalk master, you just do it and commit it. > We have to ask for review and then the feature may not be accepted. > Therefore the inverse work-flow, cherry-picking in our tree what looks > good to upstream, makes more sense. There are SUSE developers who have commit access to Spacewalk git, based on their history of providing sensible bug fixes and contributions. Trust is built over time. If you start with small fixes and features, if the patches are clean against master and they are correct and not disturbing the rest of the Spacewalk, you will build trust for future big changes that you may have planned. > - Stuff like porting pages, happened as the side-effect of features we > will have anyway in our tree but we don't know yet if we will be > accepted upstream, The longer you wait and the longer you hack in your tree, the bigger the patchset will be when you decide to show ti upstream, and the harder will be for upstream to easily accept the feature. > so we can't start the other way around, and we can't > decide whether we do or not a feature based on whether upstream will > take it or not (like it happened with SSH push). Check that communication again. I raised some general questions about the overall client -- server mechanism, issues that we saw with it in the past, and how it could be improved. I did not see answer that would indicate willingness to work on existing issues to improve the situation and maybe get the ssh push feature in as a well aligned part of the future setup. It was presented as mostly additional code which increased the complexity of the code (duplication of the scheduling functionality), solution that you propose in one form without being prepared to contribute to improving the overall setup. > We should really figure out a "run from source" here :-) In the Spacewalk team, some developers run Spacewalk in their developer's setup which I assume is equivalent to the "run from source" wish. It's not my preferred approach as it in the past lead to different setup being used than what we then released to users, leading to missed bugs. However, I can well understand the desire to do so for some reason, so if there are any patches to make it easier, just submit them for review. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
