On Thursday 21 September 2006 6:10 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 04:41:06PM -0300, James Oakley wrote:
On Thursday 21 September 2006 3:57 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them
That's a very small minority of packages. That's no reason to shun it altogether.
Whether this is a minority of packages depends on what you are working on. But even if it is a minority I don't want to use two different tool sets.
Then let's build one set we can all use.
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
I an not sure whether it was ever really promised or not. It is just that I expected Novell to use an open development model when they announced _open_SUSE but aparently I was wrong and this is not what they wanted. What we have now is public test versions, a black-box build system and some communication channels. Those things are all nice and actually it is totally legitimate for Novell to open stuff whenever they like but what they are currently doing is definitely not what I would consider _open_ and thus the "open" in openSUSE seems to be missleading in my opinion.
I'm more optimistic, myself. The distribution meetings are a good sign.
Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
So we all have private build systems that we don't publish the source for? Yes, I'm guilty of that myself, having built multiple systems...
That's exactly how it will work in my opinion until someone provides a system that is really open and does provide a new value.
Ok. Let's fix it.
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
Well, I _had_ some big interest in integrating know-how from a project I am involved in into an open build system and then use this as a base for the project.
I also had plans to consolidate my build systems into a better one for public consumption, but never got around to it. When SUSE's system was announced, I decided that it was better to join that community than distance myself from it.
Since the build service did not seem to become that open system we now have reached a level where switching to what the buildservice currently provides would be a big regression for us.
What's lacking? What do we need to do?
What do you think would need to change in the buildservice?
I didn't want to change anything with what I said here but wanted to say that a _tool_ does not _solve_ this problem, however you design it.
I understand that tools do not solve problems, but they can help by making it easier to collaborate.
Ok, but then this is obviously not the right way to use his repository (as well as mine). For my repository the philosophy is quite simple: Everything I build and can be published will be put into the repository. If someone likes it he could use it, if he does not like it he should skip this package. I am open to suggestions about packaging style or things like that but I might have reasons not to implement them.
Leaving repositories unsubscribed in rug works, but not everyone uses rug. I'd prefer separate repositories, which is something that's easy to do in the buildservice. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org