~alpine/devel

13 5

[alpine-devel] Why? ACF - million repos </sarcasm>

Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<AANLkTindJPfApS9KrK_a2sJ4BxwDEk6+54b4zLAr=wJb@mail.gmail.com>
Sender timestamp
1301530111
DKIM signature
missing
Download raw message
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
Details
Message ID
<899171.33677.qm@web130121.mail.mud.yahoo.com>
In-Reply-To
<20110331141803.67f714de@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1301575692
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<678804.43665.qm@web130120.mail.mud.yahoo.com>
In-Reply-To
<4D94795D.7040206@iki.fi> (view parent)
Sender timestamp
1301577247
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<285851.96584.qm@web130107.mail.mud.yahoo.com>
In-Reply-To
<4D948118.8050701@iki.fi> (view parent)
Sender timestamp
1301579301
DKIM signature
missing
Download raw message
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
---
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<AANLkTikXJVWfo0Yi9t8DeKUkUmWHywvFHDDiF1-Vx07i@mail.gmail.com>
In-Reply-To
<4D948118.8050701@iki.fi> (view parent)
Sender timestamp
1301579444
DKIM signature
missing
Download raw message
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
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<AANLkTinMxLydffKRiJTPV=RcdjhLfFw7iEHi7bubDwzD@mail.gmail.com>
In-Reply-To
<285851.96584.qm@web130107.mail.mud.yahoo.com> (view parent)
Sender timestamp
1301579636
DKIM signature
missing
Download raw message
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
>
>
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110331141803.67f714de@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<AANLkTindJPfApS9KrK_a2sJ4BxwDEk6+54b4zLAr=wJb@mail.gmail.com> (view parent)
Sender timestamp
1301573883
DKIM signature
missing
Download raw message
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
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4D94795D.7040206@iki.fi>
In-Reply-To
<899171.33677.qm@web130121.mail.mud.yahoo.com> (view parent)
Sender timestamp
1301576029
DKIM signature
missing
Download raw message
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
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4D948118.8050701@iki.fi>
In-Reply-To
<678804.43665.qm@web130120.mail.mud.yahoo.com> (view parent)
Sender timestamp
1301578008
DKIM signature
missing
Download raw message
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
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110331165122.589977eb@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<AANLkTinMxLydffKRiJTPV=RcdjhLfFw7iEHi7bubDwzD@mail.gmail.com> (view parent)
Sender timestamp
1301583082
DKIM signature
missing
Download raw message
On Thu, 31 Mar 2011 09:53:56 -0400
Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:

> Branching is cheap-and-easy in git.  It's not a hinderance to
> development flow like it is in SVN.

yes. Effective use of git means branching, lots of branching - and
merging. Thats one of git's strenghts.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110331165637.58c54e83@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<4D94795D.7040206@iki.fi> (view parent)
Sender timestamp
1301583397
DKIM signature
missing
Download raw message
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
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4D948A74.5010100@iki.fi>
In-Reply-To
<285851.96584.qm@web130107.mail.mud.yahoo.com> (view parent)
Sender timestamp
1301580404
DKIM signature
missing
Download raw message
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
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110331183708.66f87d63@alpinelinux.org>
In-Reply-To
<201104010150.33799.markc@renta.net> (view parent)
Sender timestamp
1301589428
DKIM signature
missing
Download raw message
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
---
Mark Constable <markc@renta.net>
Details
Message ID
<201104010150.33799.markc@renta.net>
In-Reply-To
<20110331165637.58c54e83@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1301586633
DKIM signature
missing
Download raw message
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
---
Reply to thread Export thread (mbox)