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

Tue Mar 31 19:08:38 UTC 2009

On Tue, 31 Mar 2009 20:36:43 +0300, Ville Skyttä wrote:

> 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 ;)

Heh :)
Please everyone: I'm not yet removing frozen/1.0, but please start using "1.x"
from now on. As soon as I see no more commits in frozen/1.0, I'll definitely
drop it.

Wiki updated:

    http://wiki.debian.org/Teams/BashCompletion/Git

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

Uh, right, I missed this.

> - Maybe remove extra/ from 1.0 because debian/ was removed as well.

And I missed this too.

> - Remove bash-completion.spec from all branches unless someone wants to update
>   and maintain it.

I suppose that's kept in $RPM-based-distribution repositories. Fine with me,
removed.

> - Add autotools stuff to master if that's what we're going to be using.

Cherry-picked, also added an autogen.sh to generate autotools files. (when
releasing, run ./autogen.sh first, and then pack the resulting tarball (a "make
dist-gzip" should suffice)

> - Add CHANGES to master.

Done.

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

Well, I'd need to keep Debian packaging on Alioth too, and having two different
repositories on the same machine is a bit awkward.

From now on: debian/changelog is no more used as upstream changelog (CHANGES
will be), and no one is supposed to touch debian/*, except for Debian
maintainers (which is only me, at the moment), Yet it's still useful to keep
log of the closed Debian bugs in CHANGES (as well as other BTS's), so let's use
this format in CHANGES from now on:

<distribution>: #nnnn → <distribution>'s BTS

example:

Debian: #nnnn, Ubuntu: #nnnn (let's keep it "Ubuntu" also for
{K,X,Ed,*}ubuntu), Gentoo: #nnnn, [..]

If you agree, I'll start editing CHANGES (oh, my.) to keep it
"policy-compliant" :)

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

Yes, I plan doing regular (almost) releases. Not really time-dependant, but
"feature-dependant". Or, we can choose to regularly release minor versions, and
have a new major version only when "it's ready".

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

Right.
As for now, I don't see a particular need for "topic branches", which is what
you're talking for.
We've had a frozen/1.0 (now 1.x) branch just not to introduce new features in a
going-to-be-released code, and that will happen on every new major version.
Those branches will then only contain bugfixes we think should be addressed
there, otherwise everything goes to master.

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

Already done :)

Ciao,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20090331/d421125d/attachment-0001.pgp 