Re: [alpine-devel] Why? ACF - million repos </sarcasm>
If I have to tag the entire tree for a release, I don't like it.
The reason they were put in separate repos was so that development could be done
independently. If I have to start doing lots of branching so I can release one
package and continue working on another, I don't think it's worth it.
Separate independent repos for separate independent packages.
----- Original Message ----
From: Timo Teräs <timo.teras_at_iki.fi>
To: Ted Trask <ttrask01_at_yahoo.com>
Cc: Natanael Copa <ncopa_at_alpinelinux.org>; jeremy_at_thomersonfamily.com;
Sent: Thu, March 31, 2011 9:26:48 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>
On 03/31/2011 04:14 PM, Ted Trask wrote:
> 1) Having one ACF git repo would save me some work when updating multiple
> packages / releases, but it would add some overhead too. I have a tendency to
> have unfinished work (uncommitted) on some packages while working on others.
> Since git has only one stash (right?), it would be more difficult for me to
> maintain my tree.
You can have several of them: man git-stash
> 2) Also, building would be difficult. What tag would abuild pull? Some packages
> will have untagged (not for release) mods that are older than tagged (for
> release) mods for other packages. Would abuild pull separate tags from the repo
> for each package?
Basically you would have single version number and single tag for the
whole tree. You'd need to bump only that and it'd publish anything
changed in the whole tree.
The per-module versions would need to be in separate file, and be
preferably automatically updated when you modified one of the files for
it. E.g. by git-hook on commit, or on just before tagging.
Alternatively, the submodule package version could be just the timestamp
it was last modified.
> 3) We should avoid breaking the old builds for earlier versions of alpine.
> the old repos, but only use a new, merged repo? I'm a bit gunshy since the last
> git updates broke all of the aports for packages hosted on git.a.o.
> So, I'm ok with moving to one git repo, but it sounds like quite a complication
> for abuild. And, I'm not going to be the one that has to implement it.
Yes, it'd be new feature of abuild. And probably needs some thought if
it's to be done.
This was just wish world I had. But obviously ncopa would have to do
wacky stuff in abuild to make this work.
Received on Thu Mar 31 2011 - 06:48:21 UTC