On Thu October 9 2008, Jesse Keating wrote:

> Only if we allow source repo tags to be a suitable source distribution
> method. Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.

If this is the only obstacle to get this done, I will write a patch for
Makefile.common that displays the URL for every file in sources to fetch it
from the lookaside cache. Then this URL can be provided as source tarball on
a fedorahosted wiki page.

Regards,
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> On Thu October 9 2008, Jesse Keating wrote:
>
> > Only if we allow source repo tags to be a suitable source distribution
> > method. Since fedorahosted still doesn't have an easy to use way of
> > distributing tarballs, and getting the code via a scm checkout is quite
> > easy, it should suffice.
>
> If this is the only obstacle to get this done, I will write a patch for
> Makefile.common that displays the URL for every file in sources to fetch it
> from the lookaside cache. Then this URL can be provided as source tarball on
> a fedorahosted wiki page.

Why must we insist on tarballs? Unless the tarball includes scm
metadata in it, it's practically useless for upstream patch development.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-10-09 at 09:22 -0700, Jesse Keating wrote:
> On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > Only if we allow source repo tags to be a suitable source distribution
> > > method. Since fedorahosted still doesn't have an easy to use way of
> > > distributing tarballs, and getting the code via a scm checkout is quite
> > > easy, it should suffice.
> >
> > If this is the only obstacle to get this done, I will write a patch for
> > Makefile.common that displays the URL for every file in sources to fetch it
> > from the lookaside cache. Then this URL can be provided as source tarball on
> > a fedorahosted wiki page.
>
> Why must we insist on tarballs? Unless the tarball includes scm
> metadata in it, it's practically useless for upstream patch development.

I've been contributing to various upstreams based on patches to tarballs
for a long time. It's hardly "practically useless". Sure, working with
an SCM is better (and working with one of the newer ones is even more
so), but tarballs + patches are still quite doable

Jeremy

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-10-09 at 12:24 -0400, Jeremy Katz wrote:
>
> I've been contributing to various upstreams based on patches to tarballs
> for a long time. It's hardly "practically useless". Sure, working with
> an SCM is better (and working with one of the newer ones is even more
> so), but tarballs + patches are still quite doable

Useful enough for anaconda to start uploading a tarball somewhere each
time you guys do a release?

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating wrote:
> On Thu, 2008-10-09 at 10:28 +0530, Rahul Sundaram wrote:
>> Insist that we use fedorahosted.org or other project hosting websites
>> whenever we are upstream for a project? It certainly makes it easier for
>> others to consume our bits when they don't have to crawl through source
>> rpm packages. SRPM dumps are a horrible way to manage upstream source
>> code anyway.
>
> Only if we allow source repo tags to be a suitable source distribution
> method. Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.
>
fedorahosted does have an easy to use way of distributing tarballs.
(Compare it to sourceforge's tarball mechanism if you doubt the easiness :-)

https://fedorahosted.org/releases/p/y/python-fedora/
https://fedorahosted.org/web/faq

Note: for people who have administrative access to fedorahosted.org, the
place to scp is slightly different. For instance, to upload to
python-fedora I have to do:
scp TARBALL fedorahosted.org:/srv/web/releases/p/y/python-fedora/

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating (jkeating@redhat.com) said:
> Only if we allow source repo tags to be a suitable source distribution
> method. Since fedorahosted still doesn't have an easy to use way of
> distributing tarballs, and getting the code via a scm checkout is quite
> easy, it should suffice.

Actually, my concern would be whether the admin side of fedorahosted wants
to sign up for increased load, storage, etc.. But then again, I'm not 100%
certain how many packages this would affect.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, Oct 09, 2008 at 09:22:13AM -0700, Jesse Keating wrote:
>On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
>> On Thu October 9 2008, Jesse Keating wrote:
>>
>> > Only if we allow source repo tags to be a suitable source distribution
>> > method. Since fedorahosted still doesn't have an easy to use way of
>> > distributing tarballs, and getting the code via a scm checkout is quite
>> > easy, it should suffice.
>>
>> If this is the only obstacle to get this done, I will write a patch for
>> Makefile.common that displays the URL for every file in sources to fetch it
>> from the lookaside cache. Then this URL can be provided as source tarball on
>> a fedorahosted wiki page.
>
>Why must we insist on tarballs? Unless the tarball includes scm
>metadata in it, it's practically useless for upstream patch development.

And why is upstream development being done from a Fedora SCM checkout?

josh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu October 9 2008, Jesse Keating wrote:
> On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > On Thu October 9 2008, Jesse Keating wrote:
> > > Only if we allow source repo tags to be a suitable source distribution
> > > method. Since fedorahosted still doesn't have an easy to use way of
> > > distributing tarballs, and getting the code via a scm checkout is quite
> > > easy, it should suffice.
> >
> > If this is the only obstacle to get this done, I will write a patch for
> > Makefile.common that displays the URL for every file in sources to fetch
> > it from the lookaside cache. Then this URL can be provided as source
> > tarball on a fedorahosted wiki page.
>
> Why must we insist on tarballs? Unless the tarball includes scm
> metadata in it, it's practically useless for upstream patch development.

Tarballs allow to easily build the desired software via rpm and test it. With
make patch and make rediff and make prep from Makefile.common it is also
pretty easy to create and update patches. I have sucessfully created patches
for upstream using this. Using directly an upstream scm, it is always a PITA
to make the spec build from there, because the spec needs to be heavily
modificated or I have to remember to recreate the tarball everytime. It would
like it very much, if this would be a lot easier, e.g. some intelligent
macros in spec files that allow to use a scm instead of a tarball to be used
as Source0 and some magic that allows to define what from the scm should be
used, e.g. should uncommited changes be used?

Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore
it is not much work to link to them. Therefore I do not really see what needs
to be discussed here. ;-)

