[Bash-completion-devel] bash 2.x array initialization

[Ville Skyttä]

On Tuesday 31 March 2009, David Paleino wrote:
> On Tue, 31 Mar 2009 00:13:33 +0300, Ville Skyttä wrote:
>
> > I saw 1.0 was already tagged but I don't know how the branch is supposed
> > to be managed
>
> That branch is really bad named, sorry for not thinking at the future when
> creating it. It should have been "1.x", or kinda. It's really the 1.x
> branch, so when we release 1.0, we can continue bugfixing with 1.1, 1.2,
> 1.3, cherry-picking from master and releasing tags from the "1.x" branch,
> while continuing "experimental development" in master. Clear enough? :)

Works for me.  Even better if it was documented in Wiki ;)

> If you have other suggestions, please tell :P

Maybe a bit off topic, but here goes:

- Remove to_review/ from 1.0 branch and do reviews only in master.
- Maybe remove extra/ from 1.0 because debian/ was removed as well.
- Remove bash-completion.spec from all branches unless someone wants to update
  and maintain it.
- Add autotools stuff to master if that's what we're going to be using.
- Add CHANGES to master.
- Consider removing debian/ and extra/ from master as well, or lay out and
  document rules who should touch those dirs and when (for example I think
  it's quite tedious to keep updating both debian/changelog and CHANGES).

> > and by whom
>
> Should we appoint release managers? I believe no. See the mess we have in
> Debian when having a release :P :)

If we can keep actually releasing stuff (it's been quite a while since the 
last release) and keep the various branches focused on their intended purpose, 
I don't care.  But I do think some kind of a branch maintainer (can also be a 
group) role would be welcome - those interested in maintaining a specific 
branch should be the only ones fixing branch specific issues, cherry picking 
from other branches etc and generally committing to it - it's quite 
inefficient if each committer always has to even consider committing/adapting 
all ones changes to N branches.

> I thought it was clear -- my intentions were to release bash-completion in
> February, but I only had time now.
> If you're against a release, I haven't announced it yet, so we're still in
> time.

No objections, on the contrary actually!  Except that I'd prefer if the yum 
related entries in CHANGES that crept in without the corresponding actual code 
changes could be dropped before the release (see commit 
79ef58feca717e6872f4696fd7e7db8f7dc57d0b).