Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

First, I've been using git to hack Linux for some embedded devices. My
development was in sync with upstream linux-omap to which I sent several
patches. So, consider yourself that I have some experience with git.

On 06-04-2010 08:41, Fabian Groffen wrote:
> On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
>>   - Irritating conflicts while merging branches or remote master
>>     + Similar argument for having only distfile manifests; but I digress...
>>   - Duplication of effort and information
>>   - Saves space for local checkouts
>
> This seems to assume
> a) that we will do branches, and
> b) that those branches somehow are official and in use
>
> In CVS we are not allowed to use branches, as a policy, that somehow
> makes sense.  Our stable tree is visible via keywords instead.
>
> Why would we suddenly do branches?  It still isn't a good thing.  If you
> talk about branches in the sense of a clone of the entire repo, why
> would we suddenly do massive concurrent development on the same ebuilds?

IMHO repository branching would be greatly useful on Gentoo portage,
specially for third-party and other Gentoo-based distros. It will be a
lot easier for them to keep their own changes to ebuilds while in sync
with main Gentoo tree. This is a big win for everyone.

With my experience in Gentoo-embedded I can also present a problem where
branching is extremely useful:
1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64.
2) Some dev at -embedded decides that package is useful and applies his
traditional cross-compile hackery.
3) The usual route would be to open a shi*load of bugs, wait a cr*pload
of time for the maintainer response and if the weather feels like it,
there is authorization to commit. Then there is also need to retest for
already keyworded arches so we know we don't break others.

3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start putting
quick patches in the tree for specific arches while not breaking others.

IMHO, the only bottleneck I see on Gentoo development is the massive
policy (not saying it is not needed) a -dev has to follow just to commit
a simple fix. Git my friends, will be our holly grail.
>
> I can tell you from good experience that you only do such things if you
> really have to, e.g. when you are in an overlay that needs to have
> modifications to nearly everything and you try to keep that overlay
> up-to-date with its origin, gentoo-x86.  It's no fun, because it
> conflicts pretty much on lots of things, not ChangeLogs.
>
> It seems to me, that if you are in a clone working on something, you
> just only write the ChangeLog once you merge it with its origin,
> gentoo-x86.  You have to review what happened at that stage anyway.
>
> If you really have lots of changes, you will find that many commits on
> the other side will cause you conflicts, so the ChangeLog is just a very
> small part of it.  Conclusion, if you can, try hard to keep your changes
> minimal, and preferably zero compared to the origin, gentoo-x86.
>
>

I don't know why but people seem to have eternal scarring to merge
conflicts. Yes, they happen and yes they are trivial to fix if people
don't commit crap that touches a lot of stuff. In portage, the tree is
very well organized and with some good policies like restricting each
commit to one package will pretty much prevent conflicts.

I will not comment on if Changelogs are going to give conflicts or not.
That would be best answered by the people that is running portage git
for some time.