 |
 |
> I see @amadio issue here that this change would remove some extra steps in the release process. On the other hand, if we don't automatically build Ceph because we don't know what to build against then a site would have to build the complete xrootd package to just get the Ceph part built (unless we provide an option to only build the Ceph part). As for making it difficult in the future not exactly so. For your first update after including Ceph in the repo you will need to generate a patch file and apply it to a clone of the xrootd repo (it should be clean as you are the only one modifying the code) and the create a pull request. After that, your changes would be made in the cloned xrootd repo and that step is pretty straightforward. @amadio could you comment on whether this is all correct? Hi @abh, it's mostly correct, as an exercise, I've added changes from their master branch to this pull request, and it was not difficult, just had a small and easy to resolve conflict. What I'd like to have as a goal is to have a single source of truth for everybody, and make new developments appear in our released RPMs so everybody can benefit. As the main user of xrootd-ceph, RAL may have features under development on their fork, but if they agree to contribute them back as merge requests for each feature release when they are ready for production, I think we can avoid the fork diverging too much from the main repository. @snafus What do you think? -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/2008#issuecomment-1551072580 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1