On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > On 5/16/07, Toshio Kuratomi <a.badger@xxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
