On Thursday 02 October 2008 20:33:00 Manoj Srivastava wrote: > On Thu, Oct 02 2008, George Danchev wrote: > > Quoting Manoj Srivastava <[EMAIL PROTECTED]>:
--cut-- > > Nobody is comparing git with quilt, really. Obviously you are trying > > to compare different unit types as a result of muddle thinking. It is > > not git *or* quilt, but DVCS *and* some sort of patch series and I see > > LKML and git developers constantly performing that. So, forget about > > quilt and think of the least common multiple as an abstract change > > units every can inherit and extend. > > Fine. Then I posit that the best way to help people is to give > them the same environment that I work with (preferred form of > modification and all). This means putting in ./debian/topic a patchset > for each pure featrue branch, that is not serialized, so people can > try out each fauture by itself, makes it easier for upstream or > downstream to get a single feature cherry picked. Now, that is something different, and if I understand correctly it is targetting 3.0 (git) format, that's fine. The best part is that the users will get your environement via the debian source package, i.e. what is officially released by Debian and what buildd's had been fed with, right ? I can also see your effort to avoid serialization, since it somehow doesn't fit well enough in the distributed model. However, I'm not exactly sure if users really need that since they will hardly intend to develop in parallel with you via the debian source package they just apt-get source'd, instead they would love to perform a mere audit test, i.e. how Debian patched a particular upstream version, when the simple patch series is enough. > The diff.gz is then the integration branch, and produces the > sources that the package was built from. > > The one thing you lose is the serialization changes (the efort > that is spent in serializing the features). OTOH, nothing stops the user-side to get their patch series back via `tg export --quilt' on the top of your 3.0 (git) package if needed, or am I missing something here ? Given that, the main question is: do we really need to push all that distributed burden to the mortal user, when he merely needs to see (review/audit) divergencies from upstream -> a mere patch series will do, and will simplify the things. OTOH, if he really wants to develop in parallel with you or upstream developers he will jump thru all the hoops of the distributed model and will hardly depend on your DVCS-ready debian source package. Undoubtedly, from the debian developer point of view, users doing that via the debian source package (since it is a ready to go git repo) would be a pleasant surprise, but do all users-reviewers are ready to pay that price. I'm quite uncertain about that, and only time will tell, so I might be wrong. > Given the advantages (ability to checkout any feature > independently, exact replication of the developers working > environment), I am willing to fail on the linkage between feature > branches and the integration branch being re-done on the fly during > build. re-doing that build-time might be fragile, though I can't think of any unexpected results right now, but seems to be doable. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss