IMHO, a separate release team is not needed.
For package mantainers, they both need to test the latest tarballs and
So, the most efficient way should be making those people the QA team +
In this way, when a new stable release of component X is made, all
major distros get working updated packages immediately at the same
time since the package maintainers are also the people who release the
On Sun, Dec 13, 2009 at 2:31 AM, PCMan <pcman.tw@...> wrote:
> People who I think can be members of QA team:
> AndrewLee: Debian developer
> Christoph Wickert: Fedora developer
> Julien Lavergne: Ubuntu developer
> and also recently we got a new friend from openSuSE.
> So, if those people can make a QA team, we can make sure that new
> features build and work in those major distros.
> These are my idea:
> After the team is set up, developers only push code into svn repo and
> call for testing on ML.
> It's the QA team who need to test those new features.
> If things all work, the QA team can decide when to make a new tarball
> release at any time if they see fit.
> Before making new release, the QA team fixes grammar errors and typos
> in English strings in source code.
> Then, the QA team call for translation, and the translation
> coordinator work on getting most translation done.
> Then, the QA team release tarballs for stable release and announce on
> ML, forum, and blog.
> This workflow can ensure working stable releases with nice
> translations included and fix currently broken release model.
> Also, this can greatly decrease the workload of developers and let
> them concentrate on new features and bug fixes.
> Any comment?
> On Sun, Dec 13, 2009 at 1:45 AM, Mario Behling <mb@...> wrote:
>> yes, I think this is a good idea. Best would be to have one or two
>> main QA Managers, I believe. Those persons can change according to
>> needs and resources, but if we have QA manager we have people who we
>> can refer to.
>> Secondly, I would like to start a QA testing team. I will prepare this
>> in the coming days. We can use the translation team set up as an
>> Do you agree with this? If yes, who has resources to become a QA Manager?
>> Ciao Mario
>> On Sat, Dec 12, 2009 at 9:01 AM, PCMan <pcman.tw@...> wrote:
>>> Sorry for the recent degradation in quality assurance.
>>> I'm just too busy recently.
>>> After working for more than 12 hours a day in the hospital, I'm quite
>>> exhausted and don't have much time to do all the hacking and testing.
>>> Can we set up a QA team to handle the release management?
>>> I mean, when some new features are completed, developers send message
>>> in the mailing list.
>>> Then, the QA team do the testing and fix build issues. If things are
>>> OK, they release the tarballs.
>>> Besides, when translation coordinator find most translations are
>>> completed, he can call the QA team to check package integrity.
>>> If no problems are found, new release can be made by QA team for
>>> translation updates.
>>> So, for me, I only push things I developed into svn continuously, and
>>> I don't make release myself.
>>> The QA people just do QA, and do the release management.
>>> Is this model possible?
>>> On Sat, Dec 12, 2009 at 6:00 AM, Julien Lavergne <gilir@...> wrote:
>>>> Le vendredi 11 décembre 2009 à 20:33 +0100, Christoph Wickert a écrit :
>>>>> * lxpanel-0.5.4 wont build because configure breaks due to the
>>>>> missing cpufreq plugin. Was the plugin supposed to be in the
>>>>> tarball or was configure not updated before doing the release?
>>>>> Was it tested at all?
>>>> One test that can be made is the "make dist check". Fixing all errors is
>>>> painful, but that prevent most of problems for the tarball side. Also,
>>>> it's not too late to do a 0.5.4.1 release with the fixes. Mistakes
>>>> happens :)
>>>> Julien Lavergne