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
