Purpose and Scope of COHO (was tag 3.0.0rc1 on Monday the 15th)

[Joe Bowser <bo...@gmail.com>]

Putting this here because it doesn't belong in the tag 3.0.0rc1 thread:

I agree with Jesse, who doesn't like the magic behind coho.  My main
issue with coho is that it's not a very maintainable chunk of JS, and
it appears to be the kitchen sink of automation, full of things that
just don't fit elsewhere.  It seems to do everything from create bugs,
tag releases and package them with a single command.  The only thing
it's consistently failed to do over and over again is actually test
and produce a quality release of Cordova.

I think that we should really keep our release process the same, and
that we should talk about what we want coho to do after 3.0.0 is out.
I don't think there's a lot magical behind coho, but I want to know
why I would use coho over something like repo, which is another tool
that handles multiple git repositories that is used in the Android
Open Source Project.

Anyway, I'm pretty sure there's some concerns over the insertion of
coho into flows, and I'm wondering if anyone else has any thoughts
about this.

Joe

Re: Purpose and Scope of COHO (was tag 3.0.0rc1 on Monday the 15th)

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jul 12, 2013 at 2:57 PM, Brian LeRoux <b...@brian.io> wrote:

> Well, thats not true, so lets not revise history. We did have a
> documented process emergent at CuttingReleases and since its been
> refactored by many of us. Same is true for coho.
>

Sorry, you're right that the page did exist before. I do recall trying to
follow the steps on the page for the 2.7 release and finding that steps
were missing, and some listed steps were missing the "how". Certainly did
exist before though.



>
> The difference is the recent refactoring has come about without
> discussion or consensus.
>

Here's a thread where I stated my intentions to refactor the release bug &
to automate some of the steps via coho:
http://markmail.org/message/rrjvwe7efzpv6uk2

There were no objections.


I did also create a JIRA issue to track it:
https://issues.apache.org/jira/browse/CB-3305

There were no concerns here either.


Here are a couple more threads about changing the release bug:
http://markmail.org/message/ncqqgsxmi5besl2m
http://markmail.org/message/v7vmybklrynlu5ma


>
> The concern here is what precisely we want to do with coho. Before it
> just downloaded tags and created a archive. Now it does... lots.
>

A month later I sent out an update about changes to coho:
http://markmail.org/message/2ckd2ndkrg4crkyg

There were no concerns.


>
> We want to help and work on this. Nobody is going to debate the value
> of automation or documentation. Lets not pretend those things didn't
> exist before or that the recent changes are 'for the better' without
> discussion or consensus.
>

Some discussion we did have was about whether repos should be tagged all
together or separately.
http://markmail.org/message/b5vxf6wtxphfavyr
A specific concern, which was totally valid, and I agreed with - separate
is the way to go.


I hope this shows that there was indeed discussion, and opportunities to
voice concerns (aka "silent consensus") on many aspects of coho and
altering the JIRA template. Maybe not all aspects, but certainly I had made
attempts to be clear about my intentions and changes.


If there are specific concerns with coho, or the new JIRA template, or the
wiki page, then let's carry forward with specifics.


Joe - Our tools are not responsible for creating quality releases, we are.
In my mind quality comes from a well-specified, and well-followed release
process. I haven't used the "repo" tool before, but if it can improve our
lives, then I'd love to hear about it.


>
>
>
> On Fri, Jul 12, 2013 at 11:40 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > I assure you that I did not use magic to create coho. I've found it to be
> > useful, but you certainly don't have to use it. All it does is run
> commands
> > in the end (which it prints out). If you find it to be unmaintainable,
> you
> > are free to refactor it.
> >
> > To the best of my knowledge, there was no documented release process
> before
> > I wrote http://wiki.apache.org/cordova/CuttingReleases. Now that it is
> > documented, feel free to propose changes to it.
> >
> >
> >
> > On Fri, Jul 12, 2013 at 12:49 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> I agree we should clearly scope what coho is for as a group and get
> >> that solid before charging ahead and making it central to automations.
> >>
> >> (Nobody here is against automation but I think the issue Joe brings up
> >> is that we like small clearly defined tools and agreed upon ceremonies
> >> for releases.)
> >>
> >>
> >> On Wed, Jul 10, 2013 at 4:03 PM, Joe Bowser <bo...@gmail.com> wrote:
> >> > Putting this here because it doesn't belong in the tag 3.0.0rc1
> thread:
> >> >
> >> > I agree with Jesse, who doesn't like the magic behind coho.  My main
> >> > issue with coho is that it's not a very maintainable chunk of JS, and
> >> > it appears to be the kitchen sink of automation, full of things that
> >> > just don't fit elsewhere.  It seems to do everything from create bugs,
> >> > tag releases and package them with a single command.  The only thing
> >> > it's consistently failed to do over and over again is actually test
> >> > and produce a quality release of Cordova.
> >> >
> >> > I think that we should really keep our release process the same, and
> >> > that we should talk about what we want coho to do after 3.0.0 is out.
> >> > I don't think there's a lot magical behind coho, but I want to know
> >> > why I would use coho over something like repo, which is another tool
> >> > that handles multiple git repositories that is used in the Android
> >> > Open Source Project.
> >> >
> >> > Anyway, I'm pretty sure there's some concerns over the insertion of
> >> > coho into flows, and I'm wondering if anyone else has any thoughts
> >> > about this.
> >> >
> >> > Joe
> >>
>

Re: Purpose and Scope of COHO (was tag 3.0.0rc1 on Monday the 15th)

[Brian LeRoux <b...@brian.io>]

Well, thats not true, so lets not revise history. We did have a
documented process emergent at CuttingReleases and since its been
refactored by many of us. Same is true for coho.

The difference is the recent refactoring has come about without
discussion or consensus.

The concern here is what precisely we want to do with coho. Before it
just downloaded tags and created a archive. Now it does... lots.

We want to help and work on this. Nobody is going to debate the value
of automation or documentation. Lets not pretend those things didn't
exist before or that the recent changes are 'for the better' without
discussion or consensus.



On Fri, Jul 12, 2013 at 11:40 AM, Andrew Grieve <ag...@chromium.org> wrote:
> I assure you that I did not use magic to create coho. I've found it to be
> useful, but you certainly don't have to use it. All it does is run commands
> in the end (which it prints out). If you find it to be unmaintainable, you
> are free to refactor it.
>
> To the best of my knowledge, there was no documented release process before
> I wrote http://wiki.apache.org/cordova/CuttingReleases. Now that it is
> documented, feel free to propose changes to it.
>
>
>
> On Fri, Jul 12, 2013 at 12:49 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> I agree we should clearly scope what coho is for as a group and get
>> that solid before charging ahead and making it central to automations.
>>
>> (Nobody here is against automation but I think the issue Joe brings up
>> is that we like small clearly defined tools and agreed upon ceremonies
>> for releases.)
>>
>>
>> On Wed, Jul 10, 2013 at 4:03 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > Putting this here because it doesn't belong in the tag 3.0.0rc1 thread:
>> >
>> > I agree with Jesse, who doesn't like the magic behind coho.  My main
>> > issue with coho is that it's not a very maintainable chunk of JS, and
>> > it appears to be the kitchen sink of automation, full of things that
>> > just don't fit elsewhere.  It seems to do everything from create bugs,
>> > tag releases and package them with a single command.  The only thing
>> > it's consistently failed to do over and over again is actually test
>> > and produce a quality release of Cordova.
>> >
>> > I think that we should really keep our release process the same, and
>> > that we should talk about what we want coho to do after 3.0.0 is out.
>> > I don't think there's a lot magical behind coho, but I want to know
>> > why I would use coho over something like repo, which is another tool
>> > that handles multiple git repositories that is used in the Android
>> > Open Source Project.
>> >
>> > Anyway, I'm pretty sure there's some concerns over the insertion of
>> > coho into flows, and I'm wondering if anyone else has any thoughts
>> > about this.
>> >
>> > Joe
>>

Re: Purpose and Scope of COHO (was tag 3.0.0rc1 on Monday the 15th)

[Andrew Grieve <ag...@chromium.org>]

I assure you that I did not use magic to create coho. I've found it to be
useful, but you certainly don't have to use it. All it does is run commands
in the end (which it prints out). If you find it to be unmaintainable, you
are free to refactor it.

To the best of my knowledge, there was no documented release process before
I wrote http://wiki.apache.org/cordova/CuttingReleases. Now that it is
documented, feel free to propose changes to it.



On Fri, Jul 12, 2013 at 12:49 PM, Brian LeRoux <b...@brian.io> wrote:

> I agree we should clearly scope what coho is for as a group and get
> that solid before charging ahead and making it central to automations.
>
> (Nobody here is against automation but I think the issue Joe brings up
> is that we like small clearly defined tools and agreed upon ceremonies
> for releases.)
>
>
> On Wed, Jul 10, 2013 at 4:03 PM, Joe Bowser <bo...@gmail.com> wrote:
> > Putting this here because it doesn't belong in the tag 3.0.0rc1 thread:
> >
> > I agree with Jesse, who doesn't like the magic behind coho.  My main
> > issue with coho is that it's not a very maintainable chunk of JS, and
> > it appears to be the kitchen sink of automation, full of things that
> > just don't fit elsewhere.  It seems to do everything from create bugs,
> > tag releases and package them with a single command.  The only thing
> > it's consistently failed to do over and over again is actually test
> > and produce a quality release of Cordova.
> >
> > I think that we should really keep our release process the same, and
> > that we should talk about what we want coho to do after 3.0.0 is out.
> > I don't think there's a lot magical behind coho, but I want to know
> > why I would use coho over something like repo, which is another tool
> > that handles multiple git repositories that is used in the Android
> > Open Source Project.
> >
> > Anyway, I'm pretty sure there's some concerns over the insertion of
> > coho into flows, and I'm wondering if anyone else has any thoughts
> > about this.
> >
> > Joe
>

Re: Purpose and Scope of COHO (was tag 3.0.0rc1 on Monday the 15th)

[Brian LeRoux <b...@brian.io>]

I agree we should clearly scope what coho is for as a group and get
that solid before charging ahead and making it central to automations.

(Nobody here is against automation but I think the issue Joe brings up
is that we like small clearly defined tools and agreed upon ceremonies
for releases.)


On Wed, Jul 10, 2013 at 4:03 PM, Joe Bowser <bo...@gmail.com> wrote:
> Putting this here because it doesn't belong in the tag 3.0.0rc1 thread:
>
> I agree with Jesse, who doesn't like the magic behind coho.  My main
> issue with coho is that it's not a very maintainable chunk of JS, and
> it appears to be the kitchen sink of automation, full of things that
> just don't fit elsewhere.  It seems to do everything from create bugs,
> tag releases and package them with a single command.  The only thing
> it's consistently failed to do over and over again is actually test
> and produce a quality release of Cordova.
>
> I think that we should really keep our release process the same, and
> that we should talk about what we want coho to do after 3.0.0 is out.
> I don't think there's a lot magical behind coho, but I want to know
> why I would use coho over something like repo, which is another tool
> that handles multiple git repositories that is used in the Android
> Open Source Project.
>
> Anyway, I'm pretty sure there's some concerns over the insertion of
> coho into flows, and I'm wondering if anyone else has any thoughts
> about this.
>
> Joe