Regards,
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-10-09 at 22:26 +0200, Till Maas wrote:
> On Thu October 9 2008, Jesse Keating wrote:
> > On Thu, 2008-10-09 at 18:16 +0200, Till Maas wrote:
> > > On Thu October 9 2008, Jesse Keating wrote:
> > > > Only if we allow source repo tags to be a suitable source distribution
> > > > method. Since fedorahosted still doesn't have an easy to use way of
> > > > distributing tarballs, and getting the code via a scm checkout is quite
> > > > easy, it should suffice.
> > >
> > > If this is the only obstacle to get this done, I will write a patch for
> > > Makefile.common that displays the URL for every file in sources to fetch
> > > it from the lookaside cache. Then this URL can be provided as source
> > > tarball on a fedorahosted wiki page.
> >
> > Why must we insist on tarballs? Unless the tarball includes scm
> > metadata in it, it's practically useless for upstream patch development.
>
> Tarballs allow to easily build the desired software via rpm and test it. With
> make patch and make rediff and make prep from Makefile.common it is also
> pretty easy to create and update patches. I have sucessfully created patches
> for upstream using this. Using directly an upstream scm, it is always a PITA
> to make the spec build from there, because the spec needs to be heavily
> modificated or I have to remember to recreate the tarball everytime. It would
> like it very much, if this would be a lot easier, e.g. some intelligent
> macros in spec files that allow to use a scm instead of a tarball to be used
> as Source0 and some magic that allows to define what from the scm should be
> used, e.g. should uncommited changes be used?
>
> Nevertheless, there have to be tarballs in the cvs lookaside cache, therefore
> it is not much work to link to them. Therefore I do not really see what needs
> to be discussed here. ;-)

I'm trying to see things from somebody else's point of view. Recently,
on this list, somebody else was arguing that we in Fedora land should be
doing away with tarball distribution, and srpm distribution, and instead
direct everything back to SCM, and to work on RPM so that it just
understood SCM and left tarballs in the past. Thank you for providing
some argument against that (:

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/10/9 Jesse Keating <jkeating@redhat.com>:
>
> I'm trying to see things from somebody else's point of view. Recently,
> on this list, somebody else was arguing that we in Fedora land should be
> doing away with tarball distribution, and srpm distribution, and instead
> direct everything back to SCM, and to work on RPM so that it just
> understood SCM and left tarballs in the past. Thank you for providing
> some argument against that (:

I don't think it was an argument against it - just that we need to
figure out what the patch workflow is. The fundamental question there
is - do we expose the upstream version control system, or do we say
map everything into git? Personally I lean towards the latter.

To those who think "wow, running a git mirror of everything would be
expensive", the current lookaside system ends up being the world's
worst revision control system in the long term. Putting one copy of
OpenOffice.tar.gz in the lookaside is certainly cheaper than mirroring
OpenOffice CVS into git for a few tarballs, git is going to be far
cheaper once you have N new releases of openoffice tarballs in the
lookaside. I don't know what N is for OpenOffice, but I bet it's less
than 20-30.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list