On Sun, 03 Feb 2008, Raphael Hertzog wrote:
> On Sat, 02 Feb 2008, Charles Plessy wrote:
> > Is there sombody working on Wig&Pen? Is the format consensual enough
> > that it would be accepted in Debian?
>
> I plan to work on it (but have not done anything yet except thinking about
> it and followi
On Fri, Feb 29, 2008 at 09:30:16PM +0100, Florian Weimer wrote:
> * Ben Finney:
> > It's no security risk to unpack a tarball, apply a patch to it via GNU
> > 'patch', and examine the result.
>
> History should tell you that this is not true. 8-) I can even understand
> people who state that GNU t
Hi,
For people who are trying to figure out what my merging and
branching workflow looks like, I have uploaded a recent picture for
fvwm at:
http://people.debian.org/~srivasta/fvwm.png
I should warn you that this is a large image; and is known to
crash iceweasel. I suggest
On Sat, 01 Mar 2008, Manoj Srivastava wrote:
> Why do we have to settle on a quilt based source package, when
> my proposal meets all the requirements anyway? Why does it have to be
> one or the other?
It's not going to be one or the other. Note that your changes on upstream
code can be
On Sat, 1 Mar 2008 17:24:49 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Florian Weimer <[EMAIL PROTECTED]> [2008.03.01.1650 +0100]:
>> It does, if you ship the sources with the series applied. AFAICT,
>> this is not what's usually done.
> ... or if the patches were automatica
On Sat, 1 Mar 2008 12:21:03 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.29.2153
> +0100]:
>> 3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
>> files. Each diff, applied to the orig.tar.gz , shall recreate for the
>> i
On Sat, 1 Mar 2008 14:16:20 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Florian Weimer <[EMAIL PROTECTED]> [2008.03.01.1334 +0100]:
>> The nice thing about Manoj's proposal that we (as in "the security
>> team", for instance) need not care if the Debian maintainer thinks
>> tha
also sprach Florian Weimer <[EMAIL PROTECTED]> [2008.03.01.1650 +0100]:
> It does, if you ship the sources with the series applied. AFAICT, this
> is not what's usually done.
... or if the patches were automatically applied when the source is
unpacked, which is where I think we're heading.
--
* martin f. krafft:
> also sprach Florian Weimer <[EMAIL PROTECTED]> [2008.03.01.1334 +0100]:
>> The nice thing about Manoj's proposal that we (as in "the security
>> team", for instance) need not care if the Debian maintainer thinks that
>> upstream needs pristine topic branches, an integration b
also sprach Florian Weimer <[EMAIL PROTECTED]> [2008.03.01.1334 +0100]:
> The nice thing about Manoj's proposal that we (as in "the security
> team", for instance) need not care if the Debian maintainer thinks that
> upstream needs pristine topic branches, an integration branch, a weave,
> or whate
* martin f. krafft:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.29.2153 +0100]:
>> 3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
>> files. Each diff, applied to the orig.tar.gz , shall recreate for
>> the interested user the corresponding branch in my de
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.29.2153 +0100]:
> 3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
> files. Each diff, applied to the orig.tar.gz , shall recreate for
> the interested user the corresponding branch in my development.
>
> Bi
* Manoj Srivastava:
> Now, a lot of what I need is already present.
> 1) the orig.tar.gz represents the upstream branch, exactly.
> 2) the diff.gz + orig.tar.gz represents the integration branch,
> exactly.
>
> So the missing thing is the topic branches.
> 3) I propose ./de
On Sat, Jan 26, 2008 at 11:39:32PM +0100, Pierre Habouzit wrote:
>
> Another thing is that people have the old habit to see the source
> package be the preferred form of modification for a Debian package.
Hmm. This started off a train of thought. In one sense, one
could see the source co
* Manoj Srivastava:
> But there is no such linearization, not in the way that quilt et
> al do it. The state of such integration is not maintained in the
> feature branches; it is in the history of the integration branch. As
> each feature branch was created or developed, if there wer
* Ben Finney:
> It's no security risk to unpack a tarball, apply a patch to it via GNU
> 'patch', and examine the result.
History should tell you that this is not true. 8-) I can even understand
people who state that GNU tar should never be used to uncompress
tarballs from untrusted sources, and
On Sat, Jan 26, 2008 at 11:39:32PM +0100, Pierre Habouzit wrote:
>
> Another thing is that people have the old habit to see the source
> package be the preferred form of modification for a Debian package.
erm ...
Regards,
Paddy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Manoj Srivastava wrote:
> And no, I can do this using plain old arch, and I don't really
> have to change my SCM.
> But not all Debian maintainers are using git;
>> Version control systems that have content-addressable filesystems
>> (essentially, git and Monotone) are inherently e
On Fri, 29 Feb 2008 16:11:48 +1300, Sam Vilain <[EMAIL PROTECTED]> said:
> Manoj Srivastava wrote:
>>> Yes. Feature branches are effectively forking a particular version
>>> of a project - this is not a problem, and is essential for efficient
>>> development. People jumbling together changes in
Manoj Srivastava wrote:
>> Yes. Feature branches are effectively forking a particular version of
>> a project - this is not a problem, and is essential for efficient
>> development. People jumbling together changes in "trunk" branches is
>> perhaps one of the worst upshots of the 2002-2006 or so
On Fri, 29 Feb 2008 12:35:30 +1300, Sam Vilain <[EMAIL PROTECTED]> said:
> Manoj Srivastava wrote:
>>> Feature branches don't magically allow you to avoid merge conflicts
>>> either, so this is a red herring. Once you've resolved the conflict,
>>> then it becomes just another change. This change
Manoj Srivastava wrote:
>> Feature branches don't magically allow you to avoid merge conflicts
>> either, so this is a red herring. Once you've resolved the conflict,
>> then it becomes just another change. This change can become a diff in
>> a stack of diffs.
>
> This whole message is a r
On Mon, 25 Feb 2008 19:04:10 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Mon, Feb 25, 2008 at 03:56:49AM -0600, Manoj Srivastava wrote:
>> No, it does not. If branch A has pi = 2.34567; and branch B has pi =
>> 3.14159;
>>
>> No matter how much quilting you do you cannot reconcile the
>>
On Mon, 25 Feb 2008 19:11:16 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Sun, Feb 24, 2008 at 09:31:10PM -0600, Manoj Srivastava wrote:
>> On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney
>> <[EMAIL PROTECTED]> said:
>>
>> > Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> >> David Nusinow
On Sun, Feb 24, 2008 at 09:31:10PM -0600, Manoj Srivastava wrote:
> On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney <[EMAIL PROTECTED]> said:
>
> > Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >> David Nusinow <[EMAIL PROTECTED]> said:
> >>
> >> > No matter what you want to say about your featu
On Mon, Feb 25, 2008 at 03:56:49AM -0600, Manoj Srivastava wrote:
> No, it does not. If branch A has
> pi = 2.34567;
>and branch B has
> pi = 3.14159;
>
> No matter how much quilting you do you cannot reconcile the
> fundamental conflict in the final. Either pi is 3.14159; o
On Mon, Feb 25, 2008 at 04:06:31PM +, Cyril Brulebois wrote:
> On 25/02/2008, Pierre Habouzit wrote:
> > I'm planning to write a textual version of what I demonstrated at
> > FOSDEM, with some more ideas that I had talking with Julien Cristau
> > on the grass after.
>
> Please, pretty please
On 25/02/2008, Pierre Habouzit wrote:
> I'm planning to write a textual version of what I demonstrated at
> FOSDEM, with some more ideas that I had talking with Julien Cristau
> on the grass after.
Please, pretty please, include graphics. Be it ASCII art-like
drawings, or gitk screenshots, with
On Mon, 25 Feb 2008 10:40:31 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said:
> On Mon, Feb 25, 2008 at 09:33:48AM +, Pierre Habouzit wrote:
>> When it comes to specific patches of yours, I really believe that
> I really *don't*
>
On Mon, 25 Feb 2008 10:33:48 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said:
> On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote:
>> On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said:
>>
>> > On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote
On Mon, 25 Feb 2008 09:35:13 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.25.0828
> +0100]:
>> I am not opposed to it. If you can somehow magically create a tool
>> that can linearize the feature branches, more power to you. I
>> per
On Mon, Feb 25, 2008 at 09:33:48AM +, Pierre Habouzit wrote:
> When it comes to specific patches of yours, I really believe that
I really *don't* believe
> topic branches like you advertise them are the best answer. Git makes
--
·O· Pierre H
On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote:
> On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow <[EMAIL PROTECTED]> said:
>
> > On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
> >> David Nusinow <[EMAIL PROTECTED]> writes:
> >>
> >> > The problem is that you a
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.25.0828 +0100]:
> I am not opposed to it. If you can somehow magically create a
> tool that can linearize the feature branches, more power to you. I
> personally find the prospect highly unlikely; and I would like to see
> some co
Hi,
On Sun, 24 Feb 2008, Manoj Srivastava wrote:
> I like the reduced work for each upload, and since it satisfies
> the use cases of being able to present upstream with a pure feature
> changeset;
It doesn't satisfy it completely. You can always generate a patch for
a pure feature chan
On Sun, 24 Feb 2008, Charles Plessy wrote:
> Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit :
> >
> > > - When modifying a package that uses dpatch, quilt or simple-patchsys,
> > > developpers have to find out by themselves if the target for patching
> > > the sources is pat
On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627
> +0100]:
>> I am not sure you have understood feature branches. They are
>> independent, no matter what the overlap. Each feature branch tracks
>> on
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627 +0100]:
> I am not sure you have understood feature branches. They are
> independent, no matter what the overlap. Each feature branch tracks one
> feature against upstream, no matter how the other features work.
>
>
Hi,
I think one of the differences that patch series mechanism has
wrt to new development, either in a feature or upstream, is that it
requires updates to the integration work doe every single upload. It
also requires a strict ordering between each feature, making it harder
to compile
On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
>> David Nusinow <[EMAIL PROTECTED]> writes:
>>
>> > The problem is that you and Manoj assume that this is the only way
>> > to do things. I don't believe t
On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> David Nusinow <[EMAIL PROTECTED]> said:
>>
>> > No matter what you want to say about your feature branches, you
>> > *must* apply them in a linear fashion to your final sour
On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote:
> David Nusinow <[EMAIL PROTECTED]> writes:
>
> > The problem is that you and Manoj assume that this is the only way to do
> > things. I don't believe this. Pierre Habouzit has been experimenting
> > with an alternative method of featur
David Nusinow <[EMAIL PROTECTED]> writes:
> The problem is that you and Manoj assume that this is the only way to do
> things. I don't believe this. Pierre Habouzit has been experimenting
> with an alternative method of feature branches that exports to a linear
> stack of diffs just fine. Just bec
On Sun, Feb 24, 2008 at 05:10:16PM -0800, Russ Allbery wrote:
> Ben Finney <[EMAIL PROTECTED]> writes:
> > Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
> >> But there is no such linearization, not in the way that
> >> quilt et al do it. The state of such integration is not maintained
>
Ben Finney <[EMAIL PROTECTED]> writes:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> But there is no such linearization, not in the way that
>> quilt et al do it. The state of such integration is not maintained
>> in the feature branches; it is in the history of the integration
>> b
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> David Nusinow <[EMAIL PROTECTED]> said:
>
> > No matter what you want to say about your feature branches, you
> > *must* apply them in a linear fashion to your final source tree
> > that you ship in the package. This is no way around it.
>
>
On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>> Now, you are trying to make me go towards a mechanism I think is
>> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>> shaky lin
On Sat, 2008-02-23 at 09:08:23 -0600, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
>
> Currentl
On Sat, 23 Feb 2008 16:58:01 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said:
> On Sat, Feb 23, 2008 at 03:08:23PM +, Manoj Srivastava wrote:
>> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said:
>>
>> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava w
* Teemu Likonen:
>> That would be one possible way of implementing it. I'd be satisfied
>> with that, and it's in the spirit of the way Debian tries to
>> standardize on interfaces that don't unduly limit implementation.
>
> To add up to this suggestion:
>
> If some patch system is used, there wou
Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit :
>
> > - When modifying a package that uses dpatch, quilt or simple-patchsys,
> > developpers have to find out by themselves if the target for patching
> > the sources is patch, apply-patches or apply-dpatches.
>
> Once the ne
On Sat, Feb 09, 2008 at 10:53:55AM +0100, Patrick Schoenfeld wrote:
> (BTW. there is no need to CC me with your answers, I did not ask for
> that as I am subscribed to the list :-)
>
> On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote:
> > quilt is way more powerful to refresh patc
On Sun, 24 Feb 2008, Charles Plessy wrote:
> Therefore we did not make progress since the beginning of the
> discussion:
You're trying to make progress somewhere where it's not expected.
> - The most efficient way to deal with changes to the sources for the
> packager is to use his preferred to
Le Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava a écrit :
>
> That is not the case when using featrure branches, the NMUer can
> get the information they need.
>
> But if you are a security NMUer, you have a short time frame,
Hi all,
actually, we as packagers have wr
On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
> Now, you are trying to make me go towards a mechanism I think is
> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
> shaky linear patch series) as opposed to pure, independent feature
> branches, fo
On Sat, Feb 23, 2008 at 03:08:23PM +, Manoj Srivastava wrote:
> On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said:
>
> > On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
> >> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
> >> <[EMAIL PROTECTED]>
On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <[EMAIL PROTECTED]> said:
> On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> <[EMAIL PROTECTED]> said:
>> > That does not help me during an NMU from the source package.
>>
On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> > That does not help me during an NMU from the source package.
>
> For an NMU of one of my source packages, if you can't deal with
> the dis
On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.20.1722
> +0100]:
>> I have to take care of it manually once. That is the first time I
>> setup the integration branch that merges in changes from the
>> over
On Thu, 21 Feb 2008 16:23:10 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
>> The difference here being that feature branches are, in my
>> experience, changes against the pristine upstream source. The
>> merging of differe
On Wed, 20 Feb 2008 23:09:03 +0100, sean finney <[EMAIL PROTECTED]> said:
> i think this discussion is in part to propose a system that can serve
> as a layer of abstraction between $developer's $scm implementation and
> some common format/methodology, so that when $otherdeveloper comes
> along a
On Thu, Feb 21, 2008 at 04:23:10PM +0100, martin f krafft wrote:
> also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
> > The difference here being that feature branches are, in my experience,
> > changes against the pristine upstream source. The merging of different
> > feature b
also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
> The difference here being that feature branches are, in my experience,
> changes against the pristine upstream source. The merging of different
> feature branches is done in some integration branch. Quilt patches are
> a depend
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.20.1722 +0100]:
> I have to take care of it manually once. That is the first time
> I setup the integration branch that merges in changes from the
> overlapping feature branches. This is not a big deal, because the
> human has
On Wed, Feb 20, 2008 at 11:09:03PM +0100, sean finney wrote:
> On Wednesday 20 February 2008 05:22:08 pm Manoj Srivastava wrote:
> > > Yes, just like I want to have feature branches instead of one gigantic
> > > debian branch.
> >
> > I use my CSM to provide me the changeset:
> > baz dif
On Wednesday 20 February 2008 05:22:08 pm Manoj Srivastava wrote:
> > Yes, just like I want to have feature branches instead of one gigantic
> > debian branch.
>
> I use my CSM to provide me the changeset:
> baz diff
>
> Indeed, I can get diffs between branch A and branch B --
On Wed, 20 Feb 2008 11:17:29 +0100, martin f krafft <[EMAIL PROTECTED]> said:
>> You hack in the sloppy branch. You merge change sets from the sloppy
>> branch into the feature branches. You merge the delta from the
>> feature branch into the integration branch. In my experience, there
>> is usua
also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.17.0029 +0100]:
> > But sometimes you will have to touch an integration branch and then
> > things get messy, especially if there are dependencies between feature
> > branches. I think David is making a very strong point here...
>
>
On Sat, 16 Feb 2008 20:24:12 +1100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.05.1751
> +1100]:
>> On Sat, 26 Jan 2008 11:34:27 -0500, David Nusinow
>> <[EMAIL PROTECTED]> said: [...]
>> > An alternate idea I keep seeing is feature branc
On Sat, Feb 16, 2008 at 09:24:12AM +, martin f krafft wrote:
> > Because it's a way to high level tool for the task. Git (and
> > I suppose that the following is true for other DVCS, and if not,
> > they _REALLY_ suck, and I mean it, really) has been designed so
> > that you can only ex
Sorry for the late reply. I'll send only a single reply this time
since my flood reply seemed to annoy some people. I still think
short single replies are better than long, unified ones...
also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.02.03.2038 +1100]:
> > > I'm less and less sure that
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Thu, 7 Feb 2008 11:48:47 +, Matthew Johnson <[EMAIL PROTECTED]> said:
>> On Thu Feb 07 22:42, Ben Finney wrote:
>>> In the scenario Manoj presents above, the modifications applied to
>>> upstream are easily available all in one place: the foo.
On Fri, 08 Feb 2008 09:45:06 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said:
> On Thu, Feb 07, 2008 at 11:42:16AM +, Ben Finney wrote:
>> Pierre Habouzit <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, Feb 07, 2008 at 05:12:00AM +, Manoj Srivastava wrote:
>> > > Why should I bring m
On Thu, 7 Feb 2008 11:48:47 +, Matthew Johnson <[EMAIL PROTECTED]> said:
> On Thu Feb 07 22:42, Ben Finney wrote:
>> In the scenario Manoj presents above, the modifications applied to
>> upstream are easily available all in one place: the foo.diff.gz.
> But all as one patch, not as your nice
Hi Pierre,
(BTW. there is no need to CC me with your answers, I did not ask for
that as I am subscribed to the list :-)
On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote:
> quilt is way more powerful to refresh patches when a new upstream
> occurs. It does what it can do best with
On Fri, Feb 08, 2008 at 09:50:20AM +, Patrick Schoenfeld wrote:
> Neither did I. I just thought that it could have some features that make
> it so much better then dpatch, which could actually make up the reason why
> everybody is crying "damn dpatch, glorify quilt". So now everybody says
> tha
Hi Matt,
On Wed, Feb 06, 2008 at 11:25:19AM +, Matthew Johnson wrote:
> I'd have said that it would be more sensible to define a reasonable subset
> of quilt features. A set of patches with comments at the top and a
yes, this sounds reasonable. But I'm not a quilt user and therefore
don't kno
On Thu, Feb 07, 2008 at 11:42:16AM +, Ben Finney wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
>
> > On Thu, Feb 07, 2008 at 05:12:00AM +, Manoj Srivastava wrote:
> > > Why should I bring my feature branches into a patch system, when
> > > there is no need to? As far as th
Michael Banck <[EMAIL PROTECTED]> writes:
> Well, we sort of managed to get our debian/changelog entries more
> readable due to social pressure, if we standardize on a patch exchange
> format which mandates a description in the header, we can probably
> continously improve the description of patch
On Sat, Feb 02, 2008 at 10:26:52PM +0100, Pierre Habouzit wrote:
> Bah that's the worst reason I ever seen to not use a DVCS in Debian.
> Please look at the debian packages with patches, and please tell me how
> many come with a comment about what the patch do. Please start with the
> glibc if yo
On Thu Feb 07 22:42, Ben Finney wrote:
> In the scenario Manoj presents above, the modifications applied to
> upstream are easily available all in one place: the foo.diff.gz.
But all as one patch, not as your nice separated list of commits and/or
branches.
> Whereas with a patch bundle system,
Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Thu, Feb 07, 2008 at 05:12:00AM +, Manoj Srivastava wrote:
> > Why should I bring my feature branches into a patch system, when
> > there is no need to? As far as the end user or NMUer is ocnerned, they
> > do apt-get source foo, and
On Thu, Feb 07, 2008 at 05:12:00AM +, Manoj Srivastava wrote:
> On Tue, 5 Feb 2008 09:00:52 +, Matthew Johnson <[EMAIL PROTECTED]> said:
>
> > On Tue Feb 05 00:51, Manoj Srivastava wrote:
> >> > If we can't figure out a good and clean way to keep a large stack
> >> > of long-lived patches
On Tue, 05 Feb 2008 18:30:40 +0100, Sven Mueller <[EMAIL PROTECTED]> said:
> On another note, I have a slight problem with the (other) proposal of
> using a (git/$DVCS) repository as the form of source package
> distribution. Mainly because I think this will usually add
> bloat. While developing/
On Tue, 5 Feb 2008 09:00:52 +, Matthew Johnson <[EMAIL PROTECTED]> said:
> On Tue Feb 05 00:51, Manoj Srivastava wrote:
>> > If we can't figure out a good and clean way to keep a large stack
>> > of long-lived patches in the vcs then I firmly believe we should
>> > standardize on quilt.
>>
>
On Wed Feb 06 12:09, Patrick Schoenfeld wrote:
> Hi Pierre,
>
> On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
> > Again, the discussion isn't (for me) about a tool, but an exchange
> > format. We are discussing having patches served in a quilt series, and
>
> okay, this appro
Hi Pierre,
On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
> Again, the discussion isn't (for me) about a tool, but an exchange
> format. We are discussing having patches served in a quilt series, and
okay, this approach is similar but different. So you want a quilt
series, but
On Tue, Feb 05, 2008 at 06:24:38PM +, Patrick Schoenfeld wrote:
> So, I would agree with those recommending quilt, if it has significant
> pros besides dpatch. That would be forcing to a specific tool and so
> giving up some diversity, but it would keep giving up freedom of choice
> on a low le
Hi,
On Sat, Jan 26, 2008 at 12:40:14AM +0900, Osamu Aoki wrote:
> This seems to be much cleaner than dpatch or quilt. Also with the help
> of gitk, history is much more visible. I look forward to see it matured
> and accepted.
personally I am a fan of the diversity in the Debian project. Its re
Simon Huggins wrote on 29/01/2008 02:51:
[wig&pen]
The meta data can easily be in these version control systems that
everyone on these threads seems to love so much.
If you want to keep more patches than you expose through wig&pen then
just don't publish them in the dsc.
That won't work well
On Tue Feb 05 23:34, Charles Plessy wrote:
> Case 1: It is because all the changes were in the diff.gz.
>
> Case 2: It is because a clean way of applying the contents of
> debian/patches has been developped and used.
>
> In that case, unless "dpkg-source -b" has been similarly engineered to
>
Le Tue, Feb 05, 2008 at 02:16:09PM +0200, Lars Wirzenius a écrit :
> Specifically I want "dpkg-source -x" to unpack a source package so that
> it is ready for modification, and "dpkg-source -b" to build a new source
> package after it's been edited. Patch systems can and should conform to
> that,
On Tue, Feb 05, 2008 at 06:34:08AM +, Manoj Srivastava wrote:
> On Mon, 04 Feb 2008 22:24:09 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said:
>
> > On Mon, Feb 04, 2008 at 08:02:42PM +, Guillem Jover wrote:
> >> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
> >> > Of cour
Matthew Johnson <[EMAIL PROTECTED]> writes:
> Also: * The package format should be standardised such that the same
> workflow works for everyone.
Not necessarily the pacakge *format*. The request you seem to be
referring to was that of Lars, when he requested that a specific
sequence of o
On Tue Feb 05 14:16, Lars Wirzenius wrote:
> On ti, 2008-02-05 at 12:07 +, Matthew Johnson wrote:
> > Also: * The package format should be standardised such that the same
> > workflow works for everyone.
>
> If that's a reference to my first post to this discussion, it's not
> accurate
On ti, 2008-02-05 at 12:07 +, Matthew Johnson wrote:
> Also: * The package format should be standardised such that the same
> workflow works for everyone.
If that's a reference to my first post to this discussion, it's not
accurate. I don't care about standardizing package formats, but
On Tue Feb 05 22:43, Ben Finney wrote:
> Matthew Johnson <[EMAIL PROTECTED]> writes:
>
> > I am against patch system users being forced to changed to a DVCS
> > system, however, which _has_ been suggested.
>
> I've not seen that suggested in this thread. Can you give a reference,
> please?
>
> W
Matthew Johnson <[EMAIL PROTECTED]> writes:
> I am against patch system users being forced to changed to a DVCS
> system, however, which _has_ been suggested.
I've not seen that suggested in this thread. Can you give a reference,
please?
What I've seen, that might be confused with the above, is:
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Umm. Why would any distributed version control system always
> need history truncation? I am not even sure that arch has such a
> thing; and I have never felt the need for such a beast.
>
> A distributed VCS that bundles in the whole
On Tue Feb 05 00:51, Manoj Srivastava wrote:
> > If we can't figure out a good and clean way to keep a large stack of
> > long-lived patches in the vcs then I firmly believe we should
> > standardize on quilt.
>
> I think I have indeed solved the issue of long standing feature
> sets usin
1 - 100 of 294 matches
Mail list logo
