New cvs-model mRFC
-
Oskari Kokko
New cvs-model mRFC
Mon June 15 2009 07:35:06 UTCWhile touring Poland I had time to think about the rules for commiting,
so that we wouldn't have so much problems when upgrading something.
http://www.midgard-project.org/development/mrfc/0046/
Please share your thoughts.
//Osku
--
Oskari Kokko
Consultant
Nemein Oy
oskari.kokko@nemein.com
020 1986034
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 15 2009 08:35:05 UTCOn Mon, Jun 15, 2009 at 11:19 AM, Oskari Kokko <oskari.kokko@nemein.com>wrote:
> While touring Poland I had time to think about the rules for commiting,
> so that we wouldn't have so much problems when upgrading something.
>
> http://www.midgard-project.org/development/mrfc/0046/
>
> Please share your thoughts.
Somehow I feel, that this is a bit overreaction.By the way how many active
commiters do we have? Does anyone have stats?
I think that most problems would be solved by good automated test-suite.
In this case, we just need to have rule, that every commit which changes (or
adds) functionality needs to include corresponding test-case.
I know, there is the opinion, that unit-tests are not enough to test
everything. I believe they are enough to test everything which is really
important.
Anyway, what I am trying to say is: we don't need to require test-reports.
We need to require tests and the person who applies things to "stable"
branch needs ability to easily run all the tests.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
Sent from St Petersburg, Russian Federation
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 15 2009 09:20:07 UTCHi,
On Mon, Jun 15, 2009 at 11:23 AM, Alexey Zakhlestin<indeyets@gmail.com> wrote:
> By the way how many active commiters do we have? Does anyone have stats?
Ohloh has some:
http://www.ohloh.net/p/midgard/contributors
http://www.ohloh.net/p/midgard2/contributors
> I think that most problems would be solved by good automated test-suite.
> In this case, we just need to have rule, that every commit which changes (or
> adds) functionality needs to include corresponding test-case.
That would be the optimal situation, but so far to my experience,
getting tests out of people has proven to be difficult or impossible.
We even organized phpunit training for the whole group in a recent
Midgard Gathering, but still...
> Alexey Zakhlestin
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
Sent from Helsinki, ES, Finland
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 15 2009 09:50:05 UTCOn Mon, Jun 15, 2009 at 1:10 PM, Henri Bergius <henri.bergius@iki.fi> wrote:
> Hi,
>
> On Mon, Jun 15, 2009 at 11:23 AM, Alexey Zakhlestin<indeyets@gmail.com>
> wrote:
> > By the way how many active commiters do we have? Does anyone have stats?
>
> Ohloh has some:
> http://www.ohloh.net/p/midgard/contributors
> http://www.ohloh.net/p/midgard2/contributors
>
> > I think that most problems would be solved by good automated test-suite.
> > In this case, we just need to have rule, that every commit which changes
> (or
> > adds) functionality needs to include corresponding test-case.
>
> That would be the optimal situation, but so far to my experience,
> getting tests out of people has proven to be difficult or impossible.
> We even organized phpunit training for the whole group in a recent
> Midgard Gathering, but still...
if there's no test, there's no moving to stable ;)
in case of git that would be really simple
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 15 2009 11:30:06 UTCAlexey Zakhlestin writes:
Hi!
> I think that most problems would be solved by good automated test-suite.
> In this case, we just need to have rule, that every commit which changes
> (or adds) functionality needs to include corresponding test-case.
Yes, automated unit and regression tests are a good start.
But we do not have them.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: New cvs-model mRFC
Thu June 18 2009 10:49:36 UTCFirst off, I have to say that I wholeheartedly agree with this mRFC, because this is an issue that "gets" me on almost a weekly basis as I work on client websites.
While I understand that the mental shift, which is required for something like this to be instituted is a huge undertaking, I think and have always thought, that it has to be done.
Current situation is, as Oskari pointed out, unbearable - really. Countless frustrating hours are spent on figuring out which commit has broken what, when, why and by whom. Instead this time could be spent on much more useful things, like further development or writing test / documentation.
I agree on the point that a separate development branch and stable branch are needed for each "generation" of Midgard, even if Ragnaroek is supposedly LTS and therefore should be stable (as we've noticed over some time, this is not the case). Obviously stable would be rock solid branch (Debian equivalent version of that generation) which could be used for production without having to even think about things breaking, and development in turn would be used for introducing bug fixes and features.
As far as what should be the model for submitting patches/features, I think we should look at some of the other successful open source projects. I would propose something similar to what has been agreed upon in Django, more on their patching guidelines can be read at http://docs.djangoproject.com/en/dev/internals/contributing/#submitting-patches
Of course, as Alexey pointed out earlier, automated testing-suite is necessary to make something like this work, because no-one in the project really has that much time in their hands to run through all of the patches by hand. In addition, automated test-suite will more than likely lower the threshold for all of the developers to write tests.
To summarize, I think this problem is actually two-fold:
First, the project needs to have an automated test-suite for running the tests, which generates the necessary test information for the person submitting a patch as well as for the person committing the patch to stable.
Secondly, there needs to be a mental shift (which is the difficult part here) made in the community where writing tests (and documentation, I hope!) becomes de facto, that they are required with every patch (and hopefully every commit, if applicable).
The first and second points will require some guidelines to be written and agreed upon by the community, the decision should not be in the hands of any single person, but the community as whole.
Continuing a little bit further from this, I think it would also be nice to have some kind of a code coverage report available on the midgard project website (or trac), so people could actually see what needs work.
// Joonas
-
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 22 2009 12:45:07 UTCJoonas Bergius wrote:
>
> Continuing a little bit further from this, I think it would also be *nice* to have some kind of a code coverage report available on the midgard project website (or trac), so people could actually see what needs work.
>
teppheikk promised in last years Otaniemi gathering to set up
PHPUndercontrol for M-P.org but I guess it has proven to be a bit difficult.
Writing unit tests for Thor/Ragnaroek generation is more than slightly
complex since MidCOM core supposes we're inside libapache2-mod-midgard.
As for stable and devel branches, this is simple to do and in fact I
would do it very soon regardless of the unittest situation and severely
restrict commit rights to the stable branches.
This way when someone want to get their changes to stable they will do
"pull-request" (in git lingo) (basically list the revisions and uris as
usable with svn merge) and they will need to get someone else to also
state "I have tested this to work as specified", then VCS tyrant or his
assistant can do the merge and we have single commit to revert in case
it didn't turn out so good. These merge requests would be tracked as
tickets with the ticket description listing the revisions and uris to
merge and list of the tickets fixed by said revisions.
Going for "Debian stable" kind of stability is not really workable since
that's strictly security fixes only.
/Rambo
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 22 2009 12:50:10 UTCHi,
On Mon, Jun 22, 2009 at 3:32 PM, Eero af
Heurlin<eero.afheurlin@nemein.com> wrote:
> teppheikk promised in last years Otaniemi gathering to set up
> PHPUndercontrol for M-P.org but I guess it has proven to be a bit difficult.
I would believe this is not due to difficulties, but because of
available time. If we bribe him by beer to work on this for a day, I'd
imagine we'll see a lot of progress ;-)
> Writing unit tests for Thor/Ragnaroek generation is more than slightly
> complex since MidCOM core supposes we're inside libapache2-mod-midgard.
Yep. I believe we should *mostly* forget about Ragnaroek (and
especially Thor!) tests-wise. Though Ragnaland setup makes it somewhat
possible to emulate the libapache2-mod-midgard environment with
PHP-CLI:
http://trac.midgard-project.org/browser/branches/ragnaroek/midcom/midcom.core/support/midgard-root-ragnaland.php
> As for stable and devel branches, this is simple to do and in fact I
> would do it very soon regardless of the unittest situation and severely
> restrict commit rights to the stable branches.
Agreed. In any case the first thing to do would be to sit down and get
the test coverate of midcom_core to an acceptable level. I imagine
this requires couple of days of hacking "with a destructive mindset"
from me or somebody else well-versed with MidCOM3 internals.
Alexey already started working on phpt tests for php5-midgard2, and I
think Piotras had some GObject tests for core.
> This way when someone want to get their changes to stable they will do
> "pull-request" (in git lingo) (basically list the revisions and uris as
> usable with svn merge) and they will need to get someone else to also
> state "I have tested this to work as specified", then VCS tyrant or his
> assistant can do the merge and we have single commit to revert in case
> it didn't turn out so good.
Yep, that sounds like a sane approach.
But anyway, having a sane test coverage is the first requirement here.
Otherwise regardless of the commit process we will end up with vague
"it feels like it is working" sort of testing.
> /Rambo
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 22 2009 13:20:09 UTCHenri Bergius wrote:
> Yep. I believe we should *mostly* forget about Ragnaroek (and
> especially Thor!) tests-wise.
>
>> As for stable and devel branches, this is simple to do and in fact I
>> would do it very soon regardless of the unittest situation and severely
>> restrict commit rights to the stable branches.
>
> Agreed. In any case the first thing to do would be to sit down and get
> the test coverate of midcom_core to an acceptable level. I imagine
> this requires couple of days of hacking "with a destructive mindset"
> from me or somebody else well-versed with MidCOM3 internals.
>
The core issue is much more of a problem for Ragnaroek (if we forget
about Thor for a moment) than Vinland/Mjölnir
>> This way when someone want to get their changes to stable they will do
>> "pull-request" (in git lingo) (basically list the revisions and uris as
>
> Yep, that sounds like a sane approach.
>
> But anyway, having a sane test coverage is the first requirement here.
> Otherwise regardless of the commit process we will end up with vague
> "it feels like it is working" sort of testing.
>
having two "it feels like it's working" opinions is better than one (and
for "core" components I think we may demand more than that and also have
the person doing the merge personally verify the merge works as
specified) and in any case we will have single commit to revert with
this approach rather than many.
My point with fasttracking this is that we will never have proper test
coverage for Ragnaroek and having merges to the stable branch behind
*some* process will improve the situation immensely even if it still
will be far from "perfect".
/Rambo
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] New cvs-model mRFC
Mon June 22 2009 20:42:08 UTCHi,
The core issue is much more of a problem for Ragnaroek (if we forget about Thor for a moment) than Vinland/Mjölnir
Yes, for the moment. Partly this is because new MidCOM has been written with PHP5 in mind from the beginning and so is much simpler codebase.
But mostly this is because there are far fewer people hacking on it so far. When Mjolnir starts to get anything close to the usage numbers of Ragnaroek we're sure to see similar regressions and other issues unless we address them on the process level early on.
having two "it feels like it's working" opinions is better than one (and for "core" components I think we may demand more than that and also have the person doing the merge personally verify the merge works as specified) and in any case we will have single commit to revert with this approach rather than many.
Related to this, how about putting all merge requests to core components through code review? Review Board is now at 1.0 at looks quite promising:
http://www.review-board.org/docs/manual/dev/users/getting-started/introduction/ http://www.review-board.org/screenshots/
In optimal world everybody would be free to hack on Midgard and components in their private Git repositories. But merging to the official repository would only happen when:
- tests pass (and have sufficient coverage)
- the code is reviewed
- possible IP rights issues are resolved (copyright assignments to the foundation or whatever)
This may sound bureaucratic, but I'm quite convinced in the end it'd be more productive for all of us, as then we could focus less on hunting regressions and more on writing new working code :-)
/Henri
