[beports] Re: Changeset 60

On 2008-05-21 at 00:13:34 [+0200], Andreas Färber <andreas.faerber@xxxxxx> 
wrote:
> Am 19.05.2008 um 18:04 schrieb Brecht Machiels:
> 
> > As Andreas pointed out sometime ago, BepFiles only make sense for
> > releases, and not so much for trunk revisions. I suppose group porting
> > efforts will also focus on the trunk versions?
> 
> Either trunk or branches, yes; tags would also be an option. It should
> be decided from case to case.
> 
> Maintainers probably won't like it if changes are only submitted for
> some "old" branch but not for trunk, in most cases changes to branches
> would be backports from trunk.
> On the other hand, when we don't know a software too well, it may be
> better to port a stable branch first and only then check whether trunk
> works as well. It all depends.

Personally I prefer to port released versions and "port" the patch to 
whatever the maintainers prefer before sending it upstream. When the patch 
is accepted, there's little need to track any branch.

[...]
> >>> From what I've heard about git, it sounds quite nice at least, but I
> >> haven't really used git or any of the other distributed version
> >> control
> >> systems yet. I think it's definitely worth to examine whether any
> >> of them
> >> could be used for a unified ports tree. Or if not, whether a server
> >> could
> >> be set up to host individual repositories.
> 
> Git for instance does not use custom URLs like SVN does. There are
> only "global" branches and tags; multiple disjoint projects inside one
> repository would risk name clashes and are unhandy for obtaining the
> code (cloning the repo).

OK, so individual repositories indeed sound like the best choice in this 
case.

CU, Ingo

--
BePorts homepage - http://tools.assembla.com/BePorts
List archives: http://www.freelists.org/archives/beports
Administrative contact: brecht@xxxxxxxxxxx

Other related posts: