[Koha-devel] Post-3.0 git branch and version numbering

[Galen Charlton]

Hi,

On Tue, Aug 12, 2008 at 9:32 AM, Henri-Damien LAURENT
<laurenthdl at alinto.com> wrote:
> Galen Charlton a écrit :
>> Joshua may be a volunteer; I'll let him toss his hat in the ring
>> directly if he chooses.
>
> Would Joshua be volunteer both for QA and Release Maintainer ?

I think it would be just for one or the other, but not both.

>> Great.  What are your plans (roughly speaking) for maintaining 3.0.x?
>>
>
> Stay tuned for bugs on rel30 and HEAD, and keep track of those who are on
> both versions.
> File bugs when they are only sent on lists.
> cherry pick patches which adress rel30 bugs.
> If a patch is sent related to branch 3.0, then resend the patch for
> branch3.1
> In that purpose, maybe building a smolder server for 3.0 and revive
> information nightly could be good.
> Or maybe I could use Andrew's one if allowed.

Once we've finished testing Andy's setup, LibLime would be willing to
host a public smolder for the project that would handle test reports
for both 3.0 and 3.2.

> Comments welcome.

This obviously depends on the bug counts and what the user community
requests, but roughly speaking, how many bugfix releases of 3.0.x
would you contemplate releasing, and on what schedule?

>> This can be done on a branch-by-branch basis.  In other words, we can
>> set it up so that the 3.0 maintainer can push directly to the 3.0.x
>> branch.
>>
>
> OK then for Release Maintainer.
> What about QA manager for position, if he were outside from Liblime and
> BibLibre ?

Is any such person volunteering? ;)

> Having a website where patches would be fetched by RM seems to me a solution
> which will make the RM task heavier and quite tricky if some patches are to
> be replaced, or updated. Would it not be easier if he could push sthg on his
> remote branch with signing-off his patches, same for QA ? And then, RM would
> just have to merge those remote branches.

If the QA manager maintains a tree containing validated patches that I
can pull from, that would be useful.  However, the  mechanics of
managing the git tree matter less to me than what I think the QA
manager should do, which to mind my includes the following fundamental
responsibilities:

* reviewing patches and working with contributors to improve them
* at the same time, keeping up with the flow of patches
* working to distribute patch review among all interested contributors
* proposing improvements to code or development practices to the
developer community

Regards,

Galen
-- 
Galen Charlton
VP, Research & Development, LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709
skype: gmcharlt


_______________________________________________
Koha-devel mailing list
Koha-devel at nongnu.org
http://lists.nongnu.org/mailman/listinfo/koha-devel