gmane.comp.package-management.vcs-pkg

Re: debian/topics and conflict resolution

Manoj Srivastava — 2008-10-07T04:00:06

Hi, Perhaps I should wait after drinkina high sugar content drink before posting. On Mon, Oct 06 2008, Manoj Srivastava wrote: I think I missed the point here. I never said the integration branch is not built before the source package is. I am thinking that my current work-flow is not so bad, if only I add the separate patches people want. So, I create my integratio branch as I have done since 2003, and I just ship the feature and the integration branch as patches. Sorry for jumping the gun. manoj

Re: the goal of vcs-pkg

Manoj Srivastava — 2008-10-07T03:18:44

Traditionally, one sets up a dist/configure or automake rule that figures out where the lib is, and the software uses indirection to determine the TG_LIBEXEX_DIRPATH or something. This is only a nominal benefit. If I ship the integration branch as the diff.gz, you have no conflicts to use the all the features built. Now, If I want to try just topic F, it is easier with pure topic patches. Trying just feactures E and H is also easier with just the pure topic patches, though perhaps with some work. I am looking at the common cases here. I posit the most common case is to: a) Want all the features (use the diff.gz integration branch) b) Try a single feature (use orig.tar.gz and the pure feature patch) Combinations of a subset of the patches are still relatively easy, at he expense of perhaps needing some work. *Shrug*. To get to this developers preferred mode of working, there is redundancy in the feature branch + integration branch mode,

Re: debian/topics and conflict resolution

Manoj Srivastava — 2008-10-07T03:10:00

Why does it matter to people who are looking at the source package who exactly created the integration branch? It could have been manually created, it could have been created with the assistance of tools. The take away point is that with independent features, it should be feasible for people to study each feature in isolation, or all together, easily. Looking at subsets of features, but more than one at a time, is a less common task, and should be possible, but perhaps require a little work. manoj

Re: the goal of vcs-pkg

martin f krafft — 2008-10-06T08:01:51

debian/topics and conflict resolution (was: v3 Debian sourcepackage formats)

martin f krafft — 2008-10-06T07:56:04

Re: v3 Debian source package formats

Manoj Srivastava — 2008-10-04T05:35:28

Actually, this is not targeting the 3.0 formats at all. I intend to start shipping my packages with version 1.0 format, and a ./debian/topics directory with patches corresponding to every pure feature branch I have. Right. The diff.gz is what the buildd's are fed, each of the patchsets in ./debian/topic recreate exactly the feature branches used to develop the code, the orig.tar.gz is the upstream branch. So, just using the orig.ar.gz and each of these patches, one can exactly replicate the tip of all the branches in use. I don't think fit into the distributed model has anything to do with it. I find serialized patches harder to read than pure feature patches. Also, I find it hard to try out just one feature if all the features are ordered and serialized; the features at the end of the chain are very hard to decipher. I am just making it easier for people to read the patches. Well, given that it is not the distributed vs one-off mode that makes

Re: v3 Debian source package formats

George Danchev — 2008-10-03T19:45:47

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

Re: v3 Debian source package formats

Manoj Srivastava — 2008-10-02T18:33:00

I do not see a major use case for distrusting the developer as the basis of collaboration. 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. 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). 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. manoj

Re: the goal of vcs-pkg

Manoj Srivastava — 2008-10-02T18:06:55

Now suppose you have your _own_ heirarchy of debian directories. You can just change the submodule location, which is only referred to in the build branch, and continue with ever other feature branch inherited straight from me. Indeed, you can develop in parrallel with me, getting all the feeds, and yet have the comfort of your own build system using debhelper as opposed crazy manoj build system. Making the packaging, which changes from developer to developer (cdbs, debhelper, debhelper7, yada, custom) allows for _easier_ exchanges, since only the submodule location changes. If I thought a serialized patch series had sufficient benefits, I would do the work. I would prefer ./debian//topics, where I have one patch series per topic, which all applies to upstream, and then people can try any feature they want, one at a time, or all the features at once, by using the integratiopn branch. The patches for each independent feature can still be put pu on

Re: recreating historic packages

Teemu Ikonen — 2008-10-02T12:21:50

If the revision graph is identical in both cases, I don't think there's any automated way to distinguish between them. I have to admit I don't understand why would you want to have a situation like in your second case. If you want your build branch to based on upstream-B but have a feature branch which has been merged with a later upstream version, then you will get a feature patch which contains both new upstream changes and the changes specific to the feature branch. I think it would be safe to assume (at least in the case of packaging) that all the (top-) bases in a given package version are nodes in a subgraph which starts from a single commit in the upstream branch and where paths from this upstream commit to a given base commit contain only other (top-)bases. I.e. .topdeps should only contain "upstream" and other tg branches, and all the tg branches should be up to date. Or would there be a reason to include more than one upstream commit in the set of dependencies? Teemu

Re: v3 Debian source package formats

George Danchev — 2008-10-02T08:16:36

Quoting Manoj Srivastava acm.org>: --cut-- Multiply that with the number of your possible users, and you will see what a giant time-waste is. 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.

Re: Introductory mail

Guido Günther — 2008-10-02T07:37:54

Sure, but that's doable. I've added #500865 for that. It's not very high on my todo list, but maybe somebody else comes up with a patch. Cheers, -- Guido

non-./debian/ distros (was: the goal of vcs-pkg)

martin f krafft — 2008-10-02T06:43:37

the goal of vcs-pkg (was: v3 Debian source package formats)

martin f krafft — 2008-10-02T06:40:16

Re: v3 Debian source package formats

Manoj Srivastava — 2008-10-02T03:48:31

Some do. Some take time getting accepted (make releases less often than Debian). I've carried mailagent patches for 10 years until they got accepted. Some represent a disagreement between upstream and me. So those features remain a Debian only feature. I also keep stuff required by Debian policy in distinct feature branches -- often, these are not feasible upstream, since not all other distributions conform to Debian policy. manoj

Re: v3 Debian source package formats

Aidan Van Dyk — 2008-10-02T00:50:51

Re: v3 Debian source package formats

Manoj Srivastava — 2008-10-02T00:36:08

Err. What I was sayingthat going out of the way to provide quilt series for vaporware helpers is a bad use of my energy. That does not help you; it does not prove in any way that people can not just use git. Sorry about that. Care to back up your statements o your own now? In what way am I missing important details? Work flows are supposed to be simple, but simplistic? What aspect of my work flows is simplistic? Can you back up your ad hominem accusations here, or is it just vitriol and rhetoric? Yes, I do want to make my work-flow as streamlined as possible, so I can spend more time with the new policy process, and the docbook conversion. I don't want to shortchange the users of my packages, so the less time spent in the mundane details of packaging the better. Hmm, yes. I do not see VCS agnosticism via quilt as a a great solution. Indeed, software development right now does require knowledge of software tools, and VCS' are one of

Re: v3 Debian source package formats

George Danchev — 2008-10-01T23:46:42

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..." 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. You are completely ignoring VCS-agnostic nuance. Not a factor for me. 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. Sorry, but non of them is a superior method wrt perspicuity. 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 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

Re: Introductory mail

Manoj Srivastava — 2008-10-01T20:14:12

My first thought was to make is less clever. Assuming it is run from the integration (debian) branch, it can first find the top of the tree : ,---- | base_dir=$(git-rev-parse --show-cdup 2>/dev/null) || return 1 | if [[ -n "$base_dir" ]]; then | base_dir=$(readlink -f "$base_dir") | else | base_dir=$PWD | fi `---- Then it can explicitly look for $base_dir/.gitmodules, and for path = debian in there, to see if it is a module (alternately, simply look for $base_dir/debian/.git, which is less clever, but still works). Then it can just cd $base_dir/debian/, and gather more things to add. The problem probably is keeping track of a second set of commits; we need not just the build branch, we now need a ./debian submodule branch, I would code this up, but I would first have to write up git-dch in perl. manoj

Re: v3 Debian source package formats

Manoj Srivastava — 2008-10-01T20:07:12

I am not sure where your data is that potential contributors will not be able to get the information from the DVCS. Also, there is a tradeoff: the hoops actual workers have to jump through in order to make things _possibly_ easier for vaporware potential contributors. Hmm. 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. On Wed, Oct 01 2008, George Danchev wrote: 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. 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

Re: v3 Debian source package formats

George Danchev — 2008-10-01T20:18:42

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