adding a QA responsibility to the release team??
terietor at gmail.com
Mon Sep 19 11:51:24 UTC 2011
On 18 September 2011 21:21, Rex Dieter <rdieter at fedoraproject.org> wrote:
> There's already a week between initial tarball creation (for packagers) and
> official release. Are you proposing making this longer?
In this week,the tarballs are being created?If so,we don't have a
week,because when the tarballs are out the packagers will get the non-fixed
In general,i was thinking that the timeline of 2 weeks(before the tarball
creation,could solve the issue).
> or... some other workflow?
Actually,this is a big discussion and i don't know how wise that would
be.But in KDE 5.0.Should we have to consider the release of the frameworks?
(Not the for the entire KDE,just for the frameworks part).
2 additional comments:
> * I think it may be unwise to conflate release engineering with QA, they
> really are 2 distinct items (though obviously interelated).
Yes you have right,but the time that i wrote the mail,i couldn't think a
better word.And i don't think that a QA team could be established inside
since KDE doesn't exist as a monolithic community but from subcommunities.
Also a QA team some time in her lifetime would affect the release cycle and
the change of the release cycle have been discussed a lot of times in the
past and it has been decided not to change.Moreover a QA team would have
some policy which will be against the "habit" of the subcommunities,and
our authority system is based in the relationship between us and not in our
access stuff,since we all have the same access.
> * I'm also of a mind there's no special need for additional bugzilla
> components... in the past, when/if regressions or blockers identified in our
> "week", they were dealt-with appropriately.
I propose the bugzilla compoments only as a solution for taking down the
issues.But its really not a big matter.
On 18 September 2011 21:34, Ian Monroe <ian at monroe.nu> wrote:
> Seems like the basic issue is that the (official) release + a week or
> two is usually more stable then the release. But that's because the
> release spurred people to find bugs and fix them.
this means that we have to reconsider our release timelines,and find a
I stand for yes on that one.
Tsiapaliwkas Giorgos (terietor)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the release-team