automatic tarball creation for tags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/2010 03:53 AM, Jelmer Vernooij wrote:
> It would be nice if Launchpad could automatically provide downloads of
> revisions that have been tagged. GitHub has this feature, and it's quite
> neat.

Why would we restrict it to revisions that have been tagged? bzrlib can
export any arbitrary revision to a tarball, so Loggerhead could, too.

Is it because you want the tarballs to be generated once and then stored
in the librarian so that the contents are always the same?

See also Bug #325761 and Bug #515128.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzasAUACgkQ0F+nu1YWqI1EyQCfcnimp18KhEg++2DzDlzysaYN
q6EAn1QgtxU/RsGZhQsw6YwaN0PK6mok
=Md77
-----END PGP SIGNATURE-----

On Wed, 2010-11-10 at 14:45 +0000, Aaron Bentley wrote:
> On 11/10/2010 03:53 AM, Jelmer Vernooij wrote:
> > It would be nice if Launchpad could automatically provide downloads of
> > revisions that have been tagged. GitHub has this feature, and it's quite
> > neat.
> Why would we restrict it to revisions that have been tagged? bzrlib can
> export any arbitrary revision to a tarball, so Loggerhead could, too.
>
> Is it because you want the tarballs to be generated once and then stored
> in the librarian so that the contents are always the same?
>
> See also Bug #325761 and Bug #515128.
Sorry, I was a bit vague. I'm not really interested in creating tarballs
for arbitrary revisions but rather in adding releases to a Launchpad
project this way. E.g. having such a tagged revision show up in
"+downloads" and having the latest release link show up on the frontpage
of the project.

Cheers,

Jelmer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/2010 10:11 AM, Jelmer Vernooij wrote:
> Sorry, I was a bit vague. I'm not really interested in creating tarballs
> for arbitrary revisions but rather in adding releases to a Launchpad
> project this way. E.g. having such a tagged revision show up in
> "+downloads" and having the latest release link show up on the frontpage
> of the project.

So you want every tag to be automatically converted to a release? I
don't use tags for anything other than marking releases, but I'm
reluctant to assert that tags are only useful for marking releases.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzavhgACgkQ0F+nu1YWqI2z0ACeL9XDwpDVuaTKvKjChBAcXQFr
wtUAn1Al1GW5jLneqgNjC6Yzi+9/g/ie
=qK9m
-----END PGP SIGNATURE-----

It might be nice to allow 'tag causes release' even if we don't assume
all tags are releases.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/2010 02:21 PM, Robert Collins wrote:
> It might be nice to allow 'tag causes release' even if we don't assume
> all tags are releases.

If we don't assume all tags are releases, then we would need a rule to
determine which tags are releases. What kind of rule would you propose?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkza94oACgkQ0F+nu1YWqI3M8QCY7GpWskG/og/8tBTFdN2LRED1
TgCeMHTTlVJNzRNygKnmKWNJ608SAXc=
=CqWr
-----END PGP SIGNATURE-----

On Thu, 11 Nov 2010 08:50:34 Aaron Bentley wrote:
> On 11/10/2010 02:21 PM, Robert Collins wrote:
> > It might be nice to allow 'tag causes release' even if we don't assume
> > all tags are releases.
>
> If we don't assume all tags are releases, then we would need a rule to
> determine which tags are releases. What kind of rule would you propose?

What if we had the ability to provide a tag in the release meta-data.

This would cause the tarball to be created and added for that release.

On Thu, Nov 11, 2010 at 9:10 AM, Tim Penhey <email address hidden> wrote:
> On Thu, 11 Nov 2010 08:50:34 Aaron Bentley wrote:
>> On 11/10/2010 02:21 PM, Robert Collins wrote:
>> > It might be nice to allow 'tag causes release' even if we don't assume
>> > all tags are releases.
>>
>> If we don't assume all tags are releases, then we would need a rule to
>> determine which tags are releases.  What kind of rule would you propose?
>
> What if we had the ability to provide a tag in the release meta-data.
>
> This would cause the tarball to be created and added for that release.

That could be nice. It would also be very nice to drive it entirely from bzr:
 - get Release notes and changelog from the branch
 - export a tag
 - voilà

As for rules - one way would be a policy knob:
Tags can be used to create releases from this branch:
[] Do not create releases from tags
[] All tags should cause releases
[] Tags matching this regex should cause releases [ ]
[] Tags on commits by members of this team should cause releases [v
            ]

I doubt that there is an a-priori sensible default other than 'do not
create releases from tags' - but perhaps there is?
Rob

You could also just drive releases through a script like https://launchpad.net/thekraken and have that do the tagging and creating releases.

That script is interesting but its existence doesn't obsolete our ability to produce a tag (or branch) driven workflow.

If anything, the fact that multiple people are developing such scripts (it overlaps with scripts in ubuntu-dev-tools and lptools) suggests that there would be significant interest in an integrated feature in LP. As such, I've reopened this and tagged it feature.

I did not suggest that The Kraken obsoletes the feature. I believe that users need more control than the proposed feature provides. The fact that users are using scripts suggests that people want the ability to do releases it a more automated way than the web site provides, but it does not say anything about whether the way this bug proposes to automate the feature is a good or useful way.

Speaking as a user, having what Rob proposed would at least address my use case for my smaller projects, and those are the ones I care about most.

I agree it doesn't cover all possible use cases, and there certainly will be projects that require more control than the feature provides, but they can always disable it and do manual uploads or uploads using their scripts. For the majority of projects, I think it would be a useful addition.