Re: [gitweb feature request] Release snapshots with vX.X.X tags

["J.H." <warthog19@eaglescrag.net>]

Bram,

This is true, but gitweb, in it's current incarnation, is *SLOW* using 
it as a primary distribution means is ludicrous.  Regenerating a tarball 
on each request will destroy a server, plain and simple.  Git/Gitweb 
should *NOT* be used in place of doing properly release engineering.

If Debian requires their tarballs to be done up in a certain way, this 
is either the problem of the packager, or if you want to be kind create 
a makefile target that will generate this and release both when you do a 
release:

I.E.

# make release
Generating Normal Tarball: <project>-<version>.tar.gz
Generating Debian Tarball: <project>-<version>.deb.tar.gz
# ls
Makefile  <project>-<version>.tar.gz <project>-<version>.deb.tar.gz src/
#

Then take your releases and put them on your release server.

- John 'Warthog9' Hawley

Bram Neijt wrote:
> I was going to comment inline but I think the general question can be
> read as "why would you want this?". For me it's just an extra bit of
> automation. It would keep me from having to make release tarballs. I
> would just refer all the users to a gitweb snapshot link of the "v..."
> tag. Having a release tarball with "projectname-version" with a single
> directory called "projectname-version/" in it is just good practice if
> you ask me.
> 
> Therefore it would benefit any developer like me :D : a spare time
> hobbyist who likes to automate as much of the administrative tasks, that
> go into running an open source project, as possible.
> 
> Greets,
>   Bram
> 
> PS I've found that cgit: http://hjemli.net/git/cgit/
> has this feature, so I'm probably going to give that a try and get back
> to you if I find any problems with it (the feature that is).
> 
> On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
>> Bram Neijt <bneijt@gmail.com> writes:
>>
>>> I would like to create release snapshots with a git tag like "v0.0.1".
>>> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
>>> have to be named "project-0.0.1.tar.gz" and contain a single directory
>>> with "project-0.0.1/" in the archive.
>> What the intended audience of this feature?  IOW,
>>
>>  - who are going to "click" such a link on gitweb to obtain
>>    project-0.0.1.tar.gz with project-0.0.1/?
>>
>>  - how are they going to use that tarball?
>>
>> I somehow suspect that they won't be the official Debian distro packagers.
>>
>> Most likely they actually have a clone of the upstream project (how else
>> they can stay up to date?  In addition they would want to track their own
>> changes), so it would be more efficient for them to generate such a
>> tarball from a tag, and more importantly, doing it locally means that they
>> can they can verify the tag (and the whole history leading to it) before
>> doing so, instead of relying on somebody else's gitweb.
>>
>> You could be a mere Debian user who produces a *.deb for his own use out
>> of such tarball, and in such a case you are a lot less likely be tracking
>> the project (meaning, reading the history and keeping track of fixed bugs,
>> new regressions and such) than just getting a snapshot that happens to be
>> there and building it blindly, and I can understand it would be nicer if
>> you did not have to unpack, rename and regenerate an archive.
>>
>> Also, whose gitweb installations are you envisioning to enable this new
>> feature?  Are you going to convince all the gitweb administrators of
>> projects packaged by Debian (and derivatives) that have gitweb, and what
>> are the incentive for these upstream projects to do so?  I would guess
>> that most of the upstream projects do not consider Debian as their sole
>> target distribution, and it would be a tough sell if changing the snapshot
>> name to suit Debian breaks some other distro's (or human users) needs.
>>
>> Jakub is polishing Mark's patch to change the snapshot name and contents
>> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
>> have v0.0.1, not 0.0.1 in the name).  Changing the series's default to
>> drop 'v' from the beginning of the tagname when the rest of it consists of
>> all digits and dots would not be a correct solution, as Debian is not the
>> only system in the world and other people may want different naming rules.
>>
>> In order to make his series useful for your objective, it probably would
>> require a bit more customizability, but because I cannot tell whom such a
>> feature is really trying to help, and what the deployment plans are, I
>> cannot judge if extra complexity to add such a customizability is worth
>> it.  Also because there will be conflicts in the desired archive format
>> ("Distro X people want this kind of archive, distro Y people want this
>> different kind"), the choice somehow how to come from whoever is clicking
>> the link, not from the gitweb administrator, and it probably would mean
>> the codepath involved would need a lot more careful audit than just a
>> server only "this gitweb installation would use this format"
>> configuration.
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html