V Wed, 13 Jun 2018 10:36:24 +0200 Ancor Gonzalez Sosa <[email protected]> napsáno:
> Yesterday we have a discussion (and not a pleasant one, if you ask me) > in the #yast IRC about how the skelcd-control-xxx packages are managed. > They currently live under the "yast" organization in GitHub and they > follow exactly the same rules for branching than any YaST module. > > But there are important differences. First of all, it's not a > task/responsibility of the YaST team to define how every product/role > has to behave. No, but often yast team modify it due to features that defines how it should look like. > On the other hand, these packages do not contain code, > but configuration stuff. yes, but often configuration that we need to e.g. implement something for SLE and not for openSUSE like multiproduct media layout. > Last but not least, it makes no sense to create > a maintenance update for such packages (since they only makes sense if > the content is indeed included in the installation media). In fact for self-update it makes some sense. And also e.g. system-roles which looks like skelcd can be deliver online via update repo. > > Having to observe the (relatively complex) YaST team procedures in terms > of branching and so on turns to be confusing and quite frustrating for > the people who really takes care of defining the changes on such packages. If you talk about yesterday ones, then I think it was problem on multiple side. At first I think even if it is managed outside of yast, it still needs branches. > > Shouldn't those packages have their own workflow independent of the YaST > code? And other maintainers than the YaST team, to start with. Other maintainers is nice idea, but in reality beside Richard, Ludwig and Edbert majority of changes we are do ourself. And it also makes our life easier when we are dropping stuff or doing API change that affect skelcds. BTW for opensuse skelcd it works well even with branches. Question is why for SLE it works worse? Maybe because there is no single person for SLE, so in the end it can end up as yesterday when someone thing it is ship stopper so immediately work on it and then it was disapproved. ( I can point you to bug if you are interested ). > > Cheers. Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
