virtio-r

[Barret Rhoden]

Ron / Gan -

Regarding virtio-r, today's updated work is on origin/staging and
origin/virtio-b.

I did a basic get_html, but not any VMM stuff. We can sort out how
badly I broke it tomorrow. =)

-------------------

Thanks, merged to staging at 2a9b3cdc47db..57cb90009d37 (from, to]

You can see the entire diff with 'git diff' or at
https://github.com/brho/akaros/compare/2a9b3cdc47db...57cb90009d37

Barret

[ron minnich]

I have to test tomorrow, vpn  + this hotel network are not playing nice.

ron

--
You received this message because you are subscribed to the Google Groups "Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akaros+un...@googlegroups.com.
To post to this group, send email to aka...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edward Hyunkoo Jee]

Hi everyone, I'm trying to understand the meaning of branches... What is -r and what is -b? (r for Ron and b for Barret?)

Also, what's our current policy or process for accepting a "staging" change into "master"? I remember I saw an email thread about that but not sure what the conclusion was.

Thanks

[ron minnich]

-b is the latest VMMCP which barret got all up to date today.

ron

[Kevin Klues]

On Mon, Nov 2, 2015 at 5:15 PM, Edward Hyunkoo Jee <edj...@gmail.com> wrote:
> Hi everyone, I'm trying to understand the meaning of branches... What is -r
> and what is -b? (r for Ron and b for Barret?)

The -b and -r are just conventions that barret and ron tend to use
when they are working on similar branches that they rebase back and
forth on top of each other. It's their way of working independently on
essentially the "same" branch but without stepping on each others
toes. They use them cherry-pick relevant commits back and forth until
an actual branch that is ready to be merged with master is prepared.

> Also, what's our current policy or process for accepting a "staging" change
> into "master"? I remember I saw an email thread about that but not sure what
> the conclusion was.

The way I understood it is that "staging" is just a stepping stone to
"master". When you submit a CL it will first be merged to staging
before making it into master. The ultimate plan is to run some sort
of CI (e.g. jenkins) over the staging branch, and only if all tests
pass will the commits that differ between staging and master be merged
back to master. I think for now, Barret is just letting things sit on
staging for a day or two and hoping that people play around with it
enough to weed out any obvious bugs.

~Kevin

[ron minnich]

I just tested staging and it works fine for me. Let's wait for Gan but ...

LGTM from me

ron

[Gan Shun]

So far the VM works through ham.

I'm trying to check and see if the /proc stuff is working.

--

[Barret Rhoden]

On 2015-11-02 at 20:57 Kevin Klues <klu...@gmail.com> wrote:
> The way I understood it is that "staging" is just a stepping stone to
> "master". When you submit a CL it will first be merged to staging
> before making it into master. The ultimate plan is to run some sort
> of CI (e.g. jenkins) over the staging branch, and only if all tests
> pass will the commits that differ between staging and master be merged
> back to master. I think for now, Barret is just letting things sit on
> staging for a day or two and hoping that people play around with it
> enough to weed out any obvious bugs.

Yeah. By letting things sit on staging, this gives people the
opportunity to find bugs, whether it's from a jenkins job or some other
source.

Barret

[Edward Hyunkoo Jee]

It looks like the "master" branch has not been updated for a long time. Do we manually merge "staging" changes into "master"? How often?

If we don't have an automated presubmit queue (that does automated testing against the new changes and merge them to "master" if tests pass) yet, I don't see any meaning of having "staging" branch. These days I feel that changes are sitting in "staging" for too long time. That's inconvenient, especially because we're in early stage of development and Akaros is not being used in mission critical products yet (Later, we need to cut release branches or tag release commits from "master", I guess).

Until an automated presubmit queue is established, why don't we just automatically merge "staging" changes to "master", as soon as the changes are merged to "staging"? That may break "master" from time to time, but that will happen anyway without automated process. Actually, wasn't the master branch broken for a long time recently? (I guess the fix might have been delayed because the fixing patch was sitting in "staging"). 

Barret

[Barret Rhoden]

On 2015-11-12 at 10:11 Edward Hyunkoo Jee <edj...@gmail.com> wrote:
> It looks like the "master" branch has not been updated for a long
> time. Do we manually merge "staging" changes into "master"? How often?

I do it, and it's after changes sat on staging for a day or two.

> If we don't have an automated presubmit queue (that does automated
> testing against the new changes and merge them to "master" if tests
> pass) yet, I don't see any meaning of having "staging" branch.

Agreed, though I think the fix is to set up an automated testing
framework. Then that, as well as people yelling that I broke their
stuff, is enough to cause a delay on staging.

But yeah, we aren't doing anything mission critical or anything. I'd
just like to not break things as much as we used to do.

Barret

[Kevin Klues]

Since staging was introduced, I basically ignore master and do all of
my work off of staging instead.

Kevin

> --
> You received this message because you are subscribed to the Google Groups "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to akaros+un...@googlegroups.com.
> To post to this group, send email to aka...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
~Kevin

[barret rhoden]

On 2015-11-12 at 12:26 Kevin Klues wrote:
> Since staging was introduced, I basically ignore master and do all of
> my work off of staging instead.

yeah, thinking about it a bit, the odds of anyone actually catching a
bug on staging in the day or two a commit sits there is pretty low. so
far, i've caught one, but that's it. given the massive number of bugs
we already have, it's just not worth the hassle.

so forget about staging.

barret

[Kevin Klues]

I was actually meaning to advocate for keeping staging, but telling people to base their code off of that instead of master. With staging we can rollback and modify commits if necessary. With master we can't (or shouldn't at least).

--
You received this message because you are subscribed to the Google Groups "Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akaros+un...@googlegroups.com.
To post to this group, send email to aka...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
~Kevin

[Edward Hyunkoo Jee]

Not sure that is worth.

I guess the whole point is to keep "master" always green (=builds and pass tests). And that's for developers' productivity.

(If we keep "master" always green, when a developer wants to do some work, he can just fetch master branch, and it is always guaranteed to work. He doesn't need to struggle against someone else's accidental broken patch, or wait until someone fixes it.)

If we use the "staging" branch without an automated queue, as Kevin K. said, all developers should use "staging", ignoring "master". Then that doesn't help developers' productivity at all.

Also, we expected that developers would catch bugs or breakages in "staging" branch. But, as Barret mentioned, that didn't work well. That means, we can still easily break "master", and "master" can be broken for a long time because a fix may be sitting in "staging" for a long time.

So, IMHO I feel that things should work like this.

1. Every developer should do his/her work on "master" branch.

2. A new patch should go into "staging" first. "Staging" is just a temporary branch, to run automated tests against new patches.

3. When a new patch is merged into "staging", a robot will kick automated test. If they pass, the change will be merged to "master" automatically and immediately.

As we don't have automated test suites now, currently I guess we can just put a dummy test that always pass. And then, we can add real tests from there.

[barret rhoden]

On 2015-11-12 at 13:40 Kevin Klues wrote:
> I was actually meaning to advocate for keeping staging, but telling
> people to base their code off of that instead of master. With staging
> we can rollback and modify commits if necessary. With master we can't
> (or shouldn't at least).

i was thinking of that, but then i also thought that if i started
telling people to work off of staging, that then it becomes a 'public
branch', which i didn't want to rebase.

anyway, we can always add it back later if the need arises.