Why are all (54) of the ACF modules in their own repo? How would everyone
feel about merging them into one repo? Wouldn't that make it easier to
maintain / develop for?
Jeremy Thomerson
Yes, the reason there are lots of repositories is for ease of releasing
packages. When they're separate, they can be released separately with different
versions. It can be annoying when I need to update a bunch of packages at the
same time, like I did yesterday. But, that's pretty rare. Usually when I make a
major rev bump on core and have to update all affected ACFs.
Ted
----- Original Message ----
From: Natanael Copa <ncopa@alpinelinux.org>
To: jeremy@thomersonfamily.com
Cc: Alpine-devel <alpine-devel@lists.alpinelinux.org>
Sent: Thu, March 31, 2011 8:18:03 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>
On Wed, 30 Mar 2011 20:08:31 -0400
Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:
> Why are all (54) of the ACF modules in their own repo?
When those were created there was some expectation that there would be
millions of ACF package maintainers. Each acf would be treated as a
separate project. There was also a backthought that ACF projects should
be distro agnostic and not an alpine linux thing only.
> How would> everyone feel about merging them into one repo? Wouldn't that make> it easier to maintain / develop for?
We have talked about that before. Then you cannot make new release by
just doing git tag. You can ofcourse do a makefile target for releases.
We could also treat the ACF as one big monolitic project and have one
APKBUILD for it with tons of subpackages. But then would all ACF
modules have same version number so there would be 54 package upgrades
every time any package changed.
I suppose my opinon don't count that much since I'm not involved there
so much. I have been thining of looking at ACF when get time but...
"get time" tend to never happen.
I leave it up to the people who works on it. (tdtrask)
> Jeremy Thomerson
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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.
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?
3) We should avoid breaking the old builds for earlier versions of alpine. Leave
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.
Ted
----- Original Message ----
From: Timo Teräs <timo.teras@iki.fi>
To: Ted Trask <ttrask01@yahoo.com>
Cc: Natanael Copa <ncopa@alpinelinux.org>; jeremy@thomersonfamily.com;
Alpine-devel <alpine-devel@lists.alpinelinux.org>
Sent: Thu, March 31, 2011 8:53:49 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>
On 03/31/2011 03:48 PM, Ted Trask wrote:
> Yes, the reason there are lots of repositories is for ease of releasing > packages. When they're separate, they can be released separately with different >> versions. It can be annoying when I need to update a bunch of packages at the > same time, like I did yesterday. But, that's pretty rare. Usually when I make a >> major rev bump on core and have to update all affected ACFs.
I really dislike the multiple acf repos too.
Would it be possible to instead have abuild do subpackage version based
on the sources? That we would not have the downsides ncopa mentioned
earlier.
This would also ease the tagging, cloning and setting up of non .apk
based acf tree. Because now you have to do multiple checkouts and create
multiple links to make the thing work from git checkout.
My vote would be to improve abuild to have version number override on
per-subpackage basis. That way single tag of main acf.git would
automatically re-build the updated source packages.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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.
Ted
----- Original Message ----
From: Timo Teräs <timo.teras@iki.fi>
To: Ted Trask <ttrask01@yahoo.com>
Cc: Natanael Copa <ncopa@alpinelinux.org>; jeremy@thomersonfamily.com;
Alpine-devel <alpine-devel@lists.alpinelinux.org>
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. >Leave >> 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.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
2011/3/31 Timo Teräs <timo.teras@iki.fi>
> 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>
Use git branches. When you start some chunk of work, "git checkout -b
mynewfeature master" creates mynewfeature branch from master. Work on that,
but don't merge that branch to master. Master can be the release-from
branch.
> > 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.>
Have abuild pull from master branch, or you can tag master branch with
release numbers. "Not for release" stuff is in a "development" branch
(similar to answer for #1) rather than master.
> > 3) We should avoid breaking the old builds for earlier versions of> alpine. Leave> > 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.
Jeremy
Branching is cheap-and-easy in git. It's not a hinderance to development
flow like it is in SVN.
I understand the release aspect of it now - hadn't thought of that. Will
have to give it some thought.
Jeremy
2011/3/31 Ted Trask <ttrask01@yahoo.com>
> 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.>> Ted>>>> ----- Original Message ----> From: Timo Teräs <timo.teras@iki.fi>> To: Ted Trask <ttrask01@yahoo.com>> Cc: Natanael Copa <ncopa@alpinelinux.org>; jeremy@thomersonfamily.com;> Alpine-devel <alpine-devel@lists.alpinelinux.org>> 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.> >Leave> >> > 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.>> - Timo>>
On Wed, 30 Mar 2011 20:08:31 -0400
Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:
> Why are all (54) of the ACF modules in their own repo?
When those were created there was some expectation that there would be
millions of ACF package maintainers. Each acf would be treated as a
separate project. There was also a backthought that ACF projects should
be distro agnostic and not an alpine linux thing only.
> How would> everyone feel about merging them into one repo? Wouldn't that make> it easier to maintain / develop for?
We have talked about that before. Then you cannot make new release by
just doing git tag. You can ofcourse do a makefile target for releases.
We could also treat the ACF as one big monolitic project and have one
APKBUILD for it with tons of subpackages. But then would all ACF
modules have same version number so there would be 54 package upgrades
every time any package changed.
I suppose my opinon don't count that much since I'm not involved there
so much. I have been thining of looking at ACF when get time but...
"get time" tend to never happen.
I leave it up to the people who works on it. (tdtrask)
> Jeremy Thomerson
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 03/31/2011 03:48 PM, Ted Trask wrote:
> Yes, the reason there are lots of repositories is for ease of releasing > packages. When they're separate, they can be released separately with different > versions. It can be annoying when I need to update a bunch of packages at the > same time, like I did yesterday. But, that's pretty rare. Usually when I make a > major rev bump on core and have to update all affected ACFs.
I really dislike the multiple acf repos too.
Would it be possible to instead have abuild do subpackage version based
on the sources? That we would not have the downsides ncopa mentioned
earlier.
This would also ease the tagging, cloning and setting up of non .apk
based acf tree. Because now you have to do multiple checkouts and create
multiple links to make the thing work from git checkout.
My vote would be to improve abuild to have version number override on
per-subpackage basis. That way single tag of main acf.git would
automatically re-build the updated source packages.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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. Leave > 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.
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, 31 Mar 2011 15:53:49 +0300
Timo Teräs <timo.teras@iki.fi> wrote:
> My vote would be to improve abuild to have version number override on> per-subpackage basis. That way single tag of main acf.git would> automatically re-build the updated source packages.
I'd rather have 52 separate APKBUILDs using same source package than
having 1 APKBUILD with 52 different subpackages with different
version numbers.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 03/31/2011 04:48 PM, Ted Trask wrote:
> 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.
Ok. If you want separate releases, then they need to be in separate git
repos. That's the boundary when to split repos.
You should still fix the repositories so, that I can do git checkout of
the core, and git checkout of the submodules I'm editing, and I get
working tree (without make install). This basically means removing the
relative symlinks (preferably, not using symlinks at all). Those put a
lot of assumptions on how things are on disk. It makes developing
directly out of acf-*.git hard.
Rethinking, I think my biggest annoyance is that in-tree development
does not work currently. Not that it's split repositories.
> Separate independent repos for separate independent packages.
There's still some other inter mixed relations we should fix. E.g.
acf-core depends hostname module which is found from
acf-alpine-baselayout. I think hostname should be moved to acf-core.
Additionally, we should start to maintain versioned dependencies. E.g.
each acf says which acf-core version is minimum requirement.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Fri, 1 Apr 2011 01:50:33 +1000
Mark Constable <markc@renta.net> wrote:
> On 01/04/11, Natanael Copa wrote:> > I'd rather have 52 separate APKBUILDs using same source> > package than having 1 APKBUILD with 52 different subpackages> > with different version numbers.> > Why not have a single meta repo, ie; acf-all, that has a single> APKBUILD with it's own version number and the build() does a> git submodule pull on all the other separate acf modules and> packs them all up into a single package.
yeah, git has some support for submodules. I have no experience with
those but that might be something to check up.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 01/04/11, Natanael Copa wrote:
> I'd rather have 52 separate APKBUILDs using same source> package than having 1 APKBUILD with 52 different subpackages> with different version numbers.
Why not have a single meta repo, ie; acf-all, that has a single
APKBUILD with it's own version number and the build() does a
git submodule pull on all the other separate acf modules and
packs them all up into a single package.
--markc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---