On Fri, 5 Nov 2004, Michael Schwendt wrote: > On Fri, 5 Nov 2004 13:40:57 +0100 (CET), Dag Wieers wrote: > > > > > PS Some of it could even be "legally" required in the sense that eg. > > > > fedora.us started its amavisd-new package from my SPEC file and I can't > > > > even peek to see what exactly they have changed. Bugzilla has some broken > > > > links, but there it ends. No SRPM, no SPEC file, no clue :) > > > > > > fedora.us spec files have been available separately for a very long > > > time linked at the top of http://fedora.us > > > > > > http://www.fedora.us/tempspecs/ > > > > Well, those only contain the published RPMs SPEC files. My amavisd-new > > example is a real example. > > Ah, unpublished packages. That explains it. > https://bugzilla.fedora.us/show_bug.cgi?id=1496#c16 > > Well, if the packager's download site is not reachable, the package can't > be reviewed either. Maybe it's just a temporary problem. Maybe the > packager doesn't even know about it. You could add a comment to above > ticket and tell him. Some packagers also provide extracted spec files at > their download site. > > I think it's not in fedora.us' responsibility to make available spec files > of unpublished packages (which can be arbitrary packages in the package > queue). I beg to differ. If a work in progress is not part of fedora.us, then I wonder what fedora.us really is ? Only the end result ? How can 4 people work together if only 1 person can make commits ? How can fedora.us still claim working with other repositories results in much more overhead if they still work like this ? How can you be sure that everyone agrees with changes if there's no way of knowing what changes have happened. I can confidently say we agree on 99% of what everyone is doing because everyone can see what someone else commits and can act/discuss immediately if he does not agree. The turn-over time is really making optimal use of all available resources. (In most cases everyone agrees with an author's changes though and often you see others adapt their SPEC files with the same enhancements) I would love to be able to do the same with Red Hat, fedora.us and other packages if only I could see what has been changed. I think opening up this would be the single most important action a project can do. It will lead to more transparency, more discussion and eventually to more people working towards the same goal and towards a set of coherent SPEC files. Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]