Mailinglist Archive: opensuse-packaging (174 mails)

< Previous Next >
Re: [opensuse-packaging] Please do not bypass the devel projects
  • From: Peter Poeml <poeml@xxxxxxx>
  • Date: Thu, 5 Mar 2009 15:37:50 +0100
  • Message-id: <20090305143750.GG22848@xxxxxxx>
On Fri, Jan 30, 2009 at 06:36:44PM +0100, Lars Marowsky-Bree wrote:

Responding to this well-made and well-meaning critique, but also to the
other posts on this thread.

Yes, having a powerful DVCS would be great, and it would fit the
development of the build service well, also if you consider the
existance of different instances of the build service that sources are
transported forth and back between.

I nearly think that nowadays some design decisions would have been made
in a different way.
Regarding the existance of osc, which I am to be blamed for, I wasn't
part of the build service team at the time, and needed to fill this gap
by somehow interacting with the rest API, which was the only thing that
existed back then. The build service was still closed source at the
time, and only later has been open sourced, and the development process
gradually opened up as well.
Obviously, my own itch was to make use of this new system and not to
rewrite it the system itself, and it was very easy to get something done
with simple means (a simple script). A conscious design decision was to
imitate a well-known VCS client as much as possible, because a different
client would just have sucked. And something that may not be very
obvious is that this imitation has hugely decreased the possible cost of
invention of another client, because I never did really more than just
do what they do, and see that it works. A large part of development
effort would have flown into design, experiments, mistakes, and
gradually getting where others have already gone, and it would have
taken years. So the cost of developing osc may not be as much as you
might think. On the other hand, there were two or three turning points
where a little bigger effort needed to be put in, in order to make the
thing scale and maintainable, error handling, getting some things right
that had been omitted at the beginning. Also, the inescapable iChain
proxy was a bad design choice, and I would have loved to change that
from day one, but couldn't.

Speaking about currently lacking (and badly missed) features, it is
obvious though that it's not trivial to implement them and get them
right, so we are clearly at a point where it makes sense to reconsider
the design choice of the employed VCS, and client.

I would encourage anyone trying this out - install the build service,
and try to make it work with Git as source server.
Don't just suggest such a change, but do something about it.

Regarding osc adjustment for such a change, it should be relatively easy
to adapt to using a different backend, by scrapping a lot of code and
replacing it with calls into the "real" VCS client. Or scrapping the
code altogether, and using osc only for those functions and activities
that are specific to the build service and not to be reflected in the

The more difficult part could be the "api" which all communication
between osc and the backend passes through. It would be required to
drastically change it as well, because it would either need to hand over
other VCS's protocol then, or be thrown away altogether. Supposedly, the
new "real" VCS would have its own, powerful, tried and tested api that
doesn't need any further api in its front.

"WARNING: This bug is visible to non-employees. Please be respectful!"

SUSE LINUX Products GmbH
Research & Development
< Previous Next >
This Thread
  • No further messages