v3 Debian source package formats

[George Danchev]

On Thursday 02 October 2008 20:33:00 Manoj Srivastava wrote:
> On Thu, Oct 02 2008, George Danchev wrote:
> > Quoting Manoj Srivastava <srivasta at acm.org>:

--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>