I'll admit that some of the trouble is more imaginary than real:
five
minutes spent copying, pasting and double-checking can easily seem
like
an eternity, when it's actually a mere five minutes... but why waste them, if it can be avoided?
You cannot avoid human interaction as in setting bugzilla keywords and replying to comments. You could only avoid that with ultimately
trusted
package maintainers who get direct access to a build/publish system.
Absolutely true, although I believe the current system is still daunting for a new packager or reviewer. I'm not sure how to make it less so without compromising quality other than saying that people need to just jump in, and ask for help on the list if needed.
Would there be some benefit to having a separate list for Extra's discussion?
No. It's in fedora.us already in the "stable" repository (much to the disliking of some people) and the fedora.us build system uses a
modified
version, http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ but that is not an automated build system.
Should it be sanctioned as a required tool for packagers?
No, because it behaves differently than plain rpmbuild.
Nonetheless, we really need to have a build environment that's >easily< available for prospective packagers and QA testers to build packages on. I propose mach, but a lot of people don't like it. Redhat has an internal build system. Are there plans to release it
It's been a couple months since I was last harping on the list for some feedback from the powers that be at RedHat regarding the official Fedora Extra's infrastructure. Has there been progress? This issue really needs to be resolved, even if the resolution is "we will eventually take over the fedora.us infrastructure as it stands and abide by the policies decided upon by the fedora.us community" or the other extreme of "we don't like the idea of an official Fedora Extra's after all, do your own thing", or more likely something in between.
--erik
On Wed, 30 Jun 2004 14:52:03 -0400, Erik LaBianca wrote:
[...] although I believe the current system is still daunting for a new packager or reviewer. I'm not sure how to make it less so without compromising quality other than saying that people need to just jump in, and ask for help on the list if needed.
Yes, more people are encouraged to help and work towards becoming trusted developers. If there are questions about the general process, I'm one of those who accept private mail, too.
Don't worry about "compromising quality". There is the "unstable" repository (_and_ still the "testing" repository). As soon as a package builds successfully and the source tarball has been confirmed as being released by the upstream project, a package could go into "unstable".
It's just that for every piece of software, which has a target group, there should be at least one person who would team up with the packager and say a package is ready to be published and e.g. provide the info on where it is included in another big distribution (let's say Debian, Mandrake, SuSE) already. Else people, who are not familiar with the software and who are not interested in it either, would need to spend time on it, and time is a major resource problem.
Would there be some benefit to having a separate list for Extra's discussion?
Depends on Red Hat's commitment. As long as fedora.us takes the role of a 3rd party repository with only semi-official backing, not much will change. You can see in this thread that potential package developers/maintainers are waiting for official Fedora Extras, because they hope that things will change a lot and e.g. fedora.us QA could be avoided.
Nonetheless, we really need to have a build environment that's >easily< available for prospective packagers and QA testers to build packages on.
With the current build system, failed build attempts would not be an issue if the build team did consist of more people. That can only become true if they shift some of their current activities and, for instance, they don't need to approve updates by trusted maintainers.
On Wed, 30 Jun 2004 21:31:23 +0200, Michael Schwendt wrote:
[...]
With the current build system, failed build attempts would not be an issue if the build team did consist of more people. That can only become true if they shift some of their current activities and, for instance, they don't need to approve updates by trusted maintainers.
... and, of course, that is no longer mandatory: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00887.html
Michael Schwendt wrote :
[...] As long as fedora.us takes the role of a 3rd party repository with only semi-official backing, not much will change. You can see in this thread that potential package developers/maintainers are waiting for official Fedora Extras, because they hope that things will change a lot and e.g. fedora.us QA could be avoided.
...and if only bugzilla could be avoided for the submission process, and replaced by a more comprehensive system, it would help a lot. Or maybe just customize it enough to make it unrecognizable? ;-)
Matthias
On Thu, 1 Jul 2004 10:18:45 +0200, Matthias Saou wrote:
[...] As long as fedora.us takes the role of a 3rd party repository with only semi-official backing, not much will change. You can see in this thread that potential package developers/maintainers are waiting for official Fedora Extras, because they hope that things will change a lot and e.g. fedora.us QA could be avoided.
...and if only bugzilla could be avoided for the submission process, and replaced by a more comprehensive system, it would help a lot. Or maybe just customize it enough to make it unrecognizable? ;-)
...which would be something that does not exist yet and requires a lot of development efforts. On the contrary, bugzilla is available today.
...and if only bugzilla could be avoided for the submission process, and replaced by a more comprehensive system, it would help a lot. Or maybe just customize it enough to make it unrecognizable? ;-)
...which would be something that does not exist yet and requires a lot of development efforts. On the contrary, bugzilla is available today.
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)
Aurélien
devel@lists.stg.fedoraproject.org