Decide what to do with the debian/ directory in Tor

During the dev mtg, it was suggested to keep the debian/ directory more up to date by merging weasel's changes more often. The alternative idea was to remove it entirely to make sure people don't find a debian directory and expect it to work.

changed milestone to %Tor: 0.2.2.x-final in legacy/trac

added component::core tor/tor in Legacy / Trac milestone::Tor: 0.2.2.x-final in Legacy / Trac owner::weasel in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac status::closed in Legacy / Trac type::task in Legacy / Trac labels

What's the reason why we're not merging weasel's changes often now?

Also, any solution we come up with should remember the debian/ directory in 0.2.1-maint and 0.2.1-release.

Because this will always be delayed (weasel doesn't make changes until they a new Tor version is tagged), so building from a Tor tag is never useful.

Back in svn times, weasel would push a tag for each of his releases. So using the Tor tag for that release was always wrong then too, and you were supposed to use the debian tag if you wanted the debian timeline.

Can that solution continue to work here?

It could, though weasel's debian tag would refer to a version on his debian branch. (IOW, weasel would tag a version on his branch that was made from Tor's master branch. We'd later merge his changes back into master, and copy his tag over to the master repo.) That works fine for me, if we have to do it, though it would sure be annoying if we wound up doing this for every Linux distribution under the sun and having a tag for each one.

But anyway, I'm fine with Doing Whatever Weasel Thinks Is Best, so long as it involves either removing the debian/ directory from master or merging changes from weasel. Keeping the debian dir in a permanent state of breakage is not keen.

Reassigning to weasel; he will either know the right choice, or know what questions to ask so he knows the right choice.

Trac:
Owner: N/A to weasel
Milestone: N/A to Tor: 0.2.2.x-final
Status: new to assigned

Tor still periodicly merges the entire 0.2. branch into master.

That means any changes that got merged to that branch's debian directory would somehow make it to master. This is something we do not want.

We could do debian- directories in each branch, but that's ugly; let's not do that.

So we cannot keep the debian/ directory in the maintenance branches current, which probably means it should just go away.

Therefore we probably want a documented way that ioerr^Wusers can get a debian/ dir anyway.

There are two options I can think of immediately:

• Have a git repository with just the debian/ directory. Users clone that and put that in their tor code directory as debian. Maybe externals could help here? How do users keep things in sync?
• What we have right now: a git repository that is a clone of tor's. Different branches for different distributions (stable/unstable/experimental...). These git trees hold tor plus all debian specific changes in the debian/ directory. Users just merge these into their working copy if they want a debian dir.

So if there is no debian dir in the maintenance branches, should there be one in master? It'd mean two different sets of instructions depending on which branch a user is on. And the master branch does not keep itself current either.

Sounds to me like "nuke debain/ in master" is the answer, or maybe "replace debian/ in master with a debian/README file explaining where to find the debian tor git repo."

I'd prefer the "nuke" option. Why just in master?

I see nothing wrong with nuking it in maint as well.

Removed from maint-0.2.1 and master. Closing.

Trac:
Resolution: N/A to fixed
Status: assigned to closed

Trac:
Component: Tor Client to Tor

closed

moved from legacy/trac#1735 (moved)

added Task label and removed 1 deleted label

removed 1 deleted label