Are some people interested in developing such a tool ? I am, for one. I think Zope/Plone could do a good job, since it already has a good workflow system, but it is known by fewer people that PHP for example. What we need at the core is mainly a workflow system
(states/transitions),
a system to track dependancies, ... What else ?
Is anybody interested ? Is there a real need for it ? (I think so)
The discussion could be interesting, although I'm pretty confident I won't have time to write much code. As far as platforms, I'm not real sold on zope, just because it's such a heavy framework. Python/xml/mod_python would be my tools of choice, but that's immaterial atm.
I think the first thing to do is do decide what we don't like about the current bugzilla-based system.
Some of the things I've heard / thought up:
- Easier, automated submission. This is covered with ESR's tool, I think.
- A place to upload packages for build tests. IMO this is best handled with an easily duplicated build environment on the client. Think mach. An official place to upload submitted packages, rather than having to host them yourself would be good.
- Easier startup for new packagers / QA people. This is a policy / documentation / training problem IMO. A new tool isn't going to make anything better. Bugzilla queries work pretty good when you know the keywords to use etc.
- Standardized QA procedures. This is what a few of us have been working on wrt qa-assistant and fedora-startqa. There is lots yet to do but the tools we have are pretty cool, too.
- Better turn around time. People want to submit a package, and see results. This is a personnel / policy problem. If we have a secure autobuilder, we could automatically build submissions and deploy them in some sort of "bleeding" repository where packagers could get their builds back immediately. This would keep lots of third party packagers (ESR?) happy, I bet. Then, when someone takes an interest in the package and QA's it, it can be moved to stable and it's original publisher "trusted" to make updates to it.
- Nebulous future of Fedora Extras. Blame redhat. Do I need to bet a dollar again to get a response from somebody at redhat about this?
I guess in my opinion, most of the systemic problems we have now aren't solvable programmatically yet. We need to solve a lot of these people / policy problems before we're in a position to even know what the next generation system looks like.
Just $0.02.
--erik
On Thu, 2004-07-01 at 23:58, Erik LaBianca wrote:
- Easier, automated submission.
This, I agree (as does everyone else), is a worthy goal.
This is covered with ESR's tool, I think.
At its current state, I don't. And I'm not convinced that it is feasible to even try to write such a tool now; I think the prerequisite infrastructure/process bits (er, well, chunks) are not in place yet for it to be really useful for most current and future contributors.
More comments at https://bugzilla.fedora.us/show_bug.cgi?id=1115#c7 No replies back then, and AFAICS the tool has not changed since.
When completed, I guess the tool would not be much easier to use than what "wget --load-cookies=... --post-(data|file)=... https://bugzilla.fedora.us/post_bug.cgi" already is today. Not very interesting IMO.
What would be more interesting is if one could commit stuff to a cvs/svn repo somewhere (or upload a SRPM), and have that $somewhere trigger a rpmlint/fedoralint run, build, post mailing list announcement/diffs/build logs and possibly a Bugzilla submission. Or a subset of the above, especially for non-trusted submissions.
There have been several posts on this list about a group of RH people working around the clock to get that infrastructure done (incrementally) and that it should happen soon. Unfortunately it has not happened yet, and it's been a while since the last such post or a status update.
Probably as a consequence, people outside RH have not started working on it, and waiting for details on what that infrastructure provides or what its constraints are has probably had its own negative effect on the process/policy discussions which are proceeding at a snail's pace.
Meanwhile, for example the rpm.livna.org submission process has been improved (although for trusted packagers only); it implements some parts of the above.
(D'oh, this was supposed to be a two-line reply. Sorry.)