On 23.11.2015 14:53, Richard Brown wrote:
Glad you're happy
Yes. it's implimented
No, we're not going to slow down Tumbleweed in order to optimise for unofficial repositories. Read Coolos blog post to learn how to best cope https://lizards.opensuse.org/2010/12/16/how-we-use-our-power/
I will but that's another unnecessary artificial problem for you most technically apt users. After all, normal people don't use rolling releases but tech-maniacs who do need those releases to help them in their work. You say that you "not going to slow down Tumbleweed". But what Tumbleweed users, most extreme openSUSE nerds, would actually want more: more flexible and package-rich system in general or updates just few days earlier ? I'm not asking to go full-Ubuntu on our non-volatile storages but that stuff seems really unnecessary stingy.
No, official Tumbleweed repositories will always be considered more important than Devel Projects which will always be considered more important than Home projects.
We're the openSUSE Project, we build the openSUSE distributions, while we are of course awesome and lovely and like to share our tools and build power, we're fully within our right to optimise for the primary use cases of the Project.
If you want to run your own OBS where you can set your own priorities accordingly on your own hardware, you're fully able to, and you can even link it to ours, just like Packman do.
Guess that's a fair point. But not exactly then things are broken for non-corporates without actual necessity for your benefit, almost on a whim.
The processes and requirements for package maintenance are there to ensure that people do it properly, in a way that can be picked up easily if the current people stop doing it. It's good practice to follow them, even for unofficial repositories, so I'd recommend you consider doing it anyway.
Unofficial repos get less attention because their unofficial. If people want their stuff in official repositories, we have standards and processes that need to be followed. That's what makes them official. The reward for following those standards and processes is an increase of people using, working on, and collaborating on, those things in the official repos. It's your choice if you want to 'go it alone', we wish you well and will support you as best we can, but the Project will always focus our efforts on the common goals of the Project.
I do consider it, but I can't do it when I have to deal with more pressing problems. Like breakage previously and now "constant rebuilds and blocks". That wastes time that I and anyone could use for "following good packaging practices". Why do you have to fight with your active users ? How about focusing on common goals of "the Project" and its users ?
I tried to explain, you failed to comprehend.
If we published the old (now dead) Factory:snapshot for using it, we would have to support it. We'd have to deal with people ask questions about "why is XXX broken in Factory:snapshot?" or "Please change YYY in Factory:snapshot urgently!" - we didn't need, or want that, and we'd never be in a position to fix anything reported there.. in short, it was useless as a usable thing, it was also sub-optimal as a build-against thing. Everyone who knew what they were talking about agreed with that, and now we don't need it any more, so it's dead.
No, it's you who failed to comprehend my problem with typical corporate, proprietary approach of locking already implemented user-controllable features under excuse "we don't want to make it right, so we won't allow it in any way whatsoever, so you wouldn't even see how ass-backwards it was". That's what sarcastic "effective manager" term means: not seeing forest behind the trees while focusing more on corporate rules rather than their purpose. Well, I've and a lot of people seen it, you now fixed it to be better. That's very decent of you. But it's still not a valid argument for a FOSS project.