On Wednesday 01 October 2008 22:07:12 Manoj Srivastava wrote:
> On Wed, Oct 01 2008, George Danchev wrote:
> > On Wednesday 01 October 2008 15:13:45 Manoj Srivastava wrote:
> >> On Wed, Oct 01 2008, martin f krafft wrote:
> >> > also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.10.01.0302
> >> > +0200]:
> >> *Shrug*. If the 3.0 (git) format is untenable, then I suppose
> >> I'll just let dpkg muddle through. I am not _that_ interested in making
> >> it easier for vaporware helpers to possibly contribute that I'll be
> >> willing to take a huge hit on my productivity.
> > I guess you are still missing the point and at the end your production
> > might be useless to your users/reviewers/contributors, no matter how
> > productive *you* have been.
> I am not sure where your data is that potential contributors
> will not be able to get the information from the DVCS.
That is your data, not mine; some lines above you wrote: "I am not _that_
interested in making it easier for vaporware helpers to possibly
> Also, there is a
> tradeoff: the hoops actual workers have to jump through in order to
> make things _possibly_ easier for vaporware potential contributors.
Again, you are only interested to do what is easier for you. In fact, I really
find your workflow quite simplistic and ignoring to various important
> >> The bottom line still remains making it easier for me to package
> >> software for my distribution cleanly, efficiently, and without
> >> having to jump through too many hoops.
> > It is much more efficient to invest some efforts at your side and make
> > divergencies from upstream clearly identified, than everybody else to
> > spend time on his own to investigate your divergencies from upstream
> > and doing that *your way*.
> Its not like I am using a super secret manoj only mechanism to
> hide the changes -- git and gitweb make the changes easy to discover.
You are completely ignoring VCS-agnostic nuance. Not a factor for me.
> On Wed, Oct 01 2008, George Danchev wrote:
> >> I find it easier reading code than reading patches upon patches
> >> upon patches that modify code I can read. If there are dependent
> >> patches, keeping all the previous changes in your head as you look at
> >> yet another patch modofying the same file .. well, good luck.
> > If you really read these that way, then you are really unlucky.
> I think that serialized patches makke features harder to
> understand, and would prefer actually each feature separately in an
> independent patch series; so people can try each feature out without
> trying them all.
This might be you, but not the rest of the world. Also, people are hardly
trying to develop large and nifty features in their debian/patches/
seriously. These are for tracking divergencies, not accepted upstream X.Y for
> > ... and of course clearly identified patches are already published at:
> > http://patch-tracking.debian.net and in case you forgot these patches
> > are also distibuted by cd/dvd images and official ftp archive.
> Nice, but hardly very relevant to the point.
> Because reading feature N quilt patches is harder, since it does
> not apply directly to upstream, but to upstream + N -1 patches, which
> is tricky. Unless you have non serialized independent topic patches,
> that all apply to upstream, reading all but the first patch is harder.
Sorry, but non of them is a superior method wrt perspicuity.
> >> You can easily check the integration branch in the repo versus
> >> the unpackahed sources (applying the giant diff.gz). This is not
> >> really an argument that gells with me. Heck, I don't know if what is in
> >> Linus' release branch is what is in the tarball, but I don't thinkit
> >> bothers me a lot.
> > Yes, I know it is easier for you to ingore the issue, but I don't find
> > such an ostrich policy a sound solution, but I find git+topgit+quilt
> > much better in that case.
> Oy vey. Reading about a specific feature with serialized patches
> is not easy. Selecting Feature A and Feacure F and looking to see how
> they interact without anything else is not easy.
> Quilt sucks there.
> But you prefer to ignore that, and instead accuse me of hiding
> my head in the sand. But that's irony for you.
Again not on topic, the context is point 2, which you are ignoring:
> I have also considered ./debian/topics; with one patchset per
> topic, so people can study the divergence, but ship the integration
> branch, making it easy for people to look at each feature by itself, or
> look at them all.
> >> Hey, with the 3.0 (git+) format, we can bring these people
> >> in. But in this day and ag, the arguments for distributed VCS's and
> >> distributed development trump catering to the connectivity challenged.
> > Oh, please quit explaining things we already know. I didn't write that
> > in the light of 3.0 (git) format, but in the light of your current
> > packaging. OTOH, 3.0 (git) won't help users much when your
> > divergencies from the upstream have been deeply hidden in the VCS
> > history, and we have already seen such a failure.
> Seen a failure in my packages? or some other red herring? Why
> are the divergences hidden if they are in a separate feature branch? It
> is easy to look at how each topic branch diverges from upstream --
> that is why they are ca;;ed topic branches.
I personally do not want to look at your diff.gz files released with lenny in
order to find your divergencies from upstream tar, and I really hope I won't
need to inspect your *public* branches and compare them to the source
Finally, I won't reply to joined messages resulting in complete mess wrt
contexts involved. Your approach is well known, but doesn't scale well for
the rest, but you.
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
vcs-pkg-discuss mailing list