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

From: Jeremy Thomerson <[email-masked]>
Date: Wed, 30 Mar 2011 20:08:31 -0400

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

---

From: Natanael Copa <[email-masked]>
Date: Thu, 31 Mar 2011 14:18:03 +0200

On Wed, 30 Mar 2011 20:08:31 -0400
Jeremy Thomerson <[email-masked]> 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:  [email-masked]
Help:         [email-masked]
---

---

From: Ted Trask <[email-masked]>
Date: Thu, 31 Mar 2011 05:48:12 -0700 (PDT)

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 <[email-masked]>
To: [email-masked]
Cc: Alpine-devel <[email-masked]>
Sent: Thu, March 31, 2011 8:18:03 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>

-nc

---

---

---

From: Timo Teräs <[email-masked]>
Date: Thu, 31 Mar 2011 15:53:49 +0300

> 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

---

---

From: Ted Trask <[email-masked]>
Date: Thu, 31 Mar 2011 06:14:07 -0700 (PDT)

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 <[email-masked]>
To: Ted Trask <[email-masked]>
Cc: Natanael Copa <[email-masked]>; [email-masked]; 
Alpine-devel <[email-masked]>
Sent: Thu, March 31, 2011 8:53:49 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>

- Timo

---

---

From: Timo Teräs <[email-masked]>
Date: Thu, 31 Mar 2011 16:26:48 +0300

> Since git has only one stash (right?), it would be more difficult for me to 

You can have several of them: man git-stash

> release) mods for other packages. Would abuild pull separate tags from the repo 

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.

> 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

---

---

From: Ted Trask <[email-masked]>
Date: Thu, 31 Mar 2011 06:48:21 -0700 (PDT)

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 <[email-masked]>
To: Ted Trask <[email-masked]>
Cc: Natanael Copa <[email-masked]>; [email-masked]; 
Alpine-devel <[email-masked]>
Sent: Thu, March 31, 2011 9:26:48 AM
Subject: Re: [alpine-devel] Why? ACF - million repos </sarcasm>

- Timo

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Thu, 31 Mar 2011 09:53:56 -0400

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 <[email-masked]>

> > 3) We should avoid breaking the old builds for earlier versions of
> alpine.
> >Leave
> >

---

From: Natanael Copa <[email-masked]>
Date: Thu, 31 Mar 2011 16:51:22 +0200

On Thu, 31 Mar 2011 09:53:56 -0400
Jeremy Thomerson <[email-masked]> 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

---

---

From: Timo Teräs <[email-masked]>
Date: Thu, 31 Mar 2011 17:06:44 +0300

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

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Thu, 31 Mar 2011 09:50:44 -0400

2011/3/31 Timo Teräs <[email-masked]>

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

> Alternatively, the submodule package version could be just the timestamp

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.

> alpine. Leave

Jeremy

---

From: Natanael Copa <[email-masked]>
Date: Thu, 31 Mar 2011 16:56:37 +0200

On Thu, 31 Mar 2011 15:53:49 +0300

> 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

---

---

From: Mark Constable <[email-masked]>
Date: Fri, 1 Apr 2011 01:50:33 +1000

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

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 31 Mar 2011 18:37:08 +0200

On Fri, 1 Apr 2011 01:50:33 +1000

> 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

---