Development process
by Alec Leamas
Now, there's the release, master, development and 'my' fixes branch. How
do we cooperate on these?
One question is the check-in policy. Out of the top of my head it seems
reasonable that those who can commit commits "easy" patches directly to
devel, seeking advice and review when required. And that *someone" e.
g., sochotni is the sole master of release and master branch and the
only one committing to these.
Other schemas are certainly possible, including some kind mandatory
review. But we need some kind of agreement on this...
--alec
11 years, 9 months
Handling open issues for 2.0
by Alec Leamas
There is currently 12 issues open, 6 of which targeted for 2.0
After merging the fixes branch 5 issues can be closed, 2 of which
targeted to 2.0
That would leave following open issues targeted for 2.0:
:#8 Add interactive mode (sochotni)
#13 Improve find_tag to optionally return expanded macros (sochotni)
#17 Test package in Koji scratch build (msuchy/sochotni)
#26 Show date of guidelines tool is based on (sochotni)
None of these is trivial. Time to remove the milestone from them?
11 years, 9 months
nonsubscribed test
by Stanislav Ochotnicky
testing unsubscribed sending
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11 years, 9 months