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 contribute..." > 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 details. > >> 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 any reason. > > ... 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: http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2008-October/000378.html > 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 packages released. 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 [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
