On 02/20/2013 12:38 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
>> The idea to use "git archive" was mostly from Julien Danjou. It's
>> very nice because that way, we can use xz compression, instead
>> of what upstream provides (that is, github .zi
Thomas Goirand scrisse:
> I've found that having a debian/rules entry called "get-vcs-source"
> which gets what is needed from upstream works quite nicely. Our
> workflow is described here:
>
> http://openstack.alioth.debian.org/
>
> The idea to use "git archive" was mostly from Julien Danjou. I
On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> This all seems to assume full source branches which is not something I'm
> interested in participating in at all. I've tried it and I find it very
> difficult to work with.
>
> Currently we have one VCS and one package layout. In the end, we shou
On 02/20/2013 04:31 PM, Luca BRUNO wrote:
> This may suit well for the openstack scenario, however in general I
> could see at least two shortcomings:
> * pristine upstream tarballs are not used (see the first "should" in
> devref §6.7.8.2)
> * it assumes that no tarball generation process (eg. m
Am 20.02.2013 09:31, schrieb Thomas Goirand:
> On 02/20/2013 12:38 PM, Scott Kitterman wrote:
>> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
>>> The idea to use "git archive" was mostly from Julien Danjou. It's
>>> very nice because that way, we can use xz compression, instead
On 02/20/2013 04:57 PM, Matthias Klose wrote:
> So there would be no way anymore to build using upstream tarballs?
Upstream tarballs, in some cases, is a concept of the past. When
they are released (sometimes, they simply don't exist), it may only
an image based on a git tag. Then using Git tags i
On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>If sticking to our old habits is not the only valid point, that there
>are real technical reasons why we should never be using a git tag
>as the key for an upstream release, or if you think they might be
>real difference between the "git archive
On 20/02/13 14:14, Thomas Goirand wrote:
> Now, do you know if it is possible to use git-buildpackage
> without storing the full upstream source in a branch?
Yes, most conveniently done via 'overlay = True' in debian/gbp.conf. You
have to supply a copy of the upstream tarball as you would for plai
On Wednesday, February 20, 2013 04:34:05 PM Thomas Goirand wrote:
> On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> > This all seems to assume full source branches which is not something I'm
> > interested in participating in at all. I've tried it and I find it very
> > difficult to work with.
>
Hi,
I am trying to create packages for Python3 for the source package
[1]. Following the guide [2], I get some success. However, the packages
for Python2 and Python3 differ significantly: in the Python2 package,
all machine independent data go into /usr/share/, while the Python3
package contains e
On Wednesday, February 20, 2013 10:14:26 PM Thomas Goirand wrote:
> Upstream tarballs, in some cases, is a concept of the past. When
> they are released (sometimes, they simply don't exist), it may only
> an image based on a git tag. Then using Git tags is often better,
> because tags may be PGP si
On 02/20/2013 10:23 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>
>> If sticking to our old habits is not the only valid point, that there
>> are real technical reasons why we should never be using a git tag
>> as the key for an upstream release, or if you think th
Am 20.02.2013 15:38, schrieb Olе Streicher:
> Hi,
>
> I am trying to create packages for Python3 for the source package
> [1]. Following the guide [2], I get some success. However, the packages
> for Python2 and Python3 differ significantly: in the Python2 package,
> all machine independent data g
On 20 February 2013 14:38, Olе Streicher wrote:
> I am trying to create packages for Python3 for the source package
> [1]. Following the guide [2], I get some success. However, the packages
> for Python2 and Python3 differ significantly: in the Python2 package,
> all machine independent data go i
On 20 February 2013 14:53, Thomas Goirand wrote:
> In what way the QA is different because it's a tag instead of a tarball ?
> I don't understand your reasoning. In both cases, you must make sure
> that what you are packaging is buildable, tested, QA, etc.
>
I think the idea is that, if you prep
On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote:
>> You better be darn sure that upstream has excellent QA then, and that you
>> know for sure that a tag is correctly assigned to a buildable, tested, QA
>> passed snapshot of the project.
>
>In what way the QA is different because it's a tag ins
On Feb 20, 2013, at 03:38 PM, Olе Streicher wrote:
>I am trying to create packages for Python3 for the source package
>[1]. Following the guide [2], I get some success. However, the packages
>for Python2 and Python3 differ significantly: in the Python2 package,
>all machine independent data go int
On 02/20/2013 10:43 PM, Scott Kitterman wrote:
> First, full source repositories are much larger than debian only
> repositories.
> I don't have a full checkout of all team packages locally, so that means if
> I'm going to touch a package I don't have to download, it's more time,
> bandwidth,
On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
> > First, full source repositories are much larger than debian only
> > repositories. I don't have a full checkout of all team packages locally,
> > so that means if I'm going to touc
On 02/20/2013 11:09 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote:
>
>>> You better be darn sure that upstream has excellent QA then, and that you
>>> know for sure that a tag is correctly assigned to a buildable, tested, QA
>>> passed snapshot of the project.
>> In w
On 02/20/2013 11:45 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
>>> First, full source repositories are much larger than debian only
>>> repositories. I don't have a full checkout of all team packag
[Thomas Goirand, 2013-02-20]
> I wouldn't
> mind switching to some different way of doing things if the team finds it
> relevant, and if it is more easy and unified across all packages. If so,
> please tell how you would like to work. We would loose most of the cool
> features I was used to, but so
Den 20. feb. 2013 16:23, skreiv Thomas Goirand:
If that doesn't work, you can use the pristine-tar thing, that should
always work.
I never used it, probably I should learn, it seems quite convenient. Can
anyone
give feedback about it?
My workflow for anything outside of this team and not intende
Thomas Goirand wrote:
>On 02/20/2013 11:45 PM, Scott Kitterman wrote:
>> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
First, full source repositories are much larger than debian only
repositories. I don't have a f
On Wed, Feb 20, 2013 at 06:43:11PM +0100, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-02-20]
> > I wouldn't
> > mind switching to some different way of doing things if the team finds it
> > relevant, and if it is more easy and unified across all packages. If so,
> > please tell how you would lik
On 19 February 2013 23:49, Ludovic Gasc wrote:
>
> On Feb 19, 2013 11:21 PM, "Barry Warsaw" wrote:
>>
>> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>>
>
> I can do that this week-end. I've only a github account to publish the git
> repository, unless somebody else has an access for a bet
On 21/02/2013 01:43, Piotr Ożarowski wrote:
> does git-buildpackage work with git submodules (with debian dir as a
> separate git repo)?
It should. I wrote the initial patch for submodule support in git-buildpackage.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signat
On 20/02/2013 23:45, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
> [...]
>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth i
On 21/02/2013 01:59, Scott Kitterman wrote:
> I've done the boring bits enough that my fingers mostly do them without much
> attention from my brain. If I were going to abandon my current approach, I'd
> have to see significant advantages for a new way and I don't.
Somehow I can only read this as
On Feb 21, 2013, at 11:08 AM, Chow Loong Jin wrote:
>That argument applies to any VCS that you don't use on a daily basis. You use
>bzr on a daily basis and forget how to use git. I use git on a daily basis and
>forget how to use svn/bzr and have to relearn it any time someone forces me to
>use on
On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
> On 21/02/2013 01:59, Scott Kitterman wrote:
> > I've done the boring bits enough that my fingers mostly do them without
> > much attention from my brain. If I were going to abandon my current
> > approach, I'd have to see significa
On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
...
> That argument applies to any VCS that you don't use on a daily basis. You
> use bzr on a daily basis and forget how to use git. I use git on a daily
> basis and forget how to use svn/bzr and have to relearn it any time someone
>
On 21/02/2013 11:58, Scott Kitterman wrote:
> On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
>> On 21/02/2013 01:59, Scott Kitterman wrote:
>>> I've done the boring bits enough that my fingers mostly do them without
>>> much attention from my brain. If I were going to abandon my
On 21/02/2013 12:02, Scott Kitterman wrote:
> It is to a degree, but the learning curve for git is subtantially steeper
> than
> for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another
> and
> there is no question in my mind which one, by a lot, is the most complex to
> lear
On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:
>It is to a degree, but the learning curve for git is subtantially steeper
>than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or
>another and there is no question in my mind which one, by a lot, is the most
>complex to learn.
On Feb 21, 2013, at 12:15 PM, Chow Loong Jin wrote:
>I'll admit that git isn't the simplest one, the others are not perfect either.
>To this day, I can't for the life of me figure out how to use CVS. Thank
>goodness git-cvsimport works.
Of course, CVS is 20+ years old so its ancient model is work
On Thursday, February 21, 2013 12:08:45 PM Chow Loong Jin wrote:
> On 21/02/2013 11:58, Scott Kitterman wrote:
> > On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
> >> On 21/02/2013 01:59, Scott Kitterman wrote:
> >>> I've done the boring bits enough that my fingers mostly do them
On Thu, Feb 21, 2013 at 12:37 PM, Scott Kitterman wrote:
> That's the sort of thing that convinces me it's too hard. The fact that I
> have to manually make the association between individual local and remove
> branches is just insane.
This has changed with git from experimental, it sets up the
(Re-posted back on list. Sorry ScottK.)
On 21/02/2013 12:37, Scott Kitterman wrote:
> With git (I've never used gpb, and maybe that's my problem) I end up having
> to
> do things like:
>
> git clone git://git.debian.org/….git
> for branch in pristine-tar debian/unstable ; do git branch --track
On Wednesday, February 20, 2013 11:46:31 PM Barry Warsaw wrote:
> >At least with git, you know when you've rewritten history -- you're no
> >longer on the same commit.
>
> #9 on Steve Bennett's list is right on target IMHO, but I've had this
> discussion so many times before, I don't have much ene
On 02/21/2013 12:32 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:
>
>> It is to a degree, but the learning curve for git is subtantially steeper
>> than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or
>> another and there is no question in my mind
Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit :
> On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
> ...
> > That argument applies to any VCS that you don't use on a daily basis. You
> > use bzr on a daily basis and forget how to use git. I use git on a daily
> >
On 21/02/2013 12:46, Barry Warsaw wrote:
> #9 on Steve Bennett's list is right on target IMHO, but I've had this
> discussion so many times before, I don't have much energy for it again.
>
> """
> 9. Git history is a bunch of lies
> The primary output of development work should be source code. Is
On Thursday, February 21, 2013 01:57:11 PM Thomas Goirand wrote:
> On 02/21/2013 12:32 PM, Barry Warsaw wrote:
> > On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote:
> >> It is to a degree, but the learning curve for git is subtantially steeper
> >> than for other VCS. I've learned CVS, SVN, BZR
On Thursday, February 21, 2013 03:00:56 PM Charles Plessy wrote:
> Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit :
> > On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
> > ...
> >
> > > That argument applies to any VCS that you don't use on a daily basis.
> > >
On Thursday, February 21, 2013 01:52:59 PM Chow Loong Jin wrote:
> (Re-posted back on list. Sorry ScottK.)
>
> On 21/02/2013 12:37, Scott Kitterman wrote:
> > With git (I've never used gpb, and maybe that's my problem) I end up
> > having to do things like:
> >
> > git clone git://git.debian.org/
On Thursday, February 21, 2013 02:02:09 PM Chow Loong Jin wrote:
> On 21/02/2013 12:46, Barry Warsaw wrote:
> > #9 on Steve Bennett's list is right on target IMHO, but I've had this
> > discussion so many times before, I don't have much energy for it again.
> >
> > """
> > 9. Git history is a bunc
On Feb 20, 2013 11:57 PM, "Dmitrijs Ledkovs" wrote:
>
> On 19 February 2013 23:49, Ludovic Gasc wrote:
> >
> > On Feb 19, 2013 11:21 PM, "Barry Warsaw" wrote:
> >>
> >> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
> >>
> >
> > I can do that this week-end. I've only a github account to pub
On 02/21/2013 01:36 PM, Scott Kitterman wrote:
> Agreed.
>
> I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to
> be able to find it 4 years later).
>
> Scott K
Lucky, 4 years later, the error messages of Git are
much much more helpful than they used to be (in
fact, since
On 02/21/2013 02:29 PM, Scott Kitterman wrote:
> I've tried doing this. Then I looked back and noticed that I was spending a
> LOT of time making the VCS pretty, just in case and rarely had to revert
> anything. It turned out I was spending a lot of time to save a little time
> and that's just
On Thu, 2013-02-21 at 12:08 +0800, Chow Loong Jin wrote:
> On 21/02/2013 11:58, Scott Kitterman wrote:
> > I'm all for easy. I have yet to see a full source (regardless of VCS) or
> > git
> > workflow that I didn't find more complex and harder to remember/do
> > correctly
> > than what we have
On 02/21/2013 02:26 PM, Scott Kitterman wrote:
>
>> I undertand that learning Git after BZR is hard, because learning BZR after
>> Git is equally painful. I think that the key difficulty is whether a
>> system is learned first or second, not the system itself.
>>
>> This is where git-buildpackage
52 matches
Mail list logo
