On Thu, Jun 14, 2007 at 10:29:30PM +0200, Michael Schwendt wrote:
> Additionally, I'd like to point out that criticism and input, which sound
> negative, should not be seen as nothing else than complaints. The project
> used to be more open to feedback of all sorts. In some parts of the Fedora
> Project there's a growing tendency to meet criticism with phrases like
> "put up or shut up". Not desirable.
>
> Bodhi'n'stuff: There seem to be technical/design problems in the new
> update system workflow such as that bodhi currently cannot assist with
> publishing pending updates to a temporary repository. I believe it could
> be possible with another tag in koji, which a tool like mash can use to
> fetch unreleased packages from. Additionally, defining and pushing groups
> of packages doesn't seem to be possible yet either.
Since bodhi uses mash to compose the update repos, there is no reason
why it wouldn't be able to compose temporary repository.
With regard to multi-build updates, I implemented this in my development
branch and I'm in the process of writing test cases for it. You will see
this feature in bodhi in the near future.
> With Extras (and its incomplete pushscript helper tools [1]) at least we
> *can* run repoclosure prior to and after release of new updates (and
> fortunately, blacklisting packages has not been difficult so far). For F7,
> apparently, this feature has been neglected completely. Still the release
> procedure has been modified so much that packagers are forced to push
> several knobs without that there is policy about it and additionally the
> bodhi admins need to approve update requests without that they can run any
> checks at all. Weird is also how broken deps in updates apparently are
> seen as normality instead of things that should be fixed quickly.
I hacked up repoclosure support into bodhi a while back, but when
notting proposed mashing update repos instead of managing them by hand
we had to weigh the cost of the transition:
"old school" pushing in bodhi
=============================
o still needed polish on depclosure checking (lots of false
positives arose)
o had no concept of multilib (other than the previous biarch.py file
of DOOM, and we weren't planning on digging deeper into that hole)
o had no mechanism of cleaning out old updates
mashing
=======
o handled multi-lib for us
o gave us a clean repo every time
o I was also under the impression that it did closure checking, but
come to find out it needs more work.
o needs new updateinfo.xml implementation
So handing off all of this complexity to mash was definitely a good
decision in my opinion, even if it left us with some missing
functionality in the mean time.
There is currently a thread on maintainers-list about the dependency
checking for updates. Patches/suggestions are always welcome.
luke
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
