Hi, Thanks for raising that subject.
On Mon, Mar 27, 2017 at 12:13 PM, Tristan Cacqueray <[email protected]> wrote: > On 03/27/2017 10:00 AM, Matthieu Huin wrote: > > o/ > > > > what's the expected gain from this? better targeted CI jobs? > > Well the main goal is modularity. Right now, we are bound to rebuild the > doc, the config and the release each time there is a change on the main > repository. > > We already skip most of the jobs with the SkipIf directive for the software-factory repo if for instance a change only touch docs/* but sf-rpm-build and sf-rpm-publish are not skipped. Maybe extending the skipif can improve the situation even before splitting the repo. > because I'm > > afraid the documentation will see even less love this way. And tagging > and > I think we really should take care when doing reviewes on patches affecting the workflow that another patches are proposed in order to reflect the changes in the doc but it seems we miss to do that usually. So whatever the doc is splitted or not, that reviewer and contributor job. > > generating a common CHANGELOG across all subprojects (which we should > > already do with managesf, cauth, sfmanager and pysflib but I'm not sure > we > > actually do...) would become increasingly difficult, wouldn't it? > > > Regarding the doc, the good news is that the mechanic is already in > place, managesf and sfmanager already produces their own documentation > and the main softwarefactory-doc package references those. > > Now regarding the main CHANGELOG for the project, then it makes even > more sense to have it in a page/website repository so that we don't have > to bother with branches. > Agree. https://softwarefactory-project.io/r/gitweb?p=repoxplorer.git;a=tree;h=refs/heads/gh-pages;hb=refs/heads/gh-pages That's replicated and work out of the box. Just need to take care to push changes from the master:README.md to gh-pages:index.md. > Why do you think it would be more difficult to make doc change to a > different repo? > For my part, my concern is not about the doc but more about sf-ci, sf-config, sf-(release|upgrade) split because that is already sometime hard to pass some changes that touch the config, upgrade, managesf, ... (more that one repo) with depends-on mechanics. I'm not again the split at all but we should take care to do it only if it provides significant advantages. > -Tristan > > > just my 2 cents > > > > On Mon, Mar 27, 2017 at 11:28 AM, Tristan Cacqueray <[email protected] > > > > wrote: > > > >> Hello folks, > >> > >> with the recent packaging effort, it seems like the main > >> software-factory repository could be split further: > >> > >> * sf-docs for docs/ > >> * sf-config for config/ > >> * sf-release for upgrade/ > >> * release.softwarefactory-project.io (or github similar page) for the > >> README > >> * sf-ci for the rest > >> > >> What do you think? > >> -Tristan > >> > >> > >> _______________________________________________ > >> Softwarefactory-dev mailing list > >> [email protected] > >> https://www.redhat.com/mailman/listinfo/softwarefactory-dev > >> > >> > > > > > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev > >
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
