On 03/27/2017 10:52 AM, Fabien Boucher wrote: > 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. > It's not just build time, it's also overall efficiency. Assuming we want to package the config as well as the release repo file (which could include the upgrade process), then we'll be creating a doc/config/release package for each change on this main repository...
>> 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. > > Well the ideal would be something self hosted that could be replicated too. >> 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. > Perhaps this is a sign the upgrade test could be improved. Otherwise cross repo changes have been working fine for managesf/cauth/.. Agreed this is delicate but worthy imo. > >> -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 >> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
