Last week we discussed if we were following the "potentially shippable product" with the new libstorage (looks like yes), but now the same question arises about yast2-storage. Right now, we are using the same repository for the new code and the old one. Even when using branches, you can still see mixed code in those branches. For example, the branch "new-proposal" includes the code presented during last review by HuHa that can generate proposals using only libstorage-bgl (mostly living in /lib), but also includes all the old code from yast2-storage (all the other directories). As HuHa proved during his presentation, the code works. But it has no unit tests, we don't have stats about code quality or coverage and so on. So IMHO, we need a pristine repo containing only new code that relies on libstorage-bgl (the visual partitioner that Arvin created some sprints ago, the new proposal...). For that repo, we need to have CI, coverals, rubocop and code climate, to make sure we keep the quality at acceptable levels (and installable as rpm). I guess a different branch would also make it, but I prefer to have a different repo, like we have with libstorage. We can have our own versioning schema (and changelog) and we can recreate the current branches organization for CI (master for TW, other branches for other distros) and compile it in the same OBS repo that libstorage-ng. What about yast/yast-storage-ng? What do we do with the versions? Start with 0.1? 4.0? Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org