On 20 October 2014 19:55, Barry Warsaw wrote:
> It occurs to me too that the switch from svn to git (e.g. git-dpm) is already
> a large change to current team workflow, and dropping pristine-tar might just
> be too big a move to also do right now.
We're not using pristine-tar with svn, right now;
On 10/21/2014 01:55 AM, Barry Warsaw wrote:
> It occurs to me too that the switch from svn to git (e.g. git-dpm) is already
> a large change to current team workflow, and dropping pristine-tar might just
> be too big a move to also do right now.
And things should move/improve incrementally as well
On Oct 21, 2014, at 12:48 AM, Thomas Goirand wrote:
>While I think it's important to do team work, and agree on some workflow
>conventions, I still want to explain my point of view, in the hope to
>make things better. I just hope I don't bother everyone too much with
>it... (I know I do...). Pleas
On 10/13/2014 06:11 AM, Barry Warsaw wrote:
>> While I don't agree with this decision, I prefer to just import upstream VCS
>> and do packaging based on tags, but I will still respect it when packaging in
>> the DPMT.
>
> Thank you. I personally appreciate the accommodations to the majority team
On 10/12/2014 09:30 PM, Scott Kitterman wrote:
>> Also, during the Debconf discussion, we decided we would use the
>> pristine-tar workflow, *not* using upstream VCS merge. A
>> "git-import-orig" normally goes into a single commit, which I don't
>> think would bother anyone (not on the list, or on
On 10/17/2014 01:01 AM, Tristan Seligmann wrote:
> If such a tarball exists, and is suitable
> for use in Debian, then having the upstream source in Debian match the
> tarball distributed by upstream byte-for-byte makes it much easier to
> verify that the source in Debian is unmodified from the ups
On 17 October 2014 16:57, Tristan Seligmann wrote:
> On 17 October 2014 17:19, Dimitri John Ledkov wrote:
>> There are different tag types in git. "Soft" are just named commit
>> references and indeed can be renamed at will / point to new commits,
>> however signed tags encode:
>> object SHA1id
>
On 17 October 2014 17:19, Dimitri John Ledkov wrote:
> There are different tag types in git. "Soft" are just named commit
> references and indeed can be renamed at will / point to new commits,
> however signed tags encode:
> object SHA1id
> type type-of-above
> tag tag-name
> tagger normal user na
On 17 October 2014 07:39, Tristan Seligmann wrote:
> On 16 October 2014 20:12, Hans-Christoph Steiner wrote:
>>
>>
>> Tristan Seligmann wrote:
>>> If you are fetching the upstream revisions / tags into your packaging
>>> repository, you can use the upstream tag exactly as-is, no need to
>>> re-ta
On 16 October 2014 20:12, Hans-Christoph Steiner wrote:
>
>
> Tristan Seligmann wrote:
>> If you are fetching the upstream revisions / tags into your packaging
>> repository, you can use the upstream tag exactly as-is, no need to
>> re-tag (and indeed re-tagging would generally be a bad idea).
>
>
Le Thu, Oct 16, 2014 at 02:12:40PM -0400, Hans-Christoph Steiner a écrit :
>
> I think there is a lot of value to always including the Debian upstream/v1.0
> tag. It provides a standard way to access the upstream version across all
> repos. There is no such standard out there "in the wild". The
Tristan Seligmann wrote:
> On 16 October 2014 18:01, Thomas Goirand wrote:
>> Using pristine-tar and pulling from upstream VCS is silly. If you do
>> like this, then why not just doing tag-based packaging? That's a lot
>> safer than just re-tagging on top of what upstream does (ie: no risk to
>>
Thomas Goirand wrote:
> On 10/12/2014 05:15 PM, Tristan Seligmann wrote:
>> I wasn't at Debconf, maybe this is why I'm a bit confused by what you
>> wrote here. pristine-tar and upstream VCS merge are in no way mutually
>> exclusive, but you seem to be implying that they are
>
> Using pristine-t
Thomas Goirand wrote:
> On 10/12/2014 05:15 PM, Tristan Seligmann wrote:
>> I wasn't at Debconf, maybe this is why I'm a bit confused by what you
>> wrote here. pristine-tar and upstream VCS merge are in no way mutually
>> exclusive, but you seem to be implying that they are
>
> Using pristine-t
On 16/10/14 18:01, Tristan Seligmann wrote:
> The purpose of pristine-tar is the same whether you base it on a
> revision fetched from upstream, or a revision created by
> git-import-orig or a similar tool
... or a revision created by "git-import-orig
--upstream-vcs-tag=v1.2.3", which has the cont
On 16 October 2014 18:01, Thomas Goirand wrote:
> Using pristine-tar and pulling from upstream VCS is silly. If you do
> like this, then why not just doing tag-based packaging? That's a lot
> safer than just re-tagging on top of what upstream does (ie: no risk to
> introduce any difference).
If y
On 10/12/2014 05:15 PM, Tristan Seligmann wrote:
> I wasn't at Debconf, maybe this is why I'm a bit confused by what you
> wrote here. pristine-tar and upstream VCS merge are in no way mutually
> exclusive, but you seem to be implying that they are
Using pristine-tar and pulling from upstream VCS
Barry Warsaw wrote:
> On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote:
>
>> I would expect it to make merging / rebasing Debian patches on top of
>> a new upstream version easier, since you have the granular history of
>> changes to the source tree, not one massive single commit which may
On Oct 16, 2014, at 09:26 AM, Tristan Seligmann wrote:
>I would expect it to make merging / rebasing Debian patches on top of
>a new upstream version easier, since you have the granular history of
>changes to the source tree, not one massive single commit which may
>not be accurate (eg. renames of
On 13 October 2014 00:19, Barry Warsaw wrote:
> Maybe not mutually exclusive, but what's the point? I certainly would not
> base the Debian packaging on anything but the upstream tarball, and most git
> workflows provide those as an unpacked upstream source branch. Does upstream
> vcs add value?
On Oct 12, 2014, at 11:15 AM, Tristan Seligmann wrote:
>I wasn't at Debconf, maybe this is why I'm a bit confused by what you
>wrote here. pristine-tar and upstream VCS merge are in no way mutually
>exclusive, but you seem to be implying that they are
Maybe not mutually exclusive, but what's the
On Oct 12, 2014, at 02:49 PM, Thomas Goirand wrote:
>Also, during the Debconf discussion, we decided we would use the
>pristine-tar workflow, *not* using upstream VCS merge.
More specifically, as I remember the discussion, it was decided that if
upstream uses tarball based releases (as most PyPI
On October 12, 2014 2:49:47 AM EDT, Thomas Goirand wrote:
>On 10/10/2014 12:59 PM, Ben Finney wrote:
>> Scott Kitterman writes:
>>
>>> Changing the number of commits is solving the wrong problem. The
>>> problem that needs to be solved is including upstream commits.
>That's
>>> thoroughly uninte
On 12 October 2014 08:49, Thomas Goirand wrote:
> Also, during the Debconf discussion, we decided we would use the
> pristine-tar workflow, *not* using upstream VCS merge. A
> "git-import-orig" normally goes into a single commit, which I don't
> think would bother anyone (not on the list, or on IR
On 10/10/2014 12:59 PM, Ben Finney wrote:
> Scott Kitterman writes:
>
>> Changing the number of commits is solving the wrong problem. The
>> problem that needs to be solved is including upstream commits. That's
>> thoroughly uninteresting for a packaging team.
>
> Agreed. This is a direct result
On 2014-10-10 13:13, Matthias Urlichs wrote:
> Looking at that code, IMHO it should be sufficient to add the arguments
> '--' and 'debian' to all calls of "git revlist".
Who can add this?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
Hi,
On Fri, 10 Oct 2014, Charles Plessy wrote:
> Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit :
> >
> > Where is the repository of the scripts involved? Maybe I have
> > some spare time this weekend... I hope, it's all sh or Python.
> > I forgot all my Perl.
>
> Hi Martin,
On Friday, October 10, 2014 09:04:32 Barry Warsaw wrote:
> On Oct 10, 2014, at 12:16 AM, Tianon Gravi wrote:
> >At the BoF during DebConf, me and paultag discussed how we use exactly
> >this workflow for Docker stuff in Git, and we love it. We don't ever
> >worry about any kind of upstream commits
On Oct 10, 2014, at 12:16 AM, Tianon Gravi wrote:
>At the BoF during DebConf, me and paultag discussed how we use exactly
>this workflow for Docker stuff in Git, and we love it. We don't ever
>worry about any kind of upstream commits in the packaging, and only
>deal with upstream tarballs/source
Hi,
Charles Plessy:
> https://github.com/mhagger/git-multimail/
>
Looking at that code, IMHO it should be sufficient to add the arguments
'--' and 'debian' to all calls of "git revlist".
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subj
Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit :
>
> Where is the repository of the scripts involved? Maybe I have
> some spare time this weekend... I hope, it's all sh or Python.
> I forgot all my Perl.
Hi Martin,
good news, it is in Python :)
https://github.com/mhagge
On 2014-10-10 10:13, Raphael Hertzog wrote:
> On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> > I assume, that the script uses post-receive, so it has access to
> > all commits, including all affected paths. If so, generating only
> > emails or IRC messages when debian/ is involved should be easy.
On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> On 2014-10-10 15:59, Ben Finney wrote:
> > Agreed. This is a direct result of rebasing Debian packaging history
> > onto upstream VCS history, and keeping them all in the same repo as one
> > undifferentiated history, no?
>
> Not sure, but isn't this
On 2014-10-10 15:59, Ben Finney wrote:
> Agreed. This is a direct result of rebasing Debian packaging history
> onto upstream VCS history, and keeping them all in the same repo as one
> undifferentiated history, no?
Not sure, but isn't this more a result of the scripts in use, to
not differentiate
On 9 October 2014 22:59, Ben Finney wrote:
> It's a good illustration of why I much prefer the workflow of a separate
> VCS for the ‘debian/’ directory, merged with upstream source only at
> build time. The results of the merge are in a separate location and are
> never checked into VCS, they're u
35 matches
Mail list logo
