You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2011/10/25 15:26:15 UTC
weinre - jira, versions, etc
Couple things about weinre @ Callback
- I just added a "weinre" Component for Callback's jira - I assume that's
ok.
- I suppose that weinre should ship at the same time as the rest of
Callback; the PhoneGap releases, as of late, have been more frequent than
weinre's, so that works for me - I'd be concerned if it wasn't so frequent.
- I suppose weinre should follow the same version # as the rest of Callback;
unfortunately, I'm way ahead - weinre 1.5 is the current version shipping.
Guess that means the first release of Callback will need to be 1.6 or 2.0.
:-) Srsly, I suppose I can downgrade the weinre version, and I'll add a
date where humans can see it so they realize it's current-ish.
- Or are there other options here?
- Probably should still have a way of shipping a point release out-of-band
from the rest of Callback, if some horrible error needs to be fixed.
- Still not completely clear if I can reship the weinre blob with it's
WebKit-y bits and such from apache; I have some homework to do there. There
will always be a lingering issue of LGPL code making it's way into the
WebKit Web Inspector code I reship (today it's all BSD), which kinda throws
a wrench into the gears.
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Tue, Oct 25, 2011 at 10:23, Brian LeRoux <b...@brian.io> wrote:
>
> >> - Still not completely clear if I can reship the weinre blob with it's
> >> WebKit-y bits and such from apache; I have some homework to do there.
> There
> >> will always be a lingering issue of LGPL code making it's way into the
> >> WebKit Web Inspector code I reship (today it's all BSD), which kinda
> throws
> >> a wrench into the gears.
> >
> > I guess we should be able to work out how to handle that.
>
> This is a really particular point of interest that seems to be
> discussed a bit on the legal-discuss mailing list archives. Should
> kick up a conversation there to see what the larger Apache community
> thinks. (I certainly can see many interpretations there.)
>
I spoke with Sam Ruby about this the last time we chatted; I think it's
do-able, I just need to read up on the requirements. Let me do that first
(homework) before starting a discussion.
As I alluded to, even if I could, today, ship the Web Inspector source from
WebKit, it would only be because all that code is BSD today. Tomorrow,
someone could slip some LGPL in there (WebKit allows both BSD and LGPL
code), and then things get trickier. Meaning, I need to allow for the fact
that we may not be able to ship the usable weinre blob directly out of
Apache, some day. But for as long as I can, I'd like to make one available
at Apache.
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Brian LeRoux <b...@brian.io>.
> Note that the release schedule has some effect on how to best track
> issues for a codebase. If we release weinre together with the rest of
> Callback, then having it as a component of the CB project in Jira is
> the right solution. Otherwise, if weinre would follow its own release
> schedule, having a separate WEINRE project in Jira would be easier.
Having it live w/ its own versions and shipping at a slightly
different cadence is fine by me. It certainly stands alone as a
project and, once the dust settles in Nitobi/Adobe land, we'll be
resourcing ppl on Weinre too so I hope we see some velocity increase
there. (Lots of ideas like Aardwolf integration, NodeJS service
rewire, CoffeeScript, etc keep coming up.)
> In any case it might be a good idea to start Callback version numbers
> at 2.0, especially if there'll be some renaming of APIs form PhoneGap
> to Callback.
This is a pretty good point. We didn't plan on shipping a 2.x until
the summer timeframe but this is a rather major change to things.
Interestingly, renamspacing to org.apache.callback.* isn't going to
effect our user-base since we pollute the browser globals with
awesome.
>> - Still not completely clear if I can reship the weinre blob with it's
>> WebKit-y bits and such from apache; I have some homework to do there. There
>> will always be a lingering issue of LGPL code making it's way into the
>> WebKit Web Inspector code I reship (today it's all BSD), which kinda throws
>> a wrench into the gears.
>
> I guess we should be able to work out how to handle that.
This is a really particular point of interest that seems to be
discussed a bit on the legal-discuss mailing list archives. Should
kick up a conversation there to see what the larger Apache community
thinks. (I certainly can see many interpretations there.)
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Fri, Oct 28, 2011 at 07:12, Jukka Zitting <ju...@gmail.com> wrote:
> On Fri, Oct 28, 2011 at 11:54 AM, Patrick Mueller <pm...@gmail.com> wrote:
> ...
>> So, for right now, if all the committers are fine with it, good enough?
>
> Yep. Unless anyone objects I assume we have lazy consensus on this.
Whenever we're ready to cut a new Jira for weinre, presumably at
https://issues.apache.org/jira/browse/WEINRE
and using the name "Apache weinre" as a "name" for the Cordova
subproject, I'm ready to go. I'm also in no big hurry. :-) I cut a
new non-Apache build today of weinre and was offered a "fixed in
version" field in Jira which ... didn't have a version number in it
for weinre. Which would be nice to have, but will also clutter the
version numbers for the rest of Cordova.
Same with the git repo, whenever we get around to setting up the git
repos at Apache (crossing fingers!).
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Fri, Oct 28, 2011 at 07:12, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Fri, Oct 28, 2011 at 11:54 AM, Patrick Mueller <pm...@gmail.com>
> wrote:
> > I'm actually fond of the non-cap version of the name (weinre) vs the
> > first-cap version, but that doesn't seem to be the norm at Apache - I can
> > live with calling it Apache Weinre for titling purposes or whatever.
>
> Non-cap version should be just fine. See [1] for a wide range of
> Apache names with all kinds of capitalization practices.
>
Ah, I looked at that list, but didn't scroll all the way down. So,
lowercase it is!!! "weinre".
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Oct 28, 2011 at 11:54 AM, Patrick Mueller <pm...@gmail.com> wrote:
> I'm actually fond of the non-cap version of the name (weinre) vs the
> first-cap version, but that doesn't seem to be the norm at Apache - I can
> live with calling it Apache Weinre for titling purposes or whatever.
Non-cap version should be just fine. See [1] for a wide range of
Apache names with all kinds of capitalization practices.
> We don't have a PMC yet, right?
Right. An incubating project has a Podling Project Management
Committee (PPMC), composed of project committers and mentors, that for
most purposes functions pretty much like a normal PMC should. See [2]
for the full details.
> So, for right now, if all the committers are fine with it, good enough?
Yep. Unless anyone objects I assume we have lazy consensus on this.
[1] http://projects.apache.org/indexes/alpha.html
[2] http://incubator.apache.org/guides/ppmc.html
BR,
Jukka Zitting
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Oct 27, 2011 at 13:27, Jukka Zitting <ju...@gmail.com>wrote:
> On Tue, Oct 25, 2011 at 6:47 PM, Patrick Mueller <pm...@gmail.com>
> wrote:
> > On Tue, Oct 25, 2011 at 12:40, Jukka Zitting <jukka.zitting@gmail.com
> >wrote:
> >> Separate repository (or in svn a separate folder with its own
> >> {trunk,branches,tags} structure) is the best solution for a codebase
> >> with it's own release cycle. That way you don't have to worry about
> >> the tags of more than one release cycles colliding.
> >
> > OK, why don't we shoot for that direction, independent of how the
> existing
> > runtimes are to be partitioned (and which SCM!).
>
> Sounds good.
>
> > And then, I guess we want to create a new Jira project for weinre. The
> > current Jira for Callback seems to be here:
> >
> > https://issues.apache.org/jira/browse/CB
> >
> > and named "Apache Callback".
> >
> > Should we use "Apache Callback weinre" /
> > https://issues.apache.org/jira/browse/CB-weinre ??
>
> How about simply "Apache Weinre" (or "Apache weinre"?) and put the
> issue tracker at https://issues.apache.org/jira/browse/WEINRE?
>
+1
I'm actually fond of the non-cap version of the name (weinre) vs the
first-cap version, but that doesn't seem to be the norm at Apache - I can
live with calling it Apache Weinre for titling purposes or whatever.
> It's OK for an Apache project to maintain multiple codebases with
> different names. Some of them use the "Apache <Project> <Codebase>"
> naming scheme, but it's also OK (and IMHO simpler) to name them
> "Apache <Codebase>".
>
> The main issue for projects with multiple codebases is just to make
> sure that the entire PMC feels responsible for and can maintain
> oversight over all the codebases of the project.
>
We don't have a PMC yet, right? So, for right now, if all the committers
are fine with it, good enough?
How do you other committers feel about having weinre in a separate codebase
and jira?
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Oct 25, 2011 at 6:47 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 12:40, Jukka Zitting <ju...@gmail.com>wrote:
>> Separate repository (or in svn a separate folder with its own
>> {trunk,branches,tags} structure) is the best solution for a codebase
>> with it's own release cycle. That way you don't have to worry about
>> the tags of more than one release cycles colliding.
>
> OK, why don't we shoot for that direction, independent of how the existing
> runtimes are to be partitioned (and which SCM!).
Sounds good.
> And then, I guess we want to create a new Jira project for weinre. The
> current Jira for Callback seems to be here:
>
> https://issues.apache.org/jira/browse/CB
>
> and named "Apache Callback".
>
> Should we use "Apache Callback weinre" /
> https://issues.apache.org/jira/browse/CB-weinre ??
How about simply "Apache Weinre" (or "Apache weinre"?) and put the
issue tracker at https://issues.apache.org/jira/browse/WEINRE?
It's OK for an Apache project to maintain multiple codebases with
different names. Some of them use the "Apache <Project> <Codebase>"
naming scheme, but it's also OK (and IMHO simpler) to name them
"Apache <Codebase>".
The main issue for projects with multiple codebases is just to make
sure that the entire PMC feels responsible for and can maintain
oversight over all the codebases of the project.
BR,
Jukka Zitting
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Tue, Oct 25, 2011 at 12:40, Jukka Zitting <ju...@gmail.com>wrote:
> On Tue, Oct 25, 2011 at 6:37 PM, Patrick Mueller <pm...@gmail.com>
> wrote:
> > How do multiple codebases in a single project work w/r/t SCM?
> > Same repo, or do projects use multiple repos?
>
> Separate repository (or in svn a separate folder with its own
> {trunk,branches,tags} structure) is the best solution for a codebase
> with it's own release cycle. That way you don't have to worry about
> the tags of more than one release cycles colliding.
>
OK, why don't we shoot for that direction, independent of how the existing
runtimes are to be partitioned (and which SCM!).
And then, I guess we want to create a new Jira project for weinre. The
current Jira for Callback seems to be here:
https://issues.apache.org/jira/browse/CB
and named "Apache Callback".
Should we use "Apache Callback weinre" /
https://issues.apache.org/jira/browse/CB-weinre ??
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Oct 25, 2011 at 6:37 PM, Patrick Mueller <pm...@gmail.com> wrote:
> How do multiple codebases in a single project work w/r/t SCM?
> Same repo, or do projects use multiple repos?
Separate repository (or in svn a separate folder with its own
{trunk,branches,tags} structure) is the best solution for a codebase
with it's own release cycle. That way you don't have to worry about
the tags of more than one release cycles colliding.
BR,
Jukka Zitting
Re: weinre - jira, versions, etc
Posted by Patrick Mueller <pm...@gmail.com>.
On Tue, Oct 25, 2011 at 09:53, Jukka Zitting <ju...@gmail.com>wrote:
> > - I suppose that weinre should ship at the same time as the rest of
> > Callback; the PhoneGap releases, as of late, have been more frequent than
> > weinre's, so that works for me - I'd be concerned if it wasn't so
> frequent.
>
> Either way is fine; shipping weinre with the rest of Callback or
> shipping it separately. There are plenty of Apache projects with
> multiple separate codebases that follow their own release schedules.
>
> Note that the release schedule has some effect on how to best track
> issues for a codebase. If we release weinre together with the rest of
> Callback, then having it as a component of the CB project in Jira is
> the right solution. Otherwise, if weinre would follow its own release
> schedule, having a separate WEINRE project in Jira would be easier.
How do multiple codebases in a single project work w/r/t SCM? Same repo, or
do projects use multiple repos? It probably makes the most sense for weinre
to be separate from the phonegap runtime library bits, meaning a separate
Jira project, and then I would assume a separate repo as well. We might
well have more of these "not part of the runtime" projects in the future, I
guess.
--
Patrick Mueller
http://muellerware.org
Re: weinre - jira, versions, etc
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Oct 25, 2011 at 3:26 PM, Patrick Mueller <pm...@gmail.com> wrote:
> - I just added a "weinre" Component for Callback's jira - I assume that's
> ok.
Sure.
> - I suppose that weinre should ship at the same time as the rest of
> Callback; the PhoneGap releases, as of late, have been more frequent than
> weinre's, so that works for me - I'd be concerned if it wasn't so frequent.
Either way is fine; shipping weinre with the rest of Callback or
shipping it separately. There are plenty of Apache projects with
multiple separate codebases that follow their own release schedules.
Note that the release schedule has some effect on how to best track
issues for a codebase. If we release weinre together with the rest of
Callback, then having it as a component of the CB project in Jira is
the right solution. Otherwise, if weinre would follow its own release
schedule, having a separate WEINRE project in Jira would be easier.
> - I suppose weinre should follow the same version # as the rest of Callback;
> unfortunately, I'm way ahead - weinre 1.5 is the current version shipping.
> Guess that means the first release of Callback will need to be 1.6 or 2.0.
> :-) Srsly, I suppose I can downgrade the weinre version, and I'll add a
> date where humans can see it so they realize it's current-ish.
In any case it might be a good idea to start Callback version numbers
at 2.0, especially if there'll be some renaming of APIs form PhoneGap
to Callback.
> - Still not completely clear if I can reship the weinre blob with it's
> WebKit-y bits and such from apache; I have some homework to do there. There
> will always be a lingering issue of LGPL code making it's way into the
> WebKit Web Inspector code I reship (today it's all BSD), which kinda throws
> a wrench into the gears.
I guess we should be able to work out how to handle that.
BR,
Jukka Zitting