Updates System

[Toshio Kuratomi]

On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote:
> On 5/16/07, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > On Wed, 2007-05-16 at 09:37 +0200, Hans de Goede wrote:
> > > Thus I would like to voice my concern over the web-form part of this.
> > > Preferably this would be handled in the makefile and when typing "make build"
> > > for a non-devel branch my $EDITOR would get launched opening a pre-filled
> > > template update anouncement, where I can add the necessary bits, and then upon
> > > saving this gets automatically entered into the updates system.
> > >
> > > Basicly every step added to the process is one too much, thus we should try to
> > > not add any steps if not absolutely necessary. Don't get me wrong, I'm not
> > > against using a proper updates scheme instead of the rolling model of extras
> > > (although that always worked well for me). But the whole workflow should be
> > > made as smooth as possible, as smooth as baby's buttocks preferably.
> >
> > Would a curses-style interface work for you?  It looks like it would be
> > pretty easy to write a simple tui in python that first has you fill in
> > the fields similar to the web form, pops open your editor on a temp file
> > to enter/edit some freeform text, and then submits it to the update
> > system using JSON-RPC.  Authenticating using the SSL certs might be a
> > bit harder but we could use passwords until that is resolved.
> 
> If we're going down this road, I'd personally prefer a couple things.
> (And I find myself agreeing with most of what Ralf is saying here --
> most of us aren't being paid for our work in Fedora...  We should be
> aware of the impact these changes are having, and ensure that they're
> communicated and discussed with the community at large _prior_ to
> implementation!  No one wants a repeat of the review process changes
> debacle.)
> 
> * a "make push" command that could be run to push a package w/o any
> manual intervention.  For most packages, a "make tag build push" would
> suffice, and the world wouldn't come to an end.
> 
> * a simple cli tool to allow one's pending packages to be queried, and
> pushed in part or in full.  This tool should have a non interactive
> mode (that is, be able to be run w/o requiring manual intervention).
> 
> * a published remote interface that will allow people to write their
> own tools to manipulate the pending updates queue.  I'm particularly
> impressed with the koji published api vs the plague one; this is a
> good trend.  (Now, if I could just get more information on the
> bugzilla API...)
> 
I'd like to see a way to do everything from the CLI non-interactively
(or at most, with a command line switch for a message) as well.  But I
haven't been playing around enough with Bodhi to know if that is
possible.  Knowing the architecture it sits on, I know it will be simple
to create a simple fill in the form application that can submit its data
to Bodhi and work.  The non-interactive CLI will be more work as it has
to authenticate and have to make choices that are available on the web
form like SECURITY/non-security, relevant Bug #'s, etc.  Probably sane
defaults will take care of the second issue and hopefully we can share
code with koji to make auth work but it'll take more time to implement.

> In other words, a more robust updates system would seem to be a good
> thing -- but it's not always appropriate.  Let's try to preserve the
> simplicity and efficientcy that has served Extras so well where we
> can.

I don't quite agree with the first sentence but I agree wholeheartedly
with the second.  Having update announcements is always appropriate.
Being able to do that in a simple and efficient manner in the default
case is the goal that we need to satisfy.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070516/ec1630b4/attachment.sig>