Public SPEC files please

Dag Wieers dag at wieers.com
Fri Nov 5 16:46:31 UTC 2004


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 at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]




More information about the test mailing